關於 GKE Pod 快照

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

本文提供 GKE Pod 快照的概念總覽。如要瞭解如何啟用及使用這項功能，請參閱「從 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) 和路線。

自訂資源定義

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

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

快照觸發條件

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

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

快照比對

Pod 比對會判斷 Pod 快照是否與特定 Pod 相容。方法是從 Pod 的基本執行階段規格 (也稱為精簡 Pod 規格) 建立專屬雜湊值，然後將這個雜湊值嵌入 Pod 快照中。如要從這個 Pod 快照還原後續的 Pod，必須從自己的精簡 Pod 規格產生相同的雜湊。這個程序有助於確保檢查點和還原的 Pod 在執行階段設定中完全相同。

蒸餾程序會簡化 Pod 規格，只保留重要的執行階段欄位 (例如 image)，並移除不必要的欄位 (例如 nodeName 或 nodeSelector)。您必須確保用於檢查點的 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

如要視為相容的快照，必須符合下列額外條件：

  • 硬體：新 Pod 必須在節點上執行，且該節點的機器系列和架構與原始 Pod 相同。機器系列和架構必須相同。CPU 數量和記憶體大小可能會變更。E2 機型不支援動態基礎架構。
  • 版本管理：gVisor 核心版本和 GPU 驅動程式版本必須相符。

GKE 會管理快照相容性。如果 GKE 找到相容的快照，就會從該快照還原新的 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 容器執行階段。
  • Pod 快照不支援 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)
  • 不支援搭配使用 Cloud Storage FUSE CSI 驅動程式邊車容器與 Pod 快照。
  • Pod 快照不支援 TPU 機型。

後續步驟