• 适用停机发布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。)

  1. maxUnavailable: [0, 副本数]

  2. maxSurge: [0, 副本数]

比例(两者不能同时为0。)

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

  2. 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
2
3
4
5
maxUnavailable == 0
maxSurge == 1

配置maxUnavailable == 0,maxSurge == 1,
“一上一下，先上后下”最平滑原则：1个新版本pod ready（结合readiness）后，才销毁旧版本pod。此配置适用场景是平滑更新、保证服务平稳
1
2
3
4
5
6
maxUnavailable == 1
maxSurge == 1

配置maxUnavailable == 1,maxSurge == 1,
先删除一个旧版本，待新版本创建并且running再删除一个旧版本
(和上面的例子不同, 上面是先起来一个新的再删除一个旧的,而下面是先删除一个旧的,再起来一个新的)