Kubernetes 中 Pod 更新全攻略

在 Kubernetes（K8s）运维体系中，Pod 作为最小的部署单元，其更新是日常操作的核心场景。无论是更新容器镜像、调整配置参数，还是修复应用 BUG，都需要通过合理的方式更新 Pod，同时尽可能减少业务中断。本文将从基础到进阶，全面讲解 Pod 更新的核心方法、实操步骤及避坑要点。

一、Pod 更新的核心原则：为什么不直接编辑 Pod？

首先要明确：不建议直接通过kubectl edit pod <pod-name>修改运行中的 Pod。原因在于：

1. Pod 是 K8s 中的 “一次性” 资源，一旦创建，其核心规格（如镜像、容器端口、卷挂载等）无法被持久化修改，编辑后仅临时生效，Pod 重启后会恢复原状；
2. 直接修改 Pod 无法保证更新的可追溯性和一致性，也无法利用 K8s 的滚动更新、回滚等能力；
3. 手动修改易导致集群状态混乱，不符合 K8s “声明式 API” 的设计理念。

因此，K8s 推荐通过管理 Pod 的控制器（Deployment、StatefulSet、DaemonSet 等） 来实现 Pod 的优雅更新，核心逻辑是：修改控制器的配置→K8s 根据新配置销毁旧 Pod、创建新 Pod。

二、核心更新方式：基于 Deployment 的 Pod 更新（最常用）

Deployment 是管理无状态应用最核心的控制器，其内置的滚动更新能力能最大程度保证业务连续性，也是 Pod 更新的主流方式。

1. 基础场景：更新容器镜像

这是最常见的 Pod 更新需求，比如应用版本迭代需要更换镜像。

方式 1：编辑 Deployment 配置（手动修改）

# 编辑Deployment配置，修改spec.template.spec.containers.image字段
kubectl edit deployment <deployment-name>

编辑时找到containers下的image字段，替换为新镜像（如nginx:1.25→nginx:1.26），保存后 K8s 会自动触发滚动更新。

方式 2：直接命令更新（更高效）

无需手动编辑配置文件，直接通过命令指定新镜像：

# 一键更新Deployment的镜像
kubectl set image deployment/<deployment-name> <容器名>=<新镜像地址>
# 示例：更新名为nginx-deploy的Deployment中nginx容器的镜像
kubectl set image deployment/nginx-deploy nginx=nginx:1.26

方式 3：通过 YAML 配置文件更新

若有 Deployment 的 YAML 文件，修改其中的镜像后执行：

# 应用更新后的配置文件
kubectl apply -f deployment.yaml

2. 验证更新状态

更新后可通过以下命令查看进度和状态：

# 查看Deployment的更新状态
kubectl rollout status deployment/<deployment-name>
# 查看更新历史
kubectl rollout history deployment/<deployment-name>
# 查看Pod列表，确认新Pod创建、旧Pod销毁
kubectl get pods

3. 进阶配置：自定义滚动更新策略

Deployment 默认的滚动更新策略可满足大部分场景，但也可自定义参数，比如控制更新速率、不可用比例等，在 YAML 中配置spec.strategy.rollingUpdate：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  replicas: 3
  strategy:
    rollingUpdate:
      maxSurge: 1        # 升级过程中最多可超出期望副本数的数量（可设百分比，如25%）
      maxUnavailable: 0  # 升级过程中最多不可用的Pod数量（设为0表示全程无中断）
    type: RollingUpdate  # 明确指定滚动更新策略（默认）
  template:
    spec:
      containers:
      - name: nginx
        image: nginx:1.26

• maxSurge：控制更新时临时创建的 Pod 数量，避免资源耗尽；
• maxUnavailable：控制更新时不可用的 Pod 数量，设为 0 可实现 “零停机更新”（前提是集群资源足够）。

4. 回滚：更新出错时的补救措施

若更新后发现应用异常，可快速回滚到上一个版本：

# 回滚到上一版本
kubectl rollout undo deployment/<deployment-name>
# 回滚到指定版本（先通过rollout history查看版本号）
kubectl rollout undo deployment/<deployment-name> --to-revision=2

三、特殊场景：StatefulSet/DaemonSet 的 Pod 更新

不同控制器的 Pod 更新逻辑略有差异，以下针对有状态应用和守护进程的场景说明：

1. StatefulSet（有状态应用，如数据库）

StatefulSet 管理的 Pod 有固定名称和存储，更新策略需兼顾数据一致性：

（1）自动更新（推荐）

修改 StatefulSet 的镜像后，需指定更新策略为RollingUpdate（K8s 1.7 + 支持）：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql-sts
spec:
  updateStrategy:
    type: RollingUpdate  # 滚动更新（默认）
    rollingUpdate:
      partition: 0       # 分区更新，设为0表示所有Pod依次更新
  template:
    spec:
      containers:
      - name: mysql
        image: mysql:8.0.35

执行kubectl apply -f statefulset.yaml后，StatefulSet 会按 Pod 序号（从高到低）依次更新，保证有状态应用的有序升级。

（2）分区更新（灰度发布）

若需灰度更新（如先更 1 个 Pod 验证），可设置partition参数：

updateStrategy:
  rollingUpdate:
    partition: 2  # 仅更新序号≥2的Pod（序号从0开始）

2. DaemonSet（守护进程，如日志采集、监控代理）

DaemonSet 保证每个节点运行一个 Pod，更新策略分两种：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-ds
spec:
  updateStrategy:
    type: RollingUpdate  # 滚动更新（默认）
    rollingUpdate:
      maxUnavailable: 1  # 每次更新最多不可用1个节点的Pod
  # type: OnDelete       # 旧策略：需手动删除旧Pod才会创建新Pod
  template:
    spec:
      containers:
      - name: fluentd
        image: fluentd:v1.16

• RollingUpdate：自动滚动更新，控制maxUnavailable避免全节点 Pod 同时下线；
• OnDelete：传统策略，修改配置后需手动删除旧 Pod，K8s 才会创建新 Pod。

四、Pod 更新的避坑要点

1. 镜像拉取策略：若镜像标签为latest，需设置imagePullPolicy: Always，否则 K8s 可能复用本地旧镜像，导致更新不生效；
2. 资源限制：更新时maxSurge设置过大可能导致节点资源不足，需结合集群资源合理配置；
3. 健康检查：务必为 Pod 配置livenessProbe（存活探针）和readinessProbe（就绪探针），K8s 会根据探针结果判断 Pod 是否可用，避免将流量转发到未就绪的新 Pod；
4. 有状态应用更新：StatefulSet 更新前需确认数据备份，避免更新过程中数据丢失；
5. 版本追溯：更新前建议通过kubectl get deployment <name> -o yaml > backup.yaml备份配置，便于问题排查。

五、总结

K8s 中 Pod 更新的核心是 “通过控制器声明式更新”，而非直接修改 Pod：

• 无状态应用优先用 Deployment 的滚动更新，兼顾效率和无中断；
• 有状态应用用 StatefulSet 的分区更新，保证数据一致性；
• 守护进程用 DaemonSet 的滚动更新，避免节点级故障。