3. K8s 更新机制：RollingUpdate 策略详解与参数配置

在 Kubernetes 集群中，RollingUpdate（滚动更新）是 Deployment 默认且最常用的更新策略。它通过逐步替换旧版本 Pod 实例为新版本，实现零停机的应用发布。理解其核心参数 maxSurge 与 maxUnavailable 的配置逻辑，是构建可靠回滚流水线的基础。

3.1 RollingUpdate 核心原理

滚动更新并非一次性销毁所有旧 Pod，而是遵循以下步骤循环执行：

1. 启动新 Pod：根据 maxSurge 参数，允许超出期望副本数启动新版本 Pod。
2. 等待就绪：新 Pod 通过 Readiness Probe 探测后，标记为 Ready。
3. 终止旧 Pod：根据 maxUnavailable 参数，允许一定数量的旧 Pod 不可用。
4. 重复迭代：直到所有旧 Pod 被新 Pod 替换，达到期望副本数。

3.2 核心参数：maxSurge 与 maxUnavailable

这两个参数共同控制滚动更新的速率和资源占用，直接影响发布的安全性与效率。

3.3 参数配置示例与计算逻辑

假设 Deployment 期望副本数 replicas=10，配置如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 3          # 允许最多超出 3 个 Pod
      maxUnavailable: 2    # 允许最多 2 个 Pod 不可用
  template:
    # Pod 模板定义

3.4 参数配置策略对比

3.5 参数配置避坑指南

• maxUnavailable 为 0 时：必须保证 maxSurge > 0，否则无法启动新 Pod。
• 百分比向下取整：K8s 将百分比转换为值时向下取整，最小为 1。
• 资源配额限制：maxSurge 过大可能导致集群资源不足，Pod 调度失败。
• StatefulSet 差异：StatefulSet 默认使用 OnDelete 策略，不支持 RollingUpdate 的 maxSurge/maxUnavailable。

3.6 更新进度监控与回滚触发

滚动更新过程中，K8s 通过 kubectl rollout status 监控进度。当新 Pod 启动失败或 Readiness 探测超时，更新会暂停。此时可手动触发回滚：

# 查看更新状态
kubectl rollout status deployment/my-app

# 查看更新历史
kubectl rollout history deployment/my-app

# 回滚到上一版本
kubectl rollout undo deployment/my-app

# 回滚到指定版本
kubectl rollout undo deployment/my-app --to-revision=2

3.7 与回滚流水线的集成要点

在 CI/CD 流水线中，RollingUpdate 参数配置直接影响回滚策略的设计：

• 更新历史保留：通过 spec.revisionHistoryLimit 控制保留的旧版本数量，默认 10，建议至少保留 5 个版本用于回滚。
• 自动回滚触发：结合 ProgressDeadlineSeconds（默认 600s），超时后自动触发回滚。
• 流水线阶段控制：在 CI/CD 中设置 rollout status --timeout=300s，超时则执行 rollout undo。

# 流水线脚本示例：自动回滚
kubectl set image deployment/my-app my-app=my-image:v2
if ! kubectl rollout status deployment/my-app --timeout=300s; then
  echo "更新超时，触发回滚"
  kubectl rollout undo deployment/my-app
fi