首页 » 翻译 » Kubernetes » 正文

kubernete deployment的滚动升级

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

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

k1

 

 

 

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

k2

上图中,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)

k3

如上图,因为设置了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

 

 

 

 

 

 

Zhiming Zhang

Senior devops at Appannie
一个奔跑在运维路上的胖子
Zhiming Zhang

Latest posts by Zhiming Zhang (see all)

发表评论