關於 GKE Pod 快照

Google Kubernetes Engine (GKE) Pod 快照可還原執行中 Pod 的快照，縮短工作負載啟動延遲時間。Pod 快照會儲存整個 Pod 狀態，包括記憶體和檔案系統變更。建立新的副本時，系統會從快照還原副本，讓工作負載繼續執行，而不是從新狀態開始。這項功能有助於水平擴充工作負載，例如將大量權重載入記憶體的 AI 推論模型，或載入大量依附元件的應用程式。

本文將說明 GKE Pod 快照的運作方式，並協助您評估工作負載是否能從中受益。

平台管理員、操作人員和應用程式開發人員可以參考這份文件，評估工作負載相容性、規劃快照儲存空間政策，以及瞭解 GKE 如何管理檢查點和還原作業。如要進一步瞭解Cloud de Confiance by S3NS 內容中提及的常見角色和工作範例，請參閱「常見的 GKE 使用者角色和工作」。

如要準備並在叢集中使用 Pod 快照，請參閱下列指南：

  1. 準備 Pod 快照
  2. 觸發 Pod 快照
  3. 從 Pod 快照還原工作負載

Pod 快照的使用時機

如果工作負載的初始化時間較長，請使用 Pod 快照。例如將大型模型載入 CPU 或 GPU 記憶體的 AI 推論工作負載，或是載入許多程式庫和依附元件的大型應用程式。如果工作負載的啟動時間本來就很快，Pod 快照通常不會帶來任何好處。

Pod 快照的運作方式

GKE Pod 快照會儲存 Pod 在特定時間的程序狀態副本。建立新的副本時，GKE 會從快照還原 Pod，而不是從全新狀態初始化 Pod。這項還原作業代表 Pod 會從擷取快照的時間點繼續執行。

如要以宣告方式設定 Pod 快照，請建立 Kubernetes 自訂資源，定義快照行為。在每個 GKE 節點上執行的代理程式會管理快照生命週期。代理程式會根據您定義的政策，決定何時建立新快照，以及何時使用現有快照還原新 Pod。在 GKE 控制層上執行的控制器會清除過時的快照並解決問題。Cloud Storage 會儲存 Pod 快照。

快照內容

下表列出 Pod 快照包含和排除的內容：

類別 已包含 已排除
應用程式狀態
  • 處理記憶
  • 執行緒
  • CPU 暫存器
  • 開啟檔案描述元
 無 (所有記憶體內程序狀態都會擷取)
檔案系統
  • 容器根檔案系統 (rootfs)
  • emptyDir 冊
  • tmpfs 個掛接
  • PersistentVolumeClaim 物件
  • 未列為涵蓋項目的任何其他磁碟區或儲存空間類型
網路
  • 回送連線
  • 監聽通訊端
  • Unix 網域通訊端
  • 有效外部連線 (還原時關閉)
  • 自訂路徑
  • 使用者定義的規則 (iptables、nftables)

自訂資源

如要以宣告方式設定 Pod 快照，請使用下列自訂資源：

  • PodSnapshotStorageConfig：指定快照的儲存位置。僅支援 Cloud Storage bucket。
  • PodSnapshotPolicy：根據 Kubernetes 標籤選取器，定義要建立快照的 Pod。這項自訂資源包含該功能的大部分設定選項，包括快照觸發方式、快照範圍和保留政策。
  • PodSnapshotManualTrigger (選用)：如果不使用工作負載觸發條件，請定義手動觸發條件，為特定 Pod 建立快照。

如需參考規格，請參閱 PodSnapshot CustomResourceDefinition 參考資料。

快照觸發條件

您可以透過下列方式觸發 Pod 快照：

  • 工作負載觸發條件：Pod 內的應用程式向 GKE 代理程式發出信號，表示已準備好建立快照。這類觸發條件會在工作負載週期中執行一次，例如在工作負載就緒狀態。這個方法最適合用來改善水平擴充工作負載的啟動延遲。
  • 手動觸發：您可以建立 PodSnapshotManualTrigger 自訂資源，視需要觸發特定 Pod 的快照。這類觸發條件可視需要執行多次。如果無法修改應用程式來表示準備就緒，這個方法最適合。

快照比對和相容性

為確保快照與還原的工作負載相容，GKE 會比對原始檢查點 Pod 和目標 Pod 的相容性。

GKE 會使用下列規則判斷相容性：

  • 選取順序：根據預設，GKE 會從與 Pod 命名空間和設定相符的最新 PodSnapshot 自訂資源還原工作負載。
  • 比對條件：相容性檢查取決於 PodSnapshotPolicy 自訂資源 (whole-pod 或 rootfs-only) 中設定的快照範圍。

whole-pod 範圍比對 (預設)

如果政策採用預設的 whole-pod 範圍，GKE 會檢查下列項目：

  • 精簡規格雜湊：GKE 會根據 Pod 規格中的重要執行階段欄位，產生不重複的雜湊。如要成功還原，目標 Pod 必須從其精簡規格產生相同的雜湊。這項檢查會驗證檢查點和還原的 Pod 在執行階段設定中是否相同。

    Pod 物件中的下列欄位是精簡規格的一部分，會影響不重複雜湊：

    • metadata：
      • annotations：僅限與 GKE Sandbox 相關的註解 (例如開頭為 dev.gvisor.* 前置字元的註解)。
      • labels：batch.kubernetes.io/job-completion-index
    • spec：
      • volumes：name、volumeSource、hostPath、persistentVolumeClaim、configMap
      • containers：
        • name
        • image
        • command
        • args
        • workingDir
        • ports：name、containerPort、protocol
        • volumeMounts：name、readOnly、recursiveReadOnly、mountPath、subPath、mountPropagation、subPathExpr
        • volumeDevices：name
        • lifecycle：postStart、preStop
        • terminationMessagePath
        • terminationMessagePolicy
        • securityContext (和所有子欄位)
        • stdin
        • stdinOnce
        • tty
      • initContainers：與 containers 相同的子欄位。
      • dnsPolicy
      • automountServiceAccountToken
      • hostNetwork
      • hostPID
      • hostIPC
      • shareProcessNamespace
      • securityContext
      • dnsConfig
      • runtimeClassName
      • os
      • hostUsers

  • 硬體相容性：目標 Pod 必須在與檢查點 Pod 具有相同機器系列、CPU 供應商和 CPU 特徵集 (CPUID 旗標) 的節點上執行。舉例來說，兩個節點都必須使用相同的 N2 或 G2 系列，以及相同的 Intel 或 AMD 處理器功能。GKE Sandbox 會先驗證 CPU 功能，再還原程序記憶體和 CPU 狀態，因此具有 whole-pod 範圍的快照無法還原至 CPU 功能不同的節點。

  • 版本相容性：GKE Sandbox 核心版本和 GPU 驅動程式版本，必須與原始快照中的版本相符。

rootfs-only 個範圍相符

使用 rootfs-only 範圍設定政策時 (適用於 GKE 1.35.3-gke.1031000 以上版本)，比對條件較不嚴格：

  • GKE 不會計算或比較精簡 Pod 規格雜湊。這種寬鬆的比對方式可讓您將快照還原至具有不同資源、環境或其他設定欄位的目標 Pod。不過，基礎容器映像檔和節點版本必須相容。
  • 由於程序記憶體不會還原，因此您可以將在某個機器家族上建立的快照，還原至其他機器家族 (包括 E2 機型)。

分組規則比對

如果政策使用 snapshotGroupingRules 欄位，依特定標籤值 (例如租戶或環境) 將快照分組，則還原的 Pod 必須具有相符的標籤鍵和值。Pod 快照控制器只會從相符的群組中選取快照。如要進一步瞭解如何設定分組標籤，請參閱「調整其他 Pod 快照政策設定」。

還原準備度和背景載入

從快照還原 Pod 時，系統會先還原 GKE Sandbox 核心，這通常需要幾秒鐘的時間。為盡可能縮短啟動延遲時間，應用程式會在核心還原後立即恢復。不會等待應用程式記憶體完全載入。應用程式記憶體會使用背景串流機制還原。

如果應用程式嘗試讀取尚未載入的記憶體部分，就會發生頁面錯誤。GKE Sandbox 會攔截這項錯誤、暫停應用程式執行緒，並立即從儲存空間擷取所需的記憶體頁面。這類隨選擷取的優先順序高於背景串流。

由於這項背景載入作業，如果應用程式要求未串流的記憶體，在還原後的前幾秒內，記憶體存取作業可能會出現短暫延遲。記憶體狀態完全同步後，就不會再有這種延遲。

這種背景載入行為也適用於 GPU 狀態。舉例來說，大型語言模型 (LLM) Pod 可能會顯示為 Running 狀態，並回應網路檢查，即使其 GPU 記憶體仍在填入中。在 GPU 狀態完全還原之前，模型不會完全回應推論。由於這項延遲，在評估還原速度時，請務必在模型伺服器準備好處理要求時進行評估。您可以使用首個詞元生成時間 (TTFT) 或 Pod 就緒狀態探測等指標，驗證模型伺服器是否就緒。

GPU 狀態

Pod 快照支援擷取 GPU 狀態。為使用 GPU 的 Pod 觸發快照時，NVIDIA cuda-checkpoint 工具會將 GPU 狀態儲存至程序記憶體。這個步驟可確保快照包含儲存在 GPU 上的資料，例如模型權重。GKE 會暫停 Pod 並建立快照。還原期間，GKE 會反向執行這項作業。

由於 GPU 狀態會寫入程序記憶體，因此在快照和還原作業期間，Pod 記憶體用量會增加。為 Pod 設定記憶體限制時，請考量這項額外記憶體需求。

還原 Pod 的注意事項

從 Kubernetes API 的角度來看，系統會建立新的 Pod 物件。Pod 啟動時，如果 Pod 有對應的快照，GKE 會從該快照還原 Pod，包括原始記憶體和程序狀態。不過，Pod 狀態的某些部分必須變更，才能做為新的不重複執行個體運作。

還原後，請留意下列狀態變化：

  • 網路介面：還原的 Pod 會收到新的 IP 位址。所有介面和路由都會重新設定。還原時，系統會關閉建立快照時存在的有效網路連線。監聽通訊端、回送連線和 Unix 網域通訊端連線會繼續運作。
  • 主機名稱：還原的 Pod 會採用新身分，並取得新的主機名稱。
  • 壁鐘時間：壁鐘時間會跳到目前時間。
  • 應用程式狀態：每個 Pod 的應用程式狀態必須不重複 (例如實驗 ID 或隨機號碼種子)，且必須在還原後重新初始化。
  • Secret：您必須重新建立在建立快照前建立的加密金鑰和憑證。
  • 環境變數：您可以在建立快照和還原之間變更環境變數。不過，由於環境變數儲存在應用程式記憶體中，GKE Sandbox 無法可靠地找到並取代這些變數。如果工作負載在還原後需要新的環境變數，Pod 必須手動重新整理這些變數。新的環境變數可在 /proc/gvisor/spec_environ 檔案中使用。檔案格式與 /proc/<pid>/environ 相同。

多租戶架構和身分

Pod 快照需要為每個 Pod 的 Kubernetes ServiceAccount 物件手動繫結 Identity and Access Management (IAM)，才能使用 Cloud Storage。手動 IAM 繫結可能需要一些時間才能生效，如果您需要在建立 Pod 後立即建立快照，這可能會造成問題。

為解決延遲問題並簡化多用戶群管理，您可以改用 GKE 節點服務帳戶，視需要建立效期短的權杖，不必手動將 IAM 繫結至 ServiceAccount 物件。如要使用這個方法設定 Pod 快照，請在 PodSnapshotStorageConfig 自訂資源中使用 tokenSource 欄位，並填入下列其中一個值：

  • podKSA (預設)：在 Pod 的 ServiceAccount 物件和 Cloud Storage bucket 之間，使用手動 IAM 繫結。
  • federatedP4SA：使用節點服務帳戶產生的路徑專屬權杖。

需求條件

如要使用 GKE Pod 快照，請確認您符合下列規定：

  • Pod 必須在 GKE Sandbox 中執行，因為 Pod 快照依賴 GKE Sandbox 提供的隔離環境。
  • 如果是預設的 whole-pod 快照範圍，還原 Pod 的節點必須與建立快照的節點具有相同的機器系列、CPU 供應商和 CPU 功能。僅限 CPU 的工作負載可以使用 GKE Sandbox 支援的任何非 E2 機器系列，只要符合這些硬體相容性需求即可。詳情請參閱「限制」一節。
  • 如要搭配使用 GPU 和 Pod 快照，您也必須符合下列規定：
    • 單一 GPU Pod 支援單一 GPU 和多 GPU 節點。
    • 多 GPU Pod 僅支援 L4 GPU (g2-standard-* 機型)。
    • 在 GKE 1.35.0-gke.1738000 以下版本中，在多 GPU 節點上執行的 Pod 必須使用該節點上所有可用的 GPU。在 1.35.0-gke.1738000 以上版本中，Pod 可以使用節點上的部分 GPU。
    • 如果是 GPU 工作負載，則必須使用下列其中一種支援的 GPU 機型：
      • g2-standard-4 (1 個 L4)
      • g2-standard-8 (1 個 L4)
      • g2-standard-12 (1 個 L4)
      • g2-standard-16 (1 個 L4)
      • g2-standard-32 (1 個 L4)
      • g2-standard-48 (4 個 L4)
      • g2-standard-96 (8 個 L4)
      • a2-highgpu-1g (1 個 A100-40GB)
      • a2-ultragpu-1g (1 個 A100-80GB)
      • a3-highgpu-1g (1 個 H100-80GB)

限制

GKE Pod 快照有下列限制：

  • 使用預設的 whole-pod 快照範圍時，如果 Compute Engine VM 的 CPU 功能 (CPUID 旗標) 與建立快照的 VM 不同，則無法將快照還原至該 VM：
    • whole-pod 範圍的 Pod 快照不支援 E2 機器系列，或其他動態混合 Intel 和 AMD 處理器或 CPU 世代的機器系列。檔案系統快照 (rootfs-only 範圍) 支援 E2 機器系列。
    • 即使在同一個非 E2 機器系列和 CPU 供應商中，Compute Engine 也可能佈建具有不同 CPU 平台或個別 VM CPU 特徵集的 VM。如果 Pod 排定在 CPU 功能不相符的節點上，則還原具有 whole-pod 範圍的快照會失敗。
  • 不支援透過多執行個體 GPU (MIG) 共用 GPU。
  • Pod 快照不支援 Cloud Storage FUSE CSI 驅動程式邊車容器。
  • Pod 快照不支援 TPU。

後續步驟