📚 课程目录第3章滚动升级基础

3. 滚动升级基础：Deployment 的 RollingUpdate 策略与 maxSurge / maxUnavailable 参数详解

在 Kubernetes 中，Deployment 是最常用的工作负载控制器，其默认的更新策略 RollingUpdate 允许以可控的方式逐步替换 Pod 实例，实现零停机升级。理解 maxSurge 和 maxUnavailable 两个核心参数，是掌握滚动升级速率与流量切换的关键。

3.1 RollingUpdate 策略概述

当 Deployment 的 spec.strategy.type 设置为 RollingUpdate 时，Kubernetes 会按照用户定义的速率，逐步用新版本的 Pod 替换旧版本的 Pod。整个过程由 ReplicaSet 控制器协调，确保在任何时刻，集群中可用的 Pod 数量不低于安全阈值，同时允许临时超出期望副本数以加速更新。

  核心目标：在保证服务可用性的前提下，以可控速率完成版本切换。

3.2 参数详解：maxSurge 与 maxUnavailable

这两个参数定义在 spec.strategy.rollingUpdate 下，可以设置为数值（整数）或百分比（字符串）。百分比会基于 spec.replicas 向上取整计算。

参数	含义	默认值	取值范围
maxSurge	滚动更新过程中，允许超出期望副本数（`replicas`）的最大 Pod 数量或比例。	25%	0 或正整数 / 0% ~ 100%
maxUnavailable	滚动更新过程中，允许相对于期望副本数不可用的最大 Pod 数量或比例。	25%	0 或正整数 / 0% ~ 100%

注意：当 maxSurge 和 maxUnavailable 同时为 0 时，滚动更新将无法进行，因为系统无法创建新 Pod 也无法删除旧 Pod。

3.3 参数协同工作流程

假设 Deployment 的 replicas=10，maxSurge=25%（向上取整为 3），maxUnavailable=25%（向上取整为 3）。滚动更新的过程如下：

计算边界：
- 最大可用 Pod 数：replicas + maxSurge = 10 + 3 = 13
- 最小可用 Pod 数：replicas - maxUnavailable = 10 - 3 = 7
逐步替换：
- 控制器创建新版本 Pod，直到总 Pod 数达到 13（旧 Pod 仍运行）。
- 当新 Pod 进入 Ready 状态后，开始删除旧版本 Pod，直到总 Pod 数降至 10。
- 重复上述过程，直到所有旧 Pod 被替换。

3.4 参数配置策略与场景

不同的业务场景对更新速率和可用性要求不同，合理配置 maxSurge 和 maxUnavailable 可以平衡更新速度与资源消耗。

场景	maxSurge	maxUnavailable	效果说明
快速更新	100%	0%	先创建全部新 Pod，再一次性删除旧 Pod。更新最快，但需要双倍资源。
零停机、保守更新	0%	25%	先删除部分旧 Pod，再创建新 Pod。资源消耗低，但更新较慢。
平衡模式（默认）	25%	25%	边创建新 Pod 边删除旧 Pod，速度和资源消耗适中。
严格保留可用 Pod 数	10%	0%	确保所有旧 Pod 始终可用，仅允许少量额外 Pod 创建。适用于关键业务。

避坑提示：设置 maxSurge=0 且 maxUnavailable=1 时，更新会串行执行（一次只替换一个 Pod），速度极慢。对于大规模集群，建议使用百分比而非数值，以保持配置的通用性。

3.5 实际 Deployment 配置示例

以下是一个完整的 Deployment YAML 配置，展示了如何显式设置滚动更新参数：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 3          # 允许最多超出 3 个 Pod
      maxUnavailable: 2    # 允许最多 2 个 Pod 不可用
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80

3.6 参数对流量切换的影响

滚动升级过程中，Service 的流量切换是自动且平滑的。当新 Pod 通过 readinessProbe 检测并进入 Ready 状态后，Service 的 Endpoint 控制器会立即将其加入负载均衡池；同时，被删除的旧 Pod 会从 Endpoint 中移除。因此，maxSurge 和 maxUnavailable 间接决定了流量迁移的速率：

较大的 maxSurge：允许更多新 Pod 同时上线，流量快速切换到新版本。
较大的 maxUnavailable：允许更多旧 Pod 同时下线，但可能造成瞬时流量波动。
合理的 readinessProbe 配置：确保新 Pod 在接收流量前已完全就绪，避免将流量路由到未初始化的实例。

3.7 关键总结

maxSurge 控制更新速度的上限，允许临时扩容以加速替换。
maxUnavailable 控制服务可用性的下限，确保有足够的 Pod 处理请求。
两个参数共同定义了滚动更新的安全边界，合理配置可以兼顾更新效率与稳定性。
流量切换由 Service 和 Endpoint 控制器自动完成，但需要配合 readinessProbe 确保新 Pod 就绪。