3. RollingUpdate 策略详解：maxSurge 与 maxUnavailable 对回滚的影响

Kubernetes 默认的更新策略是 RollingUpdate（滚动更新）。它通过逐步替换旧 Pod 实例来保证服务在更新期间持续可用。理解 RollingUpdate 的核心参数 maxSurge 和 maxUnavailable，是设计自动化回滚护栏的前提——这两个参数直接决定了更新速度、资源消耗以及回滚时的行为。

3.1 RollingUpdate 核心机制

滚动更新的本质是：在维持期望副本数（replicas）的前提下，逐步用新版本 Pod 替换旧版本 Pod。控制器（Deployment Controller）会创建新 Pod，等待其就绪，然后删除旧 Pod，重复此过程直到所有 Pod 都更新为新版本。

3.2 参数详解：maxSurge 与 maxUnavailable

这两个参数定义在 Deployment 的 spec.strategy.rollingUpdate 字段中，可以是数值（整数）或百分比。它们共同决定了滚动更新过程中 Pod 数量的上下边界。

3.3 参数组合对更新与回滚的影响

不同的参数组合会产生截然不同的更新行为。以下表格对比了三种典型配置及其对回滚的影响：

3.4 滚动更新与回滚的流程图示

下图展示了在 replicas=5、maxSurge=1、maxUnavailable=0 配置下，滚动更新及触发回滚的完整流程：

3.5 参数配置对回滚速度的影响

当更新过程中触发回滚时，Deployment 控制器会按照相同的 RollingUpdate 逻辑反向操作——用旧版本（v1）替换新版本（v2）。此时 maxSurge 和 maxUnavailable 同样生效：

• maxSurge 越大，回滚越快：允许同时创建更多旧版本 Pod，加速替换过程。
• maxUnavailable 越大，回滚越快但风险越高：允许更多 Pod 同时不可用，可能影响服务容量。
• maxSurge=0 且 maxUnavailable=0 时，回滚无法进行：因为没有空间创建新 Pod，也无法删除旧 Pod，更新会卡住。

3.6 实际配置示例

以下是一个生产环境推荐的 Deployment 配置片段：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1          # 最多允许 1 个额外 Pod
      maxUnavailable: 0    # 不允许 Pod 不可用
  template:
    spec:
      containers:
      - name: app
        image: my-app:v2
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10

3.7 参数配置决策矩阵

根据不同的业务场景，选择合适的参数组合：