Rolling Update

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

2. 部署三副本的应用，初始镜像为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的替换数量

3. 回滚

   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参数

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