Kubernetes學習之路（十二）之Pod控制器--ReplicaSet、Deployment

1、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：管理有狀態應用

2、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

 3、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。

一、解析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.

View Code

使用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.

View Code

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。　

二、建立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 上。

三、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
.....

View Code

查看一下 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

四、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

五、修改滾動更新策略

能夠經過打補丁的方式進行修改更新策略，以下：

[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:
....

 六、金絲雀發佈 

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