Deployment可以做到很便捷的管理Pod，只需要在Deployment中描述一下希望的Pod狀態時什麼，包括定義Pod副本數、滾動升級和回滾應用、擴容和縮容、暫停和繼續Deployment等，然後Deployment Controller就可以幫我們實現我們想要達到的狀態。
我們從一個例子入手：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
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 deployments
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 2/2 2 2 33m
- NAME：列舉出Deployments 的名字；
- READY：顯示了多少個應用的副本是可用的，目前副本數/期望副本數；
- UP-TO-DATE：顯示了副本更新的次數，這裏顯示爲2，說明已經做過2此更新；
- AVAILABLE：顯示了多少個應用的副本是可用的；
- AGE：顯示了應用運行的時間。
現在我們使用kubectl scale來做一個水平擴展：
kubectl scale deployment nginx-deployment --replicas=4
deployment.apps/nginx-deployment scaled
然後我們可以使用rollout status來查看滾動更新的狀態：
kubectl rollout status deployment/nginx-deployment
Waiting 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 rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-9754ccbdf 4 4 4 44m
在運行了一個Deployment修改後，Deployment Controller會創建一個副本爲ReplicaSet，並會生成一串隨機字符，ReplicaSet 會把這個隨機字符串加在它所控制的所有 Pod 的標籤裏，從而保證這些 Pod 不會與集羣裏的其他 Pod 混淆。
我們可以通過 kubectl get pods --show-labels來查看：
NAME READY STATUS RESTARTS AGE LABELS
nginx-deployment-9754ccbdf-5pl2j 1/1 Running 0 5m4s app=nginx,pod-template-hash=9754ccbdf
nginx-deployment-9754ccbdf-67d4g 1/1 Running 0 48m app=nginx,pod-template-hash=9754ccbdf
nginx-deployment-9754ccbdf-9drgb 1/1 Running 0 48m app=nginx,pod-template-hash=9754ccbdf
nginx-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 --record
deployment.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 rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-9754ccbdf 0 0 0 57m
nginx-deployment-dc46b5ffc 4 4 4 5m9s
默認的情況下，Deployment 會保至少有75%的Pod還是可用的，所以我們的例子中，會保證至少有3個Pod是出於可用的狀態。
這個策略，是 Deployment 對象的一個字段，名叫 RollingUpdateStrategy，如下所示：
kubectl describe deployment
Name: nginx-deployment
...
Selector: app=nginx
Replicas: 4 desired | 4 updated | 4 total | 4 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 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-deployment
deployment.apps/nginx-deployment rolled back
當然除了這個命令以外由於我們使用了--record，所以我們可以通過kubectl rollout history 來查看版本信息：
kubectl rollout history deployment/nginx-deployment
deployment.apps/nginx-deployment
REVISION CHANGE-CAUSE
2 kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record=true
3 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-deployment
deployment.apps/nginx-deployment paused
然後就可以隨意的修改這個 Deployment 的內容了。由於此時 Deployment 正處於“暫停”狀態，所以我們對 Deployment 的所有修改，都不會觸發新的“滾動更新”，也不會創建新的 ReplicaSet。
操作完之後再執行：
kubectl rollout resume deployment/nginx-deployment
deployment.apps/nginx-deployment resumed
在 kubectl rollout pause 指令之後的這段時間裏，我們對 Deployment 進行的所有修改，最後只會觸發一次“滾動更新”。