基于Kubernetes v1.7.4

关于Kubernetes Deployment滚动更新

• Kubernetes官网文档说明：https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#strategy
• 更多关于Deployment rollout的相关内容，请参考我的博文聊聊你可能误解的Kubernetes Deployment滚动更新机制

场景1：正常滚动更新流程

• 新建deployment：webserver，replicas=10，image=tomcat。

• 滚动更新应用镜像为：nginx

• 观察Replicasets的变化，可发现升级后会创建新的Replicasets，删除老的Replicasets实例，滚动创建新实例。

• 观察deployment的变化

• DESIRED: 10(一直为10)

• CURRENT: 在[replicas-maxUnavailable, replicas+maxSurge]：[8，13]之间变动，最终等于DESIRED值
• UP-TO-DATE: 已更新为nginx镜像的实例，最终等于DESIRED值。
• AVALIABLE: 新老replicaset总的实例数，最终等于DESIRED值。

场景2：应用滚动更新时，用户删除应用

• 新建deployment：webserver，replicas=10，image=tomcat。

• 更改容器镜像，触发deployment的滚动更新。

• 新老Replicaset开始进行滚动更新。

• 使用kubectl删除正在滚动更新的deployment。

• 新老replicaset的实例数被缩减为0，实例开始被删除。

• 观察deployment实例变化如下

从红框处，DESIRED=0，实例逐渐被删除。

场景3：应用滚动更新时，用户对该应用进行扩容

• 新建deployment：webserver，replicas=15，image=tomcat。

• 更改容器镜像，触发deployment的滚动更新。

开始进行滚动更新：

• 更改deployment的实例数到20

• 新老RS根据比例进行实例数扩容

  • RS实例数根据比例进行相应的增加： RS扩容后的实例数=扩容前实例数占比*扩容后最大实例数

  在此次升级中，在扩容前

  | NAME | DESIRED | CURRENT | READY | |----|----|----|----| | Webserver-1078791221 | 10 | 10 | 12 | | Webserver-3236788441 | 7 | 7 | 3 |

  升级前的总实例数：10+7=17
  升级前最多实例数：15+MaxSurge(25%)=19
  升级后最多实例数：20+ MaxSurge(25%)=25
  当前需扩容的总数：25-17=8
  所以:
  webserver-1078791221扩容后实例数=(10/19)*25=13.15(+0.5取整)=13 webserver-3236788441扩容后实例数=(7/19)*25=9.21(+0.5取整)=9

  • 剩余的实例分配给实例数最多的rs
    webserver-1078791221 较扩容前增加：13-10=3
    webserver-3236788441较扩容前增加：9-7=2
    仍剩余的实例(8-3-2=3个)分配给webserver-1078791221
    所以webserver-1078791221总实例数=10+3+3=16

    如下所示：

5）实例数更新以后，滚动升级继续进行，最终老的replicaset实例被删，替换为新的

场景4：应用滚动更新时，用户对该应用进行缩容

• 新建deployment：webserver，replicas=15，image=tomcat。

• 更改容器镜像，触发deployment的滚动更新。

开始进行滚动更新：

• 更改deployment的实例数到4

- 新老RS根据比例进行实例数缩容
RS实例数根据比例进行相应的缩减(计算方法如扩容)： RS缩容后的实例数=缩容前实例数占比*缩容后最大实例数

| NAME | DESIRED | CURRENT | READY |
|----|----|----|----|
|Webserver-1078791221 | 9 | 10 | 10|
|Webserver-3236788441 | 9 | 8 | 4 |

升级前的总实例数：9+9=18
升级前最多实例数：15+MaxSurge(25%)=19
升级后最多实例数：4+ MaxSurge(25%)=5
当前需缩容的总数：18-5=13
所以
webserver-1078791221缩容后实例数=-(9/19)*5=-2.36(-0.5取整)=2
webserver-3236788441缩容后实例数=-(9/19)*5=-2.36(-0.5取整)=2

• 多缩容的实例分配给实例数最多的rs

webserver-1078791221 较缩容前减少：9-2=7
webserver-3236788441较缩容前减少：9-2=7
多缩容的实例(7+7-13=1个)分配给实例数最多的rs(由于新老RS实例数都为9，则按照创建时间进行排序，分给最新的实例webserver-3236788441)
所以webserver-3236788441总实例数=9-7+1=3

如下所示：   

• 最终老的replicaset实例被删，替换为新的，且缩容到指定个数。

从deployment角度观察结果如下：

场景5：应用扩容时，进行滚动更新

• 新建deployment：webserver，replicas=10，image=tomcat。

• 更改deployment的实例数到20

RS的实例数变为20，开始扩容

• 更改容器镜像，触发deployment的滚动更新。

• 新老的replicaset的实例变化。
  创建新的RS，按照滚动升级策略开始更新，如下：

• 最终老的replicaset实例被删，替换为新的

• 观察deployment的实例变化如下：

场景6：应用缩容时，进行滚动更新

• 新建deployment：webserver，replicas=25，image=tomcat。

• 更改deployment的实例数到4

RS的实例数变为4，开始缩容

• 更改容器镜像，触发deployment的滚动更新。

• 新老的replicaset的实例变化
  老的RS的实例会被逐渐删除，同时新的RS开始滚动更新，符合滚动升级策略。

• 最终老的replicaset实例被删，替换为新的

• 观察deployment的实例变化如下：

deployment的实例数先被缩容到4;
UP-TO-DATE从25-0-4，表明实例被滚动到最新版本。
CURRENT 实例数在开始滚动更新后，最大数不超过5，符合滚动更新的实例数区间。

场景7：应用回滚

• 新建deployment：webserver，replicas=10，image=tomcat。

• 更改容器镜像为nginx，触发deployment的滚动更新。

等待滚动更新完成：

3）更改容器镜像为httpd，触发deployment的滚动更新。

等待滚动更新完成：

4）回滚到nginx版本。

等待滚动更新完成：

回滚到 –to-revision=2 nginx版本后，nginx版本又成为了最新的版本vision：4。

场景8：滚动更新未完成时，又开始新的滚动更新

• 新建deployment：webserver，replicas=15，image=tomcat。

• 更改容器镜像为nginx，触发deployment的滚动更新。

更新后，触发滚动升级：

• 在上个滚动更新未完成的情况下，接着更改容器镜像为httpd，再次触发deployment的滚动更新。

更新后，再次触发滚动升级：

1. 第二次滚动升级webserver-2480438009初始DESIRED=0，因为两个老的RS当前实例总数为12+7=19，已经达到最大值，所以初始为0。
2. 缩减老的RS时，遵循两个原则
   • 遍历所有老的RS，优先缩减那些unavailable的实例。
     webserver-3236788441缩减前7/7/ 3(还有4个unacailable)，所以先被缩减到3/7/3。
   • 在保证最小available个实例的前提下，缩减老的RS。 计算方法如下：
     最小可用数minAvailable = deployment.Replicas – maxUnavailable；
     当前总可用数：availablePodCount = 所有RS的AvailableReplicas总和；
     可缩减的总数：totalScaleDownCount = availablePodCount - minAvailable；
     将老的RS按创建时间从新到老排序，逐个进行缩减。
     例如，在第一次缩减webserver-1078791221时：
     webserver-2480438009 7/7/1
     webserver-1078791221 9/9/9
     webserver-3236788441 3/3/3
     minAvailable=15-15*25%=12
     availablePodCount=1+9+3=13
     totalScaleDownCount=13-12=1

所以将webserver-1078791221缩减1个实例到 8/9/9(如上图最下面的红框)

再次缩减时：
webserver-2480438009 8/8/2
webserver-1078791221 8/8/8
webserver-3236788441 3/3/3
minAvailable=15-15*25%=12 availablePodCount=2+8+3=13 totalScaleDownCount=13-12=1

webserver-1078791221缩减为0/0/0，开始用同样的方法缩减
webserver-3236788441，这里不再敖述。
相关处理Replicasets代码在：
pkg/controller/deployment/rolling.go：reconcileOldReplicaSets

• 从deployment角度观察滚动过程如下：

附录：

• https://kubernetes.io/docs/concepts/workloads/controllers/deployment/

感谢同事陈俊超辛苦的测试分析。