從手動到自動#

前幾章逐步介紹了 Request、Limit、Namespace、LimitRange、Metrics Server 等資源管理的工具。指標都收集到了，設定也都調整好了，但如果只能靠人在儀表板前盯著流量手動調整，這套機制其實就少了一塊重要的拼圖。

自動擴縮容（Autoscaling）就是把這塊拼上去的關鍵：依照預先設定的資源規範與監控指標，自動在水平、垂直甚至多個維度上擴展或縮減服務，回應系統當下的負載波動。

所有 Autoscaling 機制都建立在「事先設定好資源規格」與「Metrics Server 已就緒」之上，缺一不可。

常見的 Autoscaler 種類#

Cluster Autoscaler#

Cluster Autoscaler 屬於叢集層級的調節者，最主要的工作是調整 node-pool 中節點的數量：

  • Scale-up：當 Pod 出現 unschedulable 狀態約十秒後就會迅速判斷是否需要擴增節點。判斷本身很快，但實際開機可能需要數分鐘到十幾分鐘才能進入可用狀態。
  • Scale-down：每隔一段時間（預設約十秒）檢查 CPU 與記憶體 Request 總和是否低於 50%，並確認沒有 Pod 或 Node 的排程限制阻止縮減。
  • 設定不當會讓 Cluster Autoscaler 沒辦法順利縮容，例如：
    • Cluster Autoscaler 想關閉節點並驅逐 Pod，但違反了 Pod affinity / anti-affinity 或 PodDisruptionBudget。
    • 在節點上加 "cluster-autoscaler.kubernetes.io/scale-down-disabled": "true" annotation 可避免該節點被縮容。

由於 Cluster Autoscaler 是叢集等級的機制，在本地只有一個節點的 Docker Desktop 上很難完整體驗它的價值；在 GCP GKE、AWS EKS 等雲端平台才能看到它的真正用途。

Horizontal Pod Autoscaler#

水平擴縮（Horizontal Pod Autoscaler, HPA）是 Pod 層級的調節者，負責依照負載自動擴展或縮減 Pod 副本數：

  • Scale-up：檢查 Metrics Server，發現指標超過設定值時，增加 Deployment 的 replica。
  • Scale-down：發現指標低於設定值時，減少 Deployment 的 replica。
  • 如果原本 Deployment 已經設了固定的 replica 數量，會被 HPA 接管 — HPA 會直接覆蓋原本的設定。
  • 每次擴縮後會等三到五分鐘讓系統穩定，再繼續看下一輪指標。
  • 計算公式：
desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]

如果 currentMetricValue 是 200m、desiredMetricValue 是 100m，就代表要把 replica 調成現在的 2 倍。

  • HPA 也支援用 custom 或 external metrics 觸發擴縮。
  • 從 v2beta2 起 HPA 才支援以記憶體當指標，v1 只能看 CPU 使用率（CPU Utilization）。

HPA 的 API 版本迭代很快，網路上會看到 v1、v2、v2beta2 等各種範例，挑教學時建議直接以最新版的官方 API 文件為準。

Vertical Pod Autoscaler#

垂直擴縮（Vertical Pod Autoscaler, VPA）的目標是自動推薦並設定 Pod 的 resources.requests 與 resources.limits，讓使用者不必再手動猜該配多少 CPU、多少記憶體：

  • 觀察指標、發現 Pod 的需求變大或變小時，調整 Deployment 的 Pod resources.requests，並重啟 Pod 讓變更生效。
  • VPA 必須先把 Pod 驅逐，再透過新的 spec 重新建立 — 因為 Request/Limit 沒辦法熱更新。
  • VPA 在做推薦時會參考 Pod 的歷史資料（history data）。
  • VPA 與 HPA 不能直接混用 — 除非 HPA 採用 custom metric，或者使用支援多維擴縮的 MPA。

VPA 跟 Metrics Server 一樣，都是 Custom Resources，並非預設安裝在 Kubernetes 中。許多核心功能其實都仰賴這類擴充元件來補齊，這也讓 Kubernetes 的模組化程度持續提升。

Multidim Pod Autoscaler#

Multidim Pod Autoscaler（MPA，多維 Pod 自動擴縮）可以同時搭配多種擴縮策略，目前只在 GCP GKE 上提供：

  • 此功能目前限定 GCP GKE，本地或其他平台都無法直接使用。
  • 在 GKE 上仍屬 beta，建議先在非正式環境試水溫。
  • 多維擴縮目前的組合是「依 CPU 進行 HPA、依記憶體進行 VPA」，所以 Deployment 的 resources.requests/limits 中的 CPU 是必填欄位，因為 VPA 這邊只負責記憶體。

小結#

不同種類的 Autoscaler 對應不同層級的問題：

  • Cluster Autoscaler：節點數量。
  • HPA：Pod 副本數量。
  • VPA：單一 Pod 的資源大小。
  • MPA：在 GKE 上同時調整多個維度。

它們的共通點是：都依賴前面幾章建立起來的「資源規範 + 指標收集」基礎。接下來的兩章會分別動手玩玩 HPA 與 VPA。

原文出處#

  • GitHub：https://github.com/MikeHsu0618/2022-ithelp/tree/main/Day25
  • iThome：https://ithelp.ithome.com.tw/articles/10298125
Backward Kubernetes Ingress 路由守護神 Forward