AutoScaling - Introduction
什麼是 AutoScaling?
AutoScaling(自動擴展)是 Kubernetes 提供的一種機制,用於根據工作負載的需求自動調整計算資源的數量。 這有助於確保應用程式在高負載時獲得足夠的資源,並在低負載時釋放不必要的資源,以提高資源利用率並降低成本。
AutoScaling 的種類
Kubernetes 提供了多種 AutoScaling 機制,包括:
- Cluster Autoscaler(叢集自動擴展)
- Cluster Autoscaler 會根據叢集中未滿足的資源需求,自動增加或減少節點(Nodes)的數量。 當有 Pod 因資源不足而無法排程時,Cluster Autoscaler 會擴展節點數量; 反之,當某些節點上的 Pod 都被重新調度到其他節點後,該節點可能會被移除,以節省資源。
- Horizontal Pod Autoscaler (HPA)(水平 Pod 自動擴展)
- HPA 透過監測 Pod 的 CPU、記憶體使用率或其他自訂指標,根據負載動態調整 Pod 的數量。 例如,當 CPU 使用率超過閾值時,HPA 會增加 Pod 來分散負載;當負載降低時,HPA 會減少 Pod,以降低資源消耗。
- Vertical Pod Autoscaler (VPA)(垂直 Pod 自動擴展)
- VPA 主要用來動態調整單個 Pod 的資源限制(CPU、記憶體),而不是 Pod 數量。 當應用程式的資源需求增加時,VPA 會建議或自動調整 Pod 的 requests 和 limits, 使其獲得足夠的資源,而不需要手動修改配置。
- Multidimensional Pod Autoscaler (MPA)(多維度 Pod 自動擴展)
- MPA 是 HPA 和 VPA 的結合體,允許根據多種指標(如 CPU、記憶體、I/O、網路吞吐量等)同時調整 Pod 的數量與資源配置。 這種方式提供了更細緻的資源管理,以滿足應用程式的不同需求。
- Custom Pod Autoscaler (CPA)(自訂 Pod 自動擴展)
- CPA 允許使用者根據自訂邏輯來決定何時擴展或縮減 Pod,例如基於業務指標(如佇列長度、請求數量等)來動態調整資源配置。 可搭配 Kubernetes Event-driven Autoscaling (KEDA),透過事件驅動的方式(如 Kafka、RabbitMQ)觸發擴展, 或使用 Prometheus Adapter,根據 Prometheus 收集的指標(如請求率、記憶體使用率)來調整 Pod 數量,使擴展策略更靈活且符合應用需求。
1. Cluster Autoscaler
Cluster Autoscaler 主要負責根據 Pod 的需求自動調整節點(Node)的數量,當資源不足時會新增節點,當某些節點上的 Pod 可以被重新調度時,會自動縮減節點數量,並可與 Node Pool 搭配,根據不同類型的節點來動態調整資源以適應應用需求。
主要功能
- Scale-up(擴展):當 Pod 處於 Unschedulable 狀態時,Cluster Autoscaler 會在約 10 秒內判斷是否需要擴展,並觸發新增節點的動作,但實際上新節點啟動並變為可用狀態可能需要數分鐘到十多分鐘。
- Scale-down(縮減):Cluster Autoscaler 會定期(預設每 10 秒)檢查整體 CPU 和記憶體使用量是否低於閾值,並確保沒有受調度限制的 Pod 或 Node,然後再進行節點縮減。
- 與雲端供應商整合:支援 AWS、GCP、Azure 等雲端平台的自動擴展。
適用場景
- 動態變化的工作負載,例如 AI 訓練、CI/CD 工作流等。
- 避免為應對高峰期而長時間維持過多閒置資源。
注意事項
若設定不當,可能會導致 Cluster Autoscaler 無法正常縮減節點,常見原因包括:
- 違反 Pod 親和性/反親和性規則:當 CA 嘗試關閉節點並重新調度 Pod 時,若違反這些規則,可能導致縮減失敗。
- 受 PodDisruptionBudget 限制:若 Pod 所屬的 PodDisruptionBudget 限制了可中斷的 Pod 數量,可能會阻止節點移除。
- 手動禁用縮減:可透過在節點上設定
annotation: "cluster-autoscaler.kubernetes.io/scale-down-disabled": "true"
來防止該節點被 CA 縮減。
Pod 親和性/反親和性規則(Pod Affinity/Anti-Affinity)
- Pod 親和性(Pod Affinity): 指定 Pod 希望 與某些 Pod 安排在同一個節點或拓撲域(如同一個區域、機架等),通常用於提升性能或減少網路延遲。例如,希望應用程式的 Pod 和快取服務的 Pod 部署在相同的節點上。
- Pod 反親和性(Pod Anti-Affinity): 指定 Pod 避免 與某些 Pod 安排在同一個節點或拓撲域,常用於提高系統的可用性與容錯能力。例如,將應用的不同副本部署在不同的節點上,以避免單點故障。
這些規則可能會影響 Cluster Autoscaler 的運作,因為 CA 在縮減節點時,若無法找到符合親和性/反親和性條件的替代節點來重新調度 Pod,則該節點無法被移除。
PodDisruptionBudget(PDB,Pod 中斷預算)
- 最少可用(minAvailable):指定在任何時刻,該 Deployment、StatefulSet、ReplicaSet 等控制的 Pod 至少 需要有多少個存活。
- 最多不可用(maxUnavailable):指定在任何時刻,該 Pod 組中最多可以有多少個 Pod 處於不可用狀態。
當 Cluster Autoscaler 嘗試縮減節點時,如果刪除某個節點會導致 PDB 違規(如可用的 Pod 數量低於 minAvailable
),則該節點將無法被移除。
2. Horizontal Pod Autoscaler (HPA)
HPA 是 Pod 層級 的自動調節工具,透過監控 CPU、記憶體或自訂指標來動態調整 Pod 副本數量。 當負載增加時,HPA 會擴展 Pod 直到達到設定的最大值;反之,當負載降低時,則縮減至最小值,以確保資源效率與服務穩定性。
主要功能
- Scale-up(擴展):Autoscaler 會定期檢查 Metrics Server 的數據,當系統使用率超過預設閾值時,會透過增加
replicas
來擴展 Pod 的數量,以應對更高的負載。 - Scale-down(縮減):Autoscaler 會定期檢查 Metrics Server 的數據,當系統的資源使用率低於預設閾值時,會自動減少
replicas
數量,縮減 Pod 的數量,以節省資源並提高效率。 - 支持自訂指標:可以透過 Metrics Server 或 Prometheus 監控應用程式的指標來決定擴展策略。
適用場景
- Web 服務或 API 伺服器,因為這些應用通常有彈性負載需求。
- 需要根據流量波動調整資源的微服務架構。
注意事項
- 若在 Deployment 中已設定
replicas
數量,則該設定會被 HPA 的replicas
設定覆蓋。換句話 說,HPA 會根據自身的設定調整 Pod 的數量,忽略原本 Deployment 中的replicas
配置。 - 在完成擴展或縮減後,Autoscaler 會等待大約三到五分鐘讓系統穩定,然後再檢查 Metrics Server 的數據,以判斷是否需要進一步調整 Pod 數量。
3. Vertical Pod Autoscaler (VPA)
VPA 主要負責動態調整 Pod 的 CPU 和記憶體資源配置,根據 Pod 的實際需求自動調整其資源分配,而不改變 Pod 的副本數量。
主要功能
- Scale-up(擴展):VPA 會監控 Pod 的資源使用情況,當發現使用率超過設定閾值時,會增加 Pod 的
resource.requests
設定,並透過重啟 Pod 來應用新的資源配置。 - Scale-down(縮減):VPA 會根據 Pod 的資源使用情況,如果發現資源需求低於設定的閾值,則會減少 Pod 的
resource.requests
設定,並透過重啟 Pod 來更新配置,達到資源縮減的目的。 - 減少手動配置資源的需求:適用於長期運行且負載不均的應用。
適用場景
- 長時間執行且資源需求變化較大的應用,如資料庫、機器學習應用等。
- 需要細緻管理 CPU/記憶體資源分配的應用。
注意事項
- Pod 重啟:當 VPA 嘗試在最佳時機進行 Pod 重啟時,會刪除原有的 Pod 並建立一個新的,並且更新其
resource.requests
和resource.limits
設定。VPA 會根據 Pod 的歷史資源使用情況來決定重啟的時機。 - VPA 與 HPA 互動:目前 VPA 和 HPA 不能直接混用,除非 HPA 使用自訂指標(custom metrics)作為觸發條件,或是利用像 Multidimensional Pod Autoscaler (MPA) 等工具來實現兩者的共同使用。
- VPA 的支援情況:VPA 並未被 Kubernetes 原生支援,但某些雲端服務提供商已將其納入服務。例如,Google Kubernetes Engine (GKE) 已支援 VPA;雖然 AWS 的 EKS 並未原生支援 VPA,但使用者仍然可以手動安裝。
- 自定義資源:VPA 作為一種自定義資源(Custom Resource),類似於 Metrics Server,因此可能不會預設包含在 Kubernetes 中。不過,許多核心功能依賴這些自定義資源來實現,Kubernetes 的模組化設計讓它具備更高的彈性與擴展性。
4. Multidimensional Pod Autoscaler (MPA)
MPA 是一種結合 HPA 和 VPA 的擴展機制,根據多種指標自動調整 Pod 的副本數量和資源配置。目前,這項功能僅由 Google Cloud Platform (GCP) 的 Google Kubernetes Engine (GKE) 提供,並且處於 Beta 版本,無法在本地環境實現。
主要功能
- Scale-up(擴展):當應用的 CPU、記憶體或其他關鍵指標達到臨界點時,MPA 會同時增加 Pod 的數量或提升其資源配置。
- Scale-down( 縮減):當負載減輕時,MPA 會適當減少 Pod 的數量或降低其資源需求,以確保資源不被浪費。
適用場景
- 需要更靈活資源管理的應用,如即時數據處理、雲端遊戲伺服器等。
- 需要平衡效能與成本的微服務架構。
注意事項
- 在目前的 Beta 版本中,擴縮操作僅能根據 CPU 進行 HPA 調整,以及根據 記憶體 進行 VPA 調整。
- 若使用 MPA,需確保在 Deployment 的
resources
中預先設定cpu requests/limits
,因為目前的 VPA 僅能根據記憶體進行調整。
5. Custom Pod Autoscaler (CPA)
CPA 允許使用者根據自訂規則擴展 Pod,例如透過事件驅動或外部 API 來決定擴展條件。
主要功能
- Scale-up(擴展):當自訂指標(例如佇列長度、用戶請求數量等)達到設定值時,CPA 會啟動新的 Pod 來滿足需求。
- Scale-down(縮減):當業務需求減少時,CPA 會減少 Pod 數量,從而降低運行成本。
- 使用 Webhook、Metrics API 或 Prometheus 自訂擴展邏輯。
適用場景
- 需要根據自訂業務指標(如佇列長度、用戶請求數量)來進行擴展。
- 需要根據非標準資源指標進行擴展的應用,如 I/O 使用率、磁碟空間等。
相關工具
- Kubernetes Event-driven Autoscaling:通過事件驅動的方式,CPA 可以根據外部事件觸發 Pod 的擴展或縮減。例如,當特定事件(如消息隊列的長度)達到一定閾值時,可以自動擴展 Pod 來處理更多請求。此功能支援與多種流行事件來源整合,如 Kafka、RabbitMQ、Azure Service Bus 等。當消息隊列的長度達到預設條件時,CPA 會自動擴展 Pod 以處理更多的消息,從而達到負載均衡。
- Prometheus Adapter:Prometheus Adapter 可用於將 Prometheus 收集的自訂指標(如應用層級指標、監控數據等)引入 Kubernetes 進行 Autoscaling。透過 Prometheus Adapter,CPA 可以使用 Prometheus 的指標來決定何時擴展或縮減 Pod。
總結
Kubernetes AutoScaling 提供了多種擴展機制,可根據不同需求選擇適合的解決方案:
- Cluster Autoscaler 用於節點級別的擴展。
- HPA 用於 Pod 數量的自動擴展。
- VPA 用於 Pod 資源的自動調整。
- MPA 結合 HPA 和 VPA,提供更靈活的擴展。
- CPA 適用於自訂指標和特殊需求的擴展。