關於容量緩衝區

運算資源緩衝區可讓您主動在叢集中宣告運算資源緩衝區的層級 (使用中或待命)，藉此縮短 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 緩衝區模擬器執行模擬。

擴充性

運算資源緩衝區沒有硬性限制，但如果超過建議規模，節點佈建和 Pod 排程速度可能會變慢。緩衝區副本是緩衝區保留容量的模擬緩衝區 Pod，而非節點。為確保效能穩定，請遵守下列叢集規範：

建議的每個叢集運算資源緩衝區規模
緩衝區類型 每個叢集的緩衝區副本總數 每個叢集的緩衝區數量
使用中的緩衝區 最多 7,000 次 最多 100 人
待命緩衝區 最多 5,000 個 最多 25 人

無論是使用中或待命緩衝區，請避免建立多個緩衝區，因為每個緩衝區都需要獨立的節點集區，例如使用不同 ComputeClasses 或不同工作負載區隔設定的緩衝區。叢集自動配置器佈建新節點時，會一次擴充一個節點集區，因此新增緩衝區越多，填滿和重新填滿緩衝區所需的時間就越長。這項限制不適用於恢復待命緩衝區中已暫停的節點。

需求條件和限制

運算資源緩衝區有下列需求和限制：

  • GKE 叢集必須執行 1.37.1-gke.3020000 以上版本，才能使用運算資源緩衝區。
  • 運算資源緩衝區僅支援採用節點計費模式的工作負載，適用於 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 說明文件。

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

後續步驟