Kubernetes - Deployments (官方文件原子化翻譯筆記)

2月 7 2020 Ops 1 小时讀完 (大概 9593 字)

概述

Deployment 提供宣告式的方法來更新 Pods 以及 ReplicaSets
透過 Deployment 描述希望的狀態, 然後 Deployment Controller 會將目前的狀態改變成希望的狀態, 你可以定義 Deployments 來建立一個新的 ReplicaSets, 或是移除已存在的 Deployments, 然後重新建一個。

建立一個 Deployment

以下是 Deployment 的範例, 它建立了一個 ReplicaSet 來啟動三個 nginx Pods:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

這邊針對上面的範例做解說:

一個叫做 nginx-deployment 的 Deployment 被建立了, 可從 .metadata.name 這裡看到
這個 Deployment 建立了三個 replicated Pods, 可從 replicas 欄位得知
selector field 用於定義 Deployment 管理的 Pods 對象, 本範例中的對象為 template 中定義的 app: nginx
template 欄位中又含有以下子欄位：
- 經由 labels 欄位, 我們給 Pods 貼上標籤 app: nginx
- 從 .template.spec 欄位, 可以看到 Pods 運行一個容器, nignx, 使用 nginx Docker Hub 鏡像, 版本 1.7.9
- 建立一個容器, 並透過 name 欄位來命名為 nginx

現在讓我們來建立一個 Deployment 吧：

使用以下指令建立一個 Deployment, 你可以給指定最後加上 --record, 它會將執行的指令寫入資源的 annotation 欄位中 kubernetes.io/change-cause, 這對之後的追蹤十分有用, 比如說, 可用來檢視每個 Deployment 版本執行的指令
kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
執行 kubectl get deployments 來確認 Deployment 是不是已經建立了。如果還在建立中, 輸出應如下：
- 輸出
  NAME READY UP-TO-DATE AVAILABLE AGE
  nginx-deployment 0/3 0 0 1s
- 如果是在叢集中檢視 Deployments, 會顯示以下欄位
  - NAME 列出在這個叢集中 Deployments 的名稱
  - DESIRED 列出宣告的 replicas 的數量, 建立 Deployment 時定義的
  - CURRENT 顯示目前共有幾個 replicas 在運行
  - UP-TO-DATE 顯示已被更新來達成期望狀態的 replicas 數量
  - AVAILABLE 顯示可用的 replicas 數量
  - AGE 顯示 replica 已運行的時間
- replicas 數量的宣告值是根據 .spec.replicas 欄位

執行以下指令來檢視 Deployment rollout status

指令

kubectl rollout status deployment.v1.apps/nginx-deployment

預計輸出

Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment.apps/nginx-deployment successfully rolled out

幾秒後, 在執行以下指令一次
- 指令
  kubectl get deployments
- 預計輸出
  NAME READY UP-TO-DATE AVAILABLE AGE
  nginx-deployment 3/3 3 3 18s
  可以看到 Deployment 已經建立了三個 replicas, 且所有的 replicas 都是最新狀態以及可用
檢視被 Deployment 建立的 ReplicaSet (rs)
- 執行以下指令
  kubectl get rs
- 預計輸出
  NAME DESIRED CURRENT READY AGE
  nginx-deployment-75675f5897 3 3 3 18s
  ReplicaSet 的格式為 [DEPLOYMENT-NAME]-[RANDOM-STRING], random string 為隨機產生, 且使用 pod-template-hash 為來源之一

檢視每個 Pod 自動產生的 labels

執行指令
kubectl get pods --show-labels

預計輸出

NAME                                READY     STATUS    RESTARTS   AGE       LABELS
nginx-deployment-75675f5897-7ci7o   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-kzszj   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-qqcnn   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453

已建立完成的 ReplicaSet 會確保有三個 nginx Pods

這邊要注意的是, 務必要正確的在 Deployment 中指定適當的 selector 以及 Pod template labels (在本範例中, app:nginx), 不要讓 labels 或 selectors 跟其他的 controllers 有重疊 (包含其他的 Deployments 以及 StatefulSets), Kubernetes 不會阻止這件事, 且如果上述情形發生的話, 可能會產生衝突以及一些預期外的行為

Pod-template-hash label

注意: 不可改變這個 label
pod-template-hash label 由 Deployment controller 加到每一個它所建立的 ReplicaSet 當中。

Updating a Deployment

注意: Deployment 的 rollout 唯有當 Deployment 的 Pod template (也就是 .spec.template) 變更了, 舉例來說, 像是 template 當中的 labels 或是容器鏡像更新了。
其他的更新, 例如 Deployment 的擴縮, 不會觸發 rollout

遵循以下步驟來更新你的 Deployment:

將 nginx Pods 從鏡像版本 nginx:1.7.9 更新成 nginx:1.9.1

執行以下指令

kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1

或是簡化版本的

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

輸出應如下：

deployment.apps/nginx-deployment image updated

又或者, 你也可以使用 edit 指令, 到編輯器中將 .spac.template.spec.container[0].image 的版本從 nginx.1.7.9 變更為 nginx:1.9.1
kubectl edit deployment.v1.apps/nginx-deployment
輸出應如下：
deployment.apps/nginx-deployment edited

檢視 rollout status

執行指令

kubectl rollout status deployment.v1.apps/nginx-deployment

或是簡化版

kubectll rollout status deployment nginx-deployment

輸出應如下:

Waiting for rollout to finish: 2 out of 3 new replicas have been updated...

或

deployment.apps/nginx-deployment successfully rolled out

從更新後的 Deployment 取得更多細節：

檢視 rollout 成功的 Deployment

執行
kubectl get deployments

輸出

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           36s

檢視 ReplicaSets
- 執行
  kubectl get rs
- 輸出
  NAME DESIRED CURRENT READY AGE
  nginx-deployment-1564180365 3 3 3 6s
  nginx-deployment-2035384211 0 0 0 36s
  下一次你想要更新這些 Pod 的話, 你只需要再次更新 Deployment 的 Pod template 就行了
  Deployment 確保更新過程中只會有一定數量的 Pods 是不可用的。
  預設, 最少要有 75% 的 Pod 要處於運行中, 最多 25% 的 Pod 可容許不可用
  Deployment 同時確保在升級過程中同時只有一定數量的 Pod 會被建立, 預設最多 Pod 的 125% 期望數量可被運行 (最多 25% 增加)
  舉例來說, 如果你仔細的檢視 rollout 的過程, 你會發現, 首先 Deployment 會先建立一個新的 Pod, 然後殺掉某個舊的 Pod, 然後建立一個新的。它不會等到新的 Pod 都已經足夠了才殺掉舊的 Pod, 也不會等到舊的 Pod 已經被砍到一個足夠的數量才去建立新的 Pod, 它確保至少有兩個 Pods 可用, 而最多四個 Pods 可用

檢視 Deployment 的細節資訊:

執行
kubectl describe deployments

輸出

Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Thu, 30 Nov 2017 10:56:25 +0000
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision=2
Selector:               app=nginx
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
Labels:  app=nginx
 Containers:
  nginx:
    Image:        nginx:1.9.1
    Port:         80/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   nginx-deployment-1564180365 (3/3 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  2m    deployment-controller  Scaled up replica set nginx-deployment-2035384211 to 3
  Normal  ScalingReplicaSet  24s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 1
  Normal  ScalingReplicaSet  22s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 2
  Normal  ScalingReplicaSet  22s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 2
  Normal  ScalingReplicaSet  19s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 1
  Normal  ScalingReplicaSet  19s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 3
  Normal  ScalingReplicaSet  14s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 0

這邊可以看到, 一開始當你建立了 Deployment, 它建立了一個 ReplicaSet (nginx-deployment-2035384211), 然後直接擴增到 3 個 replicas, 而當你更新 Deployment, 它建立了一個新的 ReplicaSet (nginx-deployment-1564180365) 並且擴增到 1 個然後將舊的 ReplicaSet 縮為 2, 所以最少有 2 個 Pods 是可用的, 最多可以有 4 個 Pods 是啟動的。之後, 遵循著相同的滾動升級策略, 它持續的擴縮, 最後, 你會有三個新的 replicas, 然後 0 個舊的 Replicas

Rollover (aka multiple updates in-flight)

每次 Deployment controller 觀察到有新的 Deployment 時, 一個新的 ReplicaSet 會被建立來提供期望數量的 Pods。如果說 Deployment 被更新了, 那 label 有符合 .spec.selector 但 template 不符合 .spec.replicas 的已存在 ReplicaSet 會開始縮減數量。最後, 新的 ReplicaSet 會擴增到符合 .spec.replicas 的數量, 然後所有舊的 ReplicaSets 都縮減為 0
如果你在滾動升級途中更新一個 Deployment, Deployment 會建立一個新的 ReplicaSet 並開始擴容, 同時縮減原本擴容到一半的 ReplicaSet, 它會被加到舊的 ReplicaSets 清單, 並且開始縮減
舉例來說, 假如你建立了一個 Deployment 來建立 5 個 nginx:1.7.9 replicas, 但是當只有 3 個 replicas 的 nginx:1.7.9 被建立完成時, 你將這個 Deployment 更新成 5 個 nginx:1.9.1 的 replicas。在這個範例中, Deployment 會立即的開始砍掉這三個 nginx:1.7.9 的 Pods, 並開始建立 nginx:1.9.1 的 Pods。他不會等到 5 個 nginx:1.7.9 的 replicas 都建好之後, 再改變狀態

Label selector 更新

通常不建議修改 label selector, 且 selector 建議在一開始就規劃好。不管怎樣, 如果你需要更新 label selector, 那請一定要很小心, 並且確保你已經掌握任何它可能會造成的影響。
注意: 在 API 版本 apps/v1, Deployment 的 label selector 在建立之後就無法變更了。

Selector 的增加需要也更新 Deployment spec 中的 Pod template labels, 否則會回傳 validation error。這個變更是不可覆蓋的, 這表示說, 新的 selector 不會去選擇舊的 selector 建立的 ReplicasSet 以及 Pods, 所以結果會是, 建立了新的 ReplicaSet, 然後所有舊的 ReplicaSets 都成了孤兒。
Selector 的更新改變了 selector key 的現存 value - 造成的結果跟增加 selector 相同
Selector 的刪除會從 Deployment selector 中移除已經存在的 key - 這不需要 Pod template labels 有任何改變。已經存在的 ReplicaSets 也不會變成孤兒, 也不會有新的 ReplicaSets 會被建立。但被移除的 label 還是存在於現存的 Pods 以及 ReplicaSets 之中。

回滾 Deployment

有時, 你可能會想要回滾 Deployment; 例如說, 當一個 Deployment 並不穩定, 一直的 crash looping。預設, 所有的 Deployment rollout 歷史都會被記錄下來, 所以任何時候你都可以回滾 (你可以修改版本歷史限制來改變這一個特性)
Note: 當 Deployment 的 rollout 被觸發時, 會建立一個 Deployment revision。這表示唯有當 Deployment 的 Pod template (.spec.template) 改變了, 例如你更新了 template 的 labels 或 container images, 這樣 revision 才會被建立。其他更新, 像是擴容 Deployment 並不會建立 Deployment revision, 所以你可以無礙的手動或自動的擴縮 Deployment。這表示說, 當你回滾到一個早些的版本, 只有 Deployment 的 Pod template 部分會被回滾。

假如你在更新 Deployment 時打錯字, 把 nginx:1.9.1 打成 nginx:1.91:

執行指令

kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true

輸出

deployment.apps/nginx-deployment image updated

這時 rollout 卡住了, 確認一下：

執行

kubectl rollout status deployment.v1.apps/nginx-deployment

輸出

Waiting for rollout to finish: 1 out of 3 new replicas have been updated...

按下 Ctrl-C 來停止 rollout status 輸出, 可以參考這裏, 有更多 rollout 卡住的資訊

可以看到舊的 replicas nginx-deployment-1564180365 跟 nginx-deployment-2035384211 的數量是 2, 然後新的 replicas (nginx-deployment-3066724191) 是 1

執行
kubectl get rs

輸出

NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-1564180365   3         3         3       25s
nginx-deployment-2035384211   0         0         0       36s
nginx-deployment-3066724191   1         1         0       6s

從建立的 Pods 可以看到這個由新的 ReplicaSet 建立的 Pod 卡在 image pull loop

執行
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-1564180365-hysrc   1/1       Running            0          25s
nginx-deployment-3066724191-08mng   0/1       ImagePullBackOff   0          6s

注意: Deployment controller 自動停止了錯誤的 rollout, 並且停止擴容新的 ReplicaSet。這取決於你定義的 rollingUpdate 的參數 (更準確的說, maxUnavailable), Kubernetes 的預設值為 25%

取得 Deployment 描述

執行
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 desired | 1 updated | 4 total | 3 available | 1 unavailable
StrategyType:       RollingUpdate
MinReadySeconds:    0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx:1.91
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    ReplicaSetUpdated
OldReplicaSets:     nginx-deployment-1564180365 (3/3 replicas created)
NewReplicaSet:      nginx-deployment-3066724191 (1/1 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 1
  21s       21s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 3
  13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 0
  13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-3066724191 to 1

要解決這個問題, 你需要回滾到前一個穩定的 Deployment reversion

確認 Deployment 的 Rollout 歷史

照著以下步驟來確認 rollout 歷史:

確認 Deployment reversion

執行

kubectl rollout history deployment.v1.apps/nginx-deployment

輸出

deployments "nginx-deployment"
REVISION    CHANGE-CAUSE
1           kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true
2           kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
3           kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true

CHANGE-CAUSE 是當 revisions 建立時, 從 Deployment 的 annotation kubernetes.io/change-cause 複製到你的 revisions, 你也可以藉由以下方法指定 CHANGE-CAUSE 的 message:

輸入指令

kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1"

當我們在做資源變更時, 最後加入 --record 的 flag
手動編輯資源的 manifest 檔案, 就是 yaml 檔

若要檢視每個 revision 的細節資訊：

執行

kubectl rollout history deployment.v1.apps/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.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
  Containers:
   nginx:
    Image:      nginx:1.9.1
    Port:       80/TCP
     QoS Tier:
        cpu:      BestEffort
        memory:   BestEffort
    Environment Variables:      <none>
  No volumes.

版本回滾

照著以下步驟將 Deployment 從目前的版本回滾到之前的版本, 之前的版本為版本2

取消當前版本並回滾到之前版本
- 執行
  kubectl rollout undo deployment.v1.apps/nginx-deployment
- 輸出
  deployment.apps/nginx-deployment
- 或使用 --to-revision 指定要回滾至的版本
  kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2
- 輸出
  deployment.apps/nginx-deployment
  更多關於 rollout 的指令可以參考kubectl rollout
  Deployment 目前已經回滾到之前的穩定版本, 所以你可以看到, Deployment 產生了一個 DeploymentRollback 的事件, 代表回滾到版本 2

要確定 rollback 有成功並且 Deployment 如預期般的正常運行:

執行
kubectl get deployment nginx-deployment

輸出

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           30m

取得 Deployment 的細節描述

執行

kubectl describe deployment nginx-deployment

輸出

Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Sun, 02 Sep 2018 18:17:55 -0500
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision=4
                        kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
Selector:               app=nginx
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx:1.9.1
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   nginx-deployment-c4747d96c (3/3 replicas created)
Events:
  Type    Reason              Age   From                   Message
  ----    ------              ----  ----                   -------
  Normal  ScalingReplicaSet   12m   deployment-controller  Scaled up replica set nginx-deployment-75675f5897 to 3
  Normal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-c4747d96c to 1
  Normal  ScalingReplicaSet   11m   deployment-controller  Scaled down replica set nginx-deployment-75675f5897 to 2
  Normal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-c4747d96c to 2
  Normal  ScalingReplicaSet   11m   deployment-controller  Scaled down replica set nginx-deployment-75675f5897 to 1
  Normal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-c4747d96c to 3
  Normal  ScalingReplicaSet   11m   deployment-controller  Scaled down replica set nginx-deployment-75675f5897 to 0
  Normal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-595696685f to 1
  Normal  DeploymentRollback  15s   deployment-controller  Rolled back deployment "nginx-deployment" to revision 2
  Normal  ScalingReplicaSet   15s   deployment-controller  Scaled down replica set nginx-deployment-595696685f to 0

擴縮 Deployment

使用以下指令擴縮 Deployment:

執行

kubectl scale deployment.v1.apps/nginx-deployment --replicas=10

輸出
deployment.apps/nginx-deployment scaled

假設水平 Pod 自動擴縮在你的叢集中是有打開的, 可以設定擴縮你的 Deployment 依據給予的 Pods 最大及最小數量, 以及 CPU 的使用率

執行

kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80

輸出
deployment.apps/nginx-deployment scaled

比例擴縮

滾動升級 Deployment 支援同時運行不同版本的應用。當一個 Deployment 正處於 rollout 狀態 (在途中或暫停狀態), 此時你或者是自動調節器又發出一個擴縮請求, Deployment controller 會將額外增加的 replicas 成比例的分配到目前運作中的 ReplicaSets (有啟動 Pods 的 ReplicaSets) 以降低風險。這樣的行為稱為比例擴縮 (proportional scaling), 例如說, 你正運行著有 10 個 replicas 的 Deployment, maxSurge=3, maxUnavailable=2

確保 Deployment 下的 10 個 replicas 都有在運行

執行
kubectl get deploy

輸出

NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment     10        10        10           10          50s

將鏡像版本更新成無法被解析的版本

執行

kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag

輸出

deployment.apps/nginx-deployment image updated

這個鏡像的更新會啟動一個新的 rollout 以及 ReplicaSet nginx-deployment-1989198191, 但它會因為上面提到的 maxUnavailable 而被阻塞住

執行
kubectl get rs

輸出

NAME                          DESIRED   CURRENT   READY     AGE
nginx-deployment-1989198191   5         5         0         9s
nginx-deployment-618515232    8         8         8         1m

這時再將數量提升到 15 個
- 執行
  kubectl scale deployment nginx-deployment --replicas=15
- 此時, Deployment controller 需要決定要把這新的 5 個 replicas 使用哪一個 replicaSet 來啟動。如果你沒有使用比例擴縮的話, 所有 5 個都會使用新的 ReplicaSet。使用比例擴縮, 你將額外的 replicas 散佈到所有的 ReplicaSets, 比較多的 replicas 會被分配給擁有比較多 replica 的 replicaSet, 而比較少的 replicas 會被分配給擁有比較少 replica 的 replicaSet, 而擁有 0 個 replica 的 replicaSet 將不會被分配任何 replica
- 執行以下指令確認目前狀態
  kubectl get deploy
- 輸出
  NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
  nginx-deployment 15 18 7 8 7m
- 執行指令確認 rs 狀態
  kubectl get rs
- 輸出
  NAME DESIRED CURRENT READY AGE
  nginx-deployment-1989198191 7 7 0 7m
  nginx-deployment-618515232 11 11 11 7m
  如果最後 rollout 恢復正常, replica 恢復健康的話, 所有的 replica 都會被移動到新的 ReplicaSet

暫停以及恢復一個 Deployment

你可以在觸發一個或多個更新之前先暫停 Deployment, 然後再恢復。這讓你可以進行多個更新, 並避免掉不必要的 rollout

比如說, 取得剛建立的 Deployment 資訊：

執行
kubectl get deploly

輸出

NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx     3         3         3            3           1m

取得 rollout 狀態
kubectl get rs

輸出

NAME               DESIRED   CURRENT   READY     AGE
nginx-2142116321   3         3         3         1m

使用以下指令停止

執行

kubectl rollout pause deployment.v1.apps/nginx-deployment

輸出
deployment.apps/nginx-deployment paused

更新鏡像

執行

kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1

輸出

deployment.apps/nginx-deployment image updated

可以看到 rollout 完全沒有開始

執行

kubectl rollout history deployment.v1.apps/nginx-deployment

輸出

deployments "nginx"
REVISION  CHANGE-CAUSE
1   <none>

取得 rollout status 確保 Deployment 已經有成功更新

執行
kubectl get rs

輸出

NAME               DESIRED   CURRENT   READY     AGE
nginx-2142116321   3         3         3         2m

你可以盡可能地建立你需要的更新, 例如說, 更新資源:
- 執行
  kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
- 輸出
  deployment.apps/nginx-deployment resource requirements updated
  在暫停前的 Deployment 狀態將會保持運作, 只要 Deployment 是處於暫停的狀態, 那你所建立的更新都不會對目前狀態有任何影響。

最後, 恢復 Deployment 並且觀察新的 ReplicaSet 進行所有新的更新

執行

kubectl rollout resume deployment.v1.apps/nginx-deployment

輸出

deployment.apps/nginx-deployment resumed

觀察 rollout 的狀態直到結束

執行
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

取得最新 rollout 狀態

執行
kubectl get rs

輸出

NAME               DESIRED   CURRENT   READY     AGE
nginx-2142116321   0         0         0         2m
nginx-3926361531   3         3         3         28s

Deployment 狀態

Deployment 的生命週期中有很多種狀態, progressing 當建立一個新的 ReplicaSet, 又或者是 complete 或 fail to progress

進行中的 Deployment

當以下任務在進行中時, Kubernetes 會將 Deployment 標註為 progressing

當 Deployment 建立新的 ReplicaSet
當 Deployment 正在擴容 ReplicaSet
當 Deployment 正在縮減 ReplicaSet
有新的 Pod 可用, 至少 (就緒時間打 MinReadySeconds 定義)

你可以使用 kubectl rollout status 來監控 Deployment 狀態

完成 Deployment

有以下特點時, Kubernetes 會將 Deployment 標註為 complete

所有此 Deployment 的 replicas 都已更新到指定的最新版本, 代表說任何要求的更新都已經完成。
所有與此 Deployment 相關的 replicas 都可用
此 Deployment 下沒有舊的 replicas 在運行中

若要確認 Deployment 狀態是否為 completed, 可使用 kubectl rollout status。如果 rollout 成功完成, kubectl rollout status 回應一個值為 0 的 exit code
執行

kubectl rollout status deployment.v1.apps/nginx-deployment

輸出

Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment.apps/nginx-deployment successfully rolled out
$ echo $?
0

失敗的 Deployment

以下原因可能造成 rollout 卡住：

資源配額不足
Readiness 探測結果失敗
拉取鏡像錯誤
權限不足
資源限制
應用 runtime 配置錯誤

偵測這個情況的一個方法就是在 Deployment 的 spec (.spec.progressDeadlineSeconds), 這是個時間, 表示 Deployment controller 會在 Deployment 卡住多久之後回報這個異常

使用 kubectl 指令來設定 progressDeadlineSeconds 讓 controller 會在卡住 10 分鐘之後回報異常

執行

kubectl patch deployment.v1.apps/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'

輸出

deployment.apps/nginx-deployment patched

一旦超過設定的 deadline, Deployment controller 在 Deployment 的 .status.confitions 增加一個具有下面內容的 DeploymentCondition 屬性

Type=Progressing
Status=False
Reason=ProgressDeadlineExceeded

更多有關 [status conditions] 的資訊可以參考 Kubernetes API conventions

注意: Kubernetes 對異常的 Deployment 除了回報 Reason=ProgressDeadlineExceeded 之外, 不會有其他動作。更高階層的調節器可以利用這個訊息做相對應的動作, 比方說, 將 Deployment 回滾到之前的版本

注意: 如果你暫停 Deployment, Kubernetes 就不會確認你指定的 deadline, 你可以放心的暫停以及恢復 rollout, 不用擔心會因此而觸發 deadline

有時你可能會遇到暫時性的 Deployment 錯誤, 可能是因為你設了過短的 timeout 或是其他被認為是短暫的。例如說, 你沒有足夠的資源。如果你 describe Deployment, 你會看到以下：

執行

kubectl describe deployment nignx-deployment

輸出

<...>
Conditions:
  Type            Status  Reason
  ----            ------  ------
  Available       True    MinimumReplicasAvailable
  Progressing     True    ReplicaSetUpdated
  ReplicaFailure  True    FailedCreate
<...>

如果你執行 kubectl get deployment nginx-deployment -o yaml, Deployment status 如下：

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 progress deadline 超過, Kubernetes 會將 status 以及 reason 更新:

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

你可以藉由擴縮 Deployment 或是增加資源配額到你的命名空間來解決資源配額不足的問題。只要你滿足了資源配額, Deployment controller 會自動完成 Deployment rollout, 你將會看到 Deployment 的 status 會更新為 Status=True 以及 Reason=NewReplicaSetAvailable

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

Type=Available 配上 Status=True 表示你的 Deployment 已具有最小可用性。最小可用性是由 Deployment strategy 的設定來決定。 Type=Progressing 配上 Status=true 表示你的 Deployment 正在 rollout 途中, 或者是 process 已完成, 且心 replicas 的最低需求已滿足 (詳細資料可以查看 condition 的 reason - 在我們的案例中, Reason=NewReplicaSetAvailable, 這代表這個 Deployment 已經完成)
你可以使用 kubectl rollout status 確認 Deployment 是否有 process 失敗, 如果 Deployment 以及超出 procession deadline 的話, 會回傳一個值為非 0 的 exit code

執行

kubectl rollout status deployment.v1.apps/nginx-deployment

輸出

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 做多次的調整的話

Clean up Policy

你可以在 Deployment 中的欄位 .spec.revisionHistoryLimit 指定你想要保留的舊的 ReplicaSets 的數量, 超出這個數量的會在背景被垃圾回收掉, 預設值為 10

注意: 如果你特別將這個欄位設為 0, 所有的 history 都會被清理掉, 因此你將會無法回滾你的 Deployment

Canary Deployment

如果你想要使用 Deployment 發佈 release 到不同的使用者群或伺服器群, 你可以建立多個 Deployment, 每個發佈都有各自的 Deployment, 更多有關金絲雀 (Canary) 部署的描述, 請參考managing resources

撰寫 Deployment Spec

跟所有其他的 Kubernetes 配置檔一樣, Deployment 也需要 apiVersion, kind, 以及 metadata 欄位。一些通用的資訊可以參考應用部署, 設置容器, 以及使用 kubectl 管理資源文件
Deployment 也需要 .spec 區塊

Pod Template

.spec.template 以及 .spec.selector 是 .spec 中唯一要求的欄位
.spec.template 為 Pod template。它跟 Pod 有完全相同的配置, 唯一的不同處是它不需要 apiVersion 以及 kind, 以及它被包在另外一個一個物件內
除了 Pod 中要求的欄位之外, 在 Deployment 中的 Pod template 必須指定合適的 labels 以及 restart policy。不可與其他 controller 重疊 labels, 可參考 selector

.spec.template.spec.restartPolicy 只被允許設為 Always, 這也是默認值

Replicas

.spec.replicas 可填可不填, 用來指定想要啟動的 Pod 的數量, 預設為 1

Selector

.spec.selector 是一個必要的欄位, 它指定了一個 label selector, 定義這個 Deployment 的目標 Pods

.spec.selector 必須符合 .spec.template.metadata.labels, 否則將被 API 拒絕。

在 API 版本 apps/v1, .spec.selector 以及 .metadata.labels 預設並非 .spec.template.metadata.labels, 所以他們必須被明確的設定。再者, .spec.selector 在 app/v1 中, 建立後就不可再更改

如果 Pods 的 template 跟 Deployment 的 .spec.template 不同, 又或者 Pods 的總數量超過了 .spec.replicas 定義的數量, Deployment 可能會將 label 符合該 Deployment selector 的 Pods 結束掉。如果 Pods 的數量小於 Deployment 定義期望的數量, Deployment controller 會依照 .spec.template 開啟新的 Pods

注意: 不可重複建立 label 符合這個 selector 的 Pod, 或透過 Deployment 建立, 又或者透過其他的 controller, 像是 ReplicaSet 或 ReplicationController。如果你這麼做了, 第一個 Deployment 依然會認為是她建立了這些其他的 Pods, 且 Kubernetes 也不會阻止你這麼做。

如果你有多個 controller, 彼此的 selector 都有重疊, 那這些 controller 將會互相打架而無法正確運作。

Strategy

.spec.strategy 指定了更新 Pod 時採用的策略
.spec.strategy.type 可以是 “Recreate” 或 “RollingUpdate”, 預設為 “RollingUpdate”

Recreate Deployment

當使用 .spec.strategy.type==Recreate 時, Kubernetes 會先將所有的 Pod 都殺掉, 在建立新的

Rolling Update Deployment

上面有介紹過 RollingUpdate 的方式, 可參考 Rolling Date。當 .spec.strategy.type==RollingUpdate 時, 你可以指定 maxUnavailable 以及 maxSurge 來控制滾動升級的步驟

Max Unavailable

.spec.strategy.rollingUpdate.maxUnavailable 是一個選擇性的選項, 它指定了在更新的過程中, Pod 不可用的容許最大數量。值可以是確切的數字 (像是 5), 或是比例 (像是 10%)。如果使用比例的話, 會計算出絕對數字, 然後無條件去位。 spec.strategy.rollingUpdate.maxSurge 以及 .spec.strategy.rollingUpdate.maxUnavailable 不可同時設為 0, 後者預設為 25%
比如說, 當我把值設為 30%, 那在滾動升級過程中舊的 ReplicaSet 最多可以縮容到期望可用 Pod 數量的 70%。一旦新的 Pod 擴容了並且可用了, 舊的 ReplicaSet 才可以進一度的縮容, 確保在更新的過程中, Pods 的可用數量保持在 70% 的期望數量以上

Max Surge

.spec.strategy.rollingUpdate.maxSurge 是一個選擇性的選項, 它指定了在更新的過程中, 可用 Pods 的容許最大數量。值可以是確切的數字 (像是 5), 或是比例 (像是 10%)。如果使用比例的話, 會計算出絕對數字, 然後在無條件進位。 spec.strategy.rollingUpdate.maxSurge 以及 .spec.strategy.rollingUpdate.maxUnavailable 不可同時設為 0, 後者預設為 25%
比如說, 當我把值設為 30%, 那在滾動升級過程中舊的 ReplicaSet 最多可以擴容到期望可用 Pod 數量的 130%。一旦舊的 Pod 被殺掉了, 新的 ReplicaSet 才可以進一度的擴容, 確保在更新的過程中, Pods 的可用數量保持在最多 130% 的期望數量

Progress Deadline Seconds

.spec.progressDeadlineSeconds 是一個選擇性的欄位, 它指定了當 process 卡住的時候, Kubernetes 需要等待多久時間才回報failed progressing, 回報 Type=Progressing, Status=False, 以及 Reason=ProgressDeadlineExceeded 到資源的 status.condition 中。 Deployment controller 會持續嘗試這個 Deployment。在未來, 如果有實施自動回滾機制的話, Deployment controller 會自動地回滾 Deployment 當偵測到這樣的情況。
如果有指定的話, 那這個欄位必須要大於 .spec.minReadySeconds 欄位

Min Ready Seconds

.spec.minReadySeconds 是一個選擇性的配置欄位, 它指定了一個秒數, 一個新建立的 Pod, 被認定為可用, 並且沒有任何容器 crashing 的最低秒數。默認為 0 (Pod 被建立就被認定是可用的), 更多關於 Pod 何時會被認為是 ready 的資訊, 可參考 Container Probes

Rollback To

.spec.rollbackTo 這個欄位已經在 API 版本 extensions/v1beta1 以及 apps/v1beta1 就被廢棄了, 並且在 apps/v1beta2 已經不再被支援。取而代之的, kubectl rollout undo, 可參考 Rolling Back to a Previous Revision, 將被使用。

Revision History Limit

Deployment 的 revision history 被儲存在它所控制的 ReplicaSet 中。
.spec.revisionHistoryLimit 是一個可選配置項, 它指定了舊的 ReplicaSets 的保留數量, 所以之後可以回滾。這些舊的 ReplicaSets 會消耗 etcd 中的資源, 以及會塞滿 kubectl get rs 的輸出。 Deployment 的不同版本的配置都被儲存在 ReplicaSets, 因此, 一旦舊的 ReplicaSet 被刪除了, 你將無法再回滾到該版本的 Deployment。預設會保留 10 個舊的 ReplicaSet, 然而最佳的數量取決於新版 Deployment 的頻率以及穩定性
更準確的說, 若將這個欄位設為 0, 代表所有舊的 ReplicaSets 都會被清理掉, 所以新版的 Deployment 將無法回退。

Paused

.spec.paused 是一個可選配置選項, 其值為 boolean, 它表示了該 Deployment 是否是 paused 的狀態。狀態是否為 paused 的唯一不同之處在於, 如果我對 PodTemplateSpec 的內容作修改, 那當狀態是 paused 時, 將不會觸發新的 rollout。 Deployment 預設狀態是 not paused

Alternative to Deployments

kubectl rolling-update

kubectl rolling-update 可以使用類似的模式更新 Pods 以及 ReplicationControllers, 但還是建議使用 Deployment 的方式, 因為 Deployment 是宣告式的, 並且是 server side 的, 以及有額外的功能, 例如可以回滾到之前的版本。

Q&A

Kubernetes 中, kubectl rolling-update 與 Deployment 的方式, 在官方文件中比較推薦使用哪一種？
Deployment

Kubernetes 中, .spec.paused true 或 false 的唯一不同之處在於？
- paused 時, 不會觸發 rollout
- not paused 時, 會觸發 rollout

Kubernetes 中, Old replicaSets 的數量會消耗哪個元件的資源？
etcd

Kubernetes 中, 不同版本的 Deployment 實際上都儲存在哪裡？
ReplicaSets

Kubernetes 中, spec.progressDeadlineSeconds 務必要大於哪一個欄位？
.spec.minReadySeconds

Kubernetes 中, 當 spec.strategy.rollingUpdate.maxUnavailable 的值為 70% 時, 假如算出來的數字非整數, Kubernetes 會怎麼做？
無條件去掉小數點成整數

Kubernetes 中, spec.strategy.rollingUpdate.maxUnavailable 與 spec.strategy.rollingUpdate.maxSurge 的值可以同時設為 0 嗎？
不可

Kubernetes 中, spec.strategy.rollingUpdate.maxUnavailable 的值可以是哪兩種方式？
- 絕對數字
- 比例

Kubernetes, 當我使用 .spec.strategy.type==Recreate 時, 會怎樣的更新 Pod?
先把舊的全都殺掉, 再建立新的

Kubernetes 時, 更新 Pod 預設的 strategy 是？
RollingUpdate

Kubernetes Deployment 中, .spec.replicas 預設值為多少?
1

Kubernetes Deployment 中, .spec.template.spec.restartPolicy 預設值為?
Always

Kubernetes Deployment 中, .spec.template.spec.restartPolicy 只可設為什麼?
Always

Kubernetes deployment 中, .spec 中唯一要求哪兩個欄位？
- .spec.template
- .spec.selector

Kubernetes 中, 如果我將 .spec.revisionHistoryLimit 的值設為 0, 會發生什麼事？
所有 revision history 都會被回收掉, Deployment 會無法回滾

Kubernetes 中, .spec.revisionHistoryLimit 預設的值為多少？
10 個

Kubernetes 中, 可使用哪一個欄位來設定要保留的舊的 revision 數量？
.spec.revisionHistoryLimit

Kubernetes 中, 當我在 progress 途中使用 pause, 會計算 deadline 的時間嗎？
不會

Kubernetes 中, 當 ProgressDeadlineExceeded 被觸發, Deployment 除了回報狀況以外, 還會做什麼事情嗎？
不會

Kubernetes 中, 如果 Deployment progress 卡住超過指定的 deadline, Deployment controller 會在 DeploymentCondition 屬性中增加什麼內容？
- Type=Progressing
- Status=False
- Reason=ProgressDeadlineExceeded

Kubernetes 中, 如果 Deployment progress 卡住超過指定的 deadline, Deployment controller 會在什麼地方增加一個 DeploymentCondition 屬性？
.status.conditions

Kubernetes 中, 哪一個屬性可以決定 process 卡住之後多久會回報異常？
.spec.progressDeadlineSeconds

Kubernetes 中, 如何使用 CLI 來設定資源限制

kubectl set resources deployment/deploymentName -c=nginx --limits=cpu=200m,memory=512Mi

Kubernetes 中, 如何 resume 一個 deployment?

kubectl rollout resume deployment/deploymentName

Kubernetes 中, 如何 pause 一個 deployment?

kubectl rollout pause deployment/deploymentName

Kubernetes 中, 如果我 pause 一個 Deployment, 那它還會保持運作嗎？
會哦, 只是會鎖住目前的版本而已

Kubernetes 中, 當我暫停一個 Deployment 時, 我可以回滾它嗎？
不行哦

Kubernetes 中, pause 跟 resume 可以帶來什麼好處？
有時要進行多個修正時, 可以避免不必要的 rollout

Kubernetes 當中, 假如現在正 rollout 到一半, 這時有新的擴容需求被呼叫, 那如果我有使用 proportional scaling 的話, 新的 replica 會被加到新的 replicaSet 還是舊的 replicaSet?
會照比例分配, 擁有多個 replica 的 replicaSet 會被分配多組, 反之亦然

Kubernetes 當中, 假如現在正 rollout 到一半, 這時有新的擴容需求被呼叫, 那如果我沒有使用 proportional scaling 的話, 新的 replica 會被加到新的 replicaSet 還是舊的 replicaSet?
新的

以下的 Kubernetes CLI 的意思是？
- CLI
  kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80
- Answer:
  - 最少 10 個 pod
  - 最多 15 個 pod
  - 當 CPU 使用超過 80% 時, 多開一個 Pod

Kubernetes 中, 假如我要指定自動擴縮 Deployment 的範圍以及 CPU 使用率, 我可以怎麼做？
kubectl autoscale deployment/deploymentName --min=10 --max=15 --cpu-percent=80

Kubernetes 中, 假如我現在要擴縮指定 Deployment 到 10 個 replica, 我可以怎麼做？
kubectl scale deployment/deploymentName --replicas=replicasNumber

Kubernetes 中, 如果我要放棄目前的版本回滾到一個指定的版本, 我可以怎麼做？
kubectl rollout undo deployment/deploymentName --to-revision=revisionName

Kubernetes 中, 如果我要放棄目前的版本回滾到前一個版本, 我可以怎麼做？
kubectl rollout undo deployment/deploymentName

Kubernetes 中, 如果我要檢視指定 revision 的細節資訊, 我可以怎麼做？
kubectl rollout history deployment/deploymentName --revision=revisionName

Kubernetes 中, 有哪三種方法可以指定 CHANGE-CAUSE message?
- 藉由 kubectl annotate 指令
- 變更資源時, 加入 --record flag
- 手動變更

Kubernetes 中, 當我回滾到之前的版本, 會否對 replica 的期望數量有影響？
不會, rolling back 只會影響到 spec.template 中的內容

Kubernetes 中, Deployment revision 唯有當什麼情況之下才會被建立？
當 spec.template 中的內容有變更時

Kubernetes 中, 自 apps/v1 的版本後, Deployment 的 label selector 在建立後可以再變更嗎？
不行

Kubernetes 中, 在滾動升級的過程中, 如果新的 Deployment 還沒完成擴容我就更新了這個 Deployment, 那 Deployment controller 會等到原本的擴容任務完成之後再開始新的任務嗎？
不會, 會立即縮減舊的, 擴容新的

Kubernetes 中, 當 Deployment 被更新了, 新的 ReplicaSet 會被建立來提供期望的 Pods 數量, 那 Kubernetes 是如何判斷舊的 ReplicaSet?
label 符合 .spec.selector 但 .spec.template 不符合

Kubernetes 中, 在滾動升級的過程中, Deployment 建立新的 Pod 以及刪除舊的 Pod 的模式是？
確保不可用以及可用的 Pod 都處於指定的範圍之內, 它不會等到新的 Pod 都建好才去砍舊的, 也不會等到舊的 Pod 都砍完才去建新的

Kubernetes 中, 預設最多幾 % 的期望 Pod 數量可以處於運行中？
125%

Kubernetes 中, 當實施滾動升級時, 預設最多可以有幾% 的 Pod 不可用？
25%

Kubernetes 中, 當實施滾動升級時, 預設至少會保持幾 % 的 Pods 運行？
75%

Kubernetes 中, 當 rollout 被觸發, Deployment 是透過建立一個新的什麼資源來建立新的 Pod?
ReplicaSet

Kubernetes 中, 如果我要利用 kubectl CLI 來更新指定鏡像的版本, 我可以使用哪一個指令？
kubectl set image deployment/deploymentName containerName=imageName:tagName --record

Kubernetes 中, Deployment 的 rollout 唯有在什麼情況下會被觸發？
當 .spec.template 的內容變了

Kubernetes 中, pod-template-hash 是由 hash 哪一個 field 得來的？
PodTemplate

Kubernetes 中, pod-template-hash 的用途是？
確保一個 Deployment 建立的 ReplicaSet 不會重疊

Kubernetes 中, pod-template-hash 是由誰加到 ReplicaSet 上的？
Deployment Controller

Kubernetes 中, pod-template-hash 可以被變更嗎？
不可

Kubernetes 中, 當我們在定義 labels 以及 selectors 時, 務必要注意什麼？否則會造成衝突以及預期外的行為
不可讓 labels 或 selectors 在多個 controller 之間互相重疊

Kubernetes 中, 如果要檢視每個 pod 自動產生的 labels, 可以使用哪一個 kubectl 指令？
kubectl get pods --show-labels

Kubernetes 中, ReplicaSet 的命名格式為？
[DEPLOYMENT-NAME]-[RANDOM-STRING]

Kubernetes 中, 如果要透過 CLI 取得 ReplicaSet, 可以使用哪一個 kubectl command?
kubectl get rs

Kubernetes 中, rs 是哪一個資源的縮寫？
ReplicaSet

Kubernetes 中, 要如何查看 rollout status?

kubectl rollout status deployment deploymentName

Kubernetes 中, 當我在建立資源時加上了 --record flag, 我要怎樣才可以看到運行的 command 的紀錄？
kubectl describe resource resourceName
Kubernetes 中, 如果我想要之後使用 kubectl describe 時都可以看到該 resource 之前執行過什麼執行, 那我可以在建立該 resource 時加上哪一個 flag?
--record
Kubernetes 中, matchExpressions field 的 operator Lt 代表的意思是？
該 label 的 value 需小於指定值
Kubernetes 中, matchExpressions field 的 operator Gt 代表的意思是？
該 label 的 value 需大於指定值
Kubernetes 中, matchExpressions field 的 operator DoesNotExist 代表的意思是？
該 label key 有存在的都算
Kubernetes 中, matchExpressions field 的 operator Exist 代表的意思是？
該 label key 有存在的都算
Kubernetes 中, matchExpressions field 的 operator NotIn 代表的意思是？
該 label 的 value 需不存在於指定的 array list 當中
Kubernetes 中, matchExpressions field 的 operator In 代表的意思是？
該 label 的 value 需存在於指定的 array list 當中
Kubernetes 中, matchLabels field 代表？
一對 key/value pair
Kubernetes 中, matchExpressions field 有哪幾個 operator？
- In
- NotIn
- Exists
- DoesNotExist
- Lt
- Gt

#Kubernetes #Kubernetes Deployments