3. 滚动更新机制详解：maxSurge、maxUnavailable 参数对更新速率的影响

在 Kubernetes Deployment 的滚动更新中，maxSurge 和 maxUnavailable 是两个核心参数，它们直接决定了 Pod 替换的速率、集群资源的瞬时占用以及服务的可用性边界。理解这两个参数的协同关系，是设计高效、安全的更新策略的基础。

3.1 参数定义与默认行为

这两个参数均定义在 Deployment 的 spec.strategy.rollingUpdate 字段下，支持数值（整数）或百分比（相对于期望副本数 replicas 的百分比）。

3.2 参数对更新速率的影响模型

滚动更新的本质是一个“先创建新 Pod，再删除旧 Pod”的循环过程。每个批次中，系统会同时执行以下两个操作：

• 扩容（Scale Up）：创建新版本 Pod，数量受 maxSurge 限制。
• 缩容（Scale Down）：删除旧版本 Pod，数量受 maxUnavailable 限制。

更新速率由这两个参数的较小者决定。下面通过一个具体示例说明：

3.3 参数协同的三种典型模式

根据业务对可用性和更新速度的不同要求，可以将参数组合归纳为以下三种模式：

1. 快速更新模式（牺牲部分可用性）：设置 maxSurge: 50%，maxUnavailable: 50%。适合开发环境或非关键业务，更新速度快，但更新期间服务容量可能下降 50%。
2. 零停机模式（严格保障可用性）：设置 maxSurge: 25%，maxUnavailable: 0。适合生产环境关键服务，确保任何时候可用 Pod 数不低于期望值，但更新速度较慢，且需要额外资源承载 Surge Pod。
3. 资源受限模式（控制峰值负载）：设置 maxSurge: 1（或 10%），maxUnavailable: 1（或 10%）。适合集群资源紧张的场景，每次只变动少量 Pod，避免资源争抢。

3.4 滚动更新流程与参数交互 SVG 图

下图展示了 replicas=5，maxSurge=2，maxUnavailable=1 配置下，一个完整批次的更新流程：

3.5 参数配置的常见陷阱与最佳实践

3.6 参数对更新速率影响的定量分析

更新速率可以用“每单位时间完成的 Pod 替换数”来衡量。假设每个 Pod 从创建到就绪需要 T_ready 秒，则：

• 理论最小更新总时间 = ceil(replicas / batchSize) × T_ready
• batchSize = min(maxSurge, maxUnavailable) 的值或百分比计算值

例如，replicas=10，T_ready=30s：

3.7 参数协同的决策树 SVG 图

以下决策树帮助 SRE 工程师根据业务需求快速选择参数组合：

3.8 实战验证：通过 kubectl 观察参数影响

使用以下命令可以实时观察滚动更新过程中 Pod 的变化：

# 启动滚动更新并持续观察
kubectl set image deployment/my-app my-container=my-image:v2 --record
kubectl rollout status deployment/my-app --watch

# 在另一个终端观察 Pod 状态变化
kubectl get pods -l app=my-app -w

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

通过 -w 参数可以清晰看到：当 maxSurge 较大时，新 Pod 会快速创建；当 maxUnavailable 较小时，旧 Pod 的删除会滞后，从而保证服务容量。