Pod的升級(jí)和回滾
當(dāng)集群中的某個(gè)服務(wù)需要升級(jí)時(shí)，我們需要停止目前與該服務(wù)相關(guān)的所有Pod斥废，然后下載新版本鏡像并創(chuàng)建新的Pod椒楣。如果集群規(guī)模比較大，則這個(gè)工作變成了一個(gè)挑戰(zhàn)营袜，而且先全部停止然后逐步升級(jí)的方式會(huì)導(dǎo)致較長(zhǎng)時(shí)間的服務(wù)不可用。
Kubernetes提供了滾動(dòng)升級(jí)功能來解決上述問題丑罪。
如果Pod是通過Deployment創(chuàng)建的荚板，則用戶可以在運(yùn)行時(shí)修改Deployment的Pod定義（spec.template）或鏡像名稱凤壁，并應(yīng)用到Deployment對(duì)象上，系統(tǒng)即可完成Deployment的自動(dòng)更新操作跪另。如果在更新過程中發(fā)生了錯(cuò)誤拧抖，則還可以通過回滾操作恢復(fù)Pod的版本。
Deployment的升級(jí)
# nginx-deployment.yaml
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
[root@k8s-master01 pod]# kubectl apply -f nginx-deployment.yaml
deployment.apps/nginx-deployment created
[root@k8s-master01 pod]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-deployment-5bf87f5f59-h2llz 1/1 Running 0 3s 10.244.2.44 k8s-node01 <none> <none>
nginx-deployment-5bf87f5f59-mlz84 1/1 Running 0 3s 10.244.2.45 k8s-node01 <none> <none>
nginx-deployment-5bf87f5f59-qdjvm 1/1 Running 0 3s 10.244.1.25 k8s-node02 <none> <none>
現(xiàn)在Pod鏡像需要被更新為Nginx:1.9.1免绿，我們可以通過kubectl set image命令為Deployment設(shè)置新的鏡像名稱：
kubectl set image deployment/nginx-development nginx=nginx:1.9.1
另一種更新的方法是使用kubectl edit命令修改Deployment的配置唧席，將spec.template.spec.containers[0].image從Nginx:1.7.9更改為Nginx:1.9.1：
kubectl edit deployment/nginx-deployment
一旦鏡像名（或Pod定義）發(fā)生了修改，則將觸發(fā)系統(tǒng)完成Deployment所有運(yùn)行Pod的滾動(dòng)升級(jí)操作
可以使用kubectl rollout status命令查看Deployment的更新過程：
查看Pod使用的鏡像嘲驾，已經(jīng)更新為Nginx:1.9.1了：
[root@k8s-master01 pod]# kubectl describe pod nginx-deployment-678645bf77-4ltnc
Image: nginx:1.9.1
使用kubectl describe deployments/nginx-deployment命令仔細(xì)觀察Deployment的更新過程淌哟。
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 6m4s deployment-controller Scaled down replica set nginx-deployment-5bf87f5f59 to 2
Normal ScalingReplicaSet 6m4s deployment-controller Scaled up replica set nginx-deployment-678645bf77 to 2
Normal ScalingReplicaSet 6m3s deployment-controller Scaled up replica set nginx-deployment-678645bf77 to 3
Normal ScalingReplicaSet 6m1s deployment-controller Scaled down replica set nginx-deployment-5bf87f5f59 to 0
Normal ScalingReplicaSet 4m55s deployment-controller Scaled up replica set nginx-deployment-5bf87f5f59 to 1
Normal ScalingReplicaSet 4m54s deployment-controller Scaled down replica set nginx-deployment-678645bf77 to 2
Normal ScalingReplicaSet 4m53s (x2 over 8m4s) deployment-controller Scaled up replica set nginx-deployment-5bf87f5f59 to 3
Normal ScalingReplicaSet 103s (x2 over 6m5s) deployment-controller Scaled up replica set nginx-deployment-678645bf77 to 1
Normal ScalingReplicaSet 101s (x2 over 6m3s) deployment-controller Scaled down replica set nginx-deployment-5bf87f5f59 to 1
Normal ScalingReplicaSet 100s (x7 over 4m54s) deployment-controller (combined from similar events): Scaled down replica set nginx-deployment-5bf87f5f59 to 0
初始創(chuàng)建Deployment時(shí)，系統(tǒng)創(chuàng)建了一個(gè)ReplicaSet（nginx-deployment-5bf87f5f59）辽故，并按用戶的需求創(chuàng)建了3個(gè)Pod副本徒仓。當(dāng)更新Deployment時(shí)，系統(tǒng)創(chuàng)建了一個(gè)新的ReplicaSet（nginx-deployment-678645bf77）誊垢，并將其副本數(shù)量擴(kuò)展到1掉弛，然后將舊的ReplicaSet縮減為2。之后喂走，系統(tǒng)繼續(xù)按照相同的更新策略對(duì)新舊兩個(gè)ReplicaSet進(jìn)行逐個(gè)調(diào)整殃饿。最后，新的ReplicaSet運(yùn)行了3個(gè)新版本Pod副本芋肠，舊的ReplicaSet副本數(shù)量則縮減為0乎芳。如圖所示。
[root@k8s-master01 pod]# kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-5bf87f5f59 0 0 0 17m
nginx-deployment-678645bf77 3 3 3 15m
在整個(gè)升級(jí)的過程中业栅，系統(tǒng)會(huì)保證至少有兩個(gè)Pod可用秒咐，并且最多同時(shí)運(yùn)行4個(gè)Pod，這是Deployment通過復(fù)雜的算法完成的碘裕。Deployment需要確保在整個(gè)更新過程中只有一定數(shù)量的Pod可能處于不可用狀態(tài)携取。在默認(rèn)情況下，Deployment確卑锟祝可用的Pod總數(shù)至少為所需的副本數(shù)量（DESIRED）減1雷滋，也就是最多1個(gè)不可用（maxUnavailable=1）。Deployment還需要確保在整個(gè)更新過程中Pod的總數(shù)量不會(huì)超過所需的副本數(shù)量太多文兢。在默認(rèn)情況下晤斩，Deployment確保Pod的總數(shù)最多比所需的Pod數(shù)多1個(gè)，也就是最多1個(gè)浪涌值（maxSurge=1）姆坚。Kubernetes從1.6版本開始澳泵，maxUnavailable和maxSurge的默認(rèn)值將從1、1更新為所需副本數(shù)量的25%兼呵、25%兔辅。
這樣腊敲，在升級(jí)過程中，Deployment就能夠保證服務(wù)不中斷维苔，并且副本數(shù)量始終維持為用戶指定的數(shù)量（DESIRED）碰辅。
對(duì)更新策略的說明如下。
在Deployment的定義中介时，可以通過spec.strategy指定Pod更新的策略没宾，目前支持兩種策略：Recreate（重建）和RollingUpdate（滾動(dòng)更新），默認(rèn)值為RollingUpdate沸柔。在前面的例子中使用的就是RollingUpdate策略循衰。
- Recreate：設(shè)置spec.strategy.type=Recreate，表示Deployment在更新Pod時(shí)勉失，會(huì)先殺掉所有正在運(yùn)行的Pod羹蚣，然后創(chuàng)建新的Pod。
- RollingUpdate：設(shè)置spec.strategy.type=RollingUpdate乱凿，表示Deployment會(huì)以滾動(dòng)更新的方式來逐個(gè)更新Pod顽素。同時(shí)，可以通過設(shè)置spec.strategy.rollingUpdate下的兩個(gè)參數(shù)（maxUnavailable和maxSurge）來控制滾動(dòng)更新的過程徒蟆。
下面對(duì)滾動(dòng)更新時(shí)兩個(gè)主要參數(shù)的說明如下胁出。
- spec.strategy.rollingUpdate.maxUnavailable：用于指定Deployment在更新過程中不可用狀態(tài)的Pod數(shù)量的上限。該maxUnavailable的數(shù)值可以是絕對(duì)值（例如5）或Pod期望的副本數(shù)的百分比（例如10%）段审，如果被設(shè)置為百分比全蝶，那么系統(tǒng)會(huì)先以向下取整的方式計(jì)算出絕對(duì)值（整數(shù)）。而當(dāng)另一個(gè)參數(shù)maxSurge被設(shè)置為0時(shí)寺枉，maxUnavailable則必須被設(shè)置為絕對(duì)數(shù)值大于0（從Kubernetes 1.6開始抑淫，maxUnavailable的默認(rèn)值從1改為25%）。舉例來說姥闪，當(dāng)maxUnavailable被設(shè)置為30%時(shí)始苇，舊的ReplicaSet可以在滾動(dòng)更新開始時(shí)立即將副本數(shù)縮小到所需副本總數(shù)的70%。一旦新的Pod創(chuàng)建并準(zhǔn)備好筐喳，舊的ReplicaSet會(huì)進(jìn)一步縮容催式，新的ReplicaSet又繼續(xù)擴(kuò)容，整個(gè)過程中系統(tǒng)在任意時(shí)刻都可以確北芄椋可用狀態(tài)的Pod總數(shù)至少占Pod期望副本總數(shù)的70%荣月。
- spec.strategy.rollingUpdate.maxSurge：用于指定在Deployment更新Pod的過程中Pod總數(shù)超過Pod期望副本數(shù)部分的最大值。該maxSurge的數(shù)值可以是絕對(duì)值（例如5）或Pod期望副本數(shù)的百分比（例如10%）梳毙。如果設(shè)置為百分比哺窄，那么系統(tǒng)會(huì)先按照向上取整的方式計(jì)算出絕對(duì)數(shù)值（整數(shù)）。從Kubernetes 1.6開始，maxSurge的默認(rèn)值從1改為25%萌业。舉例來說蔑担，當(dāng)maxSurge的值被設(shè)置為30%時(shí)，新的ReplicaSet可以在滾動(dòng)更新開始時(shí)立即進(jìn)行副本數(shù)擴(kuò)容咽白，只需要保證新舊ReplicaSet的Pod副本數(shù)之和不超過期望副本數(shù)的130%即可。一旦舊的Pod被殺掉鸟缕，新的ReplicaSet就會(huì)進(jìn)一步擴(kuò)容晶框。在整個(gè)過程中系統(tǒng)在任意時(shí)刻都能確保新舊ReplicaSet的Pod副本總數(shù)之和不超過所需副本數(shù)的130%。
這里需要注意多重更新（Rollover）的情況懂从。如果Deployment的上一次更新正在進(jìn)行授段，此時(shí)用戶再次發(fā)起Deployment的更新操作，那么Deployment會(huì)為每一次更新都創(chuàng)建一個(gè)ReplicaSet番甩，而每次在新的ReplicaSet創(chuàng)建成功后侵贵，會(huì)逐個(gè)增加Pod副本數(shù)，同時(shí)將之前正在擴(kuò)容的ReplicaSet停止擴(kuò)容（更新）缘薛，并將其加入舊版本ReplicaSet列表中窍育，然后開始縮容至0的操作。
例如宴胧，假設(shè)我們創(chuàng)建一個(gè)Deployment漱抓，這個(gè)Deployment開始創(chuàng)建5個(gè)Nginx:1.7.9的Pod副本，在這個(gè)創(chuàng)建Pod動(dòng)作尚未完成時(shí)恕齐，我們又將Deployment進(jìn)行更新乞娄，在副本數(shù)不變的情況下將Pod模板中的鏡像修改為Nginx:1.9.1，又假設(shè)此時(shí)Deployment已經(jīng)創(chuàng)建了3個(gè)Nginx:1.7.9的Pod副本显歧，則Deployment會(huì)立即殺掉已創(chuàng)建的3個(gè)Nginx:1.7.9 Pod仪或，并開始創(chuàng)建Nginx:1.9.1 Pod。Deployment不會(huì)在等待Nginx:1.7.9的Pod創(chuàng)建到5個(gè)之后再進(jìn)行更新操作士骤。
還需要注意更新Deployment的標(biāo)簽選擇器（Label Selector）的情況范删。通常來說，不鼓勵(lì)更新Deployment的標(biāo)簽選擇器敦间，因?yàn)檫@樣會(huì)導(dǎo)致Deployment選擇的Pod列表發(fā)生變化瓶逃，也可能與其他控制器產(chǎn)生沖突。如果一定要更新標(biāo)簽選擇器廓块，那么請(qǐng)務(wù)必謹(jǐn)慎厢绝，確保不會(huì)出現(xiàn)其他問題。關(guān)于Deployment標(biāo)簽選擇器的更新的注意事項(xiàng)如下带猴。
1）添加選擇器標(biāo)簽時(shí)昔汉，必須同步修改Deployment配置的Pod的標(biāo)簽，為Pod添加新的標(biāo)簽，否則Deployment的更新會(huì)報(bào)驗(yàn)證錯(cuò)誤而失敯胁 ：
添加標(biāo)簽選擇器是無法向后兼容的会通，這意味著新的標(biāo)簽選擇器不會(huì)匹配和使用舊選擇器創(chuàng)建的ReplicaSets和Pod，因此添加選擇器將會(huì)導(dǎo)致所有舊版本的ReplicaSets和由舊ReplicaSets創(chuàng)建的Pod處于孤立狀態(tài)（不會(huì)被系統(tǒng)自動(dòng)刪除娄周，也不受新的ReplicaSet控制）涕侈。
為標(biāo)簽選擇器和Pod模板添加新的標(biāo)簽（使用kubectl edit deployment命令）后，效果如下：
# kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-4087004473 0 0 0 52m
nginx-deployment-3599678771 3 3 3 1m
nginx-deployment-3661742516 3 3 3 2s
可以看到新ReplicaSet（nginx-deployment-3661742516）創(chuàng)建的3個(gè)新Pod：
# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-deployment-3599678771-01h26 1/1 Running 0 2m
nginx-deployment-3599678771-57thr 1/1 Running 0 2m
nginx-deployment-3599678771-s8p21 1/1 Running 0 2m
nginx-deployment-3661742516-46djm 1/1 Running 0 52s
nginx-deployment-3661742516-kws84 1/1 Running 0 52s
nginx-deployment-3661742516-wq30s 1/1 Running 0 52s
（2）更新標(biāo)簽選擇器煤辨，即更改選擇器中標(biāo)簽的鍵或者值裳涛，也會(huì)產(chǎn)生與添加選擇器標(biāo)簽類似的效果。
（3）刪除標(biāo)簽選擇器众辨，即從Deployment的標(biāo)簽選擇器中刪除一個(gè)或者多個(gè)標(biāo)簽端三，該Deployment的ReplicaSet和Pod不會(huì)受到任何影響。但需要注意的是鹃彻，被刪除的標(biāo)簽仍會(huì)存在于現(xiàn)有的Pod和ReplicaSets上郊闯。
Deployment的回滾
有時(shí)（例如新的Deployment不穩(wěn)定時(shí)）我們可能需要將Deployment回滾到舊版本。在默認(rèn)情況下蛛株，所有Deployment的發(fā)布?xì)v史記錄都被保留在系統(tǒng)中团赁，以便于我們隨時(shí)進(jìn)行回滾（可以配置歷史記錄數(shù)量）。
假設(shè)在更新Deployment鏡像時(shí)谨履，將容器鏡像名誤設(shè)置成Nginx:1.91（一個(gè)不存在的鏡像）：
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
則這時(shí)Deployment的部署過程會(huì)卡兹蝗：
kubectl rollout status deployments nginx-deployment
Waiting for rollout to finish: 1 out of 3 new replicas have been updated...
檢查Deployment部署的歷史記錄
[root@k8s-master01 pod]# kubectl rollout history deployment/nginx-deployment
deployment.apps/nginx-deployment
REVISION CHANGE-CAUSE
5 <none>
6 <none>
注意，在創(chuàng)建Deployment時(shí)使用--record參數(shù)屉符，就可以在CHANGE-CAUSE列看到每個(gè)版本使用的命令了剧浸。另外，Deployment的更新操作是在Deployment進(jìn)行部署（Rollout）時(shí)被觸發(fā)的矗钟，這意味著當(dāng)且僅當(dāng)Deployment的Pod模板（即spec.template）被更改時(shí)才會(huì)創(chuàng)建新的修訂版本唆香，例如更新模板標(biāo)簽或容器鏡像。其他更新操作（如擴(kuò)展副本數(shù)）將不會(huì)觸發(fā)Deployment的更新操作吨艇，這也意味著我們將Deployment回滾到之前的版本時(shí)躬它，只有Deployment的Pod模板部分會(huì)被修改。
如果需要查看特定版本的詳細(xì)信息东涡，則可以加上--revision=<N>參數(shù)：
查看特定版本的信息冯吓，則可以加上--revision=<N>參數(shù)：
[root@k8s-master01 pod]# kubectl rollout history deployment/nginx-deployment --revision=5
deployment.apps/nginx-deployment with revision #5
Pod Template:
Labels: app=nginx
pod-template-hash=5bf87f5f59
Containers:
nginx:
Image: nginx:1.7.9
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
現(xiàn)在我們決定撤銷本次發(fā)布并回滾到上一個(gè)部署版本：
[root@k8s-master01 pod]# kubectl rollout undo deployment/nginx-deployment
deployment.apps/nginx-deployment rolled back
也可以使用 --to--revision 參數(shù)指定回滾到的部署版本號(hào)：
[root@k8s-master01 pod]# kubectl rollout undo deployment/nginx-deployment --to-revision=6
deployment.apps/nginx-deployment rolled back
暫停和恢復(fù)Deployment的部署操作，已完成復(fù)雜的修改
對(duì)于一次復(fù)雜的Deployment配置修改疮跑，為了避免頻繁觸發(fā)Deployment的更新操作组贺，可以先暫停Deployment的更新操作，然后進(jìn)行配置修改祖娘，再恢復(fù)Deployment失尖，一次性觸發(fā)完整的更新操作，就可以避免不必要的Deployment更新操作了
以之前創(chuàng)建的Nginx為例：
[root@k8s-master01 pod]# kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 42m
[root@k8s-master01 pod]# kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-5bf87f5f59 0 0 0 43m
nginx-deployment-678645bf77 3 3 3 41m
通過kubectl rollout pause命令暫停deployment的更新操作
[root@k8s-master01 pod]# kubectl rollout pause deployment/nginx-deployment
deployment.apps/nginx-deployment paused
之后修改Deployment的鏡像信息：
kubectl set image deployment/nginx-deployment nginx=nginx：1.9.1
查看Deployment的歷史記錄，并發(fā)現(xiàn)沒有觸發(fā)新的Deployment部署操作
[root@k8s-master01 pod]# kubectl rollout history deployment/nginx-deployment
deployment.apps/nginx-deployment
REVISION CHANGE-CAUSE
11 kubectl set image deployment/nginx-deployment nginx=nginx:1.7.9 --record=true
12 kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 --record=true
在暫停Deployment部署之后掀潮，可以根據(jù)需要進(jìn)行任意次數(shù)的配置更新菇夸。例如，再次更新容器的資源限制：
[root@k8s-master01 pod]# kubectl set resources deployment nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
deployment.apps/nginx-deployment resource requirements updated
最后仪吧，恢復(fù)這個(gè)Deployment的部署操作：
kubectl rollout resume deploy nginx-deployment
可以看到一個(gè)新的ReplicaSet被創(chuàng)建出來
[root@k8s-master01 pod]# kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-56bbb744cc 3 3 3 12s
nginx-deployment-5bf87f5f59 0 0 0 50m
nginx-deployment-678645bf77 0 0 0 48m
查看Deployment的事件信息庄新，可以看到Deployment完成了更新：
[root@k8s-master01 pod]# kubectl describe deployment nginx-deployment
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx:1.9.1
Port: 80/TCP
Host Port: 0/TCP
Limits:
cpu: 200m
memory: 512Mi
注意，在恢復(fù)暫停的Deployment之前薯鼠，無法回滾該Deployment摄咆。
使用kubectl rolling-update命令完成RC的滾動(dòng)升級(jí)
對(duì)于RC的滾動(dòng)升級(jí)，kubernetes還提供了一個(gè) kubectl rolling-update命令進(jìn)行實(shí)現(xiàn)人断。該命令創(chuàng)建了一個(gè)新的RC，然后自動(dòng)控制舊的RC中的Pod副本數(shù)量減少到0朝蜘，同時(shí)新的的RC中的Pod副本數(shù)量從0逐個(gè)增加到目標(biāo)值恶迈，來完成Pod的升級(jí)。需要注意的是谱醇，系統(tǒng)要求新的RC與舊的RC都在相同的命名空間內(nèi)暇仲。
# tomcat-controller-v1.yaml
apiVersion: v1
kind: ReplicationController
metadata:
name: tomcat
labels:
name: tomcat
version: v1
spec:
replicas: 2
selector:
name: tomcat
template:
metadata:
labels: #可以自己定義key-value
name: tomcat
spec:
containers:
- name: tomcat
image: tomcat:6.0
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8080
env: #環(huán)境變量
- name: GET_HOSTS_FROM
value: dns
[root@k8s-master01 pod]# kubectl apply -f tomcat-controller-v1.yaml
[root@k8s-master01 pod]# kubectl get rc -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
tomcat 2 2 2 16s tomcat tomcat:6.0 name=tomcat
- 進(jìn)行RC滾動(dòng)升級(jí)
# tomcat-controller-v2.yaml
apiVersion: v1
kind: ReplicationController
metadata:
name: tomcat2
labels:
name: tomcat
version: v2
spec:
replicas: 2
selector:
name: tomcat2
template:
metadata:
labels: #可以自己定義key-value
name: tomcat2
spec:
containers:
- name: tomcat
image: tomcat:7.0
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8080
env: #環(huán)境變量
- name: GET_HOSTS_FROM
value: dns
[root@k8s-master01 pod]# kubectl rolling-update tomcat -f tomcat-controller-v2.yaml
在配置文件中需要注意以下兩點(diǎn):
- RC的名字（name）不能與舊RC的名字相同。
- 在selector中應(yīng)至少有一個(gè)Label與舊RC的Label不同副渴，以標(biāo)識(shí)其為新RC奈附。在本例中新增了一個(gè)名為version的Label，以與舊RC進(jìn)行區(qū)分煮剧。即確保同一個(gè)Key至少有一個(gè)Value不一個(gè)斥滤。
等所有新的Pod都啟動(dòng)完成后，舊的Pod也被全部銷毀勉盅，這樣就完成了容器集群的更新工作佑颇。
另一種方法是不使用配置文件，直接用kubectl rolling-update命令草娜，加上--image參數(shù)指定新版鏡像名稱來完成Pod的滾動(dòng)升級(jí)
kubectl rolling-update tomcat --image=tomcat:6.0
與使用配置文件的方式不同挑胸，執(zhí)行的結(jié)果是舊RC被刪除，新RC仍將使用舊RC的名稱宰闰。
可以看到茬贵，kubectl通過新建一個(gè)新版本Pod，停掉一個(gè)舊版本Pod移袍，如此逐步迭代來完成整個(gè)RC的更新解藻。
可以看到，kubectl給RC增加了一個(gè)key為“deployment”的Label（這個(gè)key的名字可通過--deployment-label-key參數(shù)進(jìn)行修改）葡盗，Label的值是RC的內(nèi)容進(jìn)行Hash計(jì)算后的值舆逃，相當(dāng)于簽名，這樣就能很方便地比較RC里的Image名字及其他信息是否發(fā)生了變化。
如果在更新過程中發(fā)現(xiàn)配置有誤路狮，則用戶可以中斷更新操作虫啥，并通過執(zhí)行kubectl rolling- update --rollback完成Pod版本的回滾：
kubectl rolling-update tomcat --image=tomcat:6.0 --rollback
可以看出，RC的滾動(dòng)升級(jí)不具有Deployment在應(yīng)用版本升級(jí)過程中的歷史記錄奄妨、新舊版本數(shù)量的精細(xì)控制等功能涂籽，在Kubernetes的演進(jìn)過程中，RC將逐漸被RS和Deployment所取代砸抛，建議用戶優(yōu)先考慮使用Deployment完成Pod的部署和升級(jí)操作评雌。
其他管理對(duì)象的更新策略
Kubernetes從1.6版本開始，對(duì)DaemonSet和StatefulSet的更新策略也引入類似于Deployment的滾動(dòng)升級(jí)直焙，通過不同的策略自動(dòng)完成應(yīng)用的版本升級(jí)景东。
1.DaemonSet的更新策略
目前DaemonSet的升級(jí)策略包括兩種：OnDelete和RollingUpdate。
（1）OnDelete：DaemonSet的默認(rèn)升級(jí)策略奔誓，與1.5及以前版本的Kubernetes保持一致斤吐。當(dāng)使用OnDelete作為升級(jí)策略時(shí)，在創(chuàng)建好新的DaemonSet配置之后厨喂，新的Pod并不會(huì)被自動(dòng)創(chuàng)建和措，直到用戶戶手動(dòng)刪除舊版本的Pod，才觸發(fā)新建操作蜕煌。
（2）RollingUpdate：從Kubernetes 1.6版本開始引入派阱。當(dāng)使用RollingUpdate作為升級(jí)策略對(duì)DaemonSet進(jìn)行更新時(shí)，舊版本的Pod將被自動(dòng)殺掉斜纪，然后自動(dòng)創(chuàng)建新版本的DaemonSet Pod贫母。整個(gè)過程與普通Deployment的滾動(dòng)升級(jí)一樣是可控的。不過有兩點(diǎn)不同于普通Pod的滾動(dòng)升級(jí)：一是目前Kubernetes還不支持查看和管理DaemonSet的更新歷史記錄盒刚；二是DaemonSet的回滾（Rollback）并不能如同Deployment一樣直接通過kubectl rollback命令來實(shí)現(xiàn)颁独，必須通過再次提交舊版本配置的方式實(shí)現(xiàn)。
2.StatefulSet的更新策略
Kubernetes從1.6版本開始伪冰，針對(duì)StatefulSet的更新策略逐漸向Deployment和DaemonSet的更新策略看齊誓酒，也將實(shí)現(xiàn)RollingUpdate、Paritioned和OnDelete這幾種策略贮聂，以保證StatefulSet中各Pod有序地靠柑、逐個(gè)地更新，并且能夠保留更新歷史吓懈，也能回滾到某個(gè)歷史版本歼冰。
