一、Pod 控制器

1、pod 控制器简介

Pod控制器,又称之为工作负载(workload),是用于实现管理pod的中间层,确保pod资源符合预期的状态,pod的资源出现故障时,会尝试进行重启,当根据重启策略无效,则会重新新建pod的资源

在kubernetes中,按照pod的创建安方式可以将其分为两类:

  • **自主式pod:**kubernetes直接创建出来的pod,这种pod删除后就没有了,也不会重建
  • **控制器创建的pod:**通过控制器创建的pod,这种pod删除了之后还会自动重建

2、pod控制器的状态

有状态:
1.实例之间有差别,每个实例都有自己的独特性,元数据不同,例如etcd,zookeeper
2.实例之间不对等的关系,以及依靠外部存储的应用

无状态:
1.deployment认为所有的pod都是一样的
2.不用考虑顺序的要求
3.不用考虑在哪个node节点上运行
4.可以随意扩容和缩容

常规service和无头服务的区别:

**service:**一组pod访问策略,提供cluster-ip集群之间通讯,还提供负载均衡和服务发现
**Headless service:**无头服务,不需要cluster-ip,直接绑定具体的pod的IP

2、pod控制器有多种类型

1.ReplicaSet

代用户创建指定数量的pod副本数量,确保pod副本数量符合预期状态,并且支持滚动式自动扩容和缩容功能。

ReplicaSet主要三个组件组成:
(1)用户期望的pod副本数量
(2)标签选择器,判断哪个pod归自己管理
(3)当现存的pod数量不足,会根据pod资源模板进行新建
帮助用户管理无状态的pod资源,精确反应用户定义的目标数量,但是ReplicaSet不是直接使用的控制器,而是使用Deployment

2.Deployment

工作在ReplicaSet之上,用于管理无状态应用,目前来说最好的控制器。支持滚动更新和回滚功能,还提供声明式配置

ReplicaSet 与Deployment 这两个资源对象逐步替换之前RC的作用

3.DaemonSet

用于确保集群中的每一个节点只运行特定的pod副本,通常用于实现系统升级后台任务。比如ELK服务

  • 特性:服务是无状态的
  • 服务必须是守护进程

4.StatefulSet:

管理有状态应用(是有序的创建pod,删除时是倒叙删除,它们都是串行执行的)

5.Job

只要完成就立即退出,不需要重启或重建

6.Cronjob

周期性任务控制,不需要持续后台运行

3 、Pod与控制器之间的关系

  1. controllers:在集群上管理和运行容器的 pod 对象,pod通过label-selector 相关联
  2. Pod通过控制器实现应用的运维,如伸缩,升级等

img

二、Deployment(无状态)

为了更好的解决服务编排的问题,kubernetes在v1.2版本开始,引入了Deployment控制。值得一提的是,这种控制器并不直接管理pod,而是通过管理 ReplicaSet 来间接管理Pod,即:Deployment管理ReplicaSet,ReplicaSet管理Pod。所以Deployment比ReplicaSet功能更加强大

img

Deployment主要功能有下面几个:

支持ReplicaSet的所有功能
支持发布的停止、继续
支持版本滚动升级和版本回退

特点:

部署无状态应用,只关心数量,不论角色等,称无状态
管理Pod和ReplicaSet
具有上线部署、副本设定、滚动升级、回滚等功能
提供声明式更新,例如只更新一个新的image

应用场景:应用场景: Nginx, 微服务,jar

1、Deployment的资源清单文件

apiVersion: apps/v1 # 版本号
kind: Deployment # 类型       
metadata: # 元数据
  name: # rs名称 
  namespace: # 所属命名空间 
  labels: #标签
    controller: deploy
spec: # 详情描述
  replicas: 3 # 副本数量
  revisionHistoryLimit: 3 # 保留历史版本,默认是10,用于版本回退时使用
  paused: false # 暂停部署,默认是false,即deployment创建好后是否立即开始部署和创建pod
  progressDeadlineSeconds: 600 # 部署超时时间(s),默认是600
  strategy: # 策略
    type: RollingUpdate # 滚动更新策略
    rollingUpdate: # 滚动更新
      maxSurge: 30% # 最大额外可以存在的副本数,可以为百分比,也可以为整数
      maxUnavailable: 30% # 最大不可用状态的 Pod 的最大值,可以为百分比,也可以为整数
  selector: # 选择器,通过它指定该控制器管理哪些pod
    matchLabels:      # Labels匹配规则
      app: nginx-pod
    matchExpressions: # Expressions匹配规则
      - {key: app, operator: In, values: [nginx-pod]}
  template: # 模板,当副本数量不足时,会根据下面的模板创建pod副本
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.1
        ports:
        - containerPort: 80
        
#上述资源清单可以分为三部分,spec以上是deployment信息;spec的replicas到selector是副本数量、镜像更新策略、标签选择器(会和下面的Pod做关联)等;template及以下是Pod配置信息
----------------------------------------------------------------------------------------------------------

#示例:创建deployment 
vim nginx-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx	
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.4
        ports:
        - containerPort: 80

#创建资源       
kubectl create -f nginx-deployment.yaml

#查看创建的pod资源、控制器和副本
kubectl get pods,deploy,rs

查看控制器配置

kubectl edit deployment/nginx-deployment

查看历史版本

kubectl rollout history deployment/nginx-deployment

三、ReplicaSet(RS)

ReplicaSet的主要作用是保证一定数量的pod正常运行,它会持续监听这些Pod的运行状态,一旦Pod发生故障,就会重启或重建。同时它还支持对pod数量的扩缩容和镜像版本的升降级

img

1、ReplicaSet的资源清单文件

apiVersion: apps/v1 # 版本号
kind: ReplicaSet # 类型       
metadata: # 元数据
  name: # rs名称 
  namespace: # 所属命名空间 
  labels: #标签
    controller: rs
spec: # 详情描述
  replicas: 3 # 副本数量
  selector: # 选择器,通过它指定该控制器管理哪些pod
    matchLabels:      # Labels匹配规则
      app: nginx-pod
    matchExpressions: # Expressions匹配规则
      - {key: app, operator: In, values: [nginx-pod]}
  template: # 模板,当副本数量不足时,会根据下面的模板创建pod副本
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.1
        ports:
        - containerPort: 80

在这里面,需要新了解的配置项就是spec下面几个选项:

  • **replicas:**指定副本数量,其实就是当前rs创建出来的pod的数量,默认为1
  • **selector:**选择器,它的作用是建立pod控制器和pod之间的关联关系,采用的Label Selector机制。在pod模板上定义label,在控制器上定义选择器,就可以表明当前控制器能管理哪些pod了
  • **template:**模板,就是当前控制器创建pod所使用的模板板,里面其实就是前一章学过的pod的定义

2、创建ReplicaSet

vim pc-replicaset.yam

apiVersion: apps/v1
kind: ReplicaSet 
metadata:
  name: pc-replicaset
  namespace: dev
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-pod
  template:
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.1

创建rs

# 创建rs
[root@master ~]# kubectl create -f pc-replicaset.yaml
replicaset.apps/pc-replicaset created

--------------------------------------------------------
# 查看rs
# DESIRED:期望副本数量
# CURRENT:当前副本数量
# READY:已经准备好提供服务的副本数量
--------------------------------------------------------

[root@master ~]# kubectl get rs pc-replicaset -n dev -o wide
NAME			DESIRED	CORRENT	READY	AGE		CONTAINERS	IMAGES			SELECTOR	
pc-replicaset	3		3		3		22s		nginx		nginx:1.17.1	app=nginx-pod

---------------------------------------------------------------------
# 查看当前控制器创建出来的pod
# 这里发现控制器创建出来的pod的名称是在控制器名称后面拼接了-xxxx随机码
---------------------------------------------------------------------

[root@master ~]# kubectl get pod -n dev
NAME					READY		STATUS		RESTARTS	AGE
pc-replicaset-6vmvt		1/1			Running		0			54s
pc-replicaset-fm8f		1/1			Running		0			54s
pc-replicaset-snrk		1/1			Running		0			54s

四、SatefulSet(有状态)

稳定的持久化存储,即 Pod 重新调度后还是能访问到相同的持久化数据,基于 PVC 来实现

稳定的网络标志,即 pod 重新调度后其 PodName 和 HostName 不变,基于 Headless Service(即没有 Cluster IP 的 Service)来实现有序部署,有序扩展,即 Pod 是有顺序的,在部署或者扩展的时候要依据定义的顺序依次进行(即从 0 到 N-1,在下一个 Pod 运行之前所有之前的 Pod 必须都是 Running 和 Ready 状态),基于 initcontainers(初始化容器) 来实现,也可有序收缩,有序删除(即从N-1到0)

简单描述:

  • 1.部署有状态应用
  • 2.解决Pod独立生命周期,保持Pod启动顺序和唯一性
  • 3.稳定,唯一的网络标识符,持久存储(例如:etcd配置文件,节点地址发生变化,将无法使用)
  • 4.有序,优雅的部署和扩展、删除和终止(例如:mysql主从关系,先启动主,再启动从)
  • 5.有序,滚动更新

应用场景:数据库,Mysql主从,zookeeper集群,etcd集群

无论是Kube-dns还是CoreDNS,基本原理都是利用监听 Kubernetes 的 Service 和Pod,生成 DNS 记录,然后通过重新配置 Kubelet 的 DNS 选项让新启动的 Pod 使用 Kube-dns 或 CoreDNS 提供的

上面也写过,那就再重复一边是重点

1.有状态与无状态的区别

*无状态*

  • deployment认为所有的pod都是一样的
  • 不用考虑顺序的要求
  • 不用考虑在哪个node节点上运行
  • 可以随意扩容和缩容

*有状态*

  • 实例之间有差别,每个实例都有自己的独特性,元数据不同,例如etcd,zookeeper
  • 实例之间不对等的关系,以及依靠外部存储的应用

2.常规service和无头服务区别

  • service:一组Pod访问策略,提供cluster-IP群集之间通讯,还提供负载均衡和服务发现。
  • Headless service :无头服务,不需要cluster-IP,直接绑定具体的Pod的IP,也可用于为Pod资源标识符生成可解析的DNS记录

为什么要有headless?

在deployment中,每一个pod是没有名称,是随机字符串,是无序的。而statefulset中是要求有序的,每一个pod的名称必须是固定的。当节点挂了,重建之后的标识符是不变的,每一个节点的节点名称是不能改变的。pod名称是作为pod识别的唯一标识符,必须保证其标识符的稳定并且唯一,为了实现标识符的稳定,这时候就需要一个headless service 解析直达到pod,还需要给pod配置一个唯一的名称

服务发现的概念:就是应用服务之间相互定位的过程

应用场景:

动态性强:Pod会飘到别的node节点
**更新发布频繁:**互联网思维小步快跑,先实现再优化,老板永远是先上线再慢慢优化,先把idea变成产品挣到钱然后再慢慢一点一点优化
支持自动伸缩:一来大促,肯定是要扩容多个副本

K8S里服务发现的方式—DNS,使K8S集群能够自动关联Service资源的“名称”和“CLUSTER-IP”,从而达到服务被集群自动发现的目的

实现K8S里DNS功能的插件:

**skyDNS:**Kubernetes 1.3之前的版本
**kubeDNS:**Kubernetes 1.3至Kubernetes 1.11
**CoreDNS:**Kubernetes 1.11开始至今

3.Service类型

  • Cluster_IP
  • NodePort:使用Pod所在节点的IP和其端口范围
  • Headless
  • HostPort(ingress、kubesphere)
  • LoadBalance负载均衡(F5硬件负载均衡器)

PS:k8s暴露方式主要就3种:ingress loadbalance(SLB/ALB K8S集群外的负载均衡器、Ng、harproxy、KONG、traefik等等) service

4.示例

vim nginx-service.yaml
 
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
  labels:
    app: nginx
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: nginx
    
kubectl create -f nginx-service.yaml

kubectl get svc

#在node节点操作,查看集群间通讯
curl podip地址

5.headless方式

因为Pod动态IP地址,所以常用于绑定DNS访问—来尽可能固定Pod的位置

vim headless.yaml
 
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
 
kubectl apply -f headless.yaml
kubectl get svc

#再定义一个pod
vim dns-test.yaml
 
apiVersion: v1
kind: Pod
metadata:
  name: dns-test
spec:
  containers:
  - name: busybox
    image: busybox:1.28.4
    args:
    - /bin/sh
    - -c
    - sleep 36000
  restartPolicy: Never
  
  
#验证dns解析
kubectl create -f dns-test.yaml
kubectl get svc


#解析kubernetes和nginx-svc名称
kubectl exec -it dns-test sh



#创建StatefulSet.yaml文件
vim statefulSet.yaml
 
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1beta1  
kind: StatefulSet  
metadata:
  name: nginx-statefulset  
  namespace: default
spec:
  serviceName: nginx  
  replicas: 3  
  selector:
    matchLabels:  
       app: nginx
  template:  
    metadata:
      labels:
        app: nginx  
    spec:
      containers:
      - name: nginx
        image: nginx:latest  
        ports:
        - containerPort: 80 
 
 
# 清理所有pod
kubectl delete -f --all
kubectl create -f statefulSet.yaml
kubectl get pods,svc

#解析pod的唯一域名和自身的ip
kubectl apply -f dns-test.yaml
 
kubectl exec -it dns-test sh
 
nslookup nginx-statefulset-0.nginx
nslookup nginx-statefulset-1.nginx
nslookup nginx-statefulset-2.nginx

总结

StatefulSet与Deployment区别

无状态服务对象-Deployment: 用于部署无状态的服务,一般用于管理维护企业内部无状态的微服务,比如configserver、zuul、springboot。其可以管理多个副本的Pod实现无缝迁移、自动扩容缩容、自动灾难恢复、一键回滚等功能。其服务部署结构模型是Deployment->ReplicaSet->Pod;Deployment工作在ReplicaSet之上,用于管理无状态应用,通过“控制器模式”,来操作 ReplicaSet 的个数和属性,进而实现“水平扩展 / 收缩”和“滚动更新”这两个编排动作,也就是说,Deployment 控制器实际操纵的是ReplicaSet 对象,而不是 Pod 对象

有状态服务-statefuleset: 用于管理有状态应用程序的工作负载API对象。比如在生产环境中,可以部署ElasticSearch集群、MongoDB集群或者需要持久化的RabbitMQ集群、Redis集群、Kafka集群和ZooKeeper集群等,其解决了有状态服务使用容器化部署的一个问题,保证pod的hostname重启/重建后不变,通过hostname维护关联数据。其服务部署结构模型是Statefulset->ReplicaSet->Pod;Statefulset也是工作在Replicaset之上,用于管理有状态服务。有状态部署的产品设置通无状态部署

五、DaemonSet(守护进程集)

daemonset确保全部(或者一些)node上运行一个pod副本,当有node加入集群时,也会为他们新增一个pod。当有node从集群移除时,这些pod也会被回收。删除daemonset将会删除它创建的所有的pod

使用 DaemonSet 的一些典型用法:

  • 运行集群存储 daemon,例如在每个 Node 上运行 glusterd、ceph(存储)
  • 在每个 Node 上运行日志收集 daemon,例如fluentd、logstash
  • 在每个 Node 上运行监控 daemon,例如 Prometheus Node Exporter、collectd、Datadog 代理、New Relic 代理,或 Ganglia gmond

应用场景:Agent

应用场景:运行日志收集,监控,集群存储daemon

  • 在每一个Node上运行一个Pod
  • 新加入的Node也同样会自动运行一个Pod,但会受到污点影响
vim daemonSet.yaml
 
apiVersion: apps/v1
kind: DaemonSet 
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.4
        ports:
        - containerPort: 80

DaemonSet会在每个node节点都创建一个Pod

kubectl apply -f daemonSet.yaml
kubectl get pods

六、Job

Job分为普通任务(Job)和定时任务(CronJob)

常用于运行那些仅需要执行一次性执行

应用场景:数据库迁移、批处理脚本、kube-bench扫描离线数据处理,视频解码等业务

示例:

用job控制器类型创建资源,执行算圆周率的命令,保持后2000位,创建过程等同于在计算
,重试次数默认是6次,修改为4次,当遇到异常时Never状态会重启,所以要设定次数

vim job.yaml 
 
apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl:5.34.0    #不要用最新版本
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4   #重试次数默认是6次,修改为4次
  
#参数解释
#.spec.template.spec.restartPolicy该属性拥有三个候选值:OnFailure,Never和Always。默认值为Always。它主要用于描述Pod内容器的重启策略。在Job中只能将此属性设置为OnFailure或Never,否则Job将不间断运行

#.spec.backoffLimit用于设置job失败后进行重试的次数,默认值为6。默认情况下,除非Pod失败或容器异常退出,Job任务将不间断的重试,此时Job遵循 .spec.backoffLimit上述说明。一旦.spec.backoffLimit达到,作业将被标记为失败

在node1节点下载perl镜像,因为镜像比较大所以提前下载好

docker pull perl

在master操作

#创建
kubectl apply -f job.yaml

#查看到完成状态
kubectl get pod

#结果输出到控制台
kubectl logs pi-6tjtp

#清除job资源
kubectl get job
kubectl delete -f job.yaml

七、CronJob

  • 周期性任务,像Linux的Crontab一样
  • 周期性任务

应用场景:通知,备份

cronjob其它可用参数的配置

spec:
  concurrencyPolicy: Allow			#要保留的失败的完成作业数(默认为1)
  schedule: '*/1 * * * *'			#作业时间表。在此示例中,作业将每分钟运行一次
  startingDeadlineSeconds: 15		#pod必须在规定时间后的15秒内开始执行,若超过该时间未执行,则任务将不运行,且标记失败
  successfulJobsHistoryLimit: 3		#要保留的成功完成的作业数(默认为3)
  terminationGracePeriodSeconds: 30	#job存活时间 默认不设置为永久
  jobTemplate:						#作业模板。这类似于工作示例

示例:

每隔一分钟输出一条信息,打印hello

vim cronjob.yaml
 
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: lcdb
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: lcdb
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo lcdb from the Kubernetes cluster
          restartPolicy: OnFailure
          
kubectl apply -f cronjob.yaml
 
kubectl get pod
kubectl get cronjob

#清除cronjob资源
kubectl delete -f cronjob.yaml

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐