簡介

當kubernetes集群中的某個服務需要升級時，傳統的做法是，先將要更新的服務下線，業務停止后再更新版本和配置，然后重新啟動并提供服務。如果業務集群規模較大時，這個工作就變成了一個挑戰，而且先全部了停止，再逐步升級的方式會導致服務較長時間不可用。kubernetes提供了滾動更新(rolling-update)的方式來解決上述問題。

簡單來說，滾動更新就是針對多實例服務的一種不中斷服務的更新升級方式。一般情況下，對于多實例服務，滾動更新采用對各個實例逐個進行單獨更新而非同一時刻對所有實例進行全部更新的方式。

對于k8s集群部署的service來說，rolling update就是指一次僅更新一個pod，并逐個進行更新，而不是在同一時刻將該service下面的所有pod shutdown，避免業務中斷。

Service、Deployment、RS、RC和Pod之間的關系

對于我們要部署的應用來說，一般是由多個抽象的service組成。在kubernetes中，一個service通過label selector match出一個pods集合，這些Pods作為service的endpoint，是真正承載業務的實體。而pod在集群內的部署、調度、副本數則是通過Deployment或者RC這些更高級別的抽象來管理的。如下圖：

新版本的Kubernetes推薦用Deployment替代ReplicationController，在Deployment這個概念下在保持Pod副本數上實際發揮作用的是隱藏在背后的Replica Set。

因此，我們可以看到Kubernetes上Service的rolling update實質上是對Service所match出來的Pod集合的Rolling update，而控制Pod部署、調度和副本調度的卻又恰恰是Deployment和replication controller，因此后兩者才是kubernetes service rolling update真正要面對的實體。

使用kubectl rolling-update更新

使用kubectl rolling-update命令的方式，主要是針對使用RC創建的pods。
先來看下面一個示例，創建一個包含4個nginx副本的RC nginx-demo-v1-rc.yml：

apiVersion: v1 kind: ReplicationController metadata:name: nginx-demo-v1 spec:replicas: 4selector:app: nginx-demover: v1template:metadata:labels:app: nginx-demover: v1spec:containers:- name: nginx-demoimage: nginx:1.10.1ports:- containerPort: 80protocol: TCPenv:- name: NGX_DEMO_VERvalue: v1

創建一個service，nginx-demo-svc.yml內容如下：

apiVersion: v1 kind: Service metadata:name: nginx-demo-svc spec:ports:- port: 80protocol: TCPselector:app: nginx-demo

創建rc和service：

kubectl create -f nginx-demo-v1-rc.yml kubectl create -f nginx-demo-svc.yml

創建完成以后，可以通過訪問任一Pod的環境變量查看NGX_DEMO_VER的值，為v1

現在我們創建一個nginx-demo-v2-rc.yml的文件，來升級現有的pod：

apiVersion: v1 kind: ReplicationController metadata:name: nginx-demo-v2 spec:replicas: 4selector:app: nginx-demover: v2template:metadata:labels:app: nginx-demover: v2spec:containers:- name: nginx-demoimage: nginx:1.11.9ports:- containerPort: 80protocol: TCPenv:- name: NGX_DEMO_VERvalue: v2

執行更新操作：

kubectl rolling-update nginx-demo-svc -f nginx-demo-v2-rc.yml

需要注意的是，在執行滾動升級時，兩個版本的yml文件區別：

• RC的名字不能與舊的RC名字相同
• 在selector中應至少有一個label與舊的RC的label不同，以標識其為新的RC。

我們可以通過如下操作來查看更新的完整過程：

kubectl rolling-update nginx-demo-v1 --udpate-period=10s -f nginx-demo-v2-rc.yml

當所有舊的pod被新的Pod替換完成以后，更新完成。

使用kubectl rolling-update實現滾動更新的不足：

• rolling-update的邏輯是由kubectl發出N條命令到APIServer完成的，很可能因為網絡原因導致update中斷
• 需要創建一個新的rc，名字與要更新的rc不能一樣
• 回滾還需要執行rolling-update，只是用老的版本替換新的版本
• service執行的rolling-update在集群中沒有記錄，后續無法跟蹤rolling-update歷史

現如今，RC的方式已經被Deployment替代。

Deployment的rolling-update

kubernetes的Deployment是一個更高級別的抽象。Deployment會創建一個Replica Set，用來保證Deployment中的Pod的副本數。要rolling-update deployment中的Pod，只需要修改Deployment自己的yml文件并應用即可。這個修改會創建一個新的Replica Set，在增加這個新RS的pod數的同時，減少舊RS的pod，直至完全升級。而這一切都發生在Server端，并不需要kubectl參與。

創建一個Deployment yml文件nginx-demo-dm.yml：

apiVersion: extensions/v1beta1 kind: Deployment metadata:name: nginx-demo spec:replicas: 4selector:matchLabels:app: nginx-demominReadySeconds: 10template:metadata:labels:app: nginx-demoversion: v1spec:containers:- name: deployment-demoimage: nginx:1.10.1ports:- containerPort: 80protocol: TCP

創建該deployment：

kubectl create -f nginx-demo-dm.yml --record

然后我們可以直接修改該deployment文件，如下 ：

apiVersion: extensions/v1beta1 kind: Deployment metadata:name: nginx-demo spec:replicas: 4selector:matchLabels:app: nginx-demominReadySeconds: 10template:metadata:labels:app: nginx-demoversion: v2spec:containers:- name: deployment-demoimage: nginx:1.11.9ports:- containerPort: 80protocol: TCP

一共就改了兩個地方，將version改為了v2，將nginx鏡像從1.10.1改到了1.11.9，執行如下操作應用更改：

kubectl apply -f nginx-demo-dm.yml --record

這個時候，我們可以通過執行kubectl get rs來查看到rs的變化，以確認是否在執行升級。也可以通過kubectl describe deployment nginx-demo來查看詳細的rolling-update的過程。還可以通過kubectl rollout status deployment/nginx-demo來查看更新狀態。

除了使用apply方式來應用更改以外，還有另外一種方式可以直接升級。就是通過kubectl edit nginx-demo-dm.yml來編輯deployment文件，保存以后，不需要執行apply，就會自動完成升級。

我們可以注意到，在執行deployment的操作時，使用了一個–record參數，這個參數是用來告訴apiserver記錄update的歷史。可以通過如下命令來查看update歷史：

kubectl rollout history deployment nginx-demo

查看指定revision的詳細信息：

kubectl rollout history deployment hello-deployment --revision=2

需要說明的是，在升級完成以后，舊的RS也不會被刪除，這些信息都會存儲到server端，以方便回滾。
deployment下的pod的回滾操作相當簡單，直接執行rollout undo即可將deployment回滾到record中記錄的上一個revision：

kubectl rollout undo deployment nginx-demo

執行如下操作，回滾到指定版本：

kubectl rollout undo deployment hello-deployment --to-version=2

參考鏈接：http://www.bubuko.com/infodetail-2560035.html

總結

以上是生活随笔為你收集整理的K8S滚动更新示例演示的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。