kubernetes對象之deployment

時間 2019-11-11

標籤 kubernetes 對象 deployment 简体版

原文原文鏈接

系列目錄html

簡述

Deployment爲Pod和ReplicaSet提供了一個聲明式定義(declarative)方法，用來替代之前的ReplicationController來方便的管理應用。典型的應用場景包括：nginx

定義Deployment來建立Pod和ReplicaSetapi
滾動升級和回滾應用bash
擴容和縮容app
暫停和繼續Deploymentide

好比一個簡單的nginx應用能夠定義爲:oop

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

擴容:ui

kubectl scale deployment nginx-deployment --replicas 10

若是集羣支持 horizontal pod autoscaling 的話，還能夠爲Deployment設置自動擴展：spa

kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

回滾:.net

kubectl rollout undo deployment/nginx-deployment

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。

執行deployment

$ kubectl create -f docs/user-guide/nginx-deployment.yaml --record
deployment "nginx-deployment" created

注意,kubectl create -f後面跟一個文件名,實際工做中要以你的實際文件名和路徑爲準

將kubectl的 —record 的flag設置爲 true能夠在annotation中記錄當前命令建立或者升級了該資源。這在將來會頗有用，例如，查看在每一個Deployment revision中執行了哪些命令。

而後當即執行getí將得到以下結果：

$ kubectl get deployments
NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3         0         0            0           1s

輸出結果代表咱們但願的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   3         3         3            3           18s

咱們能夠看到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-2035384211   3         3         0       18s

你可能會注意到Replica Set的名字老是 - 。

$ kubectl get pods --show-labels
NAME                                READY     STATUS    RESTARTS   AGE       LABELS
nginx-deployment-2035384211-7ci7o   1/1       Running   0          18s       app=nginx,pod-template-hash=2035384211
nginx-deployment-2035384211-kzszj   1/1       Running   0          18s       app=nginx,pod-template-hash=2035384211
nginx-deployment-2035384211-qqcnn   1/1       Running   0          18s       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自己不會阻止你這麼作，若是你真的這麼作了，可能致使不正確的行爲。

更新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
Waiting for rollout to finish: 2 out of 3 new 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   3         3         3            3           36s

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-1564180365   3         3         0       6s
nginx-deployment-2035384211   0         0         0       36s

執行 get pods只會看到當前的新的pod:

$ kubectl get pods
NAME                                READY     STATUS    RESTARTS   AGE
nginx-deployment-1564180365-khku8   1/1       Running   0          14s
nginx-deployment-1564180365-nacti   1/1       Running   0          14s
nginx-deployment-1564180365-z9gth   1/1       Running   0          14s

下次更新這些pod的時候，只須要更新Deployment中的pod的template便可。

Deployment能夠保證在升級時只有必定數量的Pod是down的。默認的，它會確保至少有比指望的Pod數量少一個的Pod是up狀態（最多一個不可用）。

Deployment同時也能夠確保只建立出超過時望數量的必定數量的Pod。默認的，它會確保最多比指望的Pod數量多一個的Pod是up的（最多1個surge）。

在將來的Kuberentes版本中，將從1-1變成25%-25%） 注筆者使用的是1.13版本,已是這樣的了.

例如，若是你本身看下上面的Deployment，你會發現，開始建立一個新的Pod，而後刪除一些舊的Pod再建立一個新的。當新的Pod建立出來以前不會殺掉舊的Pod。這樣可以確保可用的Pod數量至少有2個，Pod的總數最多4個。

$ kubectl describe deployments
Name:           nginx-deployment
Namespace:      default
CreationTimestamp:  Tue, 15 Mar 2016 12:01:06 -0700
Labels:         app=nginx
Selector:       app=nginx
Replicas:       3 updated | 3 total | 3 available | 0 unavailable
StrategyType:       RollingUpdate
MinReadySeconds:    0
RollingUpdateStrategy:  1 max unavailable, 1 max surge
OldReplicaSets:     <none>
NewReplicaSet:      nginx-deployment-1564180365 (3/3 replicas created)
Events:
  FirstSeen LastSeen    Count   From                     SubobjectPath   Type        Reason              Message
  --------- --------    -----   ----                     -------------   --------    ------              -------
  36s       36s         1       {deployment-controller }                 Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-2035384211 to 3
  23s       23s         1       {deployment-controller }                 Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 1
  23s       23s         1       {deployment-controller }                 Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 2
  23s       23s         1       {deployment-controller }                 Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 2
  21s       21s         1       {deployment-controller }                 Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 0
  21s       21s         1       {deployment-controller }                 Normal      ScalingReplicaSet   Scaled 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
Waiting for rollout to finish: 2 out of 3 new 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-1564180365   2         2         0       25s
nginx-deployment-2035384211   0         0         0       36s
nginx-deployment-3066724191   2         2         2       6s

看下建立Pod，你會看到有兩個新的Replica Set建立的Pod處於ImagePullBackOff狀態，循環拉取鏡像。

$ kubectl get pods
NAME                                READY     STATUS             RESTARTS   AGE
nginx-deployment-1564180365-70iae   1/1       Running            0          25s
nginx-deployment-1564180365-jbqqo   1/1       Running            0          25s
nginx-deployment-3066724191-08mng   0/1       ImagePullBackOff   0          6s
nginx-deployment-3066724191-eocby   0/1       ImagePullBackOff   0          6s

注意，Deployment controller會自動中止壞的rollout，並中止擴容新的Replica Set

$ kubectl describe deployment
Name:           nginx-deployment
Namespace:      default
CreationTimestamp:  Tue, 15 Mar 2016 14:48:04 -0700
Labels:         app=nginx
Selector:       app=nginx
Replicas:       2 updated | 3 total | 2 available | 2 unavailable
StrategyType:       RollingUpdate
MinReadySeconds:    0
RollingUpdateStrategy:  1 max unavailable, 1 max surge
OldReplicaSets:     nginx-deployment-1564180365 (2/2 replicas created)
NewReplicaSet:      nginx-deployment-3066724191 (2/2 replicas created)
Events:
  FirstSeen LastSeen    Count   From                    SubobjectPath   Type        Reason              Message
  --------- --------    -----   ----                    -------------   --------    ------              -------
  1m        1m          1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-2035384211 to 3
  22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 1
  22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 2
  22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 2
  21s       21s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 0
  21s       21s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 3
  13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-3066724191 to 1
  13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-1564180365 to 2
  13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled 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.1
3           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 2
  Labels:       app=nginx
          pod-template-hash=1159050644
  Annotations:  kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
  Containers:
   nginx:
    Image:      nginx:1.9.1
    Port:       80/TCP
     QoS Tier:
        cpu:      BestEffort
        memory:   BestEffort
    Environment Variables:      <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   3         3         3            3           30m

$ kubectl describe deployment
Name:           nginx-deployment
Namespace:      default
CreationTimestamp:  Tue, 15 Mar 2016 14:48:04 -0700
Labels:         app=nginx
Selector:       app=nginx
Replicas:       3 updated | 3 total | 3 available | 0 unavailable
StrategyType:       RollingUpdate
MinReadySeconds:    0
RollingUpdateStrategy:  1 max unavailable, 1 max surge
OldReplicaSets:     <none>
NewReplicaSet:      nginx-deployment-1564180365 (3/3 replicas created)
Events:
  FirstSeen LastSeen    Count   From                    SubobjectPath   Type        Reason              Message
  --------- --------    -----   ----                    -------------   --------    ------              -------
  30m       30m         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-2035384211 to 3
  29m       29m         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 1
  29m       29m         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 2
  29m       29m         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 2
  29m       29m         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 0
  29m       29m         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-3066724191 to 2
  29m       29m         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-3066724191 to 1
  29m       29m         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-1564180365 to 2
  2m        2m          1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-3066724191 to 0
  2m        2m          1       {deployment-controller }                Normal      DeploymentRollback  Rolled back deployment "nginx-deployment" to revision 2
  29m       2m          2       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 3

清理Policy

你可使用如下命令擴容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。這被稱爲比例擴容。

例如，正在運行中的Deployment含有10個replica,maxSurge=3，maxUnavailable=2。

$ kubectl get deploy
NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment     10        10        10           10          50s

你更新了一個鏡像，而在集羣內部沒法解析

$ 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-1989198191   5         5         0         9s
nginx-deployment-618515232    8         8         8         1m

而後發起了一個新的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     15        18        7            8           7m
$ kubectl get rs
NAME                          DESIRED   CURRENT   READY     AGE
nginx-deployment-1989198191   7         7         0         7m
nginx-deployment-618515232    11        11        11        7m

暫停和恢復Deployment

你能夠在觸發一次或屢次更新前暫停一個Deployment，而後再恢復它。這樣你就能屢次暫停和恢復Deployment，在此期間進行一些修復工做，而不會出發沒必要要的rollout。

例如使用剛剛建立Deployment：

$ kubectl get deploy
NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx     3         3         3            3           1m
[mkargaki@dhcp129-211 kubernetes]$ kubectl get rs
NAME               DESIRED   CURRENT   READY     AGE
nginx-2142116321   3         3         3         1m

使用如下命令暫停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-2142116321   3         3         3         2m

你能夠進行任意屢次更新，例如更新使用的資源：

$ 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-2142116321   2         2         2         2m
nginx-3926361531   2         2         0         6s
nginx-3926361531   2         2         1         18s
nginx-2142116321   1         2         2         2m
nginx-2142116321   1         2         2         2m
nginx-3926361531   3         2         1         18s
nginx-3926361531   3         2         1         18s
nginx-2142116321   1         1         1         2m
nginx-3926361531   3         3         1         18s
nginx-3926361531   3         3         2         19s
nginx-2142116321   0         1         1         2m
nginx-2142116321   0         1         1         2m
nginx-2142116321   0         0         0         2m
nginx-3926361531   3         3         3         20s
^C
$ KUBECTL get rs
NAME               DESIRED   CURRENT   READY     AGE
nginx-2142116321   0         0         0         2m
nginx-3926361531   3         3         3         28s

注意：在恢復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
Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment "nginx" successfully rolled out
$ echo $?
0

Failed 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" patched

當超過截止時間後，Deployment controller會在Deployment的 status.conditions中增長一條DeploymentCondition，它包括以下屬性：

Type=Progressing
Status=False
Reason=ProgressDeadlineExceeded

注意： kubernetes除了報告Reason=ProgressDeadlineExceeded狀態信息外不會對卡住的Deployment作任何操做。更高層次的協調器能夠利用它並採起相應行動，例如，回滾Deployment到以前的版本。

你可能在使用Deployment的時候遇到一些短暫的錯誤，這些多是因爲你設置了過短的timeout，也有多是由於各類其餘錯誤致使的短暫錯誤。例如，假設你使用了無效的引用。當你Describe Deployment的時候可能會注意到以下信息：

$ kubectl describe deployment nginx-deployment
<...>
Conditions:
  Type            Status  Reason
  ----            ------  ------
  Available       True    MinimumReplicasAvailable
  Progressing     True    ReplicaSetUpdated
  ReplicaFailure  True    FailedCreate
<...>

執行 kubectl get deployment nginx-deployment -o yaml，Deployement 的狀態可能看起來像這個樣子：

status:
  availableReplicas: 2
  conditions:
  - lastTransitionTime: 2016-10-04T12:25:39Z
    lastUpdateTime: 2016-10-04T12:25:39Z
    message: Replica set "nginx-deployment-4262182780" is progressing.
    reason: ReplicaSetUpdated
    status: "True"
    type: Progressing
  - lastTransitionTime: 2016-10-04T12:25:42Z
    lastUpdateTime: 2016-10-04T12:25:42Z
    message: Deployment has minimum availability.
    reason: MinimumReplicasAvailable
    status: "True"
    type: Available
  - lastTransitionTime: 2016-10-04T12:25:39Z
    lastUpdateTime: 2016-10-04T12:25:39Z
    message: 'Error creating: pods "nginx-deployment-4262182780-" is forbidden: exceeded quota:
      object-counts, requested: pods=1, used: pods=3, limited: pods=2'
    reason: FailedCreate
    status: "True"
    type: ReplicaFailure
  observedGeneration: 3
  replicas: 2
  unavailableReplicas: 2

最終，一旦超過Deployment進程的deadline，kuberentes會更新狀態和致使Progressing狀態的緣由：

Conditions:
  Type            Status  Reason
  ----            ------  ------
  Available       True    MinimumReplicasAvailable
  Progressing     False   ProgressDeadlineExceeded
  ReplicaFailure  True    FailedCreate

你能夠經過縮容Deployment的方式解決配額不足的問題，或者增長你的namespace的配額。若是你知足了配額條件後，Deployment controller就會完成你的Deployment rollout，你將看到Deployment的狀態更新爲成功狀態（Status=True而且Reason=NewReplicaSetAvailable）。

Conditions:
  Type          Status  Reason
  ----          ------  ------
  Available     True    MinimumReplicasAvailable
  Progressing   True    NewReplicaSetAvailable

Type=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
Waiting for rollout to finish: 2 out of 3 new 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就沒法再回退了。

編寫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重複了）和適當的重啓策略。

.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。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。