在 Kubernetes 中，Deployment 提供了两种更新策略：

  • Recreate：适用于停机发布，设置 spec.strategy.type=Recreate，表示 Deployment 在更新 Pod 时，会先杀掉所有正在运行的 Pod，再创建新的 Pod
  • RollingUpdate：适用于零停机发布，设置 spec.strategy.type=RollingUpdate，表示 Deployment 会以滚动更新的方式逐个更新 Pod

滚动更新控制参数

服务在滚动更新时，Deployment 控制器的目的是：将旧版本（old_rs）副本数减少至 0、将新版本（new_rs）副本数量增至期望值（replicas）。Kubernetes 提供了以下两个参数：

  • maxUnavailable：和期望 ready 的副本数相比，不可用副本数的最大比例（或最大值），这个值越小，越能保证服务稳定，更新越平滑
  • maxSurge：和期望 ready 的副本数相比，超过期望副本数的最大比例（或最大值），这个值调得越大，副本更新速度越快

取值范围

数值（两者不能同时为 0）

  • maxUnavailable: [0, 副本数]
  • maxSurge: [0, 副本数]

比例（两者不能同时为 0）

  • maxUnavailable: [0%, 100%] 向下取整，比如 10 个副本，5% 的话 = 0.5 个，但计算按照 0 个
  • maxSurge: [0%, 100%] 向上取整，比如 10 个副本，5% 的话 = 0.5 个，但计算按照 1 个

自定义策略

Deployment controller 调整 ReplicaSet 数量时，严格通过以下公式来控制发布节奏。所以，如需快速发布，可根据实际情况调整这两个值：

1
(目标副本数 - maxUnavailable) <= 线上实际 Ready 副本数 <= (目标副本数 + maxSurge)

举例：如果期望副本数（目标副本数）是 10，期望能有至少 80% 数量的副本（线上实际 Ready 副本数: 10 * 80%）能稳定工作，所以：maxUnavailable = 2，maxSurge = 2（可自定义，建议与 maxUnavailable 保持一致）

1
8 <= 线上实际 Ready 副本数 <= 12

这样，更新过程中，线上能够正常提供服务的 Pod 数总会保持在这个区间内。

配置示例

示例 1：先上后下（最平滑）

1
2
maxUnavailable: 0
maxSurge: 1

配置 maxUnavailable=0 和 maxSurge=1，遵循"一上一下，先上后下"最平滑原则：1 个新版本 Pod ready（结合 readiness probe）后，才销毁旧版本 Pod。此配置适用场景是平滑更新、保证服务平稳。

示例 2：先下后上

1
2
maxUnavailable: 1
maxSurge: 1

配置 maxUnavailable=1 和 maxSurge=1，先删除一个旧版本，待新版本创建并且 running 后再删除一个旧版本（和上面的示例不同，上面是先起来一个新的再删除一个旧的，而这里是先删除一个旧的，再起来一个新的）。