rolling update 主要指的是我们应用程序版本的升级

例如上图，我们刚开始用的nginx1.7.0，当有新的版本的image出现的时候，说明修复了一些bug或者安全更新，我们需要升级到1.7.1 ，我们如何升级呢？

我们可以直接修改deployment 通过kubectl edit命令或者修改文件然后通过jkubectl apply 命令来实现，但是，具体升级过程中pod是如何替换的呢？

deployment有两种升级策略：

Recreate 和 rolling Update . 如下图（下图从左到右是时间线->）

 

Recreate ：当我们修改了镜像版本后，如果是recreate策略，那么kubernetes会直接干掉现有的所有Pod 然后创建新版本的pod，注意此过程因为是全部干掉然后创建新的，所以存在down time

Rolling Update: 当我们修改了镜像版本后，如果是 rolling update 策略，那么kuberenetes会逐个更新，干掉一个旧的，创建一个新的，逐步替换，不存在down time(这个策略也是默认的策略)

 

 

其实原理就是每次升级,kubernetes 就会创建一个新的replica set 和旧的replica set 一模一样（除了镜像版本），然后通过控制新旧两个replicaset的数量来实现rolling update

我们可以通过如下命令来查看rollout 状态：

如果我们在升级完成以后发现升级有问题，想回退，我们可以通过如下命令进行回退