Kubernetes Autoscaling 自動擴縮容概念介紹

發表於 分類於

在 Kubernetes 裡部署服務時，資源配置通常不是一次設定好就永遠不需要調整。流量、任務量、背景批次作業與使用者行為都可能隨時間變化。如果 Pod 數量太少，服務可能在高峰時處理不過來；如果資源預留太多，又會讓叢集長時間保留用不到的 CPU 與記憶體。

Autoscaling 的目的，就是讓 Kubernetes 可以根據實際負載與資源使用情況，自動調整工作負載或叢集資源。它不只是「流量變大就加 Pod」這麼單一，而是依照不同層級的需求，調整 Pod 數量、單一 Pod 的資源請求，甚至是 Node 數量。

這篇文章會先整理 Kubernetes Autoscaling 的整體概念，說明常見的擴縮容方向，以及 HPA 與 VPA 分別解決什麼問題。後續文章會再分別深入介紹 HPA 與 VPA 的實作方式。

為什麼需要 Autoscaling？

在沒有自動擴縮容之前，服務通常會先依照預估流量設定固定的 Pod 數量與資源大小。這種方式簡單直接，但也容易遇到兩種問題。

第一種是資源不足。當實際流量超過預期，現有 Pod 無法承受請求量時，服務可能開始延遲、逾時，甚至出現錯誤。如果每次都要等人手動調整 replicas，反應速度通常跟不上流量變化。

第二種是資源浪費。為了避免高峰流量造成服務不穩，團隊可能會把 Pod 數量或 resources.requests 設得比較高。但當流量回落後，這些資源仍然被保留在叢集中，導致其他工作負載可用的資源變少，也增加整體成本。

Autoscaling 的價值就在於讓系統可以根據觀察到的指標自動調整，讓服務在高負載時有足夠承載能力，也能在低負載時釋放不必要的資源。

Autoscaling 調整的是什麼？

Kubernetes 的 Autoscaling 可以從不同層級理解。最常見的三種方向是水平擴縮容、垂直擴縮容與叢集節點擴縮容。

類型 調整目標 解決問題
水平擴縮容 Pod 數量 當服務流量增加時，透過更多 Pod 分攤負載
垂直擴縮容 單一 Pod 的 CPU 與記憶體 requests 當 Pod 資源設定不準時，提供更合理的資源配置
叢集節點擴縮容 Node 數量 當叢集資源不足或過剩時，調整可排程容量

水平擴縮容比較像是增加服務副本，讓更多 Pod 一起處理請求。垂直擴縮容則是調整每個 Pod 本身的資源大小，讓單一 Pod 有更合適的 CPU 與記憶體請求值。叢集節點擴縮容則是在更底層處理 Node 容量，確保 Pod 有足夠的地方可以被排程。

這三種方式並不是互相取代，而是作用在不同層級。實務上，服務本身可能透過 HPA 調整 Pod 數量，透過 VPA 檢查 resources 設定是否合理，同時由 Cluster Autoscaler 或雲端平台的節點擴縮容機制補足叢集容量。

HPA：調整 Pod 數量

HPA（Horizontal Pod Autoscaler）是 Kubernetes 裡最常見的自動擴縮容方式。它會觀察指定指標，例如 CPU 使用率、記憶體使用率或自訂指標，然後調整目標工作負載的 replicas。

舉例來說，如果一個 Deployment 原本只有 1 個 Pod，當 CPU 使用率持續高於 HPA 設定的目標值時，HPA 會提高 Deployment 的 replicas，讓 Kubernetes 建立更多 Pod 來分攤負載。當負載下降後，HPA 也可以逐步減少 Pod 數量，避免資源長時間閒置。

HPA 適合處理「負載變大，需要更多服務副本」的場景，例如 Web API 流量增加、背景任務量上升，或服務需要依照請求數、佇列長度等指標增加處理能力。

不過，如果 HPA 使用 CPU utilization 作為依據，工作負載的容器需要設定 resources.requests.cpu。因為 HPA 計算 CPU 使用率時，會以實際 CPU 使用量相對於 CPU request 的比例作為判斷基準。

後續可以接著閱讀 Kubernetes HPA 水平自動擴縮容實作紀錄(待發佈)，了解 HPA 的設定參數、部署範例與觀察方式。

VPA：調整 Pod 資源請求

VPA（Vertical Pod Autoscaler）關注的不是 Pod 數量，而是每個 Pod 應該配置多少 CPU 與記憶體 requests。

在 Kubernetes 中，resources.requests 會影響 Pod 排程，也會成為 HPA 使用資源 utilization 指標時的重要基準。如果 requests 設得太低，Pod 可能看起來很容易超過目標使用率，也可能在高負載時資源不足；如果 requests 設得太高，叢集會為 Pod 預留過多資源，造成排程效率下降。

VPA 會觀察 Pod 的實際資源使用情況，計算出較合理的 CPU 與記憶體建議值。依照設定不同，VPA 可以只提供建議，也可以在 Pod 建立或重建時套用新的 requests。

VPA 適合處理「不知道 Pod resources 該設多少」的問題。對剛上線的服務、負載型態尚未穩定的應用，或需要定期檢查 requests 是否過高或過低的環境來說，VPA 可以提供很有參考價值的資源建議。

後續可以接著閱讀 Kubernetes VPA 垂直自動擴縮容實作紀錄(待發佈)，了解 VPA 的安裝、設定與建議值觀察方式。

HPA 與 VPA 的使用差異

HPA 與 VPA 都屬於 Autoscaling，但它們解決的是不同層面的問題。

項目 HPA VPA
調整方向 水平調整 垂直調整
調整內容 Deployment replicas Container resources requests
主要目的 透過更多 Pod 分攤負載 讓單一 Pod 的資源請求更合理
常見依據 CPU、記憶體、自訂指標、外部指標 Pod 歷史 CPU 與記憶體使用量
可能影響 建立或移除 Pod 可能重新建立 Pod 或只提供建議

簡單來說，HPA 回答的是「現在需要幾個 Pod 才夠？」；VPA 回答的是「每個 Pod 應該要多少資源才合理？」。

實務上要特別注意，VPA 不建議與 HPA 同時針對 CPU 或記憶體 utilization 調整同一個工作負載。原因是 HPA 會根據 requests 計算使用率，而 VPA 會調整 requests。兩者如果同時作用在相同資源指標上，可能讓擴縮容判斷互相影響。

比較常見的做法是讓 HPA 負責處理流量變化，VPA 則先使用建議模式觀察 resources 是否合理。等資源設定穩定後，再評估是否要讓 VPA 自動套用建議，或改用不會和 HPA 指標互相干擾的配置方式。

Autoscaling 需要哪些基礎條件？

Autoscaling 能否正常運作，關鍵在於 Kubernetes 是否能取得可靠的指標資料。以 HPA 和 VPA 來說，常見的基礎條件包含以下幾項。

第一，叢集需要能提供 Pod 的 CPU 與記憶體使用量。常見做法是安裝 metrics-server，讓 Kubernetes 可以查詢基本資源指標。

第二，工作負載需要設定合理的 resources.requests。這不只會影響排程，也會影響 HPA 使用 CPU 或記憶體 utilization 時的計算結果。

第三，應用程式本身要能承受擴縮容帶來的變化。HPA 擴容時會建立新 Pod，縮容時會移除 Pod；VPA 在某些模式下可能會重新建立 Pod。若服務啟動時間長、無法優雅關閉，或狀態沒有妥善外部化，擴縮容過程就可能影響可用性。

第四，擴縮容邊界需要先設計好。無論是 HPA 的 minReplicas、maxReplicas，或 VPA 的 minAllowed、maxAllowed，都應該依照服務需求與叢集容量設定，避免過度擴張或縮得太小。

小結

Kubernetes Autoscaling 的核心目的，是讓服務可以根據實際負載與資源使用情況自動調整。它可以提升高峰時的承載能力，也能在低負載時減少不必要的資源浪費。

HPA 主要負責調整 Pod 數量，適合處理流量或任務量變化；VPA 則負責評估單一 Pod 的 CPU 與記憶體 requests，適合用來修正或檢查資源配置是否合理。兩者都很實用，但使用時要理解它們作用的層級與可能互相影響的地方。

接下來的系列文章會分別透過實作範例介紹 HPA 與 VPA，從設定參數、部署方式到觀察擴縮容結果，逐步建立 Kubernetes 自動擴縮容的實作基礎。