基于Kubernetes v1.7.4
从红框处,DESIRED=0,实例逐渐被删除。
开始进行滚动更新:
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
5)实例数更新以后,滚动升级继续进行,最终老的replicaset实例被删,替换为新的
开始进行滚动更新:
- 新老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
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
如下所示:
从deployment角度观察结果如下:
RS的实例数变为20,开始扩容
RS的实例数变为4,开始缩容
deployment的实例数先被缩容到4; UP-TO-DATE从25-0-4,表明实例被滚动到最新版本。 CURRENT 实例数在开始滚动更新后,最大数不超过5,符合滚动更新的实例数区间。
等待滚动更新完成:
3)更改容器镜像为httpd,触发deployment的滚动更新。
等待滚动更新完成:
4)回滚到nginx版本。
等待滚动更新完成:
回滚到 –to-revision=2 nginx版本后,nginx版本又成为了最新的版本vision:4。
更新后,触发滚动升级:
更新后,再次触发滚动升级:
所以将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
感谢同事陈俊超辛苦的测试分析。