第7章　Rolling Update

滚动更新是一次只更新一小部分副本，成功后再更新更多的副本，最终完成所有副本的更新。滚动更新的最大好处是零停机，整个更新过程始终有副本在运行，从而保证了业务的连续性。

7.1　实践

下面我们部署三副本应用，初始镜像为httpd:2.2.31，然后将其更新到httpd:2.2.32。

httpd:2.2.31的配置文件如图7-1所示。

图7-1

通过kubectl apply部署，如图7-2所示。

图7-2

部署过程如下：

（1）创建Deployment httpd。

（2）创建ReplicaSet httpd-551879778。

（3）创建三个Pod。

（4）当前镜像为httpd:2.2.31。

将配置文件中的httpd:2.2.31替换为httpd:2.2.32，再次执行kubectl apply，如图7-3所示。

图7-3

我们发现了如下变化：

（1）Deployment httpd的镜像更新为httpd:2.2.32。

（2）新创建了ReplicaSet httpd-1276601241，镜像为httpd:2.2.32，并且管理了三个新的Pod。

（3）之前的ReplicaSet httpd-551879778里面已经没有任何Pod。

结论是：ReplicaSet httpd-551879778的三个httpd:2.2.31 Pod已经被ReplicaSet httpd-1276601241的三个httpd:2.2.32 Pod替换了。

具体过程可以通过kubectl describe deployment httpd查看，如图7-4所示。

图7-4

每次只更新替换一个Pod：

（1）ReplicaSet httpd-1276601241增加一个Pod，总数为1。

（2）ReplicaSet httpd-551879778减少一个Pod，总数为2。

（3）ReplicaSet httpd-1276601241增加一个Pod，总数为2。

（4）ReplicaSet httpd-551879778减少一个Pod，总数为1。

（5）ReplicaSet httpd-1276601241增加一个Pod，总数为3。

（6）ReplicaSet httpd-551879778减少一个Pod，总数为0。

每次替换的Pod数量是可以定制的。Kubernetes提供了两个参数maxSurge和maxUnavailable来精细控制Pod的替换数量，我们将在后面结合Health Check特性一起讨论。

7.2　回滚

kubectl apply每次更新应用时，Kubernetes都会记录下当前的配置，保存为一个revision（版次），这样就可以回滚到某个特定revision。

默认配置下，Kubernetes只会保留最近的几个revision，可以在Deployment配置文件中通过revisionHistoryLimit属性增加revision数量。

下面实践回滚功能。应用有三个配置文件，即httpd.v1.yml、httpd.v2.yml和httpd.v3.yml，分别对应不同的httpd镜像2.4.16、2.4.17和2.4.18，如图7-5、图7-6、图7-7所示。

图7-5

图7-6

图7-7

通过kubectl apply部署并更新应用，如图7-8所示。

图7-8

--record的作用是将当前命令记录到revision记录中，这样我们就可以知道每个revison对应的是哪个配置文件了。通过kubectl rollout history deployment httpd查看revison历史记录，如图7-9所示。

图7-9

CHANGE-CAUSE就是--record的结果。如果要回滚到某个版本，比如revision 1，可以执行命令kubectl rollout undo deployment httpd --to-revision=1，如图7-10所示。

图7-10

此时，revison历史记录也会发生相应变化，如图7-11所示。

图7-11

revison 1变成了revison 4。不过我们可以通过CHANGE-CAUSE知道每个revison的具体含义，所以一定要在执行kubectl apply时加上--record参数。

7.3　小结

本章我们学习了滚动更新。滚动更新采用渐进的方式逐步替换旧版本Pod。如果更新不如预期，可以通过回滚操作恢复到更新前的状态。