簡述
Deployment為Pod和ReplicaSet提供了一個聲明式定義(declarative)方法，用來替代以前的ReplicationController來方便的管理應用。典型的應用場景包括：
- 定義Deployment來創建Pod和ReplicaSet
- 滾動升級和回滾應用
- 擴容和縮容
- 暫停和繼續Deployment
比如一個簡單的nginx應用可以定義為
apiVersion:extensions/v1beta1kind:Deploymentmetadata:name:nginx-deploymentspec:replicas:3template:metadata:labels:app:nginxspec:containers:-name:nginximage:nginx:1.7.9ports:-containerPort:80
擴容：
kubectl scale deployment nginx-deployment --replicas 10如果集群支持 horizontal pod autoscaling 的話，還可以為Deployment設置自動擴展：
kubectl autoscale deployment nginx-deployment --min=10--max=15--cpu-percent=80更新鏡像也比較簡單:
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1回滾：
kubectl rollout undo deployment/nginx-deploymentDeployment概念詳細解析
本文翻譯自kubernetes官方文檔：https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/concepts/workloads/controllers/deployment.md
根據2017年5月10日的Commit 8481c02 翻譯。
Deployment是什么？
Deployment為Pod和Replica Set（下一代Replication Controller）提供聲明式更新。
你只需要在Deployment中描述你想要的目標狀態是什么，Deployment controller就會幫你將Pod和Replica Set的實際狀態改變到你的目標狀態。你可以定義一個全新的Deployment，也可以創建一個新的替換舊的Deployment。
一個典型的用例如下：
- 使用Deployment來創建ReplicaSet。ReplicaSet在后台創建pod。檢查啟動狀態，看它是成功還是失敗。
- 然后，通過更新Deployment的PodTemplateSpec字段來聲明Pod的新狀態。這會創建一個新的ReplicaSet，Deployment會按照控制的速率將pod從舊的ReplicaSet移動到新的ReplicaSet中。
- 如果當前狀態不穩定，回滾到之前的Deployment revision。每次回滾都會更新Deployment的revision。
- 擴容Deployment以滿足更高的負載。
- 暫停Deployment來應用PodTemplateSpec的多個修復，然后恢復上線。
- 根據Deployment 的狀態判斷上線是否hang住了。
- 清除舊的不必要的ReplicaSet。
創建Deployment
下面是一個Deployment示例，它創建了一個Replica Set來啟動3個nginx pod。
下載示例文件並執行命令：
$ kubectl create -f docs/user-guide/nginx-deployment.yaml --record
deployment "nginx-deployment" created
將kubectl的 —record 的flag設置為 true可以在annotation中記錄當前命令創建或者升級了該資源。這在未來會很有用，例如，查看在每個Deployment revision中執行了哪些命令。
然后立即執行getí將獲得如下結果：
$ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 30001s
輸出結果表明我們希望的repalica數是3（根據deployment中的.spec.replicas配置）當前replica數（ .status.replicas）是0, 最新的replica數（.status.updatedReplicas）是0，可用的replica數（.status.availableReplicas）是0。
過幾秒后再執行get命令，將獲得如下輸出：
$ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 333318s
我們可以看到Deployment已經創建了3個replica，所有的replica都已經是最新的了（包含最新的pod template），可用的（根據Deployment中的.spec.minReadySeconds聲明，處於已就緒狀態的pod的最少個數）。執行kubectl get rs和kubectl get pods會顯示Replica Set（RS）和Pod已創建。
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-203538421133018s
你可能會注意到Replica Set的名字總是<Deployment的名字>-<pod template的hash值>。
$ kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx-deployment-2035384211-7ci7o1/1Running018s app=nginx,pod-template-hash=2035384211
nginx-deployment-2035384211-kzszj 1/1Running018s app=nginx,pod-template-hash=2035384211
nginx-deployment-2035384211-qqcnn 1/1Running018s app=nginx,pod-template-hash=2035384211
剛創建的Replica Set將保證總是有3個nginx的pod存在。
注意： 你必須在Deployment中的selector指定正確pod template label（在該示例中是 app = nginx），不要跟其他的controller搞混了（包括Deployment、Replica Set、Replication Controller等）。Kubernetes本身不會阻止你這么做，如果你真的這么做了，這些controller之間會相互打架，並可能導致不正確的行為。
更新Deployment
注意： Deployment的rollout當且僅當Deployment的pod template（例如.spec.template）中的label更新或者鏡像更改時被觸發。其他更新，例如擴容Deployment不會觸發rollout。
假如我們現在想要讓nginx pod使用nginx:1.9.1的鏡像來代替原來的nginx:1.7.9的鏡像。
$ kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
deployment "nginx-deployment" image updated
我們可以使用edit命令來編輯Deployment，修改 .spec.template.spec.containers[0].image ，將nginx:1.7.9 改寫成nginx:1.9.1。
$ kubectl edit deployment/nginx-deployment
deployment "nginx-deployment" edited
查看rollout的狀態，只要執行：
$ kubectl rollout status deployment/nginx-deployment
Waitingfor rollout to finish:2out of 3new replicas have been updated...
deployment "nginx-deployment" successfully rolled out
Rollout成功后，get Deployment：
$ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 333336s
UP-TO-DATE的replica的數目已經達到了配置中要求的數目。
CURRENT的replica數表示Deployment管理的replica數量，AVAILABLE的replica數是當前可用的replica數量。
We can run kubectl get rs to see that the Deployment updated the Pods by creating a new Replica Set and scaling it up to 3 replicas, as well as scaling down the old Replica Set to 0 replicas.
我們通過執行kubectl get rs可以看到Deployment更新了Pod，通過創建一個新的Replica Set並擴容了3個replica，同時將原來的Replica Set縮容到了0個replica。
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-15641803653306s
nginx-deployment-203538421100036s
執行 get pods只會看到當前的新的pod:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-deployment-1564180365-khku8 1/1Running014s
nginx-deployment-1564180365-nacti 1/1Running014s
nginx-deployment-1564180365-z9gth 1/1Running014s
下次更新這些pod的時候，只需要更新Deployment中的pod的template即可。
Deployment可以保證在升級時只有一定數量的Pod是down的。默認的，它會確保至少有比期望的Pod數量少一個的Pod是up狀態（最多一個不可用）。
Deployment同時也可以確保只創建出超過期望數量的一定數量的Pod。默認的，它會確保最多比期望的Pod數量多一個的Pod是up的（最多1個surge）。
在未來的Kuberentes版本中，將從1-1變成25%-25%）。
例如，如果你自己看下上面的Deployment，你會發現，開始創建一個新的Pod，然后刪除一些舊的Pod再創建一個新的。當新的Pod創建出來之前不會殺掉舊的Pod。這樣能夠確保可用的Pod數量至少有2個，Pod的總數最多4個。
$ kubectl describe deployments
Name: nginx-deployment
Namespace:defaultCreationTimestamp:Tue,15Mar201612:01:06-0700Labels: app=nginx
Selector: app=nginx
Replicas:3 updated |3 total |3 available |0 unavailable
StrategyType:RollingUpdateMinReadySeconds:0RollingUpdateStrategy:1 max unavailable,1 max surge
OldReplicaSets:<none>NewReplicaSet: nginx-deployment-1564180365(3/3 replicas created)Events:FirstSeenLastSeenCountFromSubobjectPathTypeReasonMessage------------------------------------------------------------36s36s1{deployment-controller }NormalScalingReplicaSetScaled up replica set nginx-deployment-2035384211 to 323s23s1{deployment-controller }NormalScalingReplicaSetScaled up replica set nginx-deployment-1564180365 to 123s23s1{deployment-controller }NormalScalingReplicaSetScaled down replica set nginx-deployment-2035384211 to 223s23s1{deployment-controller }NormalScalingReplicaSetScaled up replica set nginx-deployment-1564180365 to 221s21s1{deployment-controller }NormalScalingReplicaSetScaled down replica set nginx-deployment-2035384211 to 021s21s1{deployment-controller }NormalScalingReplicaSetScaled up replica set nginx-deployment-1564180365 to 3
我們可以看到當我們剛開始創建這個Deployment的時候，創建了一個Replica Set（nginx-deployment-2035384211），並直接擴容到了3個replica。
當我們更新這個Deployment的時候，它會創建一個新的Replica Set（nginx-deployment-1564180365），將它擴容到1個replica，然后縮容原先的Replica Set到2個replica，此時滿足至少2個Pod是可用狀態，同一時刻最多有4個Pod處於創建的狀態。
接着繼續使用相同的rolling update策略擴容新的Replica Set和縮容舊的Replica Set。最終，將會在新的Replica Set中有3個可用的replica，舊的Replica Set的replica數目變成0。
Rollover（多個rollout並行）
每當Deployment controller觀測到有新的deployment被創建時，如果沒有已存在的Replica Set來創建期望個數的Pod的話，就會創建出一個新的Replica Set來做這件事。已存在的Replica Set控制label匹配.spec.selector但是template跟.spec.template不匹配的Pod縮容。最終，新的Replica Set將會擴容出.spec.replicas指定數目的Pod，舊的Replica Set會縮容到0。
如果你更新了一個的已存在並正在進行中的Deployment，每次更新Deployment都會創建一個新的Replica Set並擴容它，同時回滾之前擴容的Replica Set——將它添加到舊的Replica Set列表，開始縮容。
例如，假如你創建了一個有5個niginx:1.7.9 replica的Deployment，但是當還只有3個nginx:1.7.9的replica創建出來的時候你就開始更新含有5個nginx:1.9.1 replica的Deployment。在這種情況下，Deployment會立即殺掉已創建的3個nginx:1.7.9的Pod，並開始創建nginx:1.9.1的Pod。它不會等到所有的5個nginx:1.7.9的Pod都創建完成后才開始改變航道。
回退Deployment
有時候你可能想回退一個Deployment，例如，當Deployment不穩定時，比如一直crash looping。
默認情況下，kubernetes會在系統中保存前兩次的Deployment的rollout歷史記錄，以便你可以隨時會退（你可以修改revision history limit來更改保存的revision數）。ß
注意： 只要Deployment的rollout被觸發就會創建一個revision。也就是說當且僅當Deployment的Pod template（如.spec.template）被更改，例如更新template中的label和容器鏡像時，就會創建出一個新的revision。
其他的更新，比如擴容Deployment不會創建revision——因此我們可以很方便的手動或者自動擴容。這意味着當你回退到歷史revision是，直郵Deployment中的Pod template部分才會回退。
假設我們在更新Deployment的時候犯了一個拼寫錯誤，將鏡像的名字寫成了nginx:1.91，而正確的名字應該是nginx:1.9.1：
$ kubectl set image deployment/nginx-deployment nginx=nginx:1.91
deployment "nginx-deployment" image updated
Rollout將會卡住。
$ kubectl rollout status deployments nginx-deployment
Waitingfor rollout to finish:2out of 3new replicas have been updated...
按住Ctrl-C停止上面的rollout狀態監控。
你會看到舊的replicas（nginx-deployment-1564180365 和 nginx-deployment-2035384211）和新的replicas （nginx-deployment-3066724191）數目都是2個。
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-156418036522025s
nginx-deployment-203538421100036s
nginx-deployment-30667241912226s
看下創建Pod，你會看到有兩個新的呃Replica Set創建的Pod處於ImagePullBackOff狀態，循環拉取鏡像。
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-deployment-1564180365-70iae1/1Running025s
nginx-deployment-1564180365-jbqqo 1/1Running025s
nginx-deployment-3066724191-08mng0/1ImagePullBackOff06s
nginx-deployment-3066724191-eocby 0/1ImagePullBackOff06s
注意，Deployment controller會自動停止壞的rollout，並停止擴容新的Replica Set。
$ kubectl describe deployment
Name: nginx-deployment
Namespace:defaultCreationTimestamp:Tue,15Mar201614:48:04-0700Labels: app=nginx
Selector: app=nginx
Replicas:2 updated |3 total |2 available |2 unavailable
StrategyType:RollingUpdateMinReadySeconds:0RollingUpdateStrategy:1 max unavailable,1 max surge
OldReplicaSets: nginx-deployment-1564180365(2/2 replicas created)NewReplicaSet: nginx-deployment-3066724191(2/2 replicas created)Events:FirstSeenLastSeenCountFromSubobjectPathTypeReasonMessage------------------------------------------------------------1m1m1{deployment-controller }NormalScalingReplicaSetScaled up replica set nginx-deployment-2035384211 to 322s22s1{deployment-controller }NormalScalingReplicaSetScaled up replica set nginx-deployment-1564180365 to 122s22s1{deployment-controller }NormalScalingReplicaSetScaled down replica set nginx-deployment-2035384211 to 222s22s1{deployment-controller }NormalScalingReplicaSetScaled up replica set nginx-deployment-1564180365 to 221s21s1{deployment-controller }NormalScalingReplicaSetScaled down replica set nginx-deployment-2035384211 to 021s21s1{deployment-controller }NormalScalingReplicaSetScaled up replica set nginx-deployment-1564180365 to 313s13s1{deployment-controller }NormalScalingReplicaSetScaled up replica set nginx-deployment-3066724191 to 113s13s1{deployment-controller }NormalScalingReplicaSetScaled down replica set nginx-deployment-1564180365 to 213s13s1{deployment-controller }NormalScalingReplicaSetScaled up replica set nginx-deployment-3066724191 to 2
為了修復這個問題，我們需要回退到穩定的Deployment revision。
檢查Deployment升級的歷史記錄
首先，檢查下Deployment的revision：
$ kubectl rollout history deployment/nginx-deployment
deployments "nginx-deployment":
REVISION CHANGE-CAUSE
1 kubectl create -f docs/user-guide/nginx-deployment.yaml --record
2 kubectl set image deployment/nginx-deployment nginx=nginx:1.9.13 kubectl set image deployment/nginx-deployment nginx=nginx:1.91
因為我們創建Deployment的時候使用了—recored參數可以記錄命令，我們可以很方便的查看每次revison的變化。
查看單個revision的詳細信息：
$ kubectl rollout history deployment/nginx-deployment --revision=2
deployments "nginx-deployment" revision 2Labels: app=nginx
pod-template-hash=1159050644Annotations: kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1Containers:
nginx:Image: nginx:1.9.1Port:80/TCP
QoSTier:
cpu:BestEffort
memory:BestEffortEnvironmentVariables:<none>No volumes.
回退到歷史版本
現在，我們可以決定回退當前的rollout到之前的版本：
$ kubectl rollout undo deployment/nginx-deployment
deployment "nginx-deployment" rolled back
也可以使用 --revision參數指定某個歷史版本：
$ kubectl rollout undo deployment/nginx-deployment --to-revision=2
deployment "nginx-deployment" rolled back
與rollout相關的命令詳細文檔見kubectl rollout。
該Deployment現在已經回退到了先前的穩定版本。如你所見，Deployment controller產生了一個回退到revison 2的DeploymentRollback的event。
$ kubectl get deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 333330m
$ kubectl describe deployment
Name: nginx-deployment
Namespace:defaultCreationTimestamp:Tue,15Mar201614:48:04-0700Labels: app=nginx
Selector: app=nginx
Replicas:3 updated |3 total |3 available |0 unavailable
StrategyType:RollingUpdateMinReadySeconds:0RollingUpdateStrategy:1 max unavailable,1 max surge
OldReplicaSets:<none>NewReplicaSet: nginx-deployment-1564180365(3/3 replicas created)Events:FirstSeenLastSeenCountFromSubobjectPathTypeReasonMessage------------------------------------------------------------30m30m1{deployment-controller }NormalScalingReplicaSetScaled up replica set nginx-deployment-2035384211 to 329m29m1{deployment-controller }NormalScalingReplicaSetScaled up replica set nginx-deployment-1564180365 to 129m29m1{deployment-controller }NormalScalingReplicaSetScaled down replica set nginx-deployment-2035384211 to 229m29m1{deployment-controller }NormalScalingReplicaSetScaled up replica set nginx-deployment-1564180365 to 229m29m1{deployment-controller }NormalScalingReplicaSetScaled down replica set nginx-deployment-2035384211 to 029m29m1{deployment-controller }NormalScalingReplicaSetScaled up replica set nginx-deployment-3066724191 to 229m29m1{deployment-controller }NormalScalingReplicaSetScaled up replica set nginx-deployment-3066724191 to 129m29m1{deployment-controller }NormalScalingReplicaSetScaled down replica set nginx-deployment-1564180365 to 22m2m1{deployment-controller }NormalScalingReplicaSetScaled down replica set nginx-deployment-3066724191 to 02m2m1{deployment-controller }NormalDeploymentRollbackRolled back deployment "nginx-deployment" to revision 229m2m2{deployment-controller }NormalScalingReplicaSetScaled up replica set nginx-deployment-1564180365 to 3
清理Policy
你可以通過設置.spec.revisonHistoryLimit項來指定deployment最多保留多少revison歷史記錄。默認的會保留所有的revision；如果將該項設置為0，Deployment就不允許回退了。
Deployment擴容
你可以使用以下命令擴容Deployment：
$ kubectl scale deployment nginx-deployment --replicas 10
deployment "nginx-deployment" scaled
假設你的集群中啟用了horizontal pod autoscaling，你可以給Deployment設置一個autoscaler，基於當前Pod的CPU利用率選擇最少和最多的Pod數。
$ kubectl autoscale deployment nginx-deployment --min=10--max=15--cpu-percent=80
deployment "nginx-deployment" autoscaled
比例擴容
RollingUpdate Deployment支持同時運行一個應用的多個版本。當你活着autoscaler擴容RollingUpdate Deployment的時候，正在中途的rollout（進行中或者已經暫停的），為了降低風險，Deployment controller將會平衡已存在的活動中的ReplicaSets（有Pod的ReplicaSets）和新加入的replicas。這被稱為比例擴容。
例如，你正在運行中含有10個replica的Deployment。maxSurge=3，maxUnavailable=2。
$ kubectl get deploy
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 1010101050s
你更新了一個鏡像，而在集群內部無法解析。
$ kubectl set image deploy/nginx-deployment nginx=nginx:sometag
deployment "nginx-deployment" image updated
鏡像更新啟動了一個包含ReplicaSet nginx-deployment-1989198191的新的rollout，但是它被阻塞了，因為我們上面提到的maxUnavailable。
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-19891981915509s
nginx-deployment-6185152328881m
然后發起了一個新的Deployment擴容請求。autoscaler將Deployment的repllica數目增加到了15個。Deployment controller需要判斷在哪里增加這5個新的replica。如果我們沒有誰用比例擴容，所有的5個replica都會加到一個新的ReplicaSet中。如果使用比例擴容，新添加的replica將傳播到所有的ReplicaSet中。大的部分加入replica數最多的ReplicaSet中，小的部分加入到replica數少的ReplciaSet中。0個replica的ReplicaSet不會被擴容。
在我們上面的例子中，3個replica將添加到舊的ReplicaSet中，2個replica將添加到新的ReplicaSet中。rollout進程最終會將所有的replica移動到新的ReplicaSet中，假設新的replica成為健康狀態。
$ kubectl get deploy
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 1518787m
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-19891981917707m
nginx-deployment-6185152321111117m
暫停和恢復Deployment
你可以在出發一次或多次更新前暫停一個Deployment，然后再恢復它。這樣你就能多次暫停和恢復Deployment，在此期間進行一些修復工作，而不會出發不必要的rollout。
例如使用剛剛創建Deployment：
$ kubectl get deploy
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx 33331m[mkargaki@dhcp129-211 kubernetes]$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-21421163213331m
使用以下命令暫停Deployment：
$ kubectl rollout pause deployment/nginx-deployment
deployment "nginx-deployment" paused
然后更新Deplyment中的鏡像：
$ kubectl set image deploy/nginx nginx=nginx:1.9.1
deployment "nginx-deployment" image updated
注意新的rollout啟動了：
$ kubectl rollout history deploy/nginx
deployments "nginx"
REVISION CHANGE-CAUSE
1<none>
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-21421163213332m
你可以進行任意多次更新，例如更新使用的資源：
$ kubectl set resources deployment nginx -c=nginx --limits=cpu=200m,memory=512Mi
deployment "nginx" resource requirements updated
Deployment暫停前的初始狀態將繼續它的功能，而不會對Deployment的更新產生任何影響，只要Deployment是暫停的。
最后，恢復這個Deployment，觀察完成更新的ReplicaSet已經創建出來了：
$ kubectl rollout resume deploy nginx
deployment "nginx" resumed
$ KUBECTL get rs -w
NAME DESIRED CURRENT READY AGE
nginx-21421163212222m
nginx-39263615312206s
nginx-392636153122118s
nginx-21421163211222m
nginx-21421163211222m
nginx-392636153132118s
nginx-392636153132118s
nginx-21421163211112m
nginx-392636153133118s
nginx-392636153133219s
nginx-21421163210112m
nginx-21421163210112m
nginx-21421163210002m
nginx-392636153133320s^C
$ KUBECTL get rs
NAME DESIRED CURRENT READY AGE
nginx-21421163210002m
nginx-392636153133328s
注意： 在恢復Deployment之前你無法回退一個暫停了個Deployment。
Deployment狀態
Deployment在生命周期中有多種狀態。在創建一個新的ReplicaSet的時候它可以是 progressing 狀態， complete 狀態，或者fail to progress狀態。
Progressing Deployment
Kubernetes將執行過下列任務之一的Deployment標記為progressing狀態：
- Deployment正在創建新的ReplicaSet過程中。
- Deployment正在擴容一個已有的ReplicaSet。
- Deployment正在縮容一個已有的ReplicaSet。
- 有新的可用的pod出現。
你可以使用kubectl roullout status命令監控Deployment的進度。
Complete Deployment
Kubernetes將包括以下特性的Deployment標記為complete狀態：
- Deployment最小可用。最小可用意味着Deployment的可用replica個數等於或者超過Deployment策略中的期望個數。
- 所有與該Deployment相關的replica都被更新到了你指定版本，也就說更新完成。
- 該Deployment中沒有舊的Pod存在。
你可以用kubectl rollout status命令查看Deployment是否完成。如果rollout成功完成，kubectl rollout status將返回一個0值的Exit Code。
$ kubectl rollout status deploy/nginx Waitingfor rollout to finish:2 of 3 updated replicas are available... deployment "nginx" successfully rolled out $ echo $?0Failed Deployment
你的Deployment在嘗試部署新的ReplicaSet的時候可能卡住，用於也不會完成。這可能是因為以下幾個因素引起的：
- 無效的引用
- 不可讀的probe failure
- 鏡像拉取錯誤
- 權限不夠
- 范圍限制
- 程序運行時配置錯誤
探測這種情況的一種方式是，在你的Deployment spec中指定spec.progressDeadlineSeconds。spec.progressDeadlineSeconds表示Deployment controller等待多少秒才能確定（通過Deployment status）Deployment進程是卡住的。
下面的kubectl命令設置progressDeadlineSeconds 使controller在Deployment在進度卡住10分鍾后報告：
$ kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'"nginx-deployment" patchedOnce the deadline has been exceeded, the Deployment controller adds a with the following attributes to the Deployment’s
當超過截止時間后，Deployment controller會在Deployment的 status.conditions中增加一條DeploymentCondition，它包括如下屬性：
- Type=Progressing
- Status=False
- Reason=ProgressDeadlineExceeded
瀏覽 Kubernetes API conventions 查看關於status conditions的更多信息。
注意： kubernetes除了報告Reason=ProgressDeadlineExceeded狀態信息外不會對卡住的Deployment做任何操作。更高層次的協調器可以利用它並采取相應行動，例如，回滾Deployment到之前的版本。
注意： 如果你暫停了一個Deployment，在暫停的這段時間內kubernetnes不會檢查你指定的deadline。你可以在Deployment的rollout途中安全的暫停它，然后再恢復它，這不會觸發超過deadline的狀態。
你可能在使用Deployment的時候遇到一些短暫的錯誤，這些可能是由於你設置了太短的timeout，也有可能是因為各種其他錯誤導致的短暫錯誤。例如，假設你使用了無效的引用。當你Describe Deployment的時候可能會注意到如下信息：
$ kubectl describe deployment nginx-deployment <...>Conditions:TypeStatusReason----------------AvailableTrueMinimumReplicasAvailableProgressingTrueReplicaSetUpdatedReplicaFailureTrueFailedCreate<...>執行 kubectl get deployment nginx-deployment -o yaml，Deployement 的狀態可能看起來像這個樣子：
status:availableReplicas:2conditions:-lastTransitionTime:2016-10-04T12:25:39ZlastUpdateTime:2016-10-04T12:25:39Zmessage:Replicaset"nginx-deployment-4262182780"is progressing.reason:ReplicaSetUpdatedstatus:"True"type:Progressing-lastTransitionTime:2016-10-04T12:25:42ZlastUpdateTime:2016-10-04T12:25:42Zmessage:Deployment has minimum availability.reason:MinimumReplicasAvailablestatus:"True"type:Available-lastTransitionTime:2016-10-04T12:25:39ZlastUpdateTime:2016-10-04T12:25:39Zmessage:'Error creating: pods "nginx-deployment-4262182780-" is forbidden: exceeded quota: object-counts, requested: pods=1, used: pods=3, limited: pods=2'reason:FailedCreatestatus:"True"type:ReplicaFailureobservedGeneration:3replicas:2unavailableReplicas:2
最終，一旦超過Deployment進程的deadline，kuberentes會更新狀態和導致Progressing狀態的原因：
Conditions:TypeStatusReason----------------AvailableTrueMinimumReplicasAvailableProgressingFalseProgressDeadlineExceededReplicaFailureTrueFailedCreate你可以通過縮容Deployment的方式解決配額不足的問題，或者增加你的namespace的配額。如果你滿足了配額條件后，Deployment controller就會完成你的Deployment rollout，你將看到Deployment的狀態更新為成功狀態（Status=True並且Reason=NewReplicaSetAvailable）。
Conditions:TypeStatusReason----------------AvailableTrueMinimumReplicasAvailableProgressingTrueNewReplicaSetAvailableType=Available、 Status=True 以為這你的Deployment有最小可用性。 最小可用性是在Deployment策略中指定的參數。Type=Progressing 、 Status=True意味着你的Deployment 或者在部署過程中，或者已經成功部署，達到了期望的最少的可用replica數量（查看特定狀態的Reason——在我們的例子中Reason=NewReplicaSetAvailable 意味着Deployment已經完成）。
你可以使用kubectl rollout status命令查看Deployment進程是否失敗。當Deployment過程超過了deadline，kubectl rollout status將返回非0的exit code。
$ kubectl rollout status deploy/nginx Waitingfor rollout to finish:2out of 3new replicas have been updated... error: deployment "nginx" exceeded its progress deadline $ echo $?1操作失敗的Deployment
所有對完成的Deployment的操作都適用於失敗的Deployment。你可以對它闊／縮容，回退到歷史版本，你甚至可以多次暫停它來應用Deployment pod template。
清理Policy
你可以設置Deployment中的 .spec.revisionHistoryLimit 項來指定保留多少舊的ReplicaSet。 余下的將在后台被當作垃圾收集。默認的，所有的revision歷史就都會被保留。在未來的版本中，將會更改為2。
注意： 將該值設置為0，將導致所有的Deployment歷史記錄都會被清除，該Deploynent就無法再回退了。
用例
Canary Deployment
如果你想要使用Deployment對部分用戶或服務器發布relaese，你可以創建多個Deployment，每個對一個release，參照managing resources 中對金絲雀模式的描述。
編寫Deployment Spec
在所有的Kubernetes配置中，Deployment也需要apiVersion，kind和metadata這些配置項。配置文件的通用使用說明查看部署應用，配置容器，和使用kubeclt管理資源文檔。
Deployment也需要 .spec section.
Pod Template
.spec.template 是 .spec中唯一要求的字段。
.spec.template 是 pod template. 它跟 Pod有一模一樣的schema，除了它是嵌套的並且不需要apiVersion 和 kind字段。
另外為了划分Pod的范圍，Deployment中的pod template必須指定適當的label（不要跟其他controller重復了，參考selector）和適當的重啟策略。
.spec.template.spec.restartPolicy 可以設置為 Always , 如果不指定的話這就是默認配置。
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。
注意： 你不應該再創建其他label跟這個selector匹配的pod，或者通過其他Deployment，或者通過其他Controller，例如ReplicaSet和ReplicationController。否則該Deployment會被把它們當成都是自己創建的。Kubernetes不會阻止你這么做。
如果你有多個controller使用了重復的selector，controller們就會互相打架並導致不正確的行為。
策略
.spec.strategy 指定新的Pod替換舊的Pod的策略。 .spec.strategy.type 可以是”Recreate”或者是 “RollingUpdate”。”RollingUpdate”是默認值。
Recreate Deployment
.spec.strategy.type==Recreate時，在創建出新的Pod之前會先殺掉所有已存在的Pod。
Rolling Update Deployment
.spec.strategy.type==RollingUpdate時，Deployment使用rolling update 的方式更新Pod 。你可以指定maxUnavailable 和maxSurge 來控制 rolling update 進程。
Max Unavailable
.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%。
Max Surge
.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%。
Progress Deadline Seconds
.spec.progressDeadlineSeconds 是可選配置項，用來指定在系統報告Deployment的failed progressing ——表現為resource的狀態中type=Progressing、Status=False、 Reason=ProgressDeadlineExceeded前可以等待的Deployment進行的秒數。Deployment controller會繼續重試該Deployment。未來，在實現了自動回滾后， deployment controller在觀察到這種狀態時就會自動回滾。
如果設置該參數，該值必須大於 .spec.minReadySeconds。
Min Ready Seconds
.spec.minReadySeconds是一個可選配置項，用來指定沒有任何容器crash的Pod並被認為是可用狀態的最小秒數。默認是0（Pod在ready后就會被認為是可用狀態）。進一步了解什么什么后Pod會被認為是ready狀態，參閱 Container Probes。
Rollback To
.spec.rollbackTo 是一個可以選配置項，用來配置Deployment回退的配置。設置該參數將觸發回退操作，每次回退完成后，該值就會被清除。
Revision
.spec.rollbackTo.revision是一個可選配置項，用來指定回退到的revision。默認是0，意味着回退到歷史中最老的revision。
Revision History Limit
Deployment revision history存儲在它控制的ReplicaSets中。
.spec.revisionHistoryLimit 是一個可選配置項，用來指定可以保留的舊的ReplicaSet數量。該理想值取決於心Deployment的頻率和穩定性。如果該值沒有設置的話，默認所有舊的Replicaset或會被保留，將資源存儲在etcd中，是用kubectl get rs查看輸出。每個Deployment的該配置都保存在ReplicaSet中，然而，一旦你刪除的舊的RepelicaSet，你的Deployment就無法再回退到那個revison了。
如果你將該值設置為0，所有具有0個replica的ReplicaSet都會被刪除。在這種情況下，新的Deployment rollout無法撤銷，因為revision history都被清理掉了。
Paused
.spec.paused是可以可選配置項，boolean值。用來指定暫停和恢復Deployment。Paused和沒有paused的Deployment之間的唯一區別就是，所有對paused deployment中的PodTemplateSpec的修改都不會觸發新的rollout。Deployment被創建之后默認是非paused。
Alternative to Deployments
kubectl rolling update
Kubectl rolling update 雖然使用類似的方式更新Pod和ReplicationController。但是我們推薦使用Deployment，因為它是聲明式的，客戶端側，具有附加特性，例如即使滾動升級結束后也可以回滾到任何歷史版本。
原文：https://github.com/rootsongjc/kubernetes-handbook/blob/master/architecture/deployment.md