最新消息:

Kubernetes实现滚动升级(rolling update)

IT技术 ipcpu 12154浏览

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加入相关升级策略设定

  1. spec:
  2. replicas: 4
  3. selector:
  4. matchLabels:
  5. app: buniess
  6. strategy:
  7. type: RollingUpdate
  8. rollingUpdate:
  9. maxSurge: 2
  10. maxUnavailable: 2
  11. minReadySeconds: 5
  12. 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

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

3.2 方法二:使用kubectl replace

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

  1. spec:
  2. containers:
  3. - name: nginx
  4. # newer image version
  5. image: nginx:1.11.5
  6. imagePullPolicy: IfNotPresent
  7. #@
  8. #@然后执行替换操作
  9. $ kubectl replace -f new-nginx.yaml --record

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

  1. #@查询升级状况
  2. $ kubectl rollout status deployment <deployment>
  3. #@暂停滚动升级
  4. $ kubectl rollout pause deployment <deployment>
  5. #@恢复滚动升级
  6. $ kubectl rollout resume deployment <deployment>

四、回滚

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

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

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

  1. minReadySeconds: 5
  2. revisionHistoryLimit: 10

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

  1. # to previous revision
  2. $ kubectl rollout undo deployment <deployment>
  3. # to specific revision
  4. $ kubectl rollout undo deployment <deployment> --to-revision=<revision>
  5. # exmaple
  6. $ 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并不会丢失)

六、参考资料

https://tachingchen.com/tw/blog/Kubernetes-Rolling-Update-with-Deployment/

http://samchu.logdown.com/posts/2462697-learn-how-to-use-kubernetes-deployment-to-rolling-update-in-thirty-second

http://blog.csdn.net/WaltonWang/article/details/77461697?locationNum=5&fps=1

转载请注明:IPCPU-网络之路 » Kubernetes实现滚动升级(rolling update)