Kubernetes Pod 详解（三）—— Pod 控制器

原创已于 2025-04-10 15:55:08 修改

· 1k 阅读

9 ·

版权

文章标签：

#kubernetes #容器 #云原生 #运维 #linux #笔记

于 2025-03-16 15:02:12 首次发布

一、介绍

Pod是kubernetes的最小管理单元，在kubernetes中，按照pod的创建方式可以将其分为两类：

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

什么是Pod控制器？

Pod 控制器是管理pod的中间层，使用 Pod 控制器之后，只需要告诉 Pod 控制器，想要多少个什么样的Pod 就可以了，它会创建出满足条件的 Pod 并确保每一个 Pod 资源处于用户期望的目标状态。如果Pod 资源在运行中出现故障，它会基于指定策略重新编排 Pod 。

在 kubernetes 中，有很多类型的 pod 控制器，每种都有自己的适合的场景，常见的有下面这些：

ReplicationController ：比较原始的 pod 控制器，已经被废弃，由 ReplicaSet 替代

ReplicaSet（RS）：

        保证副本数量一直维持在期望值，并支持pod 数量扩缩容，镜像版本升级

Deployment（Deploy）：

        通过控制ReplicaSet 来控制 Pod ，并支持滚动升级、回退版本

Horizontal Pod Autosca（PHA）：

        可以根据集群负载自动水平调整Pod 的数量，实现削峰填谷

DaemonSet（DS）：

        在集群中的指定Node 上运行且仅运行一个副本，一般用于守护进程类的任务

Job ：

        它创建出来的pod 只要完成任务就立即退出，不需要重启或重建，用于执行一次性任务

Cronjob（CJ）：

        它创建的Pod 负责周期性任务控制，不需要持续后台运行

StatefulSet（有状态）：管理有状态应用

总体来说， K8S 有五种控制器，分别对应处理无状态应用、有状态应用、守护型应用和批处理应用

二、ReplicaSet（RS）

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

ReplicaSet 的资源清单文件：

apiVersion: apps/v1 # 版本号
kind: ReplicaSet # 类型       
metadata: # 元数据
  name: # rs名称 
  namespace: # 所属命名空间 
  labels: #标签
    controller: rs
spec: # 详情描述
  replicas: 3 # 副本数量  （扩缩容：只需要修改 RS副本数目就行）
  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

扩缩容和镜像升级修改之后，需要执行：

[root @master ~ ] # kubectl edit rs pc-replicaset -n dev

replicaset.apps / pc-replicaset edited

#然后查看

[root @master ~ ] # kubectl get rs -n dev -o wide

二、Deployment（Dploy）

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

Deployment主要功能有下面几个：

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

Deployment的资源清单文件：

apiVersion: apps/v1 # 版本号
kind: Deployment # 类型       
metadata: # 元数据
  name: # rs名称 
  namespace: # 所属命名空间 
  labels: #标签
    controller: deploy
spec: # 详情描述
  replicas: 3 # 副本数量
  revisionHistoryLimit: 3 # 保留历史版本
  paused: false # 暂停部署，默认是false
  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

1.扩缩容

# 变更副本数量3为5个
[root@master ~]# kubectl scale deploy pc-deployment --replicas=5 -n dev
deployment.apps/pc-deployment scaled
# 查看deployment
[root@master ~]# kubectl get deploy pc-deployment -n dev
NAME READY UP-TO-DATE AVAILABLE AGE
pc-deployment 5/5 5 5 2m

#或者 编辑deployment的副本数量，修改spec:replicas: 3即可
[root@master ~]# kubectl edit deploy pc-deployment -n dev
deployment.apps/pc-deployment edited

2.镜像更新

deployment 支持两种更新策略 : 重建更新和滚动更新 , 可以通过 strategy 指定策略类型 , 支持两个属性 :

strategy：指定新的Pod替换旧的Pod的策略，支持两个属性：

type ：指定策略类型，支持两种策略

        Recreate：在创建出新的 Pod 之前会先杀掉所有已存在的 Pod

        RollingUpdate：滚动更新，就是杀死一部分，就启动一部分，在更新过程中，存在两个版本 Pod

rollingUpdate ：当 type 为 RollingUpdate 时生效，用于为 RollingUpdate 设置参数，支持两个属

性：

        maxUnavailable：用来指定在升级过程中不可用 Pod 的最大数量，默认为 25% 。

        maxSurge：用来指定在升级过程中可以超过期望的 Pod 的最大数量，默认为 25% 。

重建更新：

编辑 .yaml 文件, 在 spec 节点下添加更新策略：

spec :

strategy : # 策略

type : Recreate # 重建更新

变更镜像，然后观察升级过程：

[root @master ~ ] # kubectl set image deployment pc-deployment nginx=nginx:1.17.2 -

n dev

deployment.apps / pc-deployment image updated

[root @master ~ ] # kubectl get pods -n dev -w

滚动策略：

编辑.yaml 文件,在spec节点下添加更新策略：

spec :

strategy : # 策略

type : RollingUpdate # 滚动更新策略

rollingUpdate :

maxSurge : 25%

maxUnavailable : 25%

变更镜像，然后观察升级过程：

[root @master ~ ] # kubectl set image deployment pc-deployment nginx=nginx:1.17.3 -

n dev

deployment.apps / pc-deployment image updated
[root @master ~ ] # kubectl get pods -n dev -w

3.版本回退

deployment 支持版本升级过程中的暂停、继续功能以及版本回退等诸多功能，下面具体来看 .

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

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

# 查看当前升级版本的状态
[root@master ~]# kubectl rollout status deploy pc-deployment -n dev
deployment "pc-deployment" successfully rolled out
# 查看升级历史记录
[root@master ~]# kubectl rollout history deploy pc-deployment -n dev
deployment.apps/pc-deployment
REVISION CHANGE-CAUSE
1 kubectl create --filename=pc-deployment.yaml --record=true
2 kubectl create --filename=pc-deployment.yaml --record=true
3 kubectl create --filename=pc-deployment.yaml --record=true
# 可以发现有三次版本记录，说明完成过两次升级
# 版本回滚
# 这里直接使用--to-revision=1回滚到了1版本， 如果省略这个选项，就是回退到上个版本，就是2版本
[root@master ~]# kubectl rollout undo deployment pc-deployment --to-revision=1 -
n dev
deployment.apps/pc-deployment rolled back
# 查看发现，通过nginx镜像版本可以发现到了第一版
[root@master ~]# kubectl get deploy -n dev -o wide

4.金丝雀发布

新旧版本并行

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

三、Horizontal Pod Autoscaler(HPA)

在前面的课程中，我们已经可以实现通过手工执行 kubectl scale 命令实现Pod扩容或缩容显然不符合Kubernetes的定位目标--自动化、智能化。 Kubernetes期望可以实现通过监测Pod况，实现pod数量的自动调整，于是就产生了Horizontal Pod Autoscaler（HPA）这种控制器。

HPA 可以获取每个 Pod 利用率，然后和 HPA 中定义的指标进行对比，同时计算出需要伸缩的具体值，最后实现Pod 的数量的调整。其实 HPA 与之前的 Deployment 一样，也属于一种 Kubernetes 资源对象，它通过追踪分析RC 控制的所有目标 Pod 的负载变化情况，来确定是否需要针对性地调整目标 Pod 的副本数，这是HPA 的实现原理。

四、 StatefulSet（有状态）

无状态应用：

认为Pod都是一样的。
没有顺序要求。
不用考虑在哪个Node节点上运行。
随意进行伸缩和扩展。

有状态应用：

有顺序的要求。
认为每个Pod都是不一样的。
需要考虑在哪个Node节点上运行。
需要按照顺序进行伸缩和扩展。
让每个Pod都是独立的，保持Pod启动顺序和唯一性。

StatefulSet 是 Kubernetes 提供的管理有状态应用的负载管理控制器。StatefulSet部署需要 HeadLinessService （无头服务）。

为什么需要HeadLinessService（无头服务）？

● 在用 Deployment 时，每一个 Pod 名称是没有顺序的，是随机字符串，因此是 Pod 名称是无序的，但是在StatefulSet 中要求必须是有序，每一个 Pod 不能被随意取代， Pod 重建后 pod 名称还是一样的。

● 而 Pod IP 是变化的，所以是以 Pod 名称来识别。 Pod 名称是 Pod 唯一性的标识符，必须持久稳定有效。这时候要用到无头服务，它可以给每个Pod 一个唯一的名称。

● StatefulSet 常用来部署 RabbitMQ 集群、 Zookeeper 集群、 MySQL 集群、 Eureka 集群等。