14.pod控制器-优快云博客

本文链接：https://blog.youkuaiyun.com/m0_56516338/article/details/132311394

文章目录

pod控制器

pod控制器

概述

Pod控制器及其功用
- Pod控制器，又称之为工作负载（workload），是用于实现管理pod的中间层，确保pod资源符合预期的状态，pod的资源出现故障时，会尝试进行重启，当根据重启策略无效，则会重新新建pod的资源。
pod控制器有多种类型：
- ReplicaSet: 代用户创建指定数量的pod副本，确保pod副本数量符合预期状态，并且支持滚动式自动扩容和缩容功能。
  - ReplicaSet主要三个组件组成：
  1. 用户期望的pod副本数量
  2. 标签选择器，判断哪个pod归自己管理
  3. 当现存的pod数量不足，会根据pod资源模板进行新建
    帮助用户管理无状态的pod资源，精确反应用户定义的目标数量，但是RelicaSet不是直接使用的控制器，而是使用Deployment。
- Deployment：工作在ReplicaSet之上，用于管理无状态应用，目前来说最好的控制器。支持滚动更新和回滚功能，还提供声明式配置。
  - ReplicaSet 与Deployment 这两个资源对象逐步替换之前RC的作用。
- DaemonSet：用于确保集群中的每一个节点只运行特定的pod副本，通常用于实现系统级后台任务。比如ELK服务
  - 特性：服务是无状态的
  - 服务必须是守护进程
- StatefulSet：管理有状态应用
- Job：只要完成就立即退出，不需要重启或重建
- Cronjob：周期性任务控制，不需要持续后台运行

有状态和无状态

有状态：有实时的数据需要存储，集群服务中，把某一台服务器抽离出去，过一段时间再加入到集群中，如果服务集群无法正常工作(相互之间需要数据同步）
无状态：没有实时的数据需要存储，集群服务中，把某一台服务器抽离出去，过一段时间再加入到集群中，如果服务集群还是正常工作(相互之间不用数据同步）

Deployment

部署无状态应用
负责创建和管理ReplicaSet，并维护pod副本数量与期望值相同
负责创建和删除pod资源，多个pod副本是并行执行的，升级策略默认为滚动更新的方式
具有上线部署、副本设定、滚动升级、回滚等功能
提供声明式更新，例如只更新一个新的image
应用场景：web服务

kubectl create deployment test01 --image=nginx:1.14 --port=80 --replicsa=3 --dry-run=client -o yaml > deploy-demo1.yaml

DaemonSet

部署无状态应用
理论上可以在k8s所有node节点上创建相同的pod资源，无论node节点什么时候加入到k8s集群（需要考虑到污点和cordon不可调度的影响）
在DaemonSet资源清单配置中不需要设置pod副本数
https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/

SatefulSet

部署有状态应用
稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现
有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现
有序收缩，有序删除（即从N-1到0）
https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

#前面是无头服务，实现稳定的网络标识
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None       #设置无头服务
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx # 必须匹配 .spec.template.metadata.labels
  serviceName: "nginx"
  replicas: 3     # 默认值是 1
  minReadySeconds: 10 # 默认值是 0
  template:
    metadata:
      labels:
        app: nginx # 必须匹配 .spec.selector.matchLabels
    spec:
      terminationGracePeriodSeconds: 10   #设置pod被删除的等待时间
      containers:
      - name: nginx
        image: registry.k8s.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:    ##内置PVC控制模板
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "my-storage-class"
      resources:
        requests:
          storage: 1Gi

StatefulSet由以下几个部分组成：
- Headless Service（无头服务）：用于为Pod资源标识符生成可解析的DNS记录。
- volumeClaimTemplates（存储卷申请模板）：基于静态或动态PV供给方式为Pod资源提供专有的固定存储。
- StatefulSet：用于管控Pod资源。
为什么要有headless？
- 在deployment中，每一个pod是没有名称，是随机字符串，是无序的。而statefulset中是要求有序的，每一个pod的名称必须是固定的。
- 当节点挂了，重建之后的标识符是不变的，每一个节点的节点名称是不能改变的。
- pod名称是作为pod识别的唯一标识符，必须保证其标识符的稳定并且唯一。
- 为了实现标识符的稳定，这时候就需要一个headless service 解析直达到pod，还需要给pod配置一个唯一的名称。
为什么要有volumeClaimTemplate？
- 大部分有状态副本集都会用到持久存储，比如分布式系统来说，由于数据是不一样的，每个节点都需要自己专用的存储节点。
- 而在 deployment中pod模板中创建的存储卷是一个共享的存储卷，多个pod使用同一个存储卷，而statefulset定义中的每一个pod都不能使用同一个存储卷，由此基于pod模板创建pod是不适应的，这就需要引入volumeClaimTemplate，当在使用statefulset创建pod时，会自动生成一个PVC，从而请求绑定一个PV，从而有自己专用的存储卷。

配置

kubectl create svc clusterip svc-test01 --tcp=80:80 --dry-run=client -o yaml > svc-test01.yaml

apiVersion: v1
kind: Service
metadata:
  name: svc-test01
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: svc-test01
  type: ClusterIP
  clusterIP: None            ##创建无头服务
status:
  loadBalancer: {}

在这里插入图片描述

kubectl create deployment deploy-test --image=nginx:1.14 --port=80 --replicas=3 --dry-run=client -o yaml > deploy-test.yaml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: deploy-test
spec:
  serviceName: svc-test01
  replicas: 3
  selector:
    matchLabels:
      app: deploy-test
  template:
    metadata:
      labels:
        app: deploy-test
    spec:
      containers:
      - image: nginx:1.14
        name: nginx
        ports:
        - containerPort: 80

在这里插入图片描述

#升级
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: deploy-test
spec:
  serviceName: svc-test01
  replicas: 3
  selector:
    matchLabels:
      app: deploy-test
  template:
    metadata:
      labels:
        app: deploy-test
    spec:
      containers:
      - image: nginx:1.15
        name: nginx
        ports:
        - containerPort: 80

在这里插入图片描述

#扩容
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: deploy-test
spec:
  serviceName: svc-test01
  replicas: 6
  selector:
    matchLabels:
      app: deploy-test
  template:
    metadata:
      labels:
        app: deploy-test
    spec:
      containers:
      - image: nginx:1.15
        name: nginx
        ports:
        - containerPort: 80

在这里插入图片描述

#缩容
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: deploy-test
spec:
  serviceName: svc-test01
  replicas: 3
  selector:
    matchLabels:
      app: deploy-test
  template:
    metadata:
      labels:
        app: deploy-test
    spec:
      containers:
      - image: nginx:1.15
        name: nginx
        ports:
        - containerPort: 80

在这里插入图片描述

#绑定PVC
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: deploy-test
spec:
  serviceName: svc-test01
  replicas: 3
  selector:
    matchLabels:
      app: deploy-test
  template:
    metadata:
      labels:
        app: deploy-test
    spec:
      containers:
      - image: nginx:1.15
        name: nginx
        ports:
        - containerPort: 80
        volumeMounts:
        - name: pvc
          mountPath: /usr/share/nginx/html        
  volumeClaimTemplates:
  - metadata:
      name: pvc
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "nfs-client-storageclass"
      resources:
        requests:
          storage: 2Gi

在这里插入图片描述

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gnBKDxhv-1692147332833)(E:\Typora\images\image-20230815192717264.png)]$

Job

job分为普通任务（Job）和定时任务（CronJob）
常用于运行那些仅需要执行一次的任务

apiVersion: batch/v1 
kind: Job
metadata:
  name: job-test01
  namespace: default
spec:
  template:
    spec:
      containers:
      - name: busybox
        image: busybox
        imagePullPolicy: IfNotPresent
        command:
        - /bin/sh
        - -c
        - "sleep 10; exit 0"
      restartPolicy: Never
  backoffLimit: 2

.spec.backoffLimit用于设置job失败后进行重试的次数，默认值为6。默认情况下，除非Pod失败或容器异常退出，Job任务将不间断的重试，此时Job遵循 


.spec.backoffLimit上述说明。一旦.spec.backoffLimit达到，作业将被标记为失败

在这里插入图片描述

apiVersion: batch/v1 
kind: Job
metadata:
  name: job-test01
  namespace: default
spec:
  template:
    spec:
      containers:
      - name: busybox
        image: busybox
        imagePullPolicy: IfNotPresent
        command:
        - /bin/sh
        - -c
        - "sleep 10; exit 1"
      restartPolicy: Never
  backoffLimit: 2

在这里插入图片描述

kubectl describe jobs.batch job-test01

在这里插入图片描述

CronJob

周期性任务，像Linux的Crontab一样。

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: cronjob-test01
  namespace: default
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: busybox
            image: busybox
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - "date; echo 123"
          restartPolicy: Never
      backoffLimit: 2

在这里插入图片描述

concurrencyPolicy: Allow			
#声明了 CronJob 创建的任务执行时发生重叠如何处理（并发性规则仅适用于相同 CronJob 创建的任务）。spec仅能声明下列规则中的一种:
                                         
●Allow (默认)：CronJob 允许并发任务执行。
●Forbid：CronJob 不允许并发任务执行；如果新任务的执行时间到了而老任务没有执行完，CronJob 会忽略新任务的执行。
●Replace：如果新任务的执行时间到了而老任务没有执行完，CronJob 会用新任务替换当前正在运行的任务。


startingDeadlineSeconds: 15		
#它表示任务如果由于某种原因错过了调度时间，开始该任务的截止时间的秒数。过了截止时间，CronJob 就不会开始任务，且标记失败.如果此字段未设置，那任务就没有最后期限。

 successfulJobsHistoryLimit: 3		
 #要保留的成功完成的任务数（默认为3）
  
  
 failedJobsHistoryLimit：1         
 #要保留多少已完成和失败的任务数（默认为1）
 
suspend：true                    
#如果设置为 true ，后续发生的执行都会被挂起。 这个设置对已经开始的执行不起作用。默认是 false。

schedule: '*/1 * * * *'			
#必需字段，作业时间表。在此示例中，作业将每分钟运行一次


jobTemplate:					
#必需字段，作业模板。这类似于工作示例

总结

Pod 的 5 种控制器：
1. Deployment
  - 部署无状态应用
  - 负责创建和管理 ReplicaSet，维护 Pod 副本数量与期望值相同
  - 负责创建和删除 Pod 资源，多个 Pod 副本时是并行执行的，升级策略默认为滚动更新的方式
2. DaemonSet
  - 部署无状态应用
  - 理论上可以在 K8S 所有 Node 节点上创建相同的 Pod 资源，无论 Node 节点什么时候加入到 K8S 集群（需要考虑到污点和cordon不可调度的影响）
  - 在 DaemonSet 资源清单配置中不需要设置 Pod 副本数（replicas）
3. StatefulSet
  - 部署有状态应用
  - 每个 Pod 名称都是唯一且固定不变的
  - 每个 Pod 都可以有自己专属的持久化存储（基于PVC模板 volumeClaimTemplates 绑定PV实现的）
  - 需要提前创建一个 Headless Service 资源（无头服务，ClusterIP可以为None），并在 StatefulSet 资源清单配置中使用 serviceName 字段关联 Headless Service
  - 可以在 Pod 内通过 <Pod名称>.<svc名称>.<命名空间>[.svc.cluster.local] 格式解析出 PodIP。（基于 Headless Service 和 CoreDNS 实现的）
  - 创建、滚动升级、扩容、缩容 Pod 都是有序进行的（默认为串行执行的，基于字段 .spec.podManagementPolicy: OrderedReady 实现的；字段值若设置为 Parallel，则为并行执行）
  - 创建、扩容是升序执行的（顺序为 Pod 标识号从 0 到 n-1）
  - 滚动升级、缩容是倒序执行的（顺序为 Pod 标识号从 n-1 到 0）
  - Service 资源的类型： 4个常规类型 + 1个特殊类型
  - ClusterIP NodePort LoadBalancer ExternalName + Headless Service
4. Job
  - 部署一次性的短期任务的Pod资源，Pod不会持久运行
  - 任务正常完成后Pod容器会正常退出并不会再重启（restartPolicy需要设置为Never或OnFailure），且也不会重建Pod
  - 如果任务执行异常导致Pod容器异常退出，会重建Pod重试任务，重试次数受 backoffLimit 字段配置影响（默认为任务失败后重试6次）
5. CronJob
  - 部署周期性的短期任务的Pod资源，Pod不会持久运行
  - 任务正常完成后Pod容器会正常退出并不会再重启（restartPolicy需要设置为Never或OnFailure），且也不会重建Pod
  - 使用必配字段 schedule 设置任务执行的周期表，格式为 “分时日月周”