Deployment可以做到很便捷的管理Pod，只需要在Deployment中描述一下希望的Pod狀態是什麼，包括定義Pod副本數、滾動升級和回滾應用、擴容和縮容、暫停和繼續Deployment等，然後Deployment Controller就可以幫我們實現我們想要達到的狀態。

我們從一個例子入手：

apiVersion: apps/v1kind: Deploymentmetadata: name: nginx-deploymentspec: selector: matchLabels: app: nginx replicas: 2 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80

這個例子中：

我們定義了一個Deployment，名字叫nginx-deployment；通過spec.replicas欄位定義了Pod的副本數是2；通過spec.selector欄位定義了被打上app: nginx的標籤的Pod才會被管理；tmplate欄位定義了這個Deployment管理的Pod應該是怎樣的，具有怎樣的屬性；

總的來說一個Deploymet控制器可以由兩部分組成：

ReplicaSet

ReplicaSet是一個副本控制器，ReplicaSet可以用selector來控制Pod的數量，而Deployments是一個更高層次的概念，它管理ReplicaSets，並提供對pod的宣告性更新以及許多其他的功能。

Deployment通過控制ReplicaSet的個數來和屬性，進而實現“水平擴充套件 / 收縮”和“滾動更新”這兩個編排動作。

水平擴充套件與滾動更新

我們可以通過下面這個命令來建立Deployment：

kubectl create -f nginx-deployment.yaml --record

這裡–record 引數作用是記錄下你每次操作所執行的命令，以方便後面檢視。

檢查一下Deployment狀態：

kubectl get deploymentsNAME READY UP-TO-DATE AVAILABLE AGEnginx-deployment 2/2 2 2  33m

NAME：列舉出Deployments 的名字；READY：顯示了多少個應用的副本是可用的，目前副本數/期望副本數；UP-TO-DATE：顯示了副本更新的次數，這裡顯示為2，說明已經做過2次更新；AVAILABLE：顯示了多少個應用的副本是可用的；AGE：顯示了應用執行的時間。

現在我們使用kubectl scale來做一個水平擴充套件：

kubectl scale deployment nginx-deployment --replicas=4deployment.apps/nginx-deployment scaled

然後我們可以使用rollout status來檢視滾動更新的狀態：

kubectl rollout status deployment/nginx-deploymentWaiting for deployment "nginx-deployment" rollout to finish: 2 of 4 updated replicas are available...Waiting for deployment "nginx-deployment" rollout to finish: 3 of 4 updated replicas are available...deployment "nginx-deployment" successfully rolled out

上面的3 of 4 updated replicas are available表示已經有3個Pod進入了UP-TO-DATE 狀態。

然後我們還可以檢視一下ReplicaSet狀態：

kubectl get rsNAME  DESIRED CURRENT READY AGEnginx-deployment-9754ccbdf 4 4 4 44m

在運行了一個Deployment修改後，Deployment Controller會建立一個副本為ReplicaSet，並會生成一串隨機字元，ReplicaSet 會把這個隨機字串加在它所控制的所有 Pod 的標籤裡，從而保證這些 Pod 不會與叢集裡的其他 Pod 混淆。

我們可以通過 kubectl get pods –show-labels來檢視：

NAME  READY STATUS RESTARTS AGE LABELSnginx-deployment-9754ccbdf-5pl2j 1/1 Running 0 5m4s app=nginx,pod-template-hash=9754ccbdfnginx-deployment-9754ccbdf-67d4g 1/1 Running 0 48m app=nginx,pod-template-hash=9754ccbdfnginx-deployment-9754ccbdf-9drgb 1/1 Running 0 48m app=nginx,pod-template-hash=9754ccbdfnginx-deployment-9754ccbdf-fdmrx 1/1 Running 0 5m4s app=nginx,pod-template-hash=9754ccbdf

下面我們看看Deployment的滾動更新是如何做的：

我們使用set image 來修改deployment中的映象

kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --recorddeployment.apps/nginx-deployment image updated

然後我們可以通過kubectl describe檢視滾動更新的過程：

$ kubectl describe deployment nginx-deployment...Events: Type Reason Age From  Message ---- ------ ---- ----  -------... Normal ScalingReplicaSet 29s  deployment-controller Scaled down replica set nginx-deployment-9754ccbdf to 3 Normal ScalingReplicaSet 29s  deployment-controller Scaled up replica set nginx-deployment-dc46b5ffc to 2 Normal ScalingReplicaSet 12s (x2 over 11m) deployment-controller Scaled down replica set nginx-deployment-9754ccbdf to 2 Normal ScalingReplicaSet 12s  deployment-controller Scaled up replica set nginx-deployment-dc46b5ffc to 3 Normal ScalingReplicaSet 11s  deployment-controller Scaled down replica set nginx-deployment-9754ccbdf to 1 Normal ScalingReplicaSet 11s  deployment-controller Scaled up replica set nginx-deployment-dc46b5ffc to 4 Normal ScalingReplicaSet 11s  deployment-controller Scaled down replica set nginx-deployment-9754ccbdf to 0

可以看到Deployment Controller控制ReplicaSet將舊的Pod 副本數一個個減少，並建立一個新的ReplicaSet：nginx-deployment-dc46b5ffc，並將其控制的Pod副本數一個個增加。

在這個“滾動更新”過程完成之後，你可以檢視一下新、舊兩個 ReplicaSet 的最終狀態：

kubectl get rsNAME  DESIRED CURRENT READY AGEnginx-deployment-9754ccbdf 0 0 0 57mnginx-deployment-dc46b5ffc 4 4 4 5m9s

預設的情況下，Deployment 會保至少有75%的Pod還是可用的，所以我們的例子中，會保證至少有3個Pod是出於可用的狀態。

這個策略，是 Deployment 物件的一個欄位，名叫 RollingUpdateStrategy，如下所示：

 kubectl describe deploymentName:  nginx-deployment...Selector: app=nginxReplicas: 4 desired | 4 updated | 4 total | 4 available | 0 unavailableStrategyType:  RollingUpdateMinReadySeconds: 0RollingUpdateStrategy: 25% max unavailable, 25% max surge...

25% max unavailable表示最大25%不可用；25% max surge表示最多可以建立多少個新的Pod。

版本控制與回滾

在上面的操作中，我們將nginx的版本設定成了1.16.1，現在我們可以通過rollout undo來進行版本的回滾：

kubectl rollout undo deployment/nginx-deploymentdeployment.apps/nginx-deployment rolled back

當然除了這個命令以外由於我們使用了–record，所以我們可以通過kubectl rollout history 來檢視版本資訊：

kubectl rollout history deployment/nginx-deploymentdeployment.apps/nginx-deploymentREVISION CHANGE-CAUSE2 kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record=true3 kubectl apply --filename=nginx-deployment.yaml --record=true

我們可以通過kubectl rollout history來看到相應版本的具體資訊：

kubectl rollout history deployment/nginx-deployment --revision=2

通過kubectl rollout undo命令來回滾到相應的版本：

kubectl rollout undo deployment/nginx-deployment --to-revision=2

Pausing 和Resuming 一個Deployment

我們在上面的操作中，每進行一步操作都會進行一次滾動更新，如果我們想一次性執行多條命令然後再一次性滾動更新，那麼可以先pause Deployment然後操作完之後再resume 它。

如下：

kubectl rollout pause deployment/nginx-deploymentdeployment.apps/nginx-deployment paused

然後就可以隨意的修改這個 Deployment 的內容了。由於此時 Deployment 正處於“暫停”狀態，所以我們對 Deployment 的所有修改，都不會觸發新的“滾動更新”，也不會建立新的 ReplicaSet。

操作完之後再執行：

kubectl rollout resume deployment/nginx-deploymentdeployment.apps/nginx-deployment resumed

在 kubectl rollout pause 指令之後的這段時間裡，我們對 Deployment 進行的所有修改，最後只會觸發一次“滾動更新”。