更新

打開?https://hub.docker.com/_/nginx?可以查詢 nginx 的鏡像版本，我們可以先選擇一個舊一點的版本。

首先，我們創(chuàng)建一個 Nginx 的 Deployment，副本數(shù)量為 3。

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

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

注：?我們也可以加上?--record?標志將所執(zhí)行的命令寫入資源注解?kubernetes.io/change-cause?中。 這對于以后的檢查是有用的。例如，要查看針對每個 Deployment 修訂版本所執(zhí)行過的命令。

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

我們只需要觸發(fā)鏡像版本更新事件，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。

執(zhí)行：

kubectl edit deployment nginx

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

上線

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

它的上線跟我們所說的更新，有些區(qū)別。因為我們所說的更新，版本是往后的，例如 1.19.0 -> 1.20.0 ，用新版本替換舊版本才叫更新。但是 Deployment 的上線，則是任意版本。它會根據(jù)我們設置的鏡像版本自動替換，可以用 1.19.0 替換 1.20.0。不過這里我們不需要糾結(jié)這些。

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

我們可以通過命令，查看 pod 的上線狀態(tài)：

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 數(shù)量：

kubectl get deployment

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

UP-TO-DATE 字段可以看到成功更新的 pod 數(shù)量。

還可以查看 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 已經(jīng)被全部更新到 nginx-85b45874d9 了，所以前者的數(shù)量為 0，我們也可以看到 pod 中，所有 pod 都是以?nginx-85b45874d9?作為前綴的。這幾個關鍵信息，我們可以截圖，后面再次對照。

如果我們的項目上線了，我們更新軟件版本，如果一次性更新所有容器或者 pod，那么我們的軟件會有一段時間處于不可用狀態(tài)，直到所有 pod 都完成更新。Deployment 可確保在更新時僅關閉一定數(shù)量的 Pod，默認情況下，它確保至少所需 Pods 75% 處于運行狀態(tài)，也就是說正在被更新的 pod 比例不超過 25%。當然，只有兩三個 pod 的 Deployment 不會按照這個比例限定。

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

Deployment 確保僅所創(chuàng)建 Pod 數(shù)量只可能比期望 Pods 數(shù)高一點點。 默認情況下，它可確保啟動的 Pod 個數(shù)比期望個數(shù)最多多出 25%（最大峰值 25%）所以在自動更新 Deployment 時，觀察到的 pod 可能為 4個。另外，在 Deployment 更新時，除了可以更改鏡像的版本，也可以更改 ReplicaSet 的數(shù)量。

執(zhí)行?kubectl describe deployment nginx?查看 Deployment 詳細信息，我們查看 Event 字段。

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

回滾

默認情況下， Deployment 的上線記錄都會保留在系統(tǒng)中，以便可以隨時回滾。

我們查看 Deployment 的上線歷史記錄：

kubectl rollout history deployment nginx

REVISION  CHANGE-CAUSE
2         
3         

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

可以看到有 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:	
    Host Port:	
    Environment:	
    Mounts:	
  Volumes:	

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

回滾是一個版本：

kubectl rollout undo deployment nginx

再執(zhí)行?kubectl rollout history deployment nginx?會看到不一樣的信息。

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

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

這里提一下?--record，在前面，我們創(chuàng)建和更新 Deployment 時，都沒有使用到這個參數(shù)。我們可以試試這個參數(shù)的作用。

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

kubectl rollout history deployment nginx

輸出：

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

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

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

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 數(shù)量。

除了 CPU 利用率，也可以基于其他應程序提供的自定義度量指標 來執(zhí)行自動擴縮。 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%(期望指標)，副本數(shù)量配置應該為 10 到 15 之間，CPU 是動態(tài)縮放 pod 的指標，會根據(jù)具體的 CPU 使用率計算副本數(shù)量，其計算公式如下。

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

算法細節(jié)請查看：https://kubernetes.io/zh/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details

比例縮放

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

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

這里不細說，請參考：https://kubernetes.io/zh/docs/concepts/workloads/controllers/deployment/#max-unavailable

默認的話，deployment 的 yaml 是這樣的：

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

我們可以改成：

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

注：執(zhí)行?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個處于可用狀態(tài)。而 maxSurge 表示允許超出的期望 pod 數(shù)量，所以nginx-7b87485749?的數(shù)量不是 2 個，而是 5個，因為允許超出 3 個。其實意思就是不需要等舊的 pod 刪除 一個，新的 pod 創(chuàng)建一個。可以多創(chuàng)建幾個 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 版本時，可以暫停。

前面我們已經(jīng)設置了這個 maxSurge 和 maxUnavailable，可以讓 pod 的創(chuàng)建慢一些。

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

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

之后，多次執(zhí)行?kubectl get replicaset?,會發(fā)現(xiàn)副本數(shù)量不會變化。

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

如果我們再次執(zhí)行：

kubectl set image deployment nginx nginx=nginx:1.19.0

會發(fā)現(xiàn)雖然提示更新了，但是實際上沒有變化。在暫停中，執(zhí)行新的更新操作是無效的。

執(zhí)行?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