kubernete 提供了非常简单易用的应用升级方式，也就是deployment 的rolling- update

例如，我们现在运行的程序镜像版本为V1 ，我们需要升级到新版本V2，我们该如何操作，我们先看一下原理，所有的deployment 都是通过ReplicationController 来控制具体的POD，我们的升级过程如下：（删掉所有现在的POD，然后创建新的，有outage 时间）

 

 

 

当然这种方式是我们非常不建议的，看一下另外一个选择（逐步替换现在V1的pod，不会出现outage）

上图中，kubernete会帮我们先删掉一个V1 ，然后增加一个V2 ，等v2 ready以后，再替换另外一个v1的镜像，这个地方需要注意，这个时候发过来的请求有的会到V1 版本，有的会到V2版本，这个升级过程中，我们可以看到kubernete帮我们额外创建了一个ReplicaSet 来管理V2 ， 当然最后会删掉

其实，上边两个图解分别对应了我们deployment 里边的两种升级策略，第一张图：Recreate 第二张图：RollingUpdate（默认策略）

当我们修改了我们deployment里边的镜像以后，会自动触发RollingUpdate（修改的方式有很多，kubectl edit deployment , kubectl patch ,kubectl apply , kubectl replace , kubectl setimage ）

在升级过程中，有两个参数很重要：分别是maxSurge 和 maxUnavailable

maxSurge: 允许在升级过程中最多可以超过期望数值多少，默认是25%，例如我们的deployment定义的replica数量是4,也就是说升级过程中，最多允许同时5个pod存在

maxUnavailable：升级过程中最多允许多少pod处于不可用状态，默认值也是25%，也就是说，4个pod的话，无论什么时候都只能有1个Pod不可用（这个地方需要注意，其实1是相对于 期望个数来说的，4个pod – 1 个pod ，也就是无论什么时候，至少要有3个Pod可用）

下边看一个有趣的例子：如果设置MaxUnavailable =0 （期望pod的数量为3）

如上图，因为设置了MaxUnavailable =0 ，也就是不允许有失败的（针对于目标期望值3 ，不允许有失败的，也就是 必须有3个及以上的pod可用），所以kubernete想帮我们增加v2，而不是删除v1，因为如果先删除v1的一个pod，就不满足3个可用pod的条件了

第二个例子，如果设置MaxUnavailable =1

这个时候Kubernete就帮我们先删除了一个v1，因为我们告诉kubernete说只要保证2个可用就可以（3-1）

如果，我们改完了镜像后开发跑来说刚刚发现了一个严重bug，需要回退更新，我们当然可以把镜像再改回v1，然后等Kubernete重复上边的步骤，我们也可以使用kubernetes提供给我们的快速回退功能：

这个命令是回退最后一次的update