關於 GKE Pod 快照

Google Kubernetes Engine (GKE) Pod 快照可還原執行中的 Pod 快照，藉此縮短工作負載啟動延遲時間。Pod 快照會儲存整個 Pod 狀態，包括記憶體和檔案系統變更。建立新副本時，系統會從快照還原副本，讓工作負載繼續執行，而不是從新狀態開始。

本文將概略介紹 GKE Pod 快照的概念。如要啟用及使用這項功能，請參閱下列文件：

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

Pod 快照的使用時機

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

Pod 快照的運作方式

GKE Pod 快照會儲存 Pod 在特定時間點的程序狀態精確副本。建立新的副本時，系統不會從全新狀態初始化 Pod，而是從快照還原 Pod，並從快照建立時的狀態繼續執行。

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

快照內容

下表說明 Pod 快照包含和不包含的內容：

類別 包含在快照中 未納入快照
應用程式狀態 應用程式的完整狀態：所有開啟的檔案描述元、執行緒、CPU 暫存器和記憶體。
檔案系統 容器根檔案系統 (rootfs)、EmptyDir 磁碟區和 tmpfs 掛接點。 前一欄未涵蓋的任何內容。最重要的是，永久磁碟區不會檢查點。
網路 迴路連線、接聽通訊端和 Unix 網域通訊端。 外部連線不會還原 (還原時會終止連線)。系統不會還原使用者新增的規則 (例如 iptables 或 nftables) 和路徑。

CustomResourceDefinitions

Pod 快照是透過下列 CRD 以宣告方式設定：

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

快照觸發條件

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

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

快照比對和相容性

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

相容性取決於下列規則：

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

whole-pod 範圍比對 (預設)

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

  1. 精簡規格雜湊：GKE 會根據 Pod 規格中的重要執行階段欄位，產生專屬雜湊。如要順利還原，目標 Pod 必須從精簡規格產生相同的雜湊。這項檢查可確保檢查點和還原的 Pod 在執行階段設定中完全相同。

    Pod 物件的下列欄位屬於精簡規格，會影響專屬雜湊：

    • metadata：
      • annotations：僅與 gVisor 執行階段相關的註解 (例如以 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

  2. 硬體相容性：目標 Pod 必須在節點上執行，且該節點的機器系列和 CPU 架構與原始檢查點 Pod 相同 (例如 N2 對 N2，或 G2 對 G2)。

  3. 版本相容性：gVisor 核心版本和 GPU 驅動程式版本必須與原始快照中擷取的版本相符。

rootfs-only 範圍比對

使用 rootfs-only 範圍設定政策時 (適用於 GKE 1.35.3-gke.1031000 以上版本)，相符條件較寬鬆：

  • GKE 不會計算或比較提煉的 Pod 規格雜湊。 只要基礎容器映像檔和節點版本相容，您就能透過這項寬鬆比對功能，將快照還原至資源、環境或其他設定欄位與原始檢查點 Pod 不同的目標 Pod。
  • 由於系統不會還原程序記憶體，因此您可以將在一個機器系列中建立的快照，還原到另一個機器系列 (包括 E2 機器類型)。

分組規則相符

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

還原準備就緒和背景載入狀態

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

如果應用程式嘗試存取尚未載入的記憶體部分，就會發生頁面錯誤。gVisor 會攔截這項錯誤、暫停應用程式執行緒，並立即從儲存空間擷取所需的記憶體頁面。系統會優先處理這項隨選擷取作業，而非背景串流。

由於這項背景載入作業，如果應用程式需要尚未串流的記憶體，還原後的前幾秒記憶體存取作業可能會出現少量延遲。記憶體狀態完全同步後，延遲現象就會消失。

這種背景載入行為也適用於 GPU 狀態。舉例來說，大型語言模型 (LLM) Pod 可能會顯示為 Running 狀態，並回應網路檢查，即使 GPU 記憶體仍在填入資料也是如此。GPU 狀態完全還原後，模型才會完全回應推論要求。因此在測量還原速度時，請務必擷取模型伺服器啟動的時間。您可以使用「第一個權杖的時間」(TTFT) 或 Pod 就緒探測器等指標，檢查模型伺服器何時啟動。

GPU 狀態

Pod 快照支援擷取 GPU 狀態。當您為使用 GPU 的 Pod 觸發快照時，NVIDIA cuda-checkpoint 工具會將 GPU 狀態儲存至程序記憶體。也就是說，儲存在 GPU 上的任何資料 (例如模型權重) 都會包含在快照中。接著，Pod 會暫停並建立快照。還原時，系統會反向執行這項程序。

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

還原 Pod 的注意事項

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

還原後，請注意下列狀態變更：

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

多用戶群架構和身分

Pod 快照需要為每個 Pod 的 Kubernetes ServiceAccount (KSA) 手動繫結 IAM，才能存取 Cloud Storage。手動 IAM 繫結可能需要一段時間才能傳播，如果您需要在建立 Pod 後立即建立快照，這可能會造成問題。

為解決延遲問題並簡化多租戶管理，您可以選擇使用 GKE 節點服務帳戶，視需要建立短期有效權杖，不必再手動將 IAM 繫結至 KSA。如要使用這種方法設定 Pod 快照，請在 PodSnapshotStorageConfig 物件中使用 tokenSource 欄位，並採用下列其中一個值：

  • podKSA (預設)：將 Pod 的 KSA 手動繫結至 Cloud Storage 值區。
  • federatedP4SA：使用節點服務帳戶鑄造的路徑專屬權杖。

限制與需求

GKE Pod 快照有下列限制：

  • Pod 必須在 GKE Sandbox 中執行，因為 Pod 快照依賴 GKE Sandbox 提供的 gVisor 容器執行階段。
  • 使用預設 whole-pod 快照範圍時，Pod 快照不支援 E2 機器類型。檔案系統快照 (rootfs-only) 支援 E2 機器類型。
  • Pod 快照的 GPU 支援功能有下列規定和限制：
    • 單一 GPU Pod 支援單一 GPU 和多 GPU 節點。
    • 多 GPU Pod 僅支援 L4 GPU (g2-standard-* 機器類型)。
    • 不支援透過多重執行個體 GPU (MIG) 共用 GPU。
    • 在 GKE 1.35.0-gke.1738000 以下版本中，在多 GPU 節點上執行的 Pod 必須使用該節點上的所有 GPU。在 1.35.0-gke.1738000 以上版本中，Pod 可以使用節點上的部分 GPU。
    • Pod 快照支援下列機器類型：
      • g2-standard-4 (1 x L4)
      • g2-standard-8 (1 x L4)
      • g2-standard-12 (1 x L4)
      • g2-standard-16 (1 x L4)
      • g2-standard-32 (1 x L4)
      • g2-standard-48 (4 x L4)
      • g2-standard-96 (8 x L4)
      • a2-highgpu-1g (1 個 A100-40GB)
      • a2-ultragpu-1g (1 個 A100-80GB)
      • a3-highgpu-1g (1 個 H100-80GB)
  • Pod 快照不支援 Cloud Storage FUSE CSI 驅動程式邊車容器。
  • Pod 快照不支援 TPU 機器類型。

後續步驟