在前面我們已經學習到了 Pod 的擴容、滾動更新等知識，我們可以手動為 Deployment 等設置 Pod 副本的數量，而這里會繼續學習 關於 Pod 擴容、收縮 的規則，讓 Pod 根據節點服務器的資源自動增加或減少 Pod 數量。
本文為作者的 Kubernetes 系列電子書的一部分，電子書已經開源，歡迎關注，電子書瀏覽地址：
https://k8s.whuanle.cn【適合國內訪問】
https://ek8s.whuanle.cn 【gitbook】
縮放 Deployment
設置副本數量
很簡單，使用 kubectl scale 命令直接設置：
kubectl scale deployment nginx --replicas=10
其它方式前面的章節已經提到過了，還有通過修改 YAML 文件的方式。
水平自動縮放
K8S 有個 Pod 水平自動擴縮（Horizontal Pod Autoscaler） 可以基於 CPU 利用率自動擴縮 ReplicationController、Deployment、ReplicaSet 和 StatefulSet 中的 Pod 數量。Pod 自動擴縮不適用於無法擴縮的對象，比如 DaemonSet。
除了 CPU 利用率，也可以基於其他應程序提供的自定義度量指標 來執行自動擴縮。
參考資料：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[當前副本數 * (當前指標 / 期望指標)]
因為筆者這里只有一個 Worker 節點，不能控制 CPU 使用率模擬場景，所以不方便演示，讀者只需要了解這個命令即可。
按照算法計算，加入當前副本數量為 12，且 CPU 使用率達到 90%，則期望副本數為 12*(90%/80%) = 13.5，那么理論上會部署 14 個 Pod，但是 CPU 再繼續增加的話，最多 15 個副本數量。如果在機器管夠的情況下，可以去掉 min 和 max 參數。
算法細節請查看：https://kubernetes.io/zh/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details
比例縮放
比例縮放指的是在上線 Deployment 時，臨時運行着應用程序的多個版本(共存)，比例縮放是控制上線時多個 Pod 服務可用數量的方式。
水平縮放只關心最終的期望 Pod 數量，直接修改副本數和水平縮放，決定最終 Pod 數量有多少個。
而比例縮放是控制對象上線過程中，新的 Pod 創建速度和 舊的 Pod 銷毀速度、 Pod 的可用程度，跟上線過程中新舊版本的 Pod 替換數量有關。
查看上一章中創建的 Deployment 的部分 YAML 如下：
spec:
progressDeadlineSeconds: 600
replicas: 1
revisionHistoryLimit: 10
selector:
matchLabels:
app: nginx
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
strategy 可以配置 Pod 是怎么更新的。
當我們設置.spec.strategy.type==RollingUpdate時，便會采取滾動更新的方式更新 Pods，此時可以指定 maxUnavailable 和 maxSurge 來控制滾動更新 過程。這個我們之前提到過，就是 Deployment 默認會保證一直有 75% 的 pod處於可用狀態，在完成更新前可能有多個版本的 pod 共存。
-
maxUnavailable
最大不可用數量或比例，舊的 Pod 會以這個數量或比例逐漸減少。
-
maxSurge
最大峰值，新的 Pod 會按照這個數量或比例逐漸創建。
3.5 章已經使用到了這兩者，這里就不細說了，讀者請參考：https://kubernetes.io/zh/docs/concepts/workloads/controllers/deployment/#max-unavailable
我們查看之前的 Deployment，執行命令 kubectl get deployment nginx -o yaml：
... ...
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
... ...
配置表示，每次只有 1/4 的 Pod 被更新、替換。
這個是所有 Deployment 的默認配置，在更新鏡像版本時，舊的 Pod 會被新的 Pod 替換，但是不是一下子完成的，每次處理 25% 的 Pod，在更新過程中，我們必須保證我們的服務依然可用，即還有舊版本的 Pod 在運行。這個配置設定了更新過程中至少保證 75% 的 Pod 還可以使用，這個就是比例縮放。
下面我們來進行實驗。
首先創建新的 Deployment ，設置副本數量為 10：
kubectl create deployment nginx --image=nginx:1.19.0 --replicas=10
# kubectl scale deployment nginx --replicas=10
我們執行 kubectl edit deployment nginx 修改縮放個數：
strategy:
rollingUpdate:
maxSurge: 3
maxUnavailable: 2
type: RollingUpdate
除了可用百分比表示，也可以使用個數表示。
舊的 Pod 按照最大 2 個的速度不斷減少；新的 Pod 按照最大 3 個的速度不斷增加；
比例縮放的配置處理好了，它會在我們上線新版本的時候生效，我們可以觀察到這個過程，但是需要快一點執行命令查看狀態。
快速執行以下命令：
kubectl set image deployment nginx nginx=nginx:1.20.0
kubectl get replicaset
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 創建較快(3個)，所以最終可能新的 Pod 數量達到 10 個了，舊的 Pod 還有很多，總數量大於 10。
最終：
NAME DESIRED CURRENT READY AGE
nginx-7b87485749 10 10 10 99m
nginx-85b45874d9 0 0 0 99m
nginx-bb957bbb5 0 0 0 41m
如果想新版本的 Pod 上線速度更快，則可以把 maxSurge 數量或比例設置大一些；為了保證上線過程穩定、服務可用程度高，可以把 maxUnavailable 設置小一些。