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

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

1. httpd:2.2.31的配置文件为：

2. 通过kubectl apply部署

3. 部署过程为：

   1. 创建Deployment htpd
   2. 创建ReplicaSet httpd-551879778
   3. 创建三个pod
   4. 当前镜像为：httpd:2.2.31

4. 将配置文件中的httpd:2.2.31替换为httpd:2.2.32，再执行kubectl apply

5. 发现：

   1. Deployment httpd的镜像更新为httpd:2.2.32
   2. 新创建了ReplicaSet httpd-1276601241，镜像为httpd:2.2.32并且管理了三个新的pod
   3. 之前的ReplicaSet httpd-551879778里面已经没有任何Pod

6. 结论：ReplicaSet httpd-551879778的三个httpd:2.2.31 pod已经被ReplicaSet httpd-1276601241的三个httpd:2.2.32 pod替换掉了

7. 具体过程通过kubectl describe deployment httpd查看

8. 每次替换的Pod数量是可以定制的，kubernetes提供了两个参数maxSurge和maxUnavailable来精细控制Pod的替换数量

回滚

1. kubectl apply每次更新应用时，kubernetes都会记录下当前的配置，保存为一个revision(版次)，这样就可以回滚到某个revision

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

3. 测试：三个配置文件，即httpd.v1.yml，httpd.v2.yml和httpd.v3.yml，分别对应不同的httpd镜像2.4.16,2.4.17,2.4.18
   
   

4. 通过kubectl apply部署并更新应用

5. –record的作用是将当前命令记录到revision记录中，这样我们就可以知道每个revision对应的是哪个配置文件，通过kubectl rollout history deployment httpd查看revision历史记录

6. change-cause就是–record的结果，如果要回滚到某个版本，比如revision 1，可以执行命令kubectl rollout undo deployment httpd --to-revision=1

7. 此时，revision历史记录也会发生变化，revision1变为了revision4，不过可以通过change-cause知道每个revision的具体含义，所以一定要在执行kubectl apply时加上 --record参数

回滚的意义：滚动更新采用渐进的方式逐步替换旧版本Pod，如果更新不如预期，可以通过回滚操作恢复到更新前的状态