Google Kubernetes Engine (GKE) 提供多種策略，可在工作負載擴充時，協助您縮短 Pod 啟動延遲時間。減少節點佈建、容器映像檔提取和應用程式初始化作業的延遲時間，有助於在流量激增時提升服務回應速度，並平衡基礎架構成本。
請參閱本文，比較 Pod 啟動生命週期中各種 GKE 啟動延遲時間縮短策略，然後選擇單一策略或分層組合，以符合工作負載需求。
瞭解 Pod 啟動生命週期
當 GKE 中的工作負載擴大，且現有節點沒有足夠的可分配容量來容納新 Pod 時，端對端啟動延遲時間會涵蓋三個連續階段：
- 在節點佈建和 Pod 排程階段，叢集自動配置器會佈建新的 Compute Engine VM、初始化節點，並向控制層註冊，以便 Kubernetes 調度器放置待處理的 Pod。
- 在容器映像檔提取階段，節點上的
kubelet元件會從 Container Registry 下載並解壓縮 Pod 要求的容器映像檔。 - 在應用程式初始化階段，容器執行階段會啟動應用程式程序、將依附元件或模型權重載入記憶體，並通過 Kubernetes 啟動和就緒探測。
不同的 GKE 功能會針對這個生命週期的特定階段。如要瞭解哪個階段對工作負載啟動時間的影響最大，請參閱「監控啟動延遲指標」。
比較縮短啟動延遲的策略
下表比較 Pod 啟動生命週期中，各種縮短 GKE 啟動延遲時間的策略：
| 策略 | 生命週期階段 | 延遲時間設定檔 | 費用和配額設定檔 | 叢集模式和硬體支援 | 適用情境 |
|---|---|---|---|---|---|
| 有效容量緩衝區 (預先發布版) | 節點佈建和 Pod 排程 | 節點已在執行，因此會立即排定 Pod。 |
執行 VM 的標準節點運算費率。 會耗用 Compute Engine vCPU、記憶體、磁碟和 IP 位址配額，以及命名空間中的 Kubernetes 資源配額。 |
Standard 叢集，以及使用自訂 ComputeClass 的 Autopilot 叢集 (依節點計費)。 支援 CPU、GPU 和 TPU。 |
吸收突發流量，並調度對延遲敏感的 GPU、TPU 或 CPU 工作負載。 |
| 待命運算資源緩衝區 (預先發布版) | 節點佈建和 Pod 排程 | 約 30 到 35 秒內即可恢復暫停的節點，比佈建新節點更快。 |
暫停期間不會產生 VM 運算費用。開機磁碟和儲存的記憶體狀態會產生永久磁碟儲存空間費用。 暫停時會耗用磁碟和 IP 位址配額，以及命名空間中的 Kubernetes 資源配額。 |
Standard 叢集 (啟用自動佈建節點功能) 和具有自訂 ComputeClass 的 Autopilot 叢集。 僅支援 CPU (不支援 GPU、TPU 或本機 SSD)。 |
維持具成本效益的爆量容量，以利流量持續成長。 |
| 快速啟動節點 | 節點佈建和 Pod 排程 | 使用預先初始化的硬體，盡可能縮短冷節點啟動時間。 | 無須額外付費。 |
Autopilot 叢集和 Standard 叢集中的 Autopilot 工作負載。 支援符合資格的一般用途和 GPU 機器系列，不含本機 SSD 或 Spot VM。 |
加速佈建基準節點，無須設定或支付閒置容量費用。 |
| 低優先順序的預留位置 Pod | 節點佈建和 Pod 排程 | 在逐出優先順序較低的預留位置 Pod 後，立即排定 Pod。 |
執行節點的標準運算費率。 需要手動部署及管理 PriorityClass。 |
Standard 和 Autopilot 叢集。 | 在採用 Pod 計費方式或 1.35 以下版本的叢集上預留備用容量。 |
| 圖像串流 | 提取容器映像檔 | 不必等待整個映像檔下載完畢，即可啟動容器。 |
無須額外付費。 必須使用 Artifact Registry 或符合資格的 Docker Hub 存放區。 |
Autopilot (預設啟用) 和 Standard 叢集。 | 縮短大型容器映像檔的映像檔提取時間。 |
| 次要開機磁碟 | 容器映像檔提取 | 將預先填入資料的永久磁碟，平行連結至新節點，並佈建節點。 | 每個節點上附加的永久磁碟和磁碟映像檔儲存空間都會產生費用。 | Standard 和 Autopilot 叢集。 | 預先載入大型容器映像檔或靜態資料集，例如機器學習模型權重。 |
| Pod 快照 | 應用程式初始化 | 直接從儲存的程序記憶體和檔案系統狀態檢查點，還原新的 Pod 副本。 | 依 Cloud Storage 中的快照儲存空間計費。 |
在 GKE Sandbox 中執行 Pod 的 Standard 和 Autopilot 叢集。 支援符合資格的 CPU 和 GPU 機型 (不含 TPU)。 |
略過 AI 推論模型和啟動常式繁重的應用程式的冗長初始化程序。 |
| CPU 啟動時增加 (預先發布版) | 應用程式初始化 | 在 Pod 啟動期間暫時提高 CPU 要求和限制，然後就地調整大小。 | 在啟動期間暫時耗用額外的節點 CPU 容量。 | 已啟用垂直 Pod 自動調度功能的 Standard 和 Autopilot 叢集。 | 加快 Java、Python 或 Node.js 等執行階段的 CPU 繫結初始化作業。 |
依 Pod 啟動階段選擇策略
以下各節說明 Pod 啟動生命週期各階段的可用選項。
加快節點佈建和 Pod 排程速度
如果現有節點無法容納待處理的 Pod，等待新節點啟動通常是擴充延遲時間的主要原因。您可以採用下列策略，減少或消除這類延遲：
- 使用容量緩衝區，以宣告方式預留備用節點容量：
- 設定有效緩衝區 (
buffer.x-k8s.io/active-capacity策略)，讓預先佈建的節點保持運作，並準備好立即排定 Pod。作用中緩衝區支援 CPU、GPU 和 TPU 工作負載。 - 設定待命緩衝區 (
buffer.gke.io/standby-capacity策略)，讓預先佈建的 CPU 節點保持暫停狀態。工作負載擴充時，GKE 會在約 30 到 35 秒內恢復待命節點，避免產生執行閒置 VM 的完整運算費用。
- 設定有效緩衝區 (
- 快速啟動節點可自動為符合資格的 Autopilot 工作負載和 GPU 機型系列，盡可能預先初始化硬體。當 GKE 為符合條件的工作負載佈建新節點時，會自動使用快速啟動節點。包括為補充相容 Autopilot 自訂 ComputeClass 的容量緩衝區而建立的節點。
- 如果工作負載採用 Autopilot Pod 計費模式，或在 1.35 以下版本的 GKE 執行，請使用 Kubernetes PriorityClasses 部署低優先順序的預留位置 Pod。如果叢集在支援的 GKE 版本上採用以節點為準的計費方式，建議使用宣告式容量緩衝區，因為您不必管理預留位置 Deployment 或 Pod 剔除迴圈。
加快容器映像檔提取速度
排程器將 Pod 放在節點上後，節點必須先提取容器映像檔，才能啟動容器。您可以採用下列策略，縮短映像檔提取延遲時間：
- 啟用映像檔串流功能後，容器就能在透過網路串流必要檔案時啟動，同時在背景下載其餘映像檔。Autopilot 叢集預設會為 Artifact Registry 中符合條件的映像檔啟用映像檔串流功能。
- 設定次要開機磁碟，將大型容器基礎層或靜態資料集預先載入至自訂磁碟映像檔。GKE 建立節點時，會一併附加從磁碟映像檔例項化的永久磁碟，並佈建節點。
- 在節點初始化期間 (
buffer.gke.io/standby-capacity-init-time註解)，執行 DaemonSet，在待命緩衝區預先載入容器映像檔。在 GKE 暫停待機節點之前，DaemonSet 會將工作負載映像檔拉到節點的開機磁碟，以便在節點恢復時，映像檔已快取。
加快應用程式初始化速度
即使節點已運作且容器映像檔已存在，應用程式仍可能需要大量時間載入架構、編譯即時 (JIT) 程式碼，或將模型權重載入記憶體。您可以運用下列策略縮短初始化時間：
- 設定 Pod 快照，在 GKE Sandbox 中擷取執行中 Pod 的記憶體和檔案系統狀態檢查點。工作負載水平擴充時，GKE 會從 Cloud Storage 的快照還原新的副本，讓 Pod 從快照建立的時間點繼續執行，而非從全新狀態初始化。
- 在 VerticalPodAutoscaler 上設定 CPU 啟動加速，在 Pod 允許和初始化期間分配額外 CPU。Pod 達到
Ready狀態，且設定的加速時間結束後，GKE 會將 Pod 的 CPU 要求就地調回基準層級，不會重新啟動容器。
結合策略，進行端對端最佳化
由於這些策略會在 Pod 啟動生命週期的不同階段運作，因此您可以分層使用這些策略，盡可能縮短端對端擴充時間：
- 結合小型有效容量緩衝區和大型待機容量緩衝區。在流量突然暴增期間，作用中緩衝區會立即吸收最初的 Pod 爆發量。同時，GKE 會在大約 30 到 35 秒內，從待命緩衝區恢復節點，以補充作用中緩衝區並處理持續成長。在背景中，叢集自動配置器會佈建及暫停新節點，以重新填滿待命緩衝區。
- 如要使用待機容量緩衝區，請在節點暫停前啟用映像檔串流或使用 DaemonSet 預先載入容器映像檔，這樣節點恢復運作時，就不會花時間下載大型容器映像檔。
- 在容量緩衝區或快速啟動節點上，啟用 CPU 啟動提升功能或 Pod 快照，這樣一來，GKE 將 Pod 排定至預先佈建或預先初始化的節點後，Pod 就不會在啟動期間受到 CPU 節流，或直接從儲存的快照還原。
如要評估單一或合併策略對工作負載的影響，請查看 Cloud Monitoring 中的「Pod Startup Latency Distribution」(Pod 啟動延遲時間分布) 和「Pod First Ready Latency」(Pod 首次就緒延遲時間) 圖表，並檢查 Cloud Logging 中的排程延遲時間記錄。如需操作說明，請參閱「監控啟動延遲指標」。