Kubernetes（五） Pod控制器详解

最新推荐文章于 2024-11-08 12:15:52 发布

ZackFairT

最新推荐文章于 2024-11-08 12:15:52 发布

阅读量41

点赞数

文章标签： kubernetes java 容器云原生开发语言

本文链接：https://blog.csdn.net/tsjjjjj/article/details/133007744

版权

Pod控制器详解

本章主要介绍Pod控制器的详细使用

1. Pod控制器介绍

在kubernetes中，按照pod的创建方式可以将其分为2类：

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

什么是Pod控制器？

Pod控制器是管理pod的中间层，使用了pod控制器之后，我们只需要告诉pod控制器，需要多少个pod就可以了。他会创建出满足条件的pod，并确保每个pod处于用户期望的状态。如果pod在运行中出现故障，控制器就会基于指定策略重启或重建pod。

在kubernetes中，有很多种类型的pod控制器，每种都有它适合的场景，常见有：

ReplicationController：比较原始的pod控制器，已经被废弃，由ReplicaSet替代
ReplicaSet：保证指定数量pod运行，并支持pod数量变更，镜像版本变更
Deployment：通过ReplicaSet来控制pod，并支持滚动升级、版本回退
Horizontal Pod Autoscaler：可以根据集群负载自动调整Pod的数量，实现削峰填谷
DaemonSet：在集群中的指定Node上都运行一个副本，一般用于守护进程类的任务
Job：它创建出来的pod只要完成任务就立即退出，用于执行一次性任务
Cronjob：它创建的pod会周期性的执行，用于执行周期性任务
StatefulSet：管理有状态应用

2. ReplicaSet

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

ReplicaSet 如下图所示：

常规配置：

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name:
  namespace:
  labels:
     controller: rs
spec:
  replicas: 3                 #副本数量
  selector:                   #选择器，通过它指定控制器管理哪些 pod 
     matchLabels:
        app: nginx-pod
     matchExpressions:
        - {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定义

部署

示例：

$ cat yamls/pc-replicaset.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: pc-replicaset
  namespace: dev
  labels:
     controller: rs
spec:
  replicas: 3                 #副本数量
  selector:
     matchLabels:
        app: nginx-pod
     matchExpressions:
        - {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

查看创建的rs：

$ kubectl get rs -n dev -o wide
NAME            DESIRED   CURRENT   READY   AGE    CONTAINERS   IMAGES         SELECTOR
pc-replicaset     3                    3               3       115s        nginx        nginx:1.17.1   app=nginx-pod,app in (nginx-pod)

扩缩容

有2种方法：

1. 直接编辑

$ kubectl edit rs -n dev
replicaset.apps/pc-replicaset edited

2. kubescale rs 命令

$ kubectl scale rs pc-replicaset --replicas=4 -n dev
replicaset.apps/pc-replicaset scaled

镜像版本升降级

同样

1. 直接编辑

$ kubectl edit rs -n dev
replicaset.apps/pc-replicaset edited

$ kubectl get rs pc-replicaset -n dev -o wide
NAME            DESIRED   CURRENT   READY   AGE     CONTAINERS   IMAGES         SELECTOR
pc-replicaset   4         4         4       5m39s   nginx        nginx:1.17.2   app=nginx-pod,app in (nginx-pod)

2. kubect set image 命令

$ kubectl set image rs pc-replicaset nginx=nginx:1.17.1 -n dev
replicaset.apps/pc-replicaset image updated

删除

使用kubectl delete 命令可以删除rs以及它管理的pod。Kubernetes在删除rs前，会将rs的replicascaler调整为0，等待所有pod被删除后，再执行rs对象的删除。

如果希望仅仅删除rs对象(保留pod)，可以使用kubectl delete 命令时添加 --cascade=false(不推荐)

当然，删除yaml的形式也是可以的

3. Deployment

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

Deployment主要功能有：

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

Deployment资源主要配置：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: 
  namespace:
  labels:
    controller: deploy
spec:
  replicas: 3
  revisionHistoryLimit: 3                      # 保留历史版本，默认为10
  paused: false                                       # 暂停部署，默认是false
  progressDeadlineSeconds: 600       # 部署超时时间(s)，默认是600
  strategy:                                              # 策略
    type: RollingUpdate                         # 滚动更新策略
    rollingUpdate:                                  # 滚动更新
      maxSurge: 30%                               # 最大额外可以存在的副本数，可以为百分比或整数
      maxUnavailable: 30%                    # 最大不可用状态的Pod的最大值，可以为百分比或整数
  selector:
    matchLabels:
      app: nginx-pod
    matchExpressions:
      - {key: app, operator: In, values: [nginx-pod]}
  template:
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.1
        ports:
        - containerPort: 80

扩缩容

1. kubectl scale deploy pc-deployment --replicas=5 -n dev

2. kubectl edit deploy pc-deployment -n dev

镜像更新

Deployment支持2种镜像更新策略：重建更新和滚动更新(默认)，可以通过strategy选项进行配置。

重建更新就是一次性删除所有老版本pod，然后重建。滚动就是先删一部分，启动一部分，中间状态是新版本与老版本pod均存在，最终只有新版本pod存在。

strategy:       # 指定新的pod替换旧pod的策略，支持2个属性
type:            # 支持2个属性
    Recreate:    # 在创建出新的Pod之前会kill掉所有已存在的pod
    RollingUpdate:     # 滚动更新，kill一部分启动一部分，在更新过程中，存在2个版本的pod
 rollingUpdate:     # 当type为RollingUpdate时生效，用于设置它的参数
     maxUnavailable:    # 用来指定在升级过程中不可用 Pod 的最大数量，默认为25%
     maxSurge:        # 用来指定在升级过程中可以超过期望的Pod的最大数量，默认为 25%

1. 重建更新

测试配置项：

$ cat yamls/pc-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
   name: pc-deployment
   namespace: dev
   labels:
      controller: deploy
spec:
   replicas: 3
   strategy:
      type: Recreate
   selector:
      matchLabels:
          app: nginx-pod
   template:
      metadata:
         labels:
            app: nginx-pod
      spec:
         containers:
         - name: nginx
           image: nginx:1.17.1
           ports:
           - containerPort: 80

变更镜像：

$ kubectl set image deployment pc-deployment nginx=nginx:1.17.2 -n dev
deployment.apps/pc-deployment image updated

$ kubectl get pods -n dev -o wide –w


NAME                             READY   STATUS    R
pc-deployment-7d7dd5499b-5wdlc   1/1     Running   0
pc-deployment-7d7dd5499b-czpzs   1/1     Running   0
pc-deployment-7d7dd5499b-dgvp5   1/1     Running   0
…
pc-deployment-7d7dd5499b-5wdlc   1/1     Terminating
pc-deployment-7d7dd5499b-dgvp5   1/1     Terminating
pc-deployment-7d7dd5499b-czpzs   1/1     Terminating
….
pc-deployment-7bbbd589d5-kkdcs   0/1     Pending    
pc-deployment-7bbbd589d5-kkdcs   0/1     Pending    
pc-deployment-7bbbd589d5-xtw4l   0/1     Pending    
…
pc-deployment-7bbbd589d5-kkdcs   0/1     ContainerCreating
pc-deployment-7bbbd589d5-xtw4l   0/1     ContainerCreating
pc-deployment-7bbbd589d5-ztfbw   0/1     ContainerCreating
…
pc-deployment-7bbbd589d5-xtw4l   1/1     Running    
pc-deployment-7bbbd589d5-ztfbw   1/1     Running    
pc-deployment-7bbbd589d5-kkdcs   1/1     Running

从这个部署记录可以看到，recreate 的策略是一次性全部terminate，然后启动新版本pod。

2. 滚动更新

更改配置：

spec:
   replicas: 3
   strategy:
      type: RollingUpdate
      rollingUpdate:
        maxUnavailable: 25%
        maxSurge: 25%

变更 image 后打印的输出：

$ kubectl get pods -n dev -o wide -w
NAME                                                    READY   STATUS     
pc-deployment-866fdcbd54-9xwrb   0/1     Pending           
pc-deployment-866fdcbd54-9xwrb   0/1     Pending      
pc-deployment-866fdcbd54-9xwrb   0/1     ContainerCreating  
pc-deployment-866fdcbd54-9xwrb   1/1     Running            
pc-deployment-7bbbd589d5-xbnmw   1/1     Terminating        
pc-deployment-866fdcbd54-wjs8n   0/1     Pending            
pc-deployment-866fdcbd54-wjs8n   0/1     Pending            
pc-deployment-866fdcbd54-wjs8n   0/1     ContainerCreating  
pc-deployment-7bbbd589d5-xbnmw   0/1     Terminating        
pc-deployment-7bbbd589d5-xbnmw   0/1     Terminating        
pc-deployment-7bbbd589d5-xbnmw   0/1     Terminating        
pc-deployment-866fdcbd54-wjs8n   1/1     Running            
pc-deployment-7bbbd589d5-2cjvp   1/1     Terminating        
pc-deployment-866fdcbd54-ls9b8   0/1     Pending            
pc-deployment-866fdcbd54-ls9b8   0/1     Pending            
pc-deployment-866fdcbd54-ls9b8   0/1     ContainerCreating  
pc-deployment-7bbbd589d5-2cjvp   0/1     Terminating        
pc-deployment-866fdcbd54-ls9b8   1/1     Running            
pc-deployment-7bbbd589d5-f44sx   1/1     Terminating        
pc-deployment-7bbbd589d5-f44sx   0/1     Terminating        
pc-deployment-7bbbd589d5-2cjvp   0/1     Terminating        
pc-deployment-7bbbd589d5-2cjvp   0/1     Terminating        
pc-deployment-7bbbd589d5-f44sx   0/1     Terminating        
pc-deployment-7bbbd589d5-f44sx   0/1     Terminating

可以看到在过程中是启动一个停止一个。

滚动更新其实是通过2个ReplicaSet 完成的，新版本pod全在新的rs中启动。旧版本pod在旧rs中陆续关闭。旧版本的ReplicaSet 不会被删掉，这是为版本回退而做的设计。

查看rs数量，可以看到第二次实验有2个rs：

$ kubectl get rs -n dev
NAME                       DESIRED   CURRENT   READY   AGE
pc-deployment-7bbbd589d5   0         0         0       32m
pc-deployment-7d7dd5499b   0         0         0       32m
pc-deployment-866fdcbd54   3         3         3       30m

3. 版本回退

Deployment支持版本升级过程中的暂停、继续功能以及版本回退等功能。

kubectl rollout 是版本升级相关的功能，支持的选项有：

status：显示当前升级状态
history：显示升级历史记录
pause：暂停版本升级过程
resume：继续已经暂停的版本升级过程
restart：重启版本升级过程
undo：回滚到上一版本(可以使用--to-version回滚到指定版本)

#查看deployment 升级的当前状态
$ kubectl rollout status deploy pc-deployment -n dev
deployment "pc-deployment" successfully rolled out

# 查看版本升级历史
$ kubectl rollout history deploy pc-deployment -n dev
deployment.apps/pc-deployment
REVISION  CHANGE-CAUSE
1         <none>
2         <none>
3         <none>

这里change-cause为<none> 是因为我们在部署 deployment的时候未添加--record的选项

加上 kubectl apply -f yamls/pc-deployment.yaml --record 后再次尝试的结果：
$ kubectl rollout history deploy pc-deployment -n dev
deployment.apps/pc-deployment
REVISION  CHANGE-CAUSE
1         kubectl apply --filename=yamls/pc-deployment.yaml --record=true
2         kubectl apply --filename=yamls/pc-deployment.yaml --record=true

# 版本回退，若未指定版本号，默认回退到上一版本
$ kubectl rollout undo deploy pc-deployment -n dev
deployment.apps/pc-deployment rolled back

# 其实这个回退版本另一方面又是一个新版本(版本1 现在变为了版本4)：
$ kubectl rollout history deploy pc-deployment -n dev
deployment.apps/pc-deployment
REVISION  CHANGE-CAUSE
2         kubectl apply --filename=yamls/pc-deployment.yaml --record=true
3         kubectl apply --filename=yamls/pc-deployment.yaml --record=true

金丝雀发布

Deployment支持更新过程中的控制，如“暂停(pause)”或继续(resume)”更新操作。

比如有一批新的Pod资源创建完成后立即暂停更新过程。此时，仅存在一部分新版本的应用，主体部分还是旧版本。然后，再筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望方式运行。确定没问题后再继续完成余下Pod资源滚动更新，否则立即回滚更新操作。这就是金丝雀发布。

# 更新deployment版本，并配置暂停deployment
$ kubectl set image deploy pc-deployment nginx=nginx:1.17.4 -n dev && kubectl rollout pause deployment pc-deployment -n dev
deployment.apps/pc-deployment image updated
deployment.apps/pc-deployment paused

# 查看 rs
$ kubectl get rs -n dev
NAME                       DESIRED   CURRENT   READY   AGE
pc-deployment-56f77b8695   1         1         1       18s
pc-deployment-7d7dd5499b   3         3         3       35m

可以看到老版本是仍有3个，新版本仅有1个

# 查看 deployment status
$ kubectl rollout status deploy pc-deployment -n dev
Waiting for deployment "pc-deployment" rollout to finish: 1 out of 3 new replicas have been updated...

后续可以将部分流量先导入到新的rs中进行测试，最终没有任何问题后，可以继续rollout的流程：
$ kubectl rollout resume deployment pc-deployment -n dev
deployment.apps/pc-deployment resumed

$ kubectl rollout status deploy pc-deployment -n dev
Waiting for deployment "pc-deployment" rollout to finish: 1 out of 3 new replicas have been updated...

Waiting for deployment spec update to be observed...
Waiting for deployment spec update to be observed...
Waiting for deployment "pc-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "pc-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "pc-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "pc-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "pc-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "pc-deployment" rollout to finish: 1 old replicas are pending termination...
Waiting for deployment "pc-deployment" rollout to finish: 1 old replicas are pending termination...
deployment "pc-deployment" successfully rolled out

4. Horizontal Pod Autoscaler(HPA)

前面都是通过kubectl scale进行的手动扩容，在生产中更多的是自动化扩展。通过HPA可以实现此续期。

HPA可以获取每个pod利用率，然后和HPA中定义的指标进行对比，同时计算需要伸缩的具体指，最后实现pod数量调整。

HPA与之前的Deployment一样，也属于一种kubernetes 资源对象，它通过追踪分析目标pod的负载变化情况，来确定是否需要针对性地调整目标pod的副本数。

4.1. 安装metrics-server

metrics-server可以用来收集集群中的资源使用情况。

$ git clone -b v0.3.6 https://github.com/kubernetes-incubator/metrics-server
$ cd metrics-server/deploy/1.8+/

# 修改metrics-server-deployment.yaml 文件以下内容
    spec:
      hostNetwork: true
      serviceAccountName: metrics-server
      volumes:
      # mount in tmp so we can safely use from-scratch images and/or read-only containers
      - name: tmp-dir
        emptyDir: {}
      containers:
      - name: metrics-server
        image: registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server-amd64:v0.3.6
        imagePullPolicy: Always
        volumeMounts:
        - name: tmp-dir
          mountPath: /tmp
        args:
        - --kubelet-insecure-tls
        - --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP

# 部署
kubectl apply -f ./

# 验证
$ kubectl get pods -n kube-system
metrics-server-5f55b696bd-xmgkp   1/1     Running   0          2m2s

部署完成后即可查看资源使用情况

# 查看资源使用情况
$ kubectl top node
NAME                                                                     CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
ip-10-0-1-217.cn-north-1.compute.internal    51m                2%            657Mi                  19%
ip-10-0-2-30.cn-north-1.compute.internal      42m                2%            565Mi                  16%

4.2. 准备deployment和service

# 创建deployment
$ kubectl get deploy,pod -n dev
NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nginx-dep   1/1     1            1           61s

NAME                             READY   STATUS    RESTARTS   AGE
pod/nginx-dep-755c49cf64-9hrfn   1/1     Running   0          61s

# 准备service
$ kubectl expose deploy nginx-dep --type=NodePort --port 80 --target-port=80 -n dev
service/nginx-dep exposed

4.3. 部署HPA

$ cat yamls/pc-hpa.yaml
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
    name: pc-hpa
    namespace: dev
spec:
    minReplicas: 1
    maxReplicas: 10
    targetCPUUtilizationPercentage: 3       # 此处用3仅是为了测试
    scaleTargetRef:                                         # 指定要扩展的target deployment
        apiVersion: apps/v1
        kind: Deployment
        name: nginx-dep

# 部署后
$ kubectl get hpa -n dev
NAME     REFERENCE                       TARGETS        MINPODS   MAXPODS   REPLICAS   AGE
pc-hpa   Deployment/nginx-dep   <unknown>/3%   1               10                  0              11s

=> 这里 unknown 表示当前的使用情况，仍在计算中，需要等待一会儿出数据
$ kubectl get hpa -n dev
NAME     REFERENCE              TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
pc-hpa   Deployment/nginx-dep   0%/3%     1         10        1          21m

如果hpa一直报invalid metrics (1 invalid out of 1), first error is: failed to get cpu utilization: missing request for cpu，说明 deploy中没有配置 CPU requests。需要执行下面的命令：
kubectl patch deployment nginx-dep -p='{"spec":{"template":{"spec":{"containers":[{"name":"nginx","resources":{"requests":{"cpu":"200m"}}}]}}}}' -n dev

开始压测，并观察hpa与deploy的结果：

$ kubectl get hpa -n dev -o wide -w
NAME     REFERENCE              TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
pc-hpa   Deployment/nginx-dep   0%/3%     1         10        1          32m
pc-hpa   Deployment/nginx-dep   3%/3%     1         10        1          32m
pc-hpa   Deployment/nginx-dep   9%/3%     1         10        1          33m

$ kubectl get deploy -n dev
NAME        READY   UP-TO-DATE   AVAILABLE   AGE
nginx-dep   3/3     3            3           51m

# 停掉一段时间后
$ kubectl get deploy -n dev
NAME        READY   UP-TO-DATE   AVAILABLE   AGE
nginx-dep   1/1     1            1           63m

5. DaemonSet

DaemonSet类型的控制器可以保证集群中每一台(或指定)节点上都运行一个副本，一般适合于日志收集、节点监控等常见。也就是说，如果一个pod提供的功能是节点级别的(每个节点都需要且仅需要一个)，那么这类Pod就适合使用DaemonSet类型的控制器创建。

DaemonSet控制器的特点：

每当向集群中添加一个节点时，指定的pod副本也会添加到该节点上
每当节点从集群中移除时，pod也就被垃圾回收了

6. Job

Job主要用于负责批量处理(一次处理多个任务)、短暂的、一次性任务。有以下2个特点：

当job创建的pod执行成功结束时，job将记录成功结束后的pod数量
当成功结束的pod达到指定的数量时，job将完成执行

主要属性有：

spec:
  completions: 1                          # 指定job需要成功运行Pods的数量。默认为1
  parallelism: 1                            # 指定job在任一时刻应该并发运行Pods的数量
  activeDeadlineSeconds: 30    # job可运行的时间期限，若是超时仍未结束，则系统会尝试终止
  backoffLimit: 6                          # job失败后重试次数，默认为6 
  manualSelector: true              # 是否使用selector选择器选择pod，默认false
  selector:                        
    matchLabels:
    app: counter-pod
    matchExpressions:
      - {key: app, operator: In, values: [counter-pod]}

7. CronJob(CJ)

Cronjob控制器以Job控制器资源为其管控对象，并借助它管理pod资源对象，Job控制器定义的作业任务在其控制器资源创建之后便立即执行。但CronJob可以以类似于Linux操作系统的方式实现周期性地在某时间点运行。

主要属性有：

spec:
  schedule:                                        # cron格式的作业调度运行时间点，控制任务什么时间执行
    concurrencyPolicy:                     # 并发执行策略，定义前一次作业未完成时是否运行后一次
    failedJobHistoryLimit:                # 为失败的任务执行那个保留的历史记录数，默认为1
    successfulJobHistoryLimit:        # 为成功的任务执行保留的历史记录数，默认为3
    startingDeadlineSeconds:         # 启动作业错误的超时时长
    jobTemplate:                               # job控制器模板，用于为cronjob控制器生成job对象
      metadata:
        spec:
          completions: 1
          parallelism: 1
          activeDeadlineSeconds: 30
          ...
          template:
            metadata:
              labels:
                app: counter-pod
            spec:
              restartPolicy: Never
            containers:
            - name: counter
              ...