基于Kubernetes v1.7.4
关于Kubernetes Deployment滚动更新
- Kubernetes官网文档说明：
- 更多关于Deployment rollout的相关内容，请参考我的博文
场景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如下所示：
- RS实例数根据比例进行相应的增加：
5）实例数更新以后，滚动升级继续进行，最终老的replicaset实例被删，替换为新的
场景4：应用滚动更新时，用户对该应用进行缩容
- 新建deployment：webserver，replicas=15，image=tomcat。
- 更改容器镜像，触发deployment的滚动更新。
开始进行滚动更新：
- 更改deployment的实例数到4
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的滚动更新。
更新后，再次触发滚动升级：
- 第二次滚动升级webserver-2480438009初始DESIRED=0，因为两个老的RS当前实例总数为12+7=19，已经达到最大值，所以初始为0。
- 缩减老的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角度观察滚动过程如下：
附录：
感谢同事陈俊超辛苦的测试分析。