📚 课程目录第4章滚动升级策略原理

4. 滚动升级原理：Kubernetes Deployment 滚动更新策略、maxSurge 与 maxUnavailable

Kubernetes Deployment 的滚动更新（Rolling Update）是生产环境中实现无宕机应用发布的核心机制。理解其底层原理，特别是 maxSurge 与 maxUnavailable 两个关键参数，是分析 Argo CD 滚动升级过程中资源配额瓶颈的前提。

4.1 滚动更新 vs. 重建与蓝绿部署

在深入参数之前，先明确滚动更新在 Kubernetes 部署策略中的定位：

部署策略	核心行为	资源消耗特征	适用场景
Recreate（重建）	先删除所有旧 Pod，再创建新 Pod	瞬时资源需求低，但存在服务中断窗口	开发环境、可接受短时宕机的应用
RollingUpdate（滚动更新）	逐步替换旧 Pod，保持一定数量的 Pod 可用	资源消耗平滑，但峰值可能超过副本数	生产环境、无状态应用、需要持续服务的场景
Blue/Green（蓝绿部署）	同时运行两套完整环境，一次性切换流量	资源需求翻倍，切换瞬间无中断	对稳定性要求极高、有充足资源冗余的场景

滚动更新在资源利用率和可用性之间取得了最佳平衡，但正是这种“逐步替换”的机制，使得资源配额（CPU/内存）在更新过程中可能出现瞬时超限。

4.2 滚动更新的核心参数：maxSurge 与 maxUnavailable

Deployment 的 spec.strategy.rollingUpdate 下有两个关键字段，它们共同决定了滚动更新的速率和资源占用峰值：

maxSurge：滚动更新期间，允许超出期望副本数（replicas）的最大 Pod 数量。可以是数字（如 2）或百分比（如 25%）。
maxUnavailable：滚动更新期间，允许不可用 Pod 的最大数量。同样可以是数字或百分比。

  关键公式： 滚动更新期间，集群中同时存在的 Pod 总数上限 = replicas + maxSurge；同时可用的 Pod 数量下限 = replicas - maxUnavailable。

4.3 滚动更新流程与资源消耗模型

以下 SVG 图展示了当 replicas=5、maxSurge=25%（向上取整为 2）、maxUnavailable=25%（向上取整为 2）时，一次典型的滚动更新过程：

4.4 参数计算规则与示例

当使用百分比时，Kubernetes 会向上取整计算实际数值。以下表格展示了不同配置下的实际行为：

replicas	maxSurge	maxUnavailable	实际 maxSurge	实际 maxUnavailable	最大 Pod 总数	最小可用 Pod
5	25%	25%	2（ceil(5*0.25)=2）	2（ceil(5*0.25)=2）	7	3
5	1	1	1	1	6	4
10	10%	10%	1（ceil(10*0.1)=1）	1（ceil(10*0.1)=1）	11	9
3	50%	0	2（ceil(3*0.5)=2）	0	5	3

最佳实践： 在 Argo CD 管理的生产环境中，建议将 maxSurge 和 maxUnavailable 设置为相同的百分比（如 25%），这样可以在保证至少 75% 的 Pod 可用的同时，将资源峰值控制在 125% 以内。如果集群资源紧张，可以进一步降低这两个值。

4.5 滚动更新过程中的 Pod 状态变化

以下 SVG 图展示了单个 Pod 在滚动更新过程中的状态转换，以及资源配额检查点：

4.6 实际配置示例

以下是一个完整的 Deployment YAML 配置，展示了滚动更新策略的声明方式：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: production
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%        # 允许超出期望副本数 25%（向上取整为 2）
      maxUnavailable: 25%  # 允许不可用副本数 25%（向上取整为 2）
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:v2
        resources:
          requests:
            cpu: "500m"
            memory: "256Mi"
          limits:
            cpu: "1"
            memory: "512Mi"

注意： 在 Argo CD 的自动同步（Auto-Sync）场景中，如果 Deployment 的滚动更新因资源配额不足而卡住，Argo CD 会持续重试同步，可能导致集群资源进一步紧张。建议在 Application 的 syncPolicy 中设置 retry 策略，避免无限重试。

4.7 本章小结

滚动更新通过 maxSurge 和 maxUnavailable 控制 Pod 替换速率，直接影响资源占用峰值。
资源配额瓶颈通常出现在“扩容阶段”，此时 Pod 总数达到 replicas + maxSurge，资源请求量最大。
百分比参数会向上取整，小副本数场景下实际影响可能比预期更大。
理解滚动更新的资源消耗模型，是后续分析 Argo CD 滚动升级中资源配额瓶颈的基础。