一、Pod控制器及其功用
Pod控制器是用於實現管理pod的中間層，確保pod資源符合預期的狀態，pod的資源出現故障時，會嘗試 進行重啟，當根據重啟策略無效，則會重新新建pod的資源。
pod控制器有多種類型：
ReplicaSet: 代用戶創建指定數量的pod副本數量，確保pod副本數量符合預期狀態，並且支持滾動式自動擴容和縮容功能。
ReplicaSet主要三個組件組成：
（1）用戶期望的pod副本數量
（2）標簽選擇器，判斷哪個pod歸自己管理
（3）當現存的pod數量不足，會根據pod資源模板進行新建
幫助用戶管理無狀態的pod資源，精確反應用戶定義的目標數量，但是RelicaSet不是直接使用的控制器，而是使用Deployment。
Deployment：工作在ReplicaSet之上，用於管理無狀態應用，目前來說最好的控制器。支持滾動更新和回滾功能，還提供聲明式配置。
DaemonSet：用於確保集群中的每一個節點只運行特定的pod副本，通常用於實現系統級后台任務。比如ELK服務
特性：服務是無狀態的
服務必須是守護進程
Job：只要完成就立即退出，不需要重啟或重建。
Cronjob：周期性任務控制，不需要持續后台運行，
StatefulSet：管理有狀態應用
二、ReplicaSet控制器
ReplicationController用來確保容器應用的副本數始終保持在用戶定義的副本數，即如果有容器異常退出，會自動創建新的Pod來替代；而如果異常多出來的容器也會自動回收。
在新版本的Kubernetes中建議使用ReplicaSet來取代ReplicationController。ReplicaSet跟ReplicationController沒有本質的不同，只是名字不一樣，並且ReplicaSet支持集合式的selector。
雖然ReplicaSet可以獨立使用，但一般還是建議使用 Deployment 來自動管理ReplicaSet，這樣就無需擔心跟其他機制的不兼容問題（比如ReplicaSet不支持rolling-update但Deployment支持）。
ReplicaSet示例：
（1）命令行查看ReplicaSet清單定義規則
[root@k8s-master ~]# kubectl explain rs [root@k8s-master ~]# kubectl explain rs.spec [root@k8s-master ~]# kubectl explain rs.spec.template
（2）新建ReplicaSet示例 [root@k8s-master ~]# vim rs-demo.yaml apiVersion: apps/v1 #api版本定義 kind: ReplicaSet #定義資源類型為ReplicaSet metadata: #元數據定義 name: myapp namespace: default spec: #ReplicaSet的規格定義 replicas: 2 #定義副本數量為2個 selector: #標簽選擇器，定義匹配pod的標簽 matchLabels: app: myapp release: canary template: #pod的模板定義 metadata: #pod的元數據定義 name: myapp-pod #自定義pod的名稱 labels: #定義pod的標簽，需要和上面定義的標簽一致，也可以多出其他標簽 app: myapp release: canary environment: qa spec: #pod的規格定義 containers: #容器定義 - name: myapp-container #容器名稱 image: ikubernetes/myapp:v1 #容器鏡像 ports: #暴露端口 - name: http containerPort: 80
（3）創建ReplicaSet定義的pod [root@k8s-master ~]# kubectl create -f rs-demo.yaml [root@k8s-master ~]# kubectl get pods #獲取pod信息 [root@k8s-master ~]# kubectl describe pods myapp-*** #查看pod詳細信息
（4）修改pod的副本數量 [root@k8s-master ~]# kubectl edit rs myapp replicas: 5 [root@k8s-master ~]# kubectl get rs -o wide
（5）修改pod的鏡像版本
[root@k8s-master ~]# kubectl edit rs myapp
image: ikubernetes/myapp:v2
[root@k8s-master ~]# kubectl delete pods myapp-*** #修改了pod鏡像版本，pod需要重建才能達到最新版本
[root@k8s-master ~]# kubectl create -f rs-demo.yaml
三、Deployment控制器
Deployment為Pod和Replica Set（下一代Replication Controller）提供聲明式更新。
只需要在 Deployment 中描述想要的目標狀態是什么，Deployment controller 就會幫您將 Pod 和ReplicaSet 的實際狀態改變到您的目標狀態。也可以定義一個全新的 Deployment 來創建 ReplicaSet 或者刪除已有的 Deployment 並創建一個新的來替換。
典型的用例如下：
- （1）使用Deployment來創建ReplicaSet。ReplicaSet在后台創建pod。檢查啟動狀態，看它是成功還是失敗。
- （2）然后，通過更新Deployment的PodTemplateSpec字段來聲明Pod的新狀態。這會創建一個新的ReplicaSet，Deployment會按照控制的速率將pod從舊的ReplicaSet移動到新的ReplicaSet中。
- （3）如果當前狀態不穩定，回滾到之前的Deployment revision。每次回滾都會更新Deployment的revision。
- （4）擴容Deployment以滿足更高的負載。
- （5）暫停Deployment來應用PodTemplateSpec的多個修復，然后恢復上線。
- （6）根據Deployment 的狀態判斷上線是否hang住了。
- （7）清除舊的不必要的 ReplicaSet。
1、解析Deployment Spec
首先看一個官方的nginx-deployment.yaml的例子：
apiVersion: v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80
在所有的 Kubernetes 配置中，Deployment 也需要apiVersion，kind和metadata這些配置項。如下：
[root@k8s-master ~]# kubectl explain deployment KIND: Deployment VERSION: extensions/v1beta1 DESCRIPTION: DEPRECATED - This group version of Deployment is deprecated by apps/v1beta2/Deployment. See the release notes for more information. Deployment enables declarative updates for Pods and ReplicaSets. FIELDS: apiVersion <string> APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#resources kind <string> Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds metadata <Object> Standard object metadata. spec <Object> Specification of the desired behavior of the Deployment. status <Object> Most recently observed status of the Deployment.
使用kubectl explain deployment.spec查看具體Deployment spec的配置選項，解析如下：
[root@k8s-master ~]# kubectl explain deployment.spec KIND: Deployment VERSION: extensions/v1beta1 RESOURCE: spec <Object> DESCRIPTION: Specification of the desired behavior of the Deployment. DeploymentSpec is the specification of the desired behavior of the Deployment. FIELDS: minReadySeconds <integer> Minimum number of seconds for which a newly created pod should be ready without any of its container crashing, for it to be considered available. Defaults to 0 (pod will be considered available as soon as it is ready) paused <boolean> Indicates that the deployment is paused and will not be processed by the deployment controller. progressDeadlineSeconds <integer> The maximum time in seconds for a deployment to make progress before it is considered to be failed. The deployment controller will continue to process failed deployments and a condition with a ProgressDeadlineExceeded reason will be surfaced in the deployment status. Note that progress will not be estimated during the time a deployment is paused. This is not set by default. replicas <integer> Number of desired pods. This is a pointer to distinguish between explicit zero and not specified. Defaults to 1. revisionHistoryLimit <integer> The number of old ReplicaSets to retain to allow rollback. This is a pointer to distinguish between explicit zero and not specified. rollbackTo <Object> DEPRECATED. The config this deployment is rolling back to. Will be cleared after rollback is done. selector <Object> Label selector for pods. Existing ReplicaSets whose pods are selected by this will be the ones affected by this deployment. strategy <Object> The deployment strategy to use to replace existing pods with new ones. template <Object> -required- Template describes the pods that will be created.
Replicas（副本數量）：
.spec.replicas 是可以選字段，指定期望的pod數量，默認是1。
Selector（選擇器）：
.spec.selector是可選字段，用來指定 label selector ，圈定Deployment管理的pod范圍。如果被指定， .spec.selector 必須匹配 .spec.template.metadata.labels，否則它將被API拒絕。如果 .spec.selector 沒有被指定， .spec.selector.matchLabels 默認是.spec.template.metadata.labels。
在Pod的template跟.spec.template不同或者數量超過了.spec.replicas規定的數量的情況下，Deployment會殺掉label跟selector不同的Pod。
Pod Template（Pod模板）：
.spec.template 是 .spec中唯一要求的字段。
.spec.template 是 pod template. 它跟 Pod有一模一樣的schema，除了它是嵌套的並且不需要apiVersion 和 kind字段。
另外為了划分Pod的范圍，Deployment中的pod template必須指定適當的label（不要跟其他controller重復了，參考selector）和適當的重啟策略。
.spec.template.spec.restartPolicy 可以設置為 Always , 如果不指定的話這就是默認配置。
strategy（更新策略）：
.spec.strategy 指定新的Pod替換舊的Pod的策略。 .spec.strategy.type 可以是"Recreate"或者是 "RollingUpdate"。"RollingUpdate"是默認值。
Recreate： 重建式更新，就是刪一個建一個。類似於ReplicaSet的更新方式，即首先刪除現有的Pod對象，然后由控制器基於新模板重新創建新版本資源對象。
rollingUpdate：滾動更新，簡單定義 更新期間pod最多有幾個等。可以指定maxUnavailable 和 maxSurge 來控制 rolling update 進程。
maxSurge：.spec.strategy.rollingUpdate.maxSurge 是可選配置項，用來指定可以超過期望的Pod數量的最大個數。該值可以是一個絕對值（例如5）或者是期望的Pod數量的百分比（例如10%）。當MaxUnavailable為0時該值不可以為0。通過百分比計算的絕對值向上取整。默認值是1。
例如，該值設置成30%，啟動rolling update后新的ReplicatSet將會立即擴容，新老Pod的總數不能超過期望的Pod數量的130%。舊的Pod被殺掉后，新的ReplicaSet將繼續擴容，舊的ReplicaSet會進一步縮容，確保在升級的所有時刻所有的Pod數量和不會超過期望Pod數量的130%。
maxUnavailable：.spec.strategy.rollingUpdate.maxUnavailable 是可選配置項，用來指定在升級過程中不可用Pod的最大數量。該值可以是一個絕對值（例如5），也可以是期望Pod數量的百分比（例如10%）。通過計算百分比的絕對值向下取整。 如果.spec.strategy.rollingUpdate.maxSurge 為0時，這個值不可以為0。默認值是1。
例如，該值設置成30%，啟動rolling update后舊的ReplicatSet將會立即縮容到期望的Pod數量的70%。新的Pod ready后，隨着新的ReplicaSet的擴容，舊的ReplicaSet會進一步縮容確保在升級的所有時刻可以用的Pod數量至少是期望Pod數量的70%。
PS：maxSurge和maxUnavailable的屬性值不可同時為0，否則Pod對象的副本數量在符合用戶期望的數量后無法做出合理變動以進行更新操作。
在配置時，用戶還可以使用Deployment控制器的spec.minReadySeconds屬性來控制應用升級的速度。新舊更替過程中，新創建的Pod對象一旦成功響應就緒探測即被認為是可用狀態，然后進行下一輪的替換。而spec.minReadySeconds能夠定義在新的Pod對象創建后至少需要等待多長的時間才能會被認為其就緒，在該段時間內，更新操作會被阻塞。
revisionHistoryLimit（歷史版本記錄）：
Deployment revision history存儲在它控制的ReplicaSets中。默認保存記錄10個
.spec.revisionHistoryLimit 是一個可選配置項，用來指定可以保留的舊的ReplicaSet數量。該理想值取決於心Deployment的頻率和穩定性。如果該值沒有設置的話，默認所有舊的Replicaset或會被保留，將資源存儲在etcd中，是用kubectl get rs查看輸出。每個Deployment的該配置都保存在ReplicaSet中，然而，一旦刪除的舊的RepelicaSet，Deployment就無法再回退到那個revison了。
如果將該值設置為0，所有具有0個replica的ReplicaSet都會被刪除。在這種情況下，新的Deployment rollout無法撤銷，因為revision history都被清理掉了。
PS：為了保存版本升級的歷史，需要再創建Deployment對象時，在命令中使用"--record"選項
rollbackTo：
.spec.rollbackTo 是一個可以選配置項，用來配置Deployment回退的配置。設置該參數將觸發回退操作，每次回退完成后，該值就會被清除。
revision：.spec.rollbackTo.revision是一個可選配置項，用來指定回退到的revision。默認是0，意味着回退到上一個revision。
progressDeadlineSeconds：
.spec.progressDeadlineSeconds 是可選配置項，用來指定在系統報告Deployment的failed progressing——表現為resource的狀態中type=Progressing、Status=False、 Reason=ProgressDeadlineExceeded前可以等待的Deployment進行的秒數。Deployment controller會繼續重試該Deployment。未來，在實現了自動回滾后， deployment controller在觀察到這種狀態時就會自動回滾。
如果設置該參數，該值必須大於 .spec.minReadySeconds。
paused：
.spec.paused是可以可選配置項，boolean值。用來指定暫停和恢復Deployment。Paused和沒有paused的Deployment之間的唯一區別就是，所有對paused deployment中的PodTemplateSpec的修改都不會觸發新的rollout。Deployment被創建之后默認是非paused。
2、創建Deployment
[root@k8s-master ~]# vim deploy-demo.yaml apiVersion: apps/v1 kind: Deployment metadata: name: myapp-deploy namespace: default spec: replicas: 2 selector: matchLabels: app: myapp release: canary template: metadata: labels: app: myapp release: canary spec: containers: - name: myapp image: ikubernetes/myapp:v1 ports: - name: http containerPort: 80 [root@k8s-master ~]# kubectl apply -f deploy-demo.yaml [root@k8s-master ~]# kubectl get deploy NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE myapp-deploy 2 0 0 0 1s [root@k8s-master ~]# kubectl get rs
輸出結果表明我們希望的repalica數是2（根據deployment中的.spec.replicas配置）當前replica數（ .status.replicas）是0, 最新的replica數（.status.updatedReplicas）是0，可用的replica數（.status.availableReplicas）是0。過幾秒后再執行get命令，將獲得如下輸出：
[root@k8s-master ~]# kubectl get deploy NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE myapp-deploy 2 2 2 2 10s
我們可以看到Deployment已經創建了2個 replica，所有的 replica 都已經是最新的了（包含最新的pod template），可用的（根據Deployment中的.spec.minReadySeconds聲明，處於已就緒狀態的pod的最少個數）。執行kubectl get rs和kubectl get pods會顯示Replica Set（RS）和Pod已創建。
[root@k8s-master ~]# kubectl get rs NAME DESIRED CURRENT READY AGE myapp-deploy-2035384211 2 2 0 18s
ReplicaSet 的名字總是<Deployment的名字>-<pod template的hash值>。
[root@k8s-master ~]# kubectl get pods --show-labels NAME READY STATUS RESTARTS AGE LABELS myapp-deploy-2035384211-7ci7o 1/1 Running 0 10s app=myapp,release=canary,pod-template-hash=2035384211 myapp-deploy-2035384211-kzszj 1/1 Running 0 10s app=myapp,release=canary,pod-template-hash=2035384211
剛創建的Replica Set將保證總是有2個myapp的 pod 存在。
注意： 在 Deployment 中的 selector 指定正確的 pod template label（在該示例中是 app = myapp,release=canary），不要跟其他的 controller 的 selector 中指定的 pod template label 搞混了（包括 Deployment、Replica Set、Replication Controller 等）。
上面示例輸出中的 pod label 里的 pod-template-hash label。當 Deployment 創建或者接管 ReplicaSet 時，Deployment controller 會自動為 Pod 添加 pod-template-hash label。這樣做的目的是防止 Deployment 的子ReplicaSet 的 pod 名字重復。通過將 ReplicaSet 的PodTemplate 進行哈希散列，使用生成的哈希值作為 label 的值，並添加到 ReplicaSet selector 里、 pod template label 和 ReplicaSet 管理中的 Pod 上。
3、Deployment更新升級
（1）通過直接更改yaml的方式進行升級，如下：
[root@k8s-master ~]# vim deploy-demo.yaml apiVersion: apps/v1 kind: Deployment metadata: name: myapp-deploy namespace: default spec: replicas: 2 selector: matchLabels: app: myapp release: canary template: metadata: labels: app: myapp release: canary spec: containers: - name: myapp image: ikubernetes/myapp:v2 ports: - name: http containerPort: 80
[root@k8s-master ~]# kubectl apply -f deploy.yaml
升級過程(我們看到，是停止一台，升級一台的這種循環。)
[root@k8s-master ~]# kubectl get pods -l app=myapp -w NAME READY STATUS RESTARTS AGE myapp-deploy-f4bcc4799-cs5xc 1/1 Running 0 23m myapp-deploy-f4bcc4799-cwzd9 1/1 Running 0 14m myapp-deploy-f4bcc4799-k4tq5 1/1 Running 0 23m myapp-deploy-f4bcc4799-shbmb 1/1 Running 0 14m myapp-deploy-f4bcc4799-vtk6m 1/1 Running 0 14m myapp-deploy-f4bcc4799-shbmb 1/1 Terminating 0 16m myapp-deploy-869b888f66-mv5c6 0/1 Pending 0 0s myapp-deploy-869b888f66-mv5c6 0/1 Pending 0 0s myapp-deploy-869b888f66-vk9j6 0/1 Pending 0 0s myapp-deploy-869b888f66-vk9j6 0/1 Pending 0 0s myapp-deploy-869b888f66-mv5c6 0/1 ContainerCreating 0 0s myapp-deploy-869b888f66-r57t5 0/1 Pending 0 0s myapp-deploy-869b888f66-r57t5 0/1 Pending 0 0s myapp-deploy-869b888f66-vk9j6 0/1 ContainerCreating 0 1s myapp-deploy-869b888f66-r57t5 0/1 ContainerCreating 0 1s myapp-deploy-869b888f66-r57t5 0/1 ContainerCreating 0 1s myapp-deploy-869b888f66-mv5c6 0/1 ContainerCreating 0 1s myapp-deploy-869b888f66-vk9j6 0/1 ContainerCreating 0 2s myapp-deploy-f4bcc4799-shbmb 0/1 Terminating 0 16m myapp-deploy-f4bcc4799-shbmb 0/1 Terminating 0 16m myapp-deploy-869b888f66-r57t5 1/1 Running 0 4s myapp-deploy-f4bcc4799-vtk6m 1/1 Terminating 0 16m myapp-deploy-869b888f66-rxzbb 0/1 Pending 0 1s myapp-deploy-869b888f66-rxzbb 0/1 Pending 0 1s myapp-deploy-869b888f66-rxzbb 0/1 ContainerCreating 0 1s myapp-deploy-869b888f66-vk9j6 1/1 Running 0 5s myapp-deploy-f4bcc4799-cwzd9 1/1 Terminating 0 16m myapp-deploy-869b888f66-vvwwv 0/1 Pending 0 0s myapp-deploy-869b888f66-vvwwv 0/1 Pending 0 0s .....
查看一下 rs的情況，以下可以看到原的rs作為備份，而現在是啟動新的rs
[root@k8s-master ~]# kubectl get rs -o wide NAME DESIRED CURRENT READY AGE CONTAINER(S) IMAGE(S) SELECTOR myapp-deploy-869b888f66 2 2 2 3m myapp-containers ikubernetes/myapp:v2 app=myapp,pod-template-hash=4256444922,release=canary myapp-deploy-f4bcc4799 0 0 0 29m myapp-containers ikubernetes/myapp:v1 app=myapp,pod-template-hash=906770355,release=canary
（2）通過set 命令直接修改image的版本進行升級，如下：
[root@k8s-master ~]# kubectl set image deployment/myapp-deploy myapp=ikubernetes/myapp:v2
4、Deployment擴容
（1）使用以下命令擴容 Deployment：
[root@k8s-master ~]# kubectl scale deployment myapp-deploy --replicas 5
（2）直接修改yaml文件的方式進行擴容：
[root@k8s-master ~]# vim demo.yaml
修改.spec.replicas的值
spec:
replicas: 5
[root@k8s-master ~]# kubectl apply -f demo.yaml
（3）通過打補丁的方式進行擴容：
[root@k8s-master ~]# kubectl patch deployment myapp-deploy -p '{"spec":{"replicas":5}}'
[root@k8s-master ~]# kuebctl get pods
5、修改滾動更新策略
可以通過打補丁的方式進行修改更新策略，如下：
[root@k8s-master ~]# kubectl patch deployment myapp-deploy -p '{"spec":{"strategy":{"rollingupdate":{"maxsurge“:1,"maxUnavailable":0}}}}' [root@k8s-master ~]# kubectl describe deploy myapp-deploy Name: myapp-deploy Namespace: default CreationTimestamp: Tue, 28 Aug 2018 09:52:03 -0400 Labels: app=myapp release=canary Annotations: deployment.kubernetes.io/revision=4 kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"name":"myapp-deploy","namespace":"default"},"spec":{"replicas":3,"selector":{... Selector: app=myapp,release=dev Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable StrategyType: RollingUpdate MinReadySeconds: 0 RollingUpdateStrategy: 0 max unavailable, 1 max surge Pod Template: ....
6、金絲雀發布
Deployment控制器支持自定義控制更新過程中的滾動節奏，如“暫停(pause)”或“繼續(resume)”更新操作。比如等待第一批新的Pod資源創建完成后立即暫停更新過程，此時，僅存在一部分新版本的應用，主體部分還是舊的版本。然后，再篩選一小部分的用戶請求路由到新版本的Pod應用，繼續觀察能否穩定地按期望的方式運行。確定沒問題之后再繼續完成余下的Pod資源滾動更新，否則立即回滾更新操作。這就是所謂的金絲雀發布（Canary Release），如下命令演示：
（1）更新deployment的v3版本，並配置暫停deployment
[root@k8s-master ~]# kubectl set image deployment myapp-deploy myapp=ikubernetes/myapp:v3 && kubectl rollout pause deployment myapp-deploy deployment "myapp-deploy" image updated deployment "myapp-deploy" paused
[root@k8s-master ~]# kubectl rollout status deployments myapp-deploy #觀察更新狀態
（2）監控更新的過程，可以看到已經新增了一個資源，但是並未按照預期的狀態去刪除一個舊的資源，就是因為使用了pause暫停命令 [root@k8s-master ~]# kubectl get pods -l app=myapp -w NAME READY STATUS RESTARTS AGE myapp-deploy-869b888f66-dpwvk 1/1 Running 0 24m myapp-deploy-869b888f66-frspv 1/1 Running 0 24m myapp-deploy-869b888f66-sgsll 1/1 Running 0 24m myapp-deploy-7cbd5b69b9-5s4sq 0/1 Pending 0 0s myapp-deploy-7cbd5b69b9-5s4sq 0/1 Pending 0 0s myapp-deploy-7cbd5b69b9-5s4sq 0/1 ContainerCreating 0 1s myapp-deploy-7cbd5b69b9-5s4sq 0/1 ContainerCreating 0 2s myapp-deploy-7cbd5b69b9-5s4sq 1/1 Running 0 19s （3）確保更新的pod沒問題了，繼續更新 [root@k8s-master ~]# kubectl rollout resume deploy myapp-deploy （4）查看最后的更新情況
[root@k8s-master ~]# kubectl get pods -l app=myapp -w NAME READY STATUS RESTARTS AGE myapp-deploy-869b888f66-dpwvk 1/1 Running 0 24m myapp-deploy-869b888f66-frspv 1/1 Running 0 24m myapp-deploy-869b888f66-sgsll 1/1 Running 0 24m myapp-deploy-7cbd5b69b9-5s4sq 0/1 Pending 0 0s myapp-deploy-7cbd5b69b9-5s4sq 0/1 Pending 0 0s myapp-deploy-7cbd5b69b9-5s4sq 0/1 ContainerCreating 0 1s myapp-deploy-7cbd5b69b9-5s4sq 0/1 ContainerCreating 0 2s myapp-deploy-7cbd5b69b9-5s4sq 1/1 Running 0 19s myapp-deploy-869b888f66-dpwvk 1/1 Terminating 0 31m myapp-deploy-7cbd5b69b9-p6kzm 0/1 Pending 0 1s myapp-deploy-7cbd5b69b9-p6kzm 0/1 Pending 0 1s myapp-deploy-7cbd5b69b9-p6kzm 0/1 ContainerCreating 0 1s myapp-deploy-7cbd5b69b9-p6kzm 0/1 ContainerCreating 0 2s myapp-deploy-869b888f66-dpwvk 0/1 Terminating 0 31m myapp-deploy-869b888f66-dpwvk 0/1 Terminating 0 31m myapp-deploy-869b888f66-dpwvk 0/1 Terminating 0 31m myapp-deploy-7cbd5b69b9-p6kzm 1/1 Running 0 18s myapp-deploy-869b888f66-frspv 1/1 Terminating 0 31m myapp-deploy-7cbd5b69b9-q8mvs 0/1 Pending 0 0s myapp-deploy-7cbd5b69b9-q8mvs 0/1 Pending 0 0s myapp-deploy-7cbd5b69b9-q8mvs 0/1 ContainerCreating 0 0s myapp-deploy-7cbd5b69b9-q8mvs 0/1 ContainerCreating 0 1s myapp-deploy-869b888f66-frspv 0/1 Terminating 0 31m myapp-deploy-869b888f66-frspv 0/1 Terminating 0 31m myapp-deploy-869b888f66-frspv 0/1 Terminating 0 31m myapp-deploy-869b888f66-frspv 0/1 Terminating 0 31m ......
7、Deployment版本回退
默認情況下，kubernetes 會在系統中保存前兩次的 Deployment 的 rollout 歷史記錄，以便可以隨時回退（您可以修改revision history limit來更改保存的revision數）。
注意： 只要 Deployment 的 rollout 被觸發就會創建一個 revision。也就是說當且僅當 Deployment 的 Pod template（如.spec.template）被更改，例如更新template 中的 label 和容器鏡像時，就會創建出一個新的 revision。
其他的更新，比如擴容 Deployment 不會創建 revision——因此我們可以很方便的手動或者自動擴容。這意味着當您回退到歷史 revision 時，只有 Deployment 中的 Pod template 部分才會回退。
[root@k8s-master ~]# kubectl rollout history deploy myapp-deploy #檢查Deployment升級記錄 deployments "myapp-deploy" REVISION CHANGE-CAUSE 0 <none> 3 <none> 4 <none> 5 <none>
這里在創建deployment時沒有增加--record參數，所以並不能看到revision的變化。在創建 Deployment 的時候使用了--record參數可以記錄命令，就可以方便的查看每次 revision 的變化。
查看單個revision 的詳細信息：
[root@k8s-master ~]# kubectl rollout history deployment/myapp-deploy --revision=2
回退歷史版本，默認是回退到上一個版本：
[root@k8s-master ~]# kubectl rollout undo deployment/myapp-deploy deployment "myapp-deploy" rolled back
也可以使用 --revision參數指定某個歷史版本：
[root@k8s-master ~]# kubectl rollout undo deployment/myapp-deploy --to-revision=2 deployment "myapp-deploy" rolled back