Kubernetes实现滚动升级(rolling update)

Kubernetes实现滚动升级(rolling update).md

一、概述

在新版的Kubernetes官方推荐使用Deployment来取代Replication Controller(rc) ，两者间主要相同点包括确保处在服务状态的Pod数量(replicas)能满足先前所设定的值以及支援滚动升级(Rolling update)，前者额外支持回滚(Roll back)的机制，因此接下来会介绍如何利用Deployment来进行滚动升级。

二、PODS、REPLICA SETS、DEPLOYMENT 三者关系图

从图中可以看到一个Deployment掌管一或多个Replica Set ，而一个Replica Set掌管一或多个Pod 。

三、滚动升级(ROLLING UPDATE)

为了让Kubernetes能够按照我们所想的方式来进行滚动升级，首先我们必须在刚刚的yaml档内的spec加入相关升级策略设定

spec:
  replicas: 4
  selector:
    matchLabels:
      app: buniess
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 2
  minReadySeconds: 5
  template:

以下是参数的介绍：

minReadySeconds: 容器内应用程式的启动时间，Kubernetes 会等待设定的时间后才继续进行升级流程，如果没有此栏位的话，Kubernetes 会假设该容器一开完后即可进行服务
maxSurge: 升级过程中最多可以比原先设定所多出的pod 数量，此栏位可以为固定值或是比例(%)例如. maxSurge: 1、replicas: 5，代表Kubernetes 会先开好1 个新pod 后才删掉一个旧的pod，整个升级过程中最多会有5+1 个pod
maxUnavailable: 最多可以有几个pod 处在无法服务的状态，当maxSurge不为零时，此栏位亦不可为零。例如. maxUnavailable: 1，代表Kubernetes 整个升级过程中最多会有1 个pod 处在无法服务的状态

以下有几种方式都可以实现滚动升级

3.1 方法一：使用kubectl set image

# format
$ kubectl set image deployment <deployment> <container>=<image> --record
# example
kubectl set image deployment  buniess  buniess=reg.pcs.com/google_containers/wss:3.0 --record

3.2 方法二：使用kubectl replace

编辑原先的配置文件，修改镜像部分

spec:
  containers:
  - name: nginx
    # newer image version
    image: nginx:1.11.5
    imagePullPolicy: IfNotPresent
#@
#@然后执行替换操作
$ kubectl replace -f new-nginx.yaml --record

3.3 查询升级状态、暂停和恢复

#@查询升级状况
$ kubectl rollout status deployment <deployment>
#@暂停滚动升级
$ kubectl rollout pause deployment <deployment>
#@恢复滚动升级
$ kubectl rollout resume deployment <deployment>

四、回滚

由于我们之前的操作都加了–record 的参数，這参数主要是告知 Kubernetes 记录此次下达的指令，所以我们可以通过以下命令来查看

[root@nhdta-1 buniess]# kubectl rollout history deployment buniess
deployments "buniess"
REVISION  CHANGE-CAUSE
1         <none>
2         <none>
3         kubectl set image deployment buniess buniess=reg.pcs.com/google_containers/wss:3.0 --record=true
4         kubectl set image deployment buniess buniess=reg.pcs.com/google_containers/wss:4.0 --record=true

这些个记录能保存多少个呢？默认是全部保存的。可以通过设置.spec.revisionHistoryLimit 来决定记录的个数，一般生产环境记录10个左右就差不多了。要不然可能会被刷屏。

  minReadySeconds: 5
  revisionHistoryLimit: 10

可以通过以下命令，来回滚到上一个版本或者特定版本

# to previous revision
$ kubectl rollout undo deployment <deployment>
# to specific revision
$ kubectl rollout undo deployment <deployment> --to-revision=<revision>
# exmaple
$ kubectl rollout undo deployment buniess --to-revision=3

五、理解rollout pause和resume（补充）

或许很多人至今还会这么觉得：整个滚动更新的过程中，一旦用户执行了kubectl rollout pause deploy/frontend后，正在执行的滚动流程就会立刻停止，然后用户执行kubectl rollout resume deploy/frontend就会继续未完成的滚动更新。那你就大错特错了！

kubectl rollout pause只会用来停止触发下一次rollout。什么意思呢？上面描述的这个场景，正在执行的滚动历程是不会停下来的，而是会继续正常的进行滚动，直到完成。等下一次，用户再次触发rollout时，Deployment就不会真的去启动执行滚动更新了，而是被卡住。直到执行了kubectl rollout resume原来被pause卡住的rollout才会继续进行。（被卡住的rollout并不会丢失）