溫馨提示×
您好，登錄后才能下訂單哦！
點(diǎn)擊 登錄注冊(cè) 即表示同意《億速云用戶(hù)服務(wù)條款》
您好，登錄后才能下訂單哦！
本篇內(nèi)容介紹了“Kubernetes Deployment滾動(dòng)更新機(jī)制是什么”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！
以下面的frontend Deployment為例，重點(diǎn)關(guān)注.spec.minReadySeconds,.spec.strategy.rollingUpdate.maxSurge,.spec.strategy.rollingUpdate. maxUnavailable。
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: frontend spec: minReadySeconds: 5 strategy: type: RollingUpdate rollingUpdate: maxSurge: 3 maxUnavailable: 2 replicas: 25 template: metadata: labels: app: guestbook tier: frontend spec: containers: - name: php-redis image: gcr.io/google-samples/gb-frontend:v4 resources: requests: cpu: 100m memory: 100Mi env: - name: GET_HOSTS_FROM value: dns # If your cluster config does not include a dns service, then to # instead access environment variables to find service host # info, comment out the 'value: dns' line above, and uncomment the # line below: # value: env ports: - containerPort: 80
.spec.minReadySeconds: 新創(chuàng)建的Pod狀態(tài)為Ready持續(xù)的時(shí)間至少為.spec.minReadySeconds才認(rèn)為Pod Available(Ready)。
.spec.strategy.rollingUpdate.maxSurge: specifies the maximum number of Pods that can be created over the desired number of Pods. The value cannot be 0 if MaxUnavailable is 0. 可以為整數(shù)或者百分比，默認(rèn)為desired Pods數(shù)的25%. Scale Up新的ReplicaSet時(shí)，按照比例計(jì)算出允許的MaxSurge，計(jì)算時(shí)向上取整(比如3.4，取4)。
.spec.strategy.rollingUpdate.maxUnavailable: specifies the maximum number of Pods that can be unavailable during the update process. The value cannot be 0 if maxSurge is 0.可以為整數(shù)或者百分比，默認(rèn)為desired Pods數(shù)的25%. Scale Down舊的ReplicaSet時(shí)，按照比例計(jì)算出允許的maxUnavailable，計(jì)算時(shí)向下取整(比如3.6，取3)。
因此，在Deployment rollout時(shí)，需要保證Available(Ready) Pods數(shù)不低于 desired pods number - maxUnavailable; 保證所有的Pods數(shù)不多于 desired pods number + maxSurge。
Note: A Deployment’s rollout is triggered if and only if the Deployment’s pod template (that is, .spec.template) is changed, for example if the labels or container images of the template are updated. Other updates, such as scaling the Deployment, do not trigger a rollout.
我們繼續(xù)以上面的Deployment為例子，并考慮最常用的情況--更新image（發(fā)布新版本）:
kubectl set image deploy frontend php-redis=gcr.io/google-samples/gb-frontend:v3 --record
set image之后，導(dǎo)致Deployment's Pod Template發(fā)生變化，就會(huì)觸發(fā)rollout。我們只考慮RollingUpdate策略（Kubernetes還支持ReCreate更新策略）。通過(guò)kubectl get rs -w來(lái)watch ReplicaSet的變化。
[root@master03 ~]# kubectl get rs -w NAME DESIRED CURRENT READY AGE frontend-3114648124 25 25 25 14m frontend-3099797709 0 0 0 1h frontend-3099797709 0 0 0 1h frontend-3099797709 3 0 0 1h frontend-3114648124 23 25 25 17m frontend-3099797709 5 0 0 1h frontend-3114648124 23 25 25 17m frontend-3114648124 23 23 23 17m frontend-3099797709 5 0 0 1h frontend-3099797709 5 3 0 1h frontend-3099797709 5 5 0 1h frontend-3099797709 5 5 1 1h frontend-3114648124 22 23 23 17m frontend-3099797709 5 5 2 1h frontend-3114648124 22 23 23 17m frontend-3114648124 22 22 22 17m frontend-3099797709 6 5 2 1h frontend-3114648124 21 22 22 17m frontend-3099797709 6 5 2 1h frontend-3114648124 21 22 22 17m frontend-3099797709 7 5 2 1h frontend-3099797709 7 6 2 1h frontend-3114648124 21 21 21 17m frontend-3099797709 7 6 2 1h frontend-3099797709 7 7 2 1h frontend-3099797709 7 7 2 1h frontend-3099797709 7 7 3 1h frontend-3099797709 7 7 4 1h frontend-3114648124 20 21 21 17m frontend-3099797709 8 7 4 1h frontend-3114648124 20 21 21 17m frontend-3114648124 20 20 20 17m frontend-3099797709 8 7 4 1h frontend-3099797709 8 8 4 1h frontend-3099797709 8 8 5 1h frontend-3114648124 19 20 20 17m frontend-3099797709 9 8 5 1h frontend-3114648124 19 20 20 17m frontend-3099797709 9 8 5 1h frontend-3099797709 9 9 5 1h frontend-3114648124 19 19 19 17m frontend-3099797709 9 9 5 1h frontend-3114648124 18 19 19 18m frontend-3099797709 10 9 5 1h frontend-3114648124 18 19 19 18m frontend-3099797709 10 9 5 1h frontend-3114648124 18 18 18 18m frontend-3099797709 10 10 5 1h frontend-3099797709 10 10 5 1h frontend-3114648124 18 18 18 18m frontend-3099797709 10 10 6 1h frontend-3099797709 10 10 6 1h frontend-3114648124 17 18 18 18m frontend-3114648124 17 18 18 18m frontend-3099797709 11 10 6 1h frontend-3099797709 11 10 6 1h frontend-3114648124 17 17 17 18m frontend-3099797709 11 11 6 1h
說(shuō)明：
frontend-3114648124為原來(lái)的RS（成為OldRS），frontend-3099797709為新建的RS（成為NewRS，當(dāng)然也可能是Old RS，如果之前執(zhí)行過(guò)這個(gè)一樣的內(nèi)容）。
maxSurge:3, maxUnavailable=2, desired replicas=25
NewRS創(chuàng)建maxSurge(3)個(gè)Pods，這時(shí)達(dá)到pods數(shù)的上限值desired replicas + maxSurge (28個(gè)）
不會(huì)等NewRS創(chuàng)建的Pods Ready，而是馬上delete OldRS maxUnavailable(2)個(gè)Pods，這時(shí)Ready的Pods number最差也能保證desired replicas - maxUnavailable(23個(gè))
接下來(lái)的流程是不固定，只要新建的Pods有幾個(gè)返回Ready，則意味著可以接著刪除幾個(gè)舊的Pods了。只要有幾個(gè)刪除成功的Pods返回，就會(huì)創(chuàng)建一定數(shù)量的Pods，只要All pods數(shù)量與上限值desired replicas + maxSurge有差值空間，就會(huì)接著創(chuàng)建新的Pods。
如此進(jìn)行滾動(dòng)更新， 直到創(chuàng)建的新Pods個(gè)數(shù)達(dá)到desired replicas，并等待它們都Ready，然后再刪除所有剩余的舊的Pods。至此，滾動(dòng)流程結(jié)束。
我們考慮這個(gè)情況，但用戶(hù)執(zhí)行某個(gè)滾動(dòng)更新后，未等待此次滾動(dòng)更新結(jié)束，就繼續(xù)執(zhí)行了一次新的滾動(dòng)更新請(qǐng)求，這時(shí)后臺(tái)滾動(dòng)流程會(huì)怎么樣呢？會(huì)亂成一鍋粥么？
我們繼續(xù)以這個(gè)例子來(lái)看：
# deploy frontend 穩(wěn)定運(yùn)行在v2(frontend-888714875)時(shí)： [root@master03 ~]# kubectl get rs -w NAME DESIRED CURRENT READY AGE ====執(zhí)行 kubectl set image deploy frontend php-redis=gcr.io/google-samples/gb-frontend:v3 --record ----備注： v3 --> frontend-776431694 frontend-776431694 0 0 0 6h frontend-776431694 0 0 0 6h frontend-776431694 3 0 0 6h frontend-888714875 23 25 25 5h frontend-776431694 5 0 0 6h frontend-888714875 23 25 25 5h frontend-888714875 23 23 23 5h frontend-776431694 5 0 0 6h frontend-776431694 5 3 0 6h frontend-776431694 5 5 0 6h frontend-776431694 5 5 1 6h frontend-776431694 5 5 2 6h frontend-776431694 5 5 3 6h frontend-776431694 5 5 4 6h frontend-776431694 5 5 4 6h frontend-888714875 22 23 23 5h frontend-776431694 6 5 4 6h frontend-888714875 22 23 23 5h frontend-888714875 22 22 22 5h frontend-776431694 6 5 4 6h frontend-776431694 6 6 4 6h frontend-776431694 6 6 4 6h frontend-888714875 19 22 22 5h frontend-776431694 9 6 4 6h frontend-888714875 19 22 22 5h frontend-776431694 9 6 4 6h frontend-888714875 19 19 19 5h frontend-776431694 9 9 4 6h frontend-888714875 19 19 19 5h ==== 執(zhí)行 kubectl set image deploy frontend php-redis=gcr.io/google-samples/gb-frontend:v4 --record ==== ----- 備注：v4 --> frontend-3099797709 ---- frontend-3099797709 0 0 0 6h frontend-3099797709 0 0 0 6h frontend-776431694 4 9 4 6h frontend-3099797709 5 0 0 6h frontend-3099797709 5 0 0 6h frontend-3099797709 5 5 0 6h frontend-776431694 4 9 4 6h frontend-776431694 4 4 4 6h frontend-3099797709 5 5 0 6h frontend-3099797709 5 5 1 6h frontend-3099797709 5 5 2 6h frontend-3099797709 5 5 3 6h frontend-3099797709 5 5 4 6h frontend-3099797709 5 5 4 6h frontend-776431694 2 4 4 6h frontend-3099797709 7 5 4 6h frontend-776431694 2 4 4 6h frontend-776431694 2 2 2 6h frontend-776431694 2 2 2 6h frontend-3099797709 7 5 4 6h frontend-776431694 0 2 2 6h frontend-3099797709 7 7 4 6h frontend-776431694 0 2 2 6h frontend-3099797709 9 7 4 6h frontend-776431694 0 0 0 6h frontend-3099797709 9 7 4 6h frontend-3099797709 9 9 4 6h frontend-776431694 0 0 0 6h frontend-3099797709 9 9 4 6h frontend-3099797709 9 9 5 6h frontend-3099797709 9 9 6 6h frontend-3099797709 9 9 7 6h frontend-888714875 17 19 19 5h frontend-3099797709 11 9 7 6h frontend-888714875 17 19 19 5h frontend-888714875 17 17 17 5h frontend-3099797709 11 9 7 6h frontend-888714875 16 17 17 5h frontend-3099797709 11 11 7 6h frontend-3099797709 12 11 7 6h frontend-888714875 16 17 17 5h frontend-888714875 16 16 16 5h frontend-3099797709 12 11 7 6h frontend-3099797709 12 12 7 6h frontend-3099797709 12 12 8 6h frontend-3099797709 12 12 8 6h frontend-888714875 15 16 16 5h frontend-3099797709 13 12 8 6h frontend-888714875 15 16 16 5h frontend-888714875 15 15 15 5h frontend-3099797709 13 12 8 6h frontend-3099797709 13 13 8 6h frontend-3099797709 13 13 8 6h frontend-3099797709 13 13 9 6h frontend-3099797709 13 13 10 6h frontend-888714875 14 15 15 5h frontend-3099797709 14 13 10 6h frontend-888714875 14 15 15 5h frontend-888714875 14 14 14 5h frontend-3099797709 14 13 10 6h frontend-888714875 14 14 14 5h frontend-3099797709 14 14 11 6h frontend-3099797709 14 14 12 6h frontend-3099797709 14 14 12 6h frontend-3099797709 14 14 12 6h frontend-888714875 11 14 14 5h frontend-3099797709 17 14 12 6h frontend-888714875 11 14 14 5h frontend-3099797709 17 14 12 6h frontend-888714875 11 11 11 5h frontend-3099797709 17 17 12 6h frontend-888714875 11 11 11 5h frontend-3099797709 17 17 12 6h frontend-3099797709 17 17 13 6h frontend-3099797709 17 17 14 6h frontend-3099797709 17 17 14 6h frontend-888714875 10 11 11 5h frontend-3099797709 18 17 14 6h frontend-888714875 10 11 11 5h frontend-888714875 10 10 10 5h frontend-3099797709 18 17 14 6h frontend-3099797709 18 18 14 6h frontend-3099797709 18 18 15 6h frontend-888714875 9 10 10 5h frontend-3099797709 18 18 16 6h frontend-888714875 9 10 10 5h frontend-3099797709 19 18 16 6h frontend-3099797709 19 18 16 6h frontend-888714875 9 9 9 5h frontend-888714875 7 9 9 5h frontend-3099797709 19 18 16 6h frontend-888714875 7 9 9 5h frontend-3099797709 21 18 16 6h frontend-888714875 7 9 9 5h frontend-3099797709 21 19 16 6h frontend-888714875 7 7 7 5h frontend-3099797709 21 21 16 6h frontend-888714875 7 7 7 5h frontend-3099797709 21 21 17 6h frontend-3099797709 21 21 18 6h frontend-3099797709 21 21 18 6h frontend-888714875 5 7 7 5h frontend-888714875 5 7 7 5h frontend-3099797709 23 21 18 6h frontend-888714875 5 5 5 5h frontend-3099797709 23 21 18 6h frontend-3099797709 23 23 18 6h frontend-3099797709 23 23 18 6h frontend-3099797709 23 23 19 6h frontend-3099797709 23 23 20 6h frontend-3099797709 23 23 20 6h frontend-888714875 3 5 5 5h frontend-3099797709 25 23 20 6h frontend-888714875 3 5 5 5h frontend-888714875 3 3 3 5h frontend-3099797709 25 23 20 6h frontend-888714875 3 3 3 5h frontend-3099797709 25 25 20 6h frontend-3099797709 25 25 21 6h frontend-3099797709 25 25 22 6h frontend-3099797709 25 25 22 6h frontend-888714875 2 3 3 5h frontend-888714875 2 3 3 5h frontend-888714875 2 2 2 5h frontend-888714875 2 2 2 5h frontend-3099797709 25 25 23 6h frontend-888714875 1 2 2 5h frontend-888714875 1 2 2 5h frontend-888714875 1 1 1 5h frontend-3099797709 25 25 23 6h frontend-888714875 0 1 1 5h frontend-888714875 0 1 1 5h frontend-888714875 0 0 0 5h frontend-3099797709 25 25 24 6h frontend-3099797709 25 25 25 6h frontend-3099797709 25 25 25 6h
說(shuō)明：
deployment frontend穩(wěn)定運(yùn)行在v2版本(RS：frontend-888714875)，然后執(zhí)行kubectl set image觸發(fā)滾動(dòng)更新到v3版本（RS: frontend-776431694）, 當(dāng)v3 RS的desired個(gè)數(shù)scale up到9個(gè)，ready個(gè)數(shù)為4個(gè)時(shí)，用戶(hù)又執(zhí)行kubectl set image觸發(fā)滾動(dòng)更新到v4版本（RS: frontend-3099797709）。
v2到v3的滾動(dòng)流程同上一小節(jié)的描述；
當(dāng)新的滾動(dòng)流程觸發(fā)后，最老的v2的RS保持不動(dòng)，不會(huì)繼續(xù)scale down。
然后v4將通過(guò)滾動(dòng)更新的方式把已經(jīng)scale up的9個(gè)v3 RS的pods替換掉，將所有v3的Pods升級(jí)到v4。
最后再接著v4 RS滾動(dòng)更新把v2的RS所有的舊Pods都升級(jí)到v4。
整個(gè)完整的滾動(dòng)流程中，都必須遵守maxSurge和maxUnavailable的約束，不能越雷池半步。
設(shè)想一個(gè)更復(fù)雜的場(chǎng)景：如果在上述v4滾動(dòng)更新替換到半吊子的v3 RS過(guò)程中，用戶(hù)又觸發(fā)了一個(gè)滾動(dòng)更新到v5版本，流程會(huì)怎么樣呢？ 不要怕，原理是一樣的，Deployment rolling update總是先把最新的RS滾動(dòng)更新替換掉，然后逐步把舊的RS滾動(dòng)更新替換掉，直到最最老的那個(gè)RS scale down為0，流程就結(jié)束了，可以簡(jiǎn)要概括如下：
剩余的v2, v3停止scale down；
v5把v4通過(guò)滾動(dòng)更新的方式替換掉;
v5再把剩余v3通過(guò)滾動(dòng)更新的方式替換掉;
v5再把剩余v2通過(guò)滾動(dòng)更新的方式替換掉;
最后的RS會(huì)按照RS從新到舊排序的方式，逐步把舊的RS Pods scale down to 0， 自己 scale up to desired pods number。
或許很多人至今還會(huì)這么覺(jué)得：整個(gè)滾動(dòng)更新的過(guò)程中，一旦用戶(hù)執(zhí)行了kubectl rollout pause deploy/frontend后，正在執(zhí)行的滾動(dòng)流程就會(huì)立刻停止，然后用戶(hù)執(zhí)行kubectl rollout resume deploy/frontend就會(huì)繼續(xù)未完成的滾動(dòng)更新。那你就大錯(cuò)特錯(cuò)了！
kubectl rollout pause只會(huì)用來(lái)停止觸發(fā)下一次rollout。什么意思呢？ 上面描述的這個(gè)場(chǎng)景，正在執(zhí)行的滾動(dòng)歷程是不會(huì)停下來(lái)的，而是會(huì)繼續(xù)正常的進(jìn)行滾動(dòng)，直到完成。等下一次，用戶(hù)再次觸發(fā)rollout時(shí)，Deployment就不會(huì)真的去啟動(dòng)執(zhí)行滾動(dòng)更新了，而是等待用戶(hù)執(zhí)行了kubectl rollout resume，流程才會(huì)真正啟動(dòng)執(zhí)行。
前提，你要知道關(guān)于
--record：
Setting the kubectl flag --record to true allows you to record current command in the annotations of the resources being created or updated.
默認(rèn)情況下，所有通過(guò)kubectl xxxx --record都會(huì)被kubernetes記錄到etcd進(jìn)行持久化，這無(wú)疑會(huì)占用資源，最重要的是，時(shí)間久了，當(dāng)你kubectl get rs時(shí)，會(huì)有成百上千的垃圾RS返回給你，那時(shí)你可能就眼花繚亂了。
上生產(chǎn)時(shí)，我們最好通過(guò)設(shè)置Deployment的.spec.revisionHistoryLimit來(lái)限制最大保留的revision number，比如15個(gè)版本，回滾的時(shí)候一般只會(huì)回滾到最近的幾個(gè)版本就足夠了。
執(zhí)行下面的命令，可以返回某個(gè)Deployment的所有record記錄：
$ kubectl rollout history deployment/nginx-deployment deployments "nginx-deployment" REVISION CHANGE-CAUSE 1 kubectl create -f docs/user-guide/nginx-deployment.yaml --record 2 kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 3 kubectl set image deployment/nginx-deployment nginx=nginx:1.91
然后執(zhí)行rollout undo命令就可以回滾到to-revision指定的版本。
kubectl rollout undo deployment/nginx-deployment --to-revision=2 deployment "nginx-deployment" rolled back
其實(shí)rollout history中記錄的revision都和ReplicaSets一一對(duì)應(yīng)。如果手動(dòng)delete某個(gè)ReplicaSet，對(duì)應(yīng)的rollout history就會(huì)被刪除，也就是還說(shuō)你無(wú)法回滾到這個(gè)revison了。
roolout history和ReplicaSet的對(duì)應(yīng)關(guān)系，可以在kubectl describe rs $RSNAME返回的revision字段中得到，這里的revision就對(duì)應(yīng)著roolout history返回的revison。
“Kubernetes Deployment滾動(dòng)更新機(jī)制是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！
免責(zé)聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱：is@yisu.com進(jìn)行舉報(bào)，并提供相關(guān)證據(jù)，一經(jīng)查實(shí)，將立刻刪除涉嫌侵權(quán)內(nèi)容。
億速云公眾號(hào)
手機(jī)網(wǎng)站二維碼
