AutoScaling - Introduction

什麼是 AutoScaling？

AutoScaling（自動擴展）是 Kubernetes 提供的一種機制，用於根據工作負載的需求自動調整計算資源的數量。 這有助於確保應用程式在高負載時獲得足夠的資源，並在低負載時釋放不必要的資源，以提高資源利用率並降低成本。

---

AutoScaling 的種類

Kubernetes 提供了多種 AutoScaling 機制，包括：

1. Cluster Autoscaler（叢集自動擴展）
   • Cluster Autoscaler 會根據叢集中未滿足的資源需求，自動增加或減少節點（Nodes）的數量。 當有 Pod 因資源不足而無法排程時，Cluster Autoscaler 會擴展節點數量； 反之，當某些節點上的 Pod 都被重新調度到其他節點後，該節點可能會被移除，以節省資源。
2. Horizontal Pod Autoscaler (HPA)（水平 Pod 自動擴展）
   • HPA 透過監測 Pod 的 CPU、記憶體使用率或其他自訂指標，根據負載動態調整 Pod 的數量。 例如，當 CPU 使用率超過閾值時，HPA 會增加 Pod 來分散負載；當負載降低時，HPA 會減少 Pod，以降低資源消耗。
3. Vertical Pod Autoscaler (VPA)（垂直 Pod 自動擴展）
   • VPA 主要用來動態調整單個 Pod 的資源限制（CPU、記憶體），而不是 Pod 數量。 當應用程式的資源需求增加時，VPA 會建議或自動調整 Pod 的 requests 和 limits，使其獲得足夠的資源，而不需要手動修改配置。
4. Multidimensional Pod Autoscaler (MPA)（多維度 Pod 自動擴展）
   • MPA 是 HPA 和 VPA 的結合體，允許根據多種指標（如 CPU、記憶體、I/O、網路吞吐量等）同時調整 Pod 的數量與資源配置。 這種方式提供了更細緻的資源管理，以滿足應用程式的不同需求。
5. 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 數量。

提示

計算公式

$$\text{desiredReplicas} = \left\lceil \text{currentReplicas} \times \left( \frac{currentMetricValue}{desiredMetricValue} \right) \right\rceil$$

其中：

• currentReplicas 為當前的 Pod 副本數量。
• currentMetricValue 為當前的資源使用量。
• desiredMetricValue 為目標的資源使用量。

---

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 適用於自訂指標和特殊需求的擴展。