kubernetes中Deployment的更新策略

在kubernetes中，pod的更新策略尤为重要，特别是在版本迭代的过程中，既要要求新版本上线，也要要求旧版本的可用，才能够保证用户持续不中断。在kubernetes中，提供了两种更新策略，分别是滚动更新（rollingUpdate)和重建更新（Recreate）不过在我们实际使用中用的最多的就是滚动更新，下面看看两种的区别。

滚动更新(rollingUpdate)

滚动更新是比较常用的方式，在更新过程中，会在删除旧pod的同时创建新的pod，这种更新方式的好处在于，可以维持服务的正常使用，服务运行不会中断。但是这样做的问题在于，会有一段时间是新版本的Pod和旧版本的Pod同时对外提供服务，客户端接收的服务可能来源于老版本的Pod，也可能来源于新版本的Pod，这将会导致服务上的差异性。事实上，相对比与其缺点，滚动更新策略的优点更加明显，即业务连续不中断，并且新老版本Pod并存可以使得提前检验新版本Pod的可用性，如果发现更新后服务出现问题，更是可以提前发现，提前处理。同时，滚动更新的缺点也可以通过分区域更新等方式来进行解决。因此，我们最常用的更新策略就是滚动更新，并且滚动更新也是Deployment控制器的默认更新策略。 Deployment滚动更新过程示意图如下所示：

重建更新(Recreate)

重建更新指的是先全部删除已有的Pod对象，然后创建新版本的Pod对象。这种更新方式，最大的弊端是在更新过程中，运行的服务要有一定时间的中断。但是有点在于这种方式的更新，没有出现新、老版本的Pod共存，并且共同提供服务的阶段。但是，相比于其有点，其缺点尤为明显。因此，在生产环境中，我们几乎很少使用重建更新这一种更新策略。使用的大多是滚动更新。

更新使用方法**

在更新过程中不管使用什么方式都可以，这里没有任何强制，不过默认的都是滚动更新方式，如果想使用重建更新(Recreate)可以在pod的yaml文件中进行修改，看下面的例子。

apiVersion: app/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 1
  minReadySeconds: 15
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.12
        ports:
        - containerPort: 80

这里使用的关键词是strategy，下面针对这些关键词的控制参数分别解释一下。

  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 1
  minReadySeconds: 15

type:类型就是更新方式，RollingUpdate是滚动更新，Recreate是重建更新。

maxSurge: 最大激增数, 指更新过程中, 最多可以比replicas预先设定值多出的pod数量, 可以为固定值或百分比(默认25%), 更新过程中最多会有replicas + maxSurge个pod

maxUnavailable: 最大无效数, 指更新过程中, 最多有几个pod处于无法服务状态, 当maxSurge不为0时, 此栏位也不可为0, 整个更新过程中, 会有maxUnavailable个pod处于Terminating状态

minReadySeconds: 容器内应用的启动时间, pod变为run状态, 会在minReadySeconds后继续更新下一个pod. 如果不设置该属性, pod会在run成功后, 立即更新下一个pod.

这里的更新必须注意的是，如果你的replicas比较大，需要考虑的是你的资源使用情况，比如你的副本数是3，剩余资源只能创建2个，在版本迭代中会对node节点资源不够使用的问题，所以需要在版本中只能创建一个，删除一个，这样的使用使用率才是最高的。