今天继续给大家介绍Linux运维相关知识，本文主要内容是Deployment控制器更新策略。
一、Deployment更新策略简介
在前文Kubernetes详解（二十二）——Deployment控制器中，我们介绍了Deployment控制器的基本知识以及资源清单创建过程。今天，我们来讲解一下Deployment控制器控制Pod更新的基本知识。
ReplicaSet控制器的应用更新需要手动分成多步并且按照次序完成，过程繁琐还容易出错。（在Kubernetes详解（二十一）——ReplicaSet控制器实战应用一文中我们讲到过，ReplicaSet在设置Pod更新后，不会立即更新Pod，而是需要我们手动删除之前的Pod后才会更新Pod）而如果我们使用Deployment控制器，当我们配置Pod更新后，Deployment控制器就会自动执行Pod的更新操作，无需我们手动控制，并且还支持我们通过提前设置参数的方式干预其更新过程。
二、Deployment更新分类
Deployment控制器支持两种更新策略——滚动更新（rollingUpdate）和重建更新（Recreate）。这两种更新策略差异如下：
1、重建更新。
重建更新指的是先全部删除已有的Pod对象，然后创建新版本的Pod对象。这种更新方式，最大的弊端是在更新过程中，运行的服务要有一定时间的中断。但是有点在于这种方式的更新，没有出现新、老版本的Pod共存，并且共同提供服务的阶段。但是，相比于其有点，其缺点尤为明显。因此，在生产环境中，我们几乎很少使用重建更新这一种更新策略。使用的大多是滚动更新。接下来，我就给大家详细介绍滚动更新的过程。
2、滚动更新。
在删除一部分老旧版本的Pod的同时，创建新版本的Pod资源。这种更新方式的好处在于，可以维持服务的正常提供，服务运行不会中断。但是这样做的问题在于，会存在一段时间，新版本的Pod和旧版本的Pod同时提供服务，客户端接收的服务可能来源于老版本的Pod，也可能来源于新版本的Pod，这将会导致服务上的差异性。事实上，相对比与其缺点，滚动更新策略的优点更加明显，即业务连续不中断，并且新老版本Pod并存可以使得提前检验新版本Pod的可用性，如果发现更新后服务出现问题，更是可以提前发现，提前处理。同时，滚动更新的缺点也可以通过分区域更新等方式来进行解决。因此，我们最常用的更新策略就是滚动更新，并且滚动更新也是Deployment控制器的默认更新策略。
Deployment滚动更新过程示意图如下所示：
三、Deployment更新控制参数
在Deployment滚动更新过程中，我们可以使用maxSurge和maxAvailable两个参数来控制滚动更新的过程。这两个参数一般同时进行定义，其含义分别如下：
1、maxSurge
指定在更新过程中，Pod的实际数量比Pod的期望数量可以多出的个数或者是百分比。该参数的值可以是0、正整数或者是一个百分比。例如，如果该参数设置为2，Pod的数量设置为3，那么在pod的更新过程中，Pod的数量最多为4。
2、maxAvailable
指定在更新过程中，Pod的实际数量必Pod的期望数量可以少的个数或者是百分比。该参数的值可以是0、正整数或者是一个百分比。例如，如果该参数设置为2，Pod的数量设置为3，那么在pod的更新过程中，Pod的数量最少为1。
从以上解释可以看出，maxSurge参数主要指定了在更新过程中Pod的最大值，防止在更新过程占据大量资源，而maxAvailable参数则主要指定了更新过程中Pod的最小值，防止在Pod更新过程中因为Pod数量不足而使得服务异常。
原创不易，转载请说明出处：https://blog.csdn.net/weixin_40228200