在維運 Kubernetes 叢集的過程中，手動調整 Pod 數量或資源配置是一件非常痛苦的事情。流量突然暴增時來不及反應，閒置時又浪費一堆雲端費用。好在 Kubernetes 提供了多種自動擴縮機制，能夠根據實際狀況智慧地調整應用程式的規模。
本文會帶大家認識四種主要的自動擴縮機制：HPA（Horizontal Pod Autoscaler）、VPA（Vertical Pod Autoscaler）、CPA（Cluster Proportional Autoscaler） 以及 CA（Cluster Autoscaler），並從三個面向來分析每一種機制：
- 適用場景
- 觸發條件
- 調整目標
HPA（水平 Pod 自動擴縮器）
適用場景
當你的服務流量有明顯的波峰波谷，例如電商在促銷時段湧入大量請求，平常又相對平靜，這時候就很適合用 HPA。它能動態地增減 Pod 副本數量，讓你的 Deployment 或 ReplicaSet 始終維持在一個合理的負載水位。
觸發條件
HPA 是 Kubernetes 內建的控制器，會定期向 API Server 查詢 Metrics Server 收集到的指標（如 CPU、記憶體使用率），再和你在 Pod 中設定的 requests 值做比較。一旦超過你定義的閾值，就會觸發擴縮。
| 設定項目 | 說明 |
|---|---|
minReplicas | Pod 最少副本數 |
maxReplicas | Pod 最多副本數 |
targetCPUUtilizationPercentage | CPU 使用率目標百分比 |
behavior | 控制每次擴縮的速率（百分比或絕對值） |
調整目標
HPA 調整的是 Pod 的數量。透過 behavior 參數，你可以精細控制每次擴縮時新增或減少的 Pod 比例，避免劇烈震盪。
除了原生的資源指標以外，HPA 還可以搭配 KEDA 等專案，引入自訂指標（例如訊息佇列長度、HTTP 請求數等）來做更精準的決策。
VPA（垂直 Pod 自動擴縮器）
適用場景
不同於 HPA 透過增加副本來應對負載，VPA 的思路是「把單一 Pod 養大」。剛部署一個新服務時，你可能根本不知道該給多少 CPU 和記憶體的 requests/limits，設太高浪費資源，設太低又容易 OOM。VPA 會持續觀察每個 Pod 的實際資源用量，然後自動推薦或直接調整到合適的數值。
觸發條件
部署 VPA 控制器後，你可以建立 VPA 物件指定要觀察哪些 Deployment。VPA 需要一段時間收集數據才能算出合理的建議值，短期的觀察結果可能不夠準確。
| 運作模式 | 說明 |
|---|---|
Auto / Recreate | 自動調整 requests/limits 並重啟 Pod |
Off | 僅計算建議值，不實際更動 Pod |
Initial | 僅在 Pod 建立時套用建議值 |
調整目標
VPA 針對個別 Pod 的 CPU/記憶體 requests 和 limits 進行調整，不會改變副本數量。在 Auto/Recreate 模式下會重建 Pod 來套用新設定，Off 模式則只是提供數據讓你自行決定。
CPA（叢集比例自動擴縮器）
適用場景
HPA 和 VPA 都是針對「應用本身的負載」做反應，但有些基礎元件的規模應該跟著叢集大小走。最經典的例子就是 CoreDNS：叢集節點越多、Pod 越多，DNS 查詢量就越大，DNS 服務也需要跟著擴容。CPA 就是為了這種場景設計的。
觸發條件
CPA 的觸發依據是叢集的規模指標，而非應用的資源使用情況。它根據節點數量或總 CPU 核心數來計算合適的副本數。
| 參數 | 說明 |
|---|---|
coresPerReplica | 每個副本負責多少 CPU 核心 |
nodesPerReplica | 每個副本負責多少節點 |
計算公式如下：
replicas = max( ceil(cores / coresPerReplica), ceil(nodes / nodesPerReplica) )調整目標
CPA 根據叢集規模動態調整目標 Pod 的副本數量，確保基礎服務的容量能跟上叢集的成長。
CA（叢集自動擴縮器）
適用場景
前面三種機制都是在「現有節點」上做文章，但如果所有節點的資源都用完了，新的 Pod 排程不上去怎麼辦？CA 就是用來動態增減節點數量的。當 Pod 因為資源不足而卡在 Pending 狀態時，CA 會自動新增節點；反過來，當節點使用率長時間偏低，CA 也會移除多餘的節點來省錢，這在雲端環境中特別實用。
觸發條件
| 觸發情境 | CA 動作 |
|---|---|
| Pod 因資源不足進入 Pending 狀態 | 新增節點 |
| 節點使用率長時間低於閾值 | 移除節點 |
移除節點時，CA 會先透過類似 drain 的操作將節點上的 Pod 遷移走，這時候要特別注意 PodDisruptionBudget 和 terminationGracePeriodSeconds 的設定，避免服務中斷。
不同的雲端平台（EKS、GKE、AKS）對 CA 的實作細節不太一樣，例如跨可用區均勻分佈節點、使用 annotation 防止特定 Pod 被驅逐等，都需要查閱各平台的文件。
調整目標
CA 調整的是叢集中的節點數量。當某個節點被移除時，上面的 Pod 會被重新排程到其他節點執行。
四種機制的比較總結
| 機制 | 調整對象 | 觸發依據 | 典型場景 |
|---|---|---|---|
| HPA | Pod 副本數 | CPU/記憶體/自訂指標 | 流量波動的 Web 服務 |
| VPA | Pod 的 CPU/記憶體設定 | 歷史資源用量 | 新服務的資源調校 |
| CPA | Pod 副本數 | 叢集節點數/CPU 核心數 | CoreDNS 等基礎服務 |
| CA | 叢集節點數 | Pod 排程狀態/節點使用率 | 雲端環境節省成本 |
實務搭配建議
這四種機制並非互斥，實務上經常搭配使用：
- HPA + CA：HPA 擴增 Pod，CA 確保有足夠的節點承載這些新 Pod，這是最常見的組合。
- VPA + HPA：VPA 負責長期的資源配置最佳化，HPA 負責即時的流量應對（但要注意兩者可能會互相衝突，建議 VPA 用
Off模式搭配 HPA）。 - CPA + CA：基礎服務隨叢集規模擴展，節點數量也跟著動態調整。
此外，由於擴縮過程中 Pod 和節點數量會頻繁變動，可能導致 Pod 分佈不均的問題。這時候可以搭配 descheduler 或善用 Affinity、TopologySpreadConstraints 來維持合理的部署分佈。
參考資源：
發佈留言