3. 滚动升级策略基础：Kubernetes Deployment 滚动更新原理、maxSurge 与 maxUnavailable 参数详解

在 Argo CD 管理应用交付的实践中，滚动升级（Rolling Update）是 Deployment 默认且最常用的更新策略。理解其底层原理与核心参数，是后续进行资源配额校准与瓶颈分析的前提。本章将深入剖析 Kubernetes 滚动更新的工作机制，并详细解读 maxSurge 与 maxUnavailable 两个关键参数。

3.1 Kubernetes Deployment 滚动更新原理

滚动更新的核心目标是在不中断服务的前提下，逐步用新版本的 Pod 替换旧版本的 Pod。其本质是通过控制新旧两个 ReplicaSet 的副本数量，实现平滑过渡。

下图展示了滚动更新的基本流程：

滚动更新的关键步骤可以概括为：

1. 触发更新：修改 Deployment 的 Pod 模板（如镜像版本），控制器检测到差异后开始执行滚动更新。
2. 创建新 ReplicaSet：控制器根据新的 Pod 模板创建一个新的 ReplicaSet，初始副本数为 0。
3. 逐步扩缩：按照 maxSurge 和 maxUnavailable 的配置，逐步增加新 ReplicaSet 的副本数，同时减少旧 ReplicaSet 的副本数。
4. 健康检查：新 Pod 就绪后，才会继续下一轮替换。如果新 Pod 启动失败，更新过程会暂停或回滚。
5. 完成更新：旧 ReplicaSet 副本数降为 0，新 ReplicaSet 达到期望副本数，更新完成。

3.2 maxSurge 与 maxUnavailable 参数详解

maxSurge 和 maxUnavailable 是控制滚动更新速率和可用性的两个核心参数。它们可以设置为数值（整数）或百分比，默认值均为 25%。

3.3 参数组合与行为分析

不同的参数组合会产生不同的滚动更新行为。理解这些组合对于设计合理的更新策略至关重要。

3.4 参数配置示例

以下是一个 Deployment 的 YAML 配置示例，展示了如何设置 maxSurge 和 maxUnavailable：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1          # 允许超出期望副本数 1 个 Pod
      maxUnavailable: 0    # 不允许有不可用的 Pod
  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"

3.5 滚动更新与资源配额的关系

滚动更新过程中，新旧 Pod 会同时存在一段时间，这会导致集群资源使用量出现临时峰值。这个峰值的大小直接由 maxSurge 参数决定。

从表中可以看出，maxSurge 越大，更新期间的最大 Pod 数就越多，对资源配额的需求也越高。在 Argo CD 的自动化部署场景中，如果集群资源配额设置不当，滚动更新可能会因为资源不足而失败或卡住。