關於容量緩衝區

容量緩衝區可讓您主動在叢集中宣告使用中或待命容量緩衝區的級別，進而縮短 Google Kubernetes Engine (GKE) 工作負載的 Pod 啟動延遲時間。預先宣告備用容量，就能以符合成本效益的方式，加快工作負載啟動速度。

本文說明容量緩衝區的運作方式。如要瞭解如何啟用及使用容量緩衝區，請參閱「設定容量緩衝區」。

容量緩衝區的使用時機

如果應用程式容易受到啟動延遲影響，且需要快速擴充，請使用容量緩衝區。當流量突然增加時，主動緩衝區會提供預先佈建的容量，專為低延遲擴充而設計。當流量持續增加時，待命緩衝區能以比預先佈建更實惠的成本調度 Pod。

容量緩衝區有下列優點：

  • 盡可能縮短調度資源延遲時間：主動緩衝區會提供執行中的節點，有助於盡可能縮短延遲時間。待命緩衝區可快速恢復，提供容量的速度比新節點快，成本也比使用中緩衝區低。
  • 符合成本效益的過度佈建：容量緩衝區可協助您維持安全網。對於大規模工作負載，這種方法通常比其他過度佈建方法更符合成本效益，例如降低水平 Pod 自動配置器 (HPA) 使用率目標，這可能會隨著叢集成長而線性增加閒置容量。
  • 滿足工作負載需求：您可以完全掌控容量緩衝區設定。您可以選擇整合自訂 DaemonSet 來預先載入映像檔、調整啟動時間，以及控管緩衝區空間，以符合需求。

如果工作負載對延遲時間較為敏感，且需要快速擴充，建議使用容量緩衝區，例如 AI 代理、AI 推論、特賣活動期間的零售應用程式，或玩家活動高峰期的遊戲伺服器。

容量緩衝區的運作方式

使用 Kubernetes CapacityBuffer 自訂資源定義備用容量緩衝區，藉此實作容量緩衝區。GKE 叢集自動配置器會監控 CapacityBuffer 資源，並將其視為待處理需求，確保有備用容量可用。如果叢集容量不足，無法滿足緩衝區中定義的資源要求，叢集自動配置器就會佈建額外節點。

工作負載擴充時，GKE 會按照下列優先順序，將待處理的 Pod 排定至可用容量：

  1. 在有效緩衝區中執行節點
  2. 待命緩衝區中尚未暫停的執行中節點
  3. 待命緩衝區中的暫停節點
  4. 新佈建的節點

為了盡快排定待處理的 Pod，GKE 會先使用可用的緩衝容量，再佈建新節點。即使自訂 ComputeClass 中有更高優先順序的規則，會佈建新節點，系統仍會優先採用這項規則。

緩衝容量不限於 scalableRef 欄位中參照的工作負載。任何待處理 Pod 的排程限制 (例如節點選取器、容許條件和資源要求) 如果與緩衝區節點的設定相符，就能宣告該容量。如要為特定工作負載預留容量緩衝區，請設定工作負載區隔，在工作負載和容量緩衝區中新增相符的容忍度和節點選取器 (或節點親和性)。

當工作負載耗用使用中緩衝區的容量時，叢集自動配置器會從相容的待命緩衝區 (如有) 恢復節點，或佈建新節點，藉此補充使用中緩衝區。當工作負載或使用中的緩衝區耗用待命緩衝區中的節點時，叢集自動配置器會佈建並暫停新節點，藉此補充待命緩衝區。當工作負載縮減，節點使用率偏低時，叢集自動配置器會在縮減穩定時間範圍後，刪除多餘的執行中節點，而不是將節點重新暫停至待命緩衝區。為了補充待命緩衝區，GKE 會分別佈建及暫停新的節點。

容量緩衝策略

您可以根據延遲時間和成本需求，使用不同的佈建策略來設定容量緩衝區。

使用中的緩衝區

有效緩衝區提供執行中的節點，可低延遲擴充預留容量內的工作負載。由於節點已在執行，因此在擴充事件期間，宣告 Pod 的延遲時間極短。

待命緩衝區

待命緩衝區提供已暫停的節點。待命策略比主動策略更具成本效益，但在節點接受工作負載之前，需要短暫延遲才能恢復節點。

費用和定價

除了標準的節點運算費用外，容量緩衝區不收取額外費用，適用於標準節點集區和選取特定硬體的 Autopilot 工作負載。容量緩衝區不支援依 Pod 計算的計費模式。

基礎節點的計費方式因緩衝區類型而異：

  • 有效緩衝區：GKE 會維護執行中的 VM，做為有效緩衝區容量，並依據節點標準運算費率向您收費。
  • 待命緩衝區：VM 執行個體暫停時，您不需支付運算費用 (CPU 或記憶體)。您會產生少量的儲存費用 (例如 VM 啟動磁碟和儲存的記憶體狀態)，以及靜態外部 IP 位址等相關聯資源的費用。當 GKE 恢復待命 VM 來託管工作負載時，則會按照標準節點運算費率計費。詳情請參閱「已暫停執行個體的定價」。

CapacityBuffer CRD

如要設定容量緩衝區，請建立 CapacityBuffer CustomResourceDefinition (CRD)。您可以設定容量緩衝區，以符合不同條件：

  • 固定副本：根據參照 Pod 範本的資源要求，指定要建立的緩衝 Pod 固定數量。這項設定是建立已知大小緩衝區的最簡單方法。
  • 資源限制：指定緩衝區應保留的 CPU 和記憶體總量。控制器會根據參照 Pod 範本的資源要求，計算要建立多少緩衝 Pod。
  • 百分比：將緩衝區空間定義為現有可擴充物件的百分比，該物件定義了擴充子資源 (例如 Deployment、StatefulSet、ReplicaSet 或 Job)。緩衝區大小會隨著參照工作負載的規模動態調整。只有實作 Kubernetes scale 子資源的物件，才支援以百分比為單位的容量緩衝區。

您可以合併使用這些選項，例如同時設定 replicas 和 percentage，讓 GKE 使用較大的值做為下限，並將 limits 設為上限。

詳情請參閱 CapacityBuffer CRD 參考文件。

最佳做法

設定容量緩衝區時，請參考下列建議，盡可能提高成本效益和回應速度：

  • 採用成本最佳、待命優先的策略：如果工作負載可容忍約 30 秒的短暫擴充延遲，請優先使用待命緩衝區。這項策略可避免全新 VM 的冷節點啟動，且不需支付使用中 VM 的全額費用。
  • 針對延遲敏感的工作負載使用主動緩衝區：如果工作負載無法容忍節點恢復時間，且 Pod 排程時間必須盡可能縮短，請使用主動緩衝區。
  • 採用混合策略，兼顧效能和成本：結合小型活躍緩衝區和大型待命緩衝區，打造符合成本效益的設定。GKE 會優先從待命緩衝區恢復節點 (約需 30 秒)，以重新填滿使用中緩衝區，同時在背景佈建新節點，以回填待命緩衝區。這種設定會以有效容量吸收初始尖峰，並使用成本較低的待命容量因應持續成長。
  • 設定初始突發流量的作用中緩衝區大小：定義作用中緩衝區的大小，以涵蓋預期會遇到的初始副本突發流量，直到待命緩衝區節點恢復運作為止。
  • 為持續負載設定待命緩衝區大小：定義足以涵蓋預期擴充負載的待命緩衝區，以便緩衝區在背景從冷啟動重新填滿。如果待命緩衝區的大小足夠，Pod 排程延遲時間上限可縮短至恢復節點所需的時間，大約 30 秒。當容量緩衝區開始使用並重新填滿時，新的緩衝區節點會先轉換為啟用狀態，然後再暫停。這項策略有助於在長時間負載期間提升有效容量。
  • 使用緩衝區模擬器：嘗試不同的有效和待命緩衝區大小，找出最適合特定工作負載的結果。請前往 https://github.com/gke-labs/buffers-simulator，使用開放原始碼 GKE 緩衝區模擬器，模擬工作負載資源調度行為，微調緩衝區大小規則，並達成效能目標。
  • 縮短從零開始調度工作負載資源時的冷啟動延遲時間：將使用 HPA 縮減至零或從零擴充 (minReplicas: 0) 的工作負載與容量緩衝區配對。當需求增加且工作負載從零開始擴充時，GKE 會立即在預熱緩衝區節點上排定 Pod，而不是等待新的運算節點佈建。
  • 考慮在標準叢集上使用 optimize-utilization 自動調度資源設定檔：由於容量緩衝區已保留備用空間，您可以設定 optimize-utilization 自動調度資源設定檔 (--autoscaling-profile=optimize-utilization)，讓叢集自動配置器在需求下降後，更快縮減未充分運用的節點。這個設定檔也會將 Pod 更緊密地封裝到節點上，因此請先評估更緊密的裝箱是否符合工作負載可用性需求，再啟用這項功能。

計算緩衝區空間

將使用中緩衝區與待命緩衝區結合，即可預估需要多少緩衝區副本 (或模擬緩衝區 Pod)，才能吸收流量高峰。如要計算這項預估值，請使用預期的擴充率 (以每秒 Pod 數量為單位)、待命節點恢復延遲時間，以及冷節點建立延遲時間。這些延遲時間會因 VM 機器系列和節點設定而異。舉例來說，待命節點的恢復延遲時間通常為 30 到 35 秒，而新節點的建立延遲時間通常為 60 到 120 秒，具體取決於機器系列。如要測量叢集的實際延遲時間，請參閱「監控啟動延遲時間指標」。

  1. 計算有效緩衝區空間，涵蓋待命節點恢復時建立的 Pod：

    \[ \text{Active buffer replicas} = \text{Expected scale-up rate} \times \text{Standby node resume latency} \]

  2. 計算待命緩衝區空間，涵蓋新冷節點完成佈建時建立的其餘 Pod：

    \[ \text{Standby buffer replicas} = (\text{Expected scale-up rate} \times \text{Cold node creation latency}) - \text{Active buffer replicas} \]

舉例來說，如果工作負載以每秒 2 個 Pod 的速度擴充，待命節點需要 30 秒才能恢復，而新的冷節點需要 90 秒才能佈建：

  • 有效緩衝區需要 \( 2 \times 30 = 60 \) 個副本，才能吸收前 30 秒的尖峰流量。
  • 待命緩衝區需要 \( (2 \times 90) - 60 = 120 \) 個副本，才能涵蓋剩餘的 60 秒，而叢集自動配置器會在背景佈建新的冷節點，補充緩衝區。如果流量高峰以相同速率持續超過 90 秒，這些補充的節點就會準備好為傳入的 Pod 提供服務，不需等待時間。

如要根據工作負載資源調度模式測試這些預估值，請使用 GKE 緩衝區模擬器執行模擬。

需求條件和限制

容量緩衝區有下列需求和限制：

  • GKE 叢集必須執行 1.35.2-gke.1842000 以上版本，才能使用主動緩衝區；執行 1.36.0-gke.2253000 以上版本，才能使用待命緩衝區。
  • 容量緩衝區僅支援採用節點計費模式的工作負載，適用於 Standard 節點集區和選取特定硬體的 Autopilot 節點集區。容量緩衝區不支援使用依 Pod 計算的計費模式的工作負載。
  • 在 Standard 叢集上，建議您啟用節點集區自動建立功能。啟用自動建立節點集區功能後，叢集自動配置器會根據 CapacityBuffer 中的資源要求，建立新的節點集區。如未啟用節點集區自動建立功能，叢集自動配置器只會擴充現有節點集區。
  • 使用中和待命容量緩衝區的配額消耗方式不同：
    • 在有效緩衝區中執行的節點會計入 vCPU、記憶體、磁碟和 IP 位址 Compute Engine 配額。
    • 待命緩衝區中暫停的節點，在暫停期間不會計入 Compute Engine vCPU 或記憶體配額。不過，這些 VM 仍會耗用 IP 位址配額和磁碟配額，包括用於儲存已暫停 VM 記憶體的 Persistent disk standard (GB) 配額。
    • 在 Kubernetes 中，無論是運作中或暫停的待命緩衝區單位，都會計入命名空間中的 Kubernetes 資源配額，就像緩衝區 Pod 正在運作一樣。
  • 如果 CapacityBuffer 設定依附元件 (例如 PodTemplate) 選取自訂 ComputeClass，則依附元件必須定義任何容許、節點選取器或執行階段類別，才能在佈建的節點上排程 (例如 GKE Sandbox 的需求)。如需操作說明，請參閱自訂 ComputeClass 說明文件。

待命緩衝區還有下列限制：

  • Standard 叢集必須啟用節點集區自動建立功能，才能支援這些資源。
  • 支援 1.36.0-gke.2853000 以上版本的 Autopilot 叢集。
  • 不支援連接 GPU 或 TPU 的節點。
  • 不支援本機 SSD。
  • 雖然待命緩衝區支援節點儲存空間的客戶自行管理加密金鑰 (CMEK)，但節點記憶體在暫停期間會使用 Google-owned and Google-managed encryption keys 加密。
  • 不支援機密 Google Kubernetes Engine 節點。
  • 待命緩衝區僅支援 GKE Container-Optimized OS 和 Ubuntu 節點映像檔。不支援 Windows Server 節點。如果您使用自訂節點作業系統，請務必確認該 OS 支援 Compute Engine 暫停和恢復作業。
  • 您應熟悉 Compute Engine 暫停和繼續作業的相關限制。主要限制包括：
    • 不支援磁碟受客戶提供加密金鑰 (CSEK) 保護的節點。
    • 不支援記憶體超過 208 GB 的節點。
    • 不支援裸機執行個體。
    • 節點 OS 必須支援 ACPI S3 睡眠信號。
    • 暫停程序的時間長度與記憶體大小成正比。

後續步驟