Kubernetes中Deployment的升級與回滾

2022-04-01 13:04:00

更新

開啟 https://hub.docker.com/_/nginx 可以查詢 nginx 的映象版本，我們可以先選擇一箇舊一點的版本。

首先，我們建立一個 Nginx 的 Deployment，副本數量為 3。

kubectl create deployment nginx --image=nginx:1.19.0 --replicas=3

首次部署的時候，跟之前的操作一致，不需要什麼特殊的命令。

注：我們也可以加上 --record 標誌將所執行的命令寫入資源註解 kubernetes.io/change-cause 中。這對於以後的檢查是有用的。例如，要檢視針對每個 Deployment 修訂版本所執行過的命令。

其實更新 pod 是非常簡單的，我們不需要控制每個 pod 的更新，也不需要擔心會不會對業務產生影響，k8s 會自動控制這些過程。

我們只需要觸發映象版本更新事件，k8s 會自動為我們更新 pod 的。

kubectl set image deployment.apps/nginx nginx=nginx:1.20.0

格式為：

kubectl set image deployment.apps/{deployment名稱} {映象名稱}:={映象名稱}:{版本}

我們可以檢視 pod 的詳細資訊：

kubectl describe pods

找到 Events 描述：

... ...
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  66s   default-scheduler  Successfully assigned default/nginx-7b87485749-rlmcx to instance-2
  Normal  Pulled     66s   kubelet            Container image "nginx:1.20.0" already present on machine
  Normal  Created    66s   kubelet            Created container nginx
  Normal  Started    65s   kubelet            Started container nginx

為了記錄版本更新資訊，我們需要在 kubectl create deployment、kubectl set image 命令後面加上 -- --record。

我們還可以通過 edit 方式更新 pod。

執行：

kubectl edit deployment nginx

然後會彈出編輯 yaml 的介面，將 .spec.template.spec.containers[0].image 從 nginx:1.19.0 更改至 nginx:1.20.0，然後儲存即可。

上線

僅當 Deployment Pod 模板（即 .spec.template）發生改變時，例如模板的標籤或容器映象被更新，才會觸發 Deployment 上線。其他更新（如對 Deployment 執行擴縮容的操作）不會觸發上線動作。Deployment 的上線動作可以為我們更新 pod 的版本。

它的上線跟我們所說的更新，有些區別。因為我們所說的更新，版本是往後的，例如 1.19.0 -> 1.20.0 ，用新版本替換舊版本才叫更新。但是 Deployment 的上線，則是任意版本。它會根據我們設定的映象版本自動替換，可以用 1.19.0 替換 1.20.0。不過這裡我們不需要糾結這些。

當我們更新 pod 版本時，k8s 會自動負載均衡，而不是把所有 pod 刪除，再重新建立新版本 pod，它會以穩健的方式逐漸替換 pod。

我們可以通過命令，檢視 pod 的上線狀態：

kubectl rollout status deployment nginx

輸出類似於：

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

或者

deployment "nginx-deployment" successfully rolled out

我們也可以通過獲取 deployment 資訊時，檢視已更新的 pod 數量：

kubectl get deployment

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

UP-TO-DATE 欄位可以看到成功更新的 pod 數量。

還可以檢視 ReplicaSet 和 pod：

kubectl get replicaset
kubectl get pods

輸出型別於：

NAME               DESIRED   CURRENT   READY   AGE
nginx-7b87485749   0         0         0       20m
nginx-85b45874d9   3         3         3       21m

NAME                     READY   STATUS    RESTARTS   AGE
nginx-85b45874d9-nrbg8   1/1     Running   0          12m
nginx-85b45874d9-qc7f2   1/1     Running   0          12m
nginx-85b45874d9-t48vw   1/1     Running   0          12m

可以看到有兩個 ReplicaSet，nginx-7b87485749 已經被全部更新到 nginx-85b45874d9 了，所以前者的數量為 0，我們也可以看到 pod 中，所有 pod 都是以 nginx-85b45874d9 作為字首的。這幾個關鍵資訊，我們可以截圖，後面再次對照。

如果我們的專案上線了，我們更新軟體版本，如果一次性更新所有容器或者 pod，那麼我們的軟體會有一段時間處於不可用狀態，直到所有 pod 都完成更新。Deployment 可確保在更新時僅關閉一定數量的 Pod，預設情況下，它確保至少所需 Pods 75% 處於執行狀態，也就是說正在被更新的 pod 比例不超過 25%。當然，只有兩三個 pod 的 Deployment 不會按照這個比例限定。

如果我們的 pod 數量足夠大，或者在更新 Deployment 時迅速輸出上線狀態，可以看到新舊的 pod 數量加起來不一定就是 3 個，因為它不會殺死老 Pods，直到有足夠的數量新的 Pods 已經出現。在足夠數量的舊 Pods 被殺死前並沒有建立新 Pods。它確保至少 2 個 Pod 可用，同時最多總共 4 個 Pod 可用。

Deployment 確保僅所建立 Pod 數量只可能比期望 Pods 數高一點點。預設情況下，它可確保啟動的 Pod 個數比期望個數最多多出 25%（最大峰值 25%）所以在自動更新 Deployment 時，觀察到的 pod 可能為 4個。另外，在 Deployment 更新時，除了可以更改映象的版本，也可以更改 ReplicaSet 的數量。

執行 kubectl describe deployment nginx 檢視 Deployment 詳細資訊，我們檢視 Event 欄位。

但是這些原理等知識我們都不需要記，也不需要深入，我們記得有這回事就行，有需要的時候也可以直接檢視檔案的。

回滾

預設情況下， Deployment 的上線記錄都會保留在系統中，以便可以隨時回滾。

我們檢視 Deployment 的上線歷史記錄：

kubectl rollout history deployment nginx

REVISION  CHANGE-CAUSE
2         <none>
3         <none>

注：我們的版本不一定一樣，因為我為了這這篇文章，進行了一些測試，可能版本數量比你的多。

可以看到有 2，3 兩個版本，我們檢視版本3 的資訊：

kubectl rollout history deployment nginx --revision=3

deployment.apps/nginx with revision #3
Pod Template:
  Labels:	app=nginx
	pod-template-hash=85b45874d9
  Containers:
   nginx:
    Image:	nginx:1.20.0
    Port:	<none>
    Host Port:	<none>
    Environment:	<none>
    Mounts:	<none>
  Volumes:	<none>

目前介紹了幾個檢視 Deployment 上線的歷史記錄，下面我真正來回滾 Deployment。

回滾是一個版本：

kubectl rollout undo deployment nginx

再執行 kubectl rollout history deployment nginx 會看到不一樣的資訊。

此時版本數量多了，我們還可以指定回滾到特點的版本。

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

這裡提一下 --record，在前面，我們建立和更新 Deployment 時，都沒有使用到這個引數。我們可以試試這個引數的作用。

kubectl set image deployment.apps/nginx nginx=nginx:1.19.0

kubectl rollout history deployment nginx

輸出：

REVISION  CHANGE-CAUSE
5         <none>
6         kubectl set image deployment.apps/nginx nginx=nginx:1.19.0 --record=true

說明加上了 --record ，會把我們操作時的命令記錄下來。

但是我們這裡目前來說，只有兩個記錄，我們明明提交了多次，但是這裡查詢的只有兩條記錄，這時因為我們操作的時候，只用到了 1.19.0、1.20.0 兩個版本，所以也就只有這兩個版本的提交記錄。多用幾個版本，輸出結果：

REVISION  CHANGE-CAUSE
7         kubectl set image deployment.apps/nginx nginx=nginx:1.19.0 --record=true
8         kubectl set image deployment.apps/nginx nginx=nginx:1.20.0 --record=true
9         kubectl set image deployment.apps/nginx nginx=nginx:latest --record=true

縮放 Deployment

直接設定

很簡單，使用 kubectl scale 命令直接設定：

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

修改 yaml 的方式也行，一是修改 yaml檔案，使用 kubectl apply -f 的方式更新，或者使用 kube edit 的方式。

Pod 水平自動縮放

K8S有個 Pod 水平自動擴縮（Horizontal Pod Autoscaler）可以基於 CPU 利用率自動擴縮 ReplicationController、Deployment、ReplicaSet 和 StatefulSet 中的 Pod 數量。

除了 CPU 利用率，也可以基於其他應程式提供的自定義度量指標來執行自動擴縮。 Pod 自動擴縮不適用於無法擴縮的物件，比如 DaemonSet。

參考資料：https://kubernetes.io/zh/docs/tasks/run-application/horizontal-pod-autoscale/

命令：

kubectl autoscale deployment nginx --min=10 --max=15 --cpu-percent=80

表示目標 CPU 使用率為 80%(期望指標)，副本數量設定應該為 10 到 15 之間，CPU 是動態縮放 pod 的指標，會根據具體的 CPU 使用率計算副本數量，其計算公式如下。

期望副本數 = ceil[當前副本數 * (當前指標 / 期望指標)]

演演算法細節請檢視：https://kubernetes.io/zh/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details

比例縮放

另外還有個比例縮放，允許 Deployment 支援同時執行應用程式的多個版本。

當我們設定.spec.strategy.type==RollingUpdate時，採取捲動更新的方式更新 Pods，就可以指定 maxUnavailable 和 maxSurge 來控制捲動更新過程。這個我們之前提到過，就是 Deployment 預設會保證一直有 75% 的 pod處於可用狀態，在完成更新前可能有多個版本的 pod 共存。

這裡不細說，請參考：https://kubernetes.io/zh/docs/concepts/workloads/controllers/deployment/

預設的話，deployment 的 yaml 是這樣的：

  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate

我們可以改成：

  strategy:
    rollingUpdate:
      maxSurge: 3
      maxUnavailable: 2
    type: RollingUpdate

注：執行 kubectl edit deployment nginx 直接改。

我們可以觀察到這個過程：

root@instance-1:~# kubectl set image deployment nginx nginx=nginx:1.20.0
deployment.apps/nginx image updated
root@instance-1:~# kubectl get replicaset
NAME               DESIRED   CURRENT   READY   AGE
nginx-7b87485749   5         5         0       93m
nginx-85b45874d9   0         0         0       93m
nginx-bb957bbb5    8         8         8       35m

前面我們設定了最大存在兩個不可用 pod(maxUnavailable=2)，所以一開始會更新兩個 pod，所以 nginx-bb957bbb5 8個處於可用狀態。而 maxSurge 表示允許超出的期望 pod 數量，所以nginx-7b87485749 的數量不是 2 個，而是 5個，因為允許超出 3 個。其實意思就是不需要等舊的 pod 刪除一個，新的 pod 建立一個。可以多建立幾個 pod，再按照慢一些的速度刪除舊的 pod，最終完成版本更新。

最終：

NAME               DESIRED   CURRENT   READY   AGE
nginx-7b87485749   10        10        10      99m
nginx-85b45874d9   0         0         0       99m
nginx-bb957bbb5    0         0         0       41m

暫停 Deployment 上線

命令：

kubectl rollout pause deployment nginx

用途就是我們更新 Deployment 的 pod 版本時，可以暫停。

前面我們已經設定了這個 maxSurge 和 maxUnavailable，可以讓 pod 的建立慢一些。

執行下面的命令可以快速卡住上線過程。

kubectl set image deployment nginx nginx=nginx:latest
kubectl rollout pause deployment nginx

之後，多次執行 kubectl get replicaset ,會發現副本數量不會變化。

NAME               DESIRED   CURRENT   READY   AGE
nginx-7b87485749   8         8         8       109m
nginx-85b45874d9   0         0         0       109m
nginx-bb957bbb5    5         5         5       52m

如果我們再次執行：

kubectl set image deployment nginx nginx=nginx:1.19.0

會發現雖然提示更新了，但是實際上沒有變化。在暫停中，執行新的更新操作是無效的。

執行 kubectl rollout history deployment nginx 也查不到我們提交的 1.19.0 的請求。

暫停的時候，我們可以更新一些限制的 CPU 和資源：

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

恢復 Deployment：

kubectl rollout resume deployment nginx

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支援it145.com。