Kubernetes | 滚动更新 | 回滚

                       --昨夜西风凋碧树，独上高楼，望尽天涯路

Kubernetes提供的滚动更新机制每次更新一小部分，零停机，实现了业务的连续性；回滚机制则是保证了每次更新应用的时候都会记录下当前的配置，保存为一个revision，这样就可以回滚到某个特定的revision。

• 更新

根据下面配置文件，部署一个5副本应用httpd:2.2.31:

通过kubectl apply部署以及查看部署情况：

之后假设需要更新应用版本，修改yml文件httpd版本之后重新发布：

查看部署信息，发现Deployment httpd的进行更新为httpd:2.2.32,新建了Replicaset httpd-7fdc6565b4，并且所有的pod都已经替换为httpd-7fdc6565b4：

通过kubectl describe deployment httpd查看详细的信息：

解释一下Events中的内容：

1）httpd:2.2.31版本的httpd-67b69fb7f5存在5个副本，首先启动两个httpd:2.2.32版本的 httpd-7fdc6565b4 副本，此时一共有7个副本

2）减少httpd-67b69fb7f5的一个副本，增加 httpd-7fdc6565b4 的一个副本，保持总数7个副本不变，依次递减

3）最后启动完httpd-7fdc6565b4的5个副本之后，删除完httpd-67b69fb7f5副本

滚动更新可以通过参数maxSurge和maxUnavailable来控制滚动更新中旧副本和新副本更替的数目

maxSurge：

控制滚动更新过程中副本总数超过DESIRED的上限。maxSurge可以是具体的整数，也可以是百分比，向上取整。maxSurge默认值为25%。

例如DESIRED为10，那么副本总数的最大值为roundUp(10 + 10*25%)=13,所以CURRENT为13。

maxUnavailable：

控制滚动更新过程中，不可用副本占DESIRED的最大比例。maxUnavailable可以是具体的整数，也可以是百分之百，向下取整。默认值为25%。

例如DESIRED为10，那么可用的副本数至少要为 10-roundDown(10*25%)=8,所以AVAILABLE为8。

maxSurge越大，初始创建的新副本数量就越多；maxUnavailable越大，初始销毁的旧副本数目就越多。

如果要更改maxSurge或者maxUnavailable：

• 回滚

编写三个版本的yml文件（默认配置下Kubernetes只会保留最近的几个revision，可以在yml配置文件中通过revisionHistoryLimit设置revision的数量）：

通过kubectl apply发布并更新应用（--record是将当前命令记录到revision记录中，这样Kubernetes就可以知道每个revision对应哪个配置文件）：

通过kubectl rollout history deployment httpd查看revision的历史记录：

执行命令 kubectl rollout undo deployment httpd --to-revision=1  进行回滚，之后查看回滚后的版本，发现已经回到版本1：

再次查看revision的历史记录发现历史记录再更新（通过CHANGE-CAUSE来查找每个revision的具体含义，所以一定要在kubectl apply的时候加上--record记录历史记录）：

下面举一个反面例子不加--record 部署：

根据上图我们发现会更新版本，查看revision，发现没有revision记录描述：

执行回滚命令发现回滚成功，再次查看历史，发现历史也会更新：

得到的结果和上面夹--record参数的结果是一样的，但是由于没有将当前命令记录到revision记录中，会导致根本无法知道revision ID和应用版本的对应情况。

综上：记得加--record