前言
一直以来，知道K8S具有滚动更新的策略，能支持我们发布的应用实时切换上线，不用停机发布，这个本身也是趋势，但是没有好好的了解过K8S是怎么去实现的，今天正好有人问了我这个问题，所以趁着有时间了解了一下。
常用的部署方式
在了解Rolling Update之前，先说下我们的部署方式，在通常情况下，我们不会直接创建一个Pod或者一个Replica Set，而是通过Deployment去发布一个应用，虽然Deployment跟RS的主要职责是一样的，都是保证Pod的数量和监控，二者大部分功能都是完全一致的，可以把Deployment看成是一个升级版的RS，官方也推荐使用Deployment来管理Pod。具体的区别如下。
- Replication Controller全部功能：Deployment继承了上面描述的Replication Controller全部功能。
- 事件和状态查看：可以查看Deployment的升级详细进度和状态。
- 回滚：当升级pod镜像或者相关参数的时候发现问题，可以使用回滚操作回滚到上一个稳定的版本或者指定的版本。
- 版本记录: 每一次对Deployment的操作，都能保存下来，给予后续可能的回滚使用。
- 暂停和启动：对于每一次升级，都能够随时暂停和启动。
- 多种升级方案：Recreate：删除所有已存在的pod,重新创建新的; RollingUpdate：滚动升级，逐步替换的策略，同时滚动升级时，支持更多的附加参数，例如设置最大不可用pod数量，最小升级间隔时间等等。
Rolling Update
本身Rolling Update是支持RS和Deployment，这里以Deployment Rolling Update为例，当我们更新了Deployment中的应用镜像号后，滚动更新是如何工作的呢？我们可以尝试用命令 $ kubectl get rs -w -n namespace |grep Replica Set Name 来监控整个过程，如下图：
可以看到执行新的部署后，Deployment会创建一个新的RS（每个RS具有一个hash Id ），上图中的New RS是：7bbc459bdb ，Old RS是：777458cb8d。从监控过程中看到，一开始创建的时候New RS的Pod副本数是0 ，当RS创建完毕后，会更新成Pod数量为1，当创建的pod ready后，在更新Old
RS的Pod副本数量量为1，随后更新New RS Pod副本数量为2，最后在更新Old RS pod数量为0。 这样就实现了Rolling Update策略（rolling update 可以设置滚动升级百分比）。
那么，每个Replica Set 是怎么知道哪些Pod是由自己去控制的呢？
这个就要说到强大的标签管理了，在创建Pod时，有一个pod-template-hash，通过当前RS创建的Pod，这个hash值是一样的，这样就可以分辨新旧版本的Pod，不会出无法分辨的情况了。至此，相信大家已经搞明白Rolling Update是如何工作了。
PS：另外在K8S中 RS的会默认保存10个历史记录加上一个当前的RS，总共11个RS记录（可以调整）方便我们去做回滚。例如，order service的RS的数量如下。
