hydd的Linux笔记Day74

这篇Linux笔记主要介绍了Kubernetes(K8s)中的服务管理,包括Service的类型、代理模式、Headless服务以及发布服务的方式如NodePort、LoadBalancer和Ingress。此外,还详细讲解了存储卷管理,如ConfigMap、持久化存储卷(PV/PVC)、emptyDir、hostPath和NFS共享存储。最后,通过案例展示了服务和存储卷的实战应用。
摘要由CSDN通过智能技术生成

Day74

service服务管理

服务基础

会变化的资源

会变化的Pod资源,当发现某一个pod不能使用的时候RS会在其它机器上再创建一个相同的Pod,以及对应的容器

service服务

会变化的pod给我们访问带来很多不便

sevice就是解决办法之一

service会创建一个cluster ip,这个地址对应资源地址,不管pod如何变化,service总能找到对应的pod,且cluster ip保持不变,如果pod对应着多个容器,service会自动在多个容器实现负载均衡

service通过port,nodePort,targetPort将访问请求最终映射到Pod的容器内部服务上

service的三种端口

targetPort: 是pod上容器服务监听端口,例如apache服务的端口是80

port:service暴露在cluster ip上的端口,是提供给集群内部客户访问service的入口,供集群内部服务访问使用

nodePort:是提供给集群外部客户访问service入口的一种方式,是集群外访问集群内资源的一种方式

使用命令行也可以定义服务

kubectl expose 资源类型 资源名称 --port=服务端口 --target-port=容器端口 --name-service的名字

服务自动发现

cluster-ip是集群分配的服务ip,供集群访问,在集群内部也可以通过服务的名称访问,服务的名称是通过coredns解析的,每个服务在创建的过程中都会自动完成注册

服务名称:<服务名称>.<名称空间>.svc.cluster.local

查询服务可以使用

​ kubectl get service

访问服务:集群内可以直接访问服务,但集群外无法访问服务

服务的代理模式

代理模式的种类

K8s v1.0服务支持userspace 代理模式

k8s v1.1 服务支持 iptable 代理模式

k8是 v1.8 服务支持ipvs 代理模式

在k8s v1.2 中kube-proxy的iptable模式成为默认设置,现在默认使用ipvs,如果不能满足要求回退至iptables模式

img

img

img

服务类型

service允许指定一个Type类型,默认是Cluster IP

cluster IP:通过集群的内部IP暴露服务,服务只能在集群内部访问,这样是默认的ServiceType

NodePort:通过每个Node上的IP和静态端口暴露服务。NodePort服务会路由到Cluster IP服务

LoadBalancer:使用云提供商的负载均衡器可以路由到iNodePort服务和Cluster IP 服务。

ExternalName:容器可以使用自定义的域名访问外网

Headless服务

有时不需要或者不想要负载均衡,以及单独的service IP。遇到这种情况,我们就可以创建Headless服务

Headless服务会把ip通过多个A记录的形式解析到具体的容器IP上面,多用于有状态的服务。

发布服务

外部服务

对外发布服务

有时我们需要集群内部和集群外部的服务能够实现互访

LoadBalancer:使用外部的云服务(需要支持,externallPs)

nodePort: 基于端口对外提供服务

lngress:使用ingress控制器

nodePort发布服务

详见后面的案例

访问nodePort

简单的nodePort也可以命令直接创建

kuberctl expose 资源类型 资源名称 --type-=Node --port=80 --target-port=80 --name=服务名称

nodePort开放的端口所有node均能访问

Ingress介绍

Ingress是什么

ingress公开了从集群外部到集群内service路由

可以将ingress配置为提供服务外部可访问的URL、负载均衡流量

ingress控制器通常由负载均衡器来实现

必须具有ingress控制器才能满足ingress的要求,仅创建资源无效。

img

ingress安装配置

ingress控制器安装

详见后面的案例

存储卷管理

ConfigMap

概述

configMap是在pod中映射的一种方式,允许你将配置文件与镜像文件分离,使得容器化的应用程序具有可移植性

为什么要使用ConfigMap

在日常生活中经常要修改各种配置文件的参数,数据库的地址用户名密码等,这些操作在容器内非常麻烦、POD在重启或者迁移的时候又会恢复到初始状态,使用ConfigMap就可以解决这样的问题。

持久化部署

为什么需要持久化存储卷

磁盘上的文件生命周期是短暂的,这就使得在容器中运行重要应用的时候就会出现一些问题。首先,当容器崩溃时kubectl会重启它,但是容器中的文件将丢失——容器以干净的状态重新启动。其次在Pod中同时运行多个容器时,这些容器之间通常需要共享文件。kubernetes中的Volume抽象就很好的解决了这些问题。

img

emptyDir

emptyDir是最基础的Volume类型,用于存储临时数据的简单空目录。如果Pod设置了emptyDir类型Volume,Pod被分配到Bode上的时候,会创建emptyDir,只要Pod运行在Node上,emptyDir都会存在(容器挂掉不会导致emptyDir丢失数据),

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值