存快照恢復」)
GKE Pod 快照把 AI 推理的「冷啟動」變成「內(nèi)存快照恢復」做推理服務的人都有一個共同的痛擴容慢。新副本起來了但它得先把幾十 GB 的模型權(quán)重從存儲讀進 GPU 內(nèi)存 —— 這期間 Pod 是 Running但一個請求都接不了。K8s 的 HPA 看著 Running 就認為擴容成功實際流量打進來全是超時。GKE 的Pod 快照Pod snapshots就是來解決這件事的。它不是加速模型加載而是干脆跳過加載——把一個已經(jīng)跑起來的 Pod 的內(nèi)存狀態(tài)整個存下來新副本直接從這份內(nèi)存快照里醒過來。這篇文章基于 Google 官方文檔把它的機制、邊界、以及幾個很容易踩的坑講清楚。一、它到底做了什么官方定義很直接Pod 快照通過恢復正在運行的 Pod 的快照來縮短工作負載啟動延遲?？煺諘４嬲麄€ Pod 狀態(tài)包括內(nèi)存和文件系統(tǒng)更改。創(chuàng)建新副本時系統(tǒng)從快照恢復這些副本從而讓工作負載恢復resume而不是從新狀態(tài)開始。這里的動詞很關(guān)鍵不是start是resume。官方點名的受益場景就包括把大量權(quán)重加載到內(nèi)存中的 AI 推理模型以及加載大量依賴項的應用。反過來官方也明確說了什么時候沒用啟動時間已經(jīng)很短的工作負載通常不會受益于 Pod 快照。所以別拿它去優(yōu)化一個本來 2 秒就起來的服務 —— 恢復內(nèi)核本身就要幾秒鐘。二、架構(gòu)三個 CRD 三段式分工整套東西是聲明式的由三個自定義資源描述CRD作用PodSnapshotStorageConfig指定快照存儲位置。僅支持 Cloud Storage 存儲桶PodSnapshotPolicy按Kubernetes 標簽選擇器定義要拍快照的 Pod包含大部分配置含觸發(fā)方式、快照范圍、保留政策PodSnapshotManualTrigger可選。不用工作負載觸發(fā)器時用它手動為特定 Pod 創(chuàng)建快照運行時是三段分工每個 GKE 節(jié)點上的代理管理快照生命周期按策略決定何時創(chuàng)建快照、何時用現(xiàn)有快照恢復新 PodGKE 控制平面上的控制器清理過時快照、解決問題Cloud Storage存快照數(shù)據(jù)。三、快照到底存了什么官方原表這張表是全文最實用的部分直接決定你的應用能不能用類別? 已包含? 已排除應用狀態(tài)進程內(nèi)存、執(zhí)行線程、CPU 寄存器、打開文件描述符無捕獲所有內(nèi)存中的進程狀態(tài)文件系統(tǒng)容器根文件系統(tǒng)rootfs、emptyDir卷、tmpfsPersistentVolumeClaim 對象、其他未列出的卷/存儲類型網(wǎng)絡環(huán)回連接、監(jiān)聽套接字、Unix 網(wǎng)域套接字活躍的外部連接恢復時關(guān)閉自定義路由—用戶定義的規(guī)則iptables、nftables兩個要特別注意的點emptyDir和 tmpfs 會被存下來但 PVC 不會。如果你把模型權(quán)重放在 PVC 上快照里沒有它 —— 恢復后還得重新讀盤。外部連接在恢復時被關(guān)閉。如果 Pod 里維持著到數(shù)據(jù)庫、到上游服務的長連接恢復后這些連接是斷的應用必須自己能重連。四、兩種觸發(fā)方式別選錯工作負載觸發(fā)器手動觸發(fā)怎么做Pod 內(nèi)的應用主動向 GKE 代理發(fā)信號表明已準備好被快照創(chuàng)建PodSnapshotManualTriggerCR執(zhí)行次數(shù)在工作負載周期中執(zhí)行一次例如就緒狀態(tài)下可按需執(zhí)行任意次適用最適合縮短橫向伸縮的啟動延遲你無法修改應用去發(fā)就緒信號時選型邏輯很清楚如果你的應用能改加一行我準備好了的信號用工作負載觸發(fā)器 —— 這樣每次都是在一個已知良好的狀態(tài)下拍快照。如果應用是第三方的、動不了才退而用手動觸發(fā)。五、?? 最容易踩的坑恢復 ≠ 可用這一節(jié)建議所有做推理服務的人認真看。官方文檔里寫得很清楚但很容易被忽略?；謴瓦^程是這樣的GKE Sandbox 內(nèi)核先恢復—— 通常需要幾秒鐘內(nèi)核一恢復應用立即恢復執(zhí)行不等應用內(nèi)存加載完—— 這是為了最大限度縮短啟動延遲應用內(nèi)存靠后臺流式傳輸慢慢灌如果應用讀到還沒加載的內(nèi)存 → 觸發(fā)缺頁中斷→ GKE Sandbox 攔截、暫停該線程、立即從存儲拉取所需內(nèi)存頁這個按需拉取的優(yōu)先級高于后臺流。代價是恢復后的前幾秒內(nèi)存訪問會有短暫延遲等內(nèi)存狀態(tài)完全同步才消失。而最關(guān)鍵的一句是這句 —— 它同樣適用于 GPU大語言模型LLMPod可能看起來處于 Running 狀態(tài)即使其 GPU 內(nèi)存仍在填充中也會響應網(wǎng)絡檢查。在 GPU 狀態(tài)完全恢復之前模型不會完全響應推理。翻譯一下這個陷阱你以為的Pod Running → 可以接流量了 實際上的Pod Running → 網(wǎng)絡探針通了 → 但模型還不響應推理如果你用默認的 **readiness probe就緒探針**做判斷它會誤報就緒—— 探針只是網(wǎng)絡層面通了不代表模型能推理。官方給的解法衡量恢復速度時必須以模型服務器準備好處理請求為準可以用TTFTTime To First Token首次令牌時間或者改Pod 就緒性探針讓它真的能判斷模型是否就緒這件事的實際后果如果你的 HPA 依賴 readiness而 readiness 又誤報那么擴容瞬間打進來的流量會全部超時?？煺帐∠碌募虞d時間可能被這段假就緒窗口吃掉。六、GPU 狀態(tài)是怎么存的GPU 這塊單獨說因為機制不太一樣觸發(fā) GPU Pod 的快照時NVIDIA 的cuda-checkpoint工具會把 GPU 狀態(tài)保存到進程內(nèi)存這樣能確保存在 GPU 上的數(shù)據(jù)比如模型權(quán)重被包含進快照GKE 會暫停 Pod然后拍攝快照恢復時反向執(zhí)行。?? 一個具體的容量陷阱由于 GPU 狀態(tài)會寫入進程內(nèi)存在快照和恢復操作期間Pod 內(nèi)存用量會增加。在為 Pod 設(shè)置內(nèi)存限額時請考慮這一額外的內(nèi)存需求。也就是說你的 memory limit 不能按模型跑起來占多少來設(shè)得留出 GPU 狀態(tài)序列化到內(nèi)存時的那一份。設(shè)得太緊會在拍快照那一刻被 OOM Kill。七、恢復后必須處理的 6 件事從 Kubernetes API 看恢復出來的是一個新的 Pod 對象。有些狀態(tài)必須變才能作為新實例運行#項恢復后1網(wǎng)絡接口收到新 IP所有接口和路由重新配置快照時的外部連接被關(guān)閉監(jiān)聽套接字、環(huán)回、Unix 域套接字正常2主機名采用新身份、新主機名3掛鐘時間跳到當前時間4應用狀態(tài)每個 Pod 的應用狀態(tài)必須唯一例如實驗 ID 或隨機數(shù)種子——必須在恢復后重新初始化5Secret拍攝快照前創(chuàng)建的加密密鑰和證書必須重新創(chuàng)建6環(huán)境變量快照與恢復之間可以改但環(huán)境變量存在應用內(nèi)存里GKE Sandbox無法可靠地找到并替換它們。若恢復后依賴新環(huán)境變量Pod 必須手動刷新新變量可在/proc/gvisor/spec_environ取用格式同/proc/pid/environ第 4 條最容易被忽略。如果你的服務用隨機數(shù)種子、UUID、或者啟動時生成的自增 ID 來區(qū)分實例 ——恢復出來的每個副本都會帶著同一個種子。做 A/B 實驗、做請求去重、做分片路由的這一條會直接出 bug。八、兼容性不是隨便就能恢復能不能從快照恢復取決于一套匹配規(guī)則。whole-pod 范圍默認嚴精簡規(guī)范哈希GKE 從 Pod 規(guī)范的基本運行時字段算出唯一哈希目標 Pod 必須算出相同的哈希。字段范圍包括containersname / image / command / args / workingDir / ports / volumeMounts / securityContext …、initContainers、volumes、dnsPolicy、runtimeClassName等等。硬件兼容目標 Pod 必須在相同機器系列 CPU 架構(gòu)的節(jié)點上 ——N2 只能到 N2G2 只能到 G2。版本兼容GKE Sandbox 內(nèi)核版本和GPU 驅(qū)動程序版本必須與快照捕獲時一致。rootfs-only 范圍松GKE 1.35.3-gke.1031000不計算、不比較精簡 Pod 規(guī)范哈?！?可以恢復到資源、環(huán)境或其他配置字段不同的目標 Pod底層容器映像和節(jié)點版本仍須兼容因為不恢復進程內(nèi)存可以跨機器系列恢復包括 E2。這就是兩個范圍的核心取舍whole-podrootfs-only恢復內(nèi)容進程內(nèi)存 文件系統(tǒng)只有文件系統(tǒng)匹配嚴格度嚴哈希 機器系列 內(nèi)核/驅(qū)動版本松跨機器系列??含 E2加速效果跳過模型加載只省掉文件系統(tǒng)準備如果你要的是跳過幾十 GB 權(quán)重加載必須用 whole-pod—— rootfs-only 不恢復進程內(nèi)存GPU 里的權(quán)重還得重新灌。九、硬性要求清單要跑起來這些條件一條都不能少項要求集群版本1.35.3-gke.1234000 或更高身份必須啟用Workload Identity Federation for GKEAutopilot 默認啟用沙箱Pod 必須在 GKE Sandbox 中運行快照依賴它提供的隔離環(huán)境。Autopilot 默認支持Standard 需創(chuàng)建或更新節(jié)點池GPU 支持范圍單 GPU Pod單 GPU / 多 GPU 節(jié)點均支持多 GPU Pod僅 L4g2-standard-*支持的機型g2-standard-4/8/12/16/321×L4、g2-standard-484×L4、g2-standard-968×L4、a2-highgpu-1g1×A100-40GB、a2-ultragpu-1g1×A100-80GB、a3-highgpu-1g1×H100-80GB啟用命令# Autopilot新建集群gcloud container clusters create-auto CLUSTER_NAME\--enable-pod-snapshots\--locationCONTROL_PLANE_LOCATION\--cluster-versionCLUSTER_VERSION# 已有集群先把版本升上去再開啟gcloud container clusters upgrade CLUSTER_NAME\--cluster-versionCLUSTER_VERSION\--locationCONTROL_PLANE_LOCATION gcloud container clusters update CLUSTER_NAME\--enable-pod-snapshots\--locationCONTROL_PLANE_LOCATION十、限制清單選型前先看這個限制說明E2 機型默認whole-pod 范圍不支持 E2文件系統(tǒng)快照rootfs-only支持MIG不支持多實例 GPUMIG共享Cloud Storage FUSE CSI邊車容器不支持Pod 快照TPU不支持Autopilot 默認機型GKE可能默認用不支持快照的機器類型。用 whole-pod 時官方建議用自定義 ComputeClass優(yōu)先兼容機型Autopilot 那條有個現(xiàn)成的坑你什么都不配Autopilot 可能給你調(diào)度到 E2 上然后快照功能直接不可用。官方的做法是定義一個ComputeClassapiVersion:cloud.google.com/v1kind:ComputeClassmetadata:name:non-e2-classspec:priorities:-machineFamily:n2-machineFamily:c3activeMigration:optimizeRulePriority:falsewhenUnsatisfiable:DoNotScaleUp然后在 Pod 里引用spec:nodeSelector:cloud.google.com/compute-class:non-e2-classwhenUnsatisfiable: DoNotScaleUp的意思是寧可擴容失敗也不要調(diào)度到不兼容的機器上。十一、多租戶場景的一個延遲問題如果你是多租戶每個租戶一個 ServiceAccount這里有個坑Pod 快照需要為每個 Pod 的 Kubernetes ServiceAccount 手動創(chuàng)建 IAM 綁定才能使用 Cloud Storage。手動 IAM 綁定可能需要一段時間才能傳播——如果你需要在創(chuàng)建 Pod 后立即拍攝快照這可能會成為問題。解法不用手動綁定改用節(jié)點服務賬號按需鑄造短期令牌。在PodSnapshotStorageConfig里用tokenSource字段取值行為podKSA默認Pod 的 ServiceAccount 與 Cloud Storage 存儲桶之間的手動 IAM 綁定federatedP4SA由節(jié)點服務賬號鑄造的、特定于路徑的令牌多租戶規(guī)模大的話federatedP4SA能省掉IAM 傳播等待這一環(huán)。小結(jié)把 GKE Pod 快照的要點濃縮成幾句它加速的不是加載是恢復—— 把已運行 Pod 的內(nèi)存整個存下來新副本從內(nèi)存快照 resume而不是 start。最大的坑是Running ≠ 可用—— 官方明說 LLM Pod 可能在 GPU 內(nèi)存還沒填滿時就響應網(wǎng)絡檢查默認 readiness 探針會誤報。必須用 TTFT 或能真正反映模型就緒的探針。GPU 狀態(tài)會寫進進程內(nèi)存會吃內(nèi)存限額—— 設(shè) memory limit 時要留出余量否則拍快照那一刻會被 OOM。whole-pod 與 rootfs-only 是兩條路—— 想跳過權(quán)重加載只能用 whole-pod但它匹配嚴格機器系列、內(nèi)核、驅(qū)動版本都要一致且不支持 E2。它不是萬能加速器—— 啟動本來就快的工作負載、TPU、MIG 共享、Cloud Storage FUSE 邊車都不適用。一句話選型如果你的痛點是幾十 GB 權(quán)重每次擴容都要重灌這個功能值得評估如果只是Pod 調(diào)度慢那不是它解決的問題。參考資料內(nèi)容來源核驗時間快照機制、包含/排除內(nèi)容、觸發(fā)方式、兼容性匹配、后臺加載、GPU 狀態(tài)、恢復后差異、要求與限制GKE Pod 快照簡介官方文檔 · 簡體中文2026-10-07集群版本要求、Workload Identity Federation、啟用命令、ComputeClass 示例準備使用 Pod 快照官方文檔 · 簡體中文2026-10-07CRD 字段參考PodSnapshot CustomResourceDefinition 參考文檔2026-10-07說明本文未引用任何第三方基準數(shù)字。InfoQ 有一篇帶性能數(shù)據(jù)的報道但其頁面返回HTTP 405人機驗證未能核對原文故不使用。標簽云原生/kubernetes、人工智能摘要≤256 字GKE Pod 快照通過保存正在運行 Pod 的完整內(nèi)存與文件系統(tǒng)狀態(tài)讓新副本從快照 resume 而非重新初始化用于緩解 AI 推理等重加載工作負載的擴容延遲。本文基于 Google 官方文檔梳理三個 CRD 的分工、快照包含與排除的內(nèi)容、工作負載觸發(fā)與手動觸發(fā)兩種方式、whole-pod 與 rootfs-only 兩種范圍的兼容性差異并重點說明三個易踩的坑 —— LLM Pod 可能顯示 Running 但 GPU 內(nèi)存未填充完、默認就緒探針會誤報須用 TTFT 衡量、GPU 狀態(tài)寫入進程內(nèi)存會推高內(nèi)存用量。另附集群版本、機型、Sandbox 等硬性要求與限制清單。 GKE Pod 快照：把 AI 推理的「冷啟動」變成「內(nèi)存快照恢復」
GKE Pod 快照把 AI 推理的「冷啟動」變成「內(nèi)存快照恢復」做推理服務的人都有一個共同的痛擴容慢。新副本起來了但它得先把幾十 GB 的模型權(quán)重從存儲讀進 GPU 內(nèi)存 —— 這期間 Pod 是 Running但一個請求都接不了。K8s 的 HPA 看著 Running 就認為擴容成功實際流量打進來全是超時。GKE 的Pod 快照Pod snapshots就是來解決這件事的。它不是加速模型加載而是干脆跳過加載——把一個已經(jīng)跑起來的 Pod 的內(nèi)存狀態(tài)整個存下來新副本直接從這份內(nèi)存快照里醒過來。這篇文章基于 Google 官方文檔把它的機制、邊界、以及幾個很容易踩的坑講清楚。一、它到底做了什么官方定義很直接Pod 快照通過恢復正在運行的 Pod 的快照來縮短工作負載啟動延遲?？煺諘４嬲麄€ Pod 狀態(tài)包括內(nèi)存和文件系統(tǒng)更改。創(chuàng)建新副本時系統(tǒng)從快照恢復這些副本從而讓工作負載恢復resume而不是從新狀態(tài)開始。這里的動詞很關(guān)鍵不是start是resume。官方點名的受益場景就包括把大量權(quán)重加載到內(nèi)存中的 AI 推理模型以及加載大量依賴項的應用。反過來官方也明確說了什么時候沒用啟動時間已經(jīng)很短的工作負載通常不會受益于 Pod 快照。所以別拿它去優(yōu)化一個本來 2 秒就起來的服務 —— 恢復內(nèi)核本身就要幾秒鐘。二、架構(gòu)三個 CRD 三段式分工整套東西是聲明式的由三個自定義資源描述CRD作用PodSnapshotStorageConfig指定快照存儲位置。僅支持 Cloud Storage 存儲桶PodSnapshotPolicy按Kubernetes 標簽選擇器定義要拍快照的 Pod包含大部分配置含觸發(fā)方式、快照范圍、保留政策PodSnapshotManualTrigger可選。不用工作負載觸發(fā)器時用它手動為特定 Pod 創(chuàng)建快照運行時是三段分工每個 GKE 節(jié)點上的代理管理快照生命周期按策略決定何時創(chuàng)建快照、何時用現(xiàn)有快照恢復新 PodGKE 控制平面上的控制器清理過時快照、解決問題Cloud Storage存快照數(shù)據(jù)。三、快照到底存了什么官方原表這張表是全文最實用的部分直接決定你的應用能不能用類別? 已包含? 已排除應用狀態(tài)進程內(nèi)存、執(zhí)行線程、CPU 寄存器、打開文件描述符無捕獲所有內(nèi)存中的進程狀態(tài)文件系統(tǒng)容器根文件系統(tǒng)rootfs、emptyDir卷、tmpfsPersistentVolumeClaim 對象、其他未列出的卷/存儲類型網(wǎng)絡環(huán)回連接、監(jiān)聽套接字、Unix 網(wǎng)域套接字活躍的外部連接恢復時關(guān)閉自定義路由—用戶定義的規(guī)則iptables、nftables兩個要特別注意的點emptyDir和 tmpfs 會被存下來但 PVC 不會。如果你把模型權(quán)重放在 PVC 上快照里沒有它 —— 恢復后還得重新讀盤。外部連接在恢復時被關(guān)閉。如果 Pod 里維持著到數(shù)據(jù)庫、到上游服務的長連接恢復后這些連接是斷的應用必須自己能重連。四、兩種觸發(fā)方式別選錯工作負載觸發(fā)器手動觸發(fā)怎么做Pod 內(nèi)的應用主動向 GKE 代理發(fā)信號表明已準備好被快照創(chuàng)建PodSnapshotManualTriggerCR執(zhí)行次數(shù)在工作負載周期中執(zhí)行一次例如就緒狀態(tài)下可按需執(zhí)行任意次適用最適合縮短橫向伸縮的啟動延遲你無法修改應用去發(fā)就緒信號時選型邏輯很清楚如果你的應用能改加一行我準備好了的信號用工作負載觸發(fā)器 —— 這樣每次都是在一個已知良好的狀態(tài)下拍快照。如果應用是第三方的、動不了才退而用手動觸發(fā)。五、?? 最容易踩的坑恢復 ≠ 可用這一節(jié)建議所有做推理服務的人認真看。官方文檔里寫得很清楚但很容易被忽略?；謴瓦^程是這樣的GKE Sandbox 內(nèi)核先恢復—— 通常需要幾秒鐘內(nèi)核一恢復應用立即恢復執(zhí)行不等應用內(nèi)存加載完—— 這是為了最大限度縮短啟動延遲應用內(nèi)存靠后臺流式傳輸慢慢灌如果應用讀到還沒加載的內(nèi)存 → 觸發(fā)缺頁中斷→ GKE Sandbox 攔截、暫停該線程、立即從存儲拉取所需內(nèi)存頁這個按需拉取的優(yōu)先級高于后臺流。代價是恢復后的前幾秒內(nèi)存訪問會有短暫延遲等內(nèi)存狀態(tài)完全同步才消失。而最關(guān)鍵的一句是這句 —— 它同樣適用于 GPU大語言模型LLMPod可能看起來處于 Running 狀態(tài)即使其 GPU 內(nèi)存仍在填充中也會響應網(wǎng)絡檢查。在 GPU 狀態(tài)完全恢復之前模型不會完全響應推理。翻譯一下這個陷阱你以為的Pod Running → 可以接流量了 實際上的Pod Running → 網(wǎng)絡探針通了 → 但模型還不響應推理如果你用默認的 **readiness probe就緒探針**做判斷它會誤報就緒—— 探針只是網(wǎng)絡層面通了不代表模型能推理。官方給的解法衡量恢復速度時必須以模型服務器準備好處理請求為準可以用TTFTTime To First Token首次令牌時間或者改Pod 就緒性探針讓它真的能判斷模型是否就緒這件事的實際后果如果你的 HPA 依賴 readiness而 readiness 又誤報那么擴容瞬間打進來的流量會全部超時?？煺帐∠碌募虞d時間可能被這段假就緒窗口吃掉。六、GPU 狀態(tài)是怎么存的GPU 這塊單獨說因為機制不太一樣觸發(fā) GPU Pod 的快照時NVIDIA 的cuda-checkpoint工具會把 GPU 狀態(tài)保存到進程內(nèi)存這樣能確保存在 GPU 上的數(shù)據(jù)比如模型權(quán)重被包含進快照GKE 會暫停 Pod然后拍攝快照恢復時反向執(zhí)行。?? 一個具體的容量陷阱由于 GPU 狀態(tài)會寫入進程內(nèi)存在快照和恢復操作期間Pod 內(nèi)存用量會增加。在為 Pod 設(shè)置內(nèi)存限額時請考慮這一額外的內(nèi)存需求。也就是說你的 memory limit 不能按模型跑起來占多少來設(shè)得留出 GPU 狀態(tài)序列化到內(nèi)存時的那一份。設(shè)得太緊會在拍快照那一刻被 OOM Kill。七、恢復后必須處理的 6 件事從 Kubernetes API 看恢復出來的是一個新的 Pod 對象。有些狀態(tài)必須變才能作為新實例運行#項恢復后1網(wǎng)絡接口收到新 IP所有接口和路由重新配置快照時的外部連接被關(guān)閉監(jiān)聽套接字、環(huán)回、Unix 域套接字正常2主機名采用新身份、新主機名3掛鐘時間跳到當前時間4應用狀態(tài)每個 Pod 的應用狀態(tài)必須唯一例如實驗 ID 或隨機數(shù)種子——必須在恢復后重新初始化5Secret拍攝快照前創(chuàng)建的加密密鑰和證書必須重新創(chuàng)建6環(huán)境變量快照與恢復之間可以改但環(huán)境變量存在應用內(nèi)存里GKE Sandbox無法可靠地找到并替換它們。若恢復后依賴新環(huán)境變量Pod 必須手動刷新新變量可在/proc/gvisor/spec_environ取用格式同/proc/pid/environ第 4 條最容易被忽略。如果你的服務用隨機數(shù)種子、UUID、或者啟動時生成的自增 ID 來區(qū)分實例 ——恢復出來的每個副本都會帶著同一個種子。做 A/B 實驗、做請求去重、做分片路由的這一條會直接出 bug。八、兼容性不是隨便就能恢復能不能從快照恢復取決于一套匹配規(guī)則。whole-pod 范圍默認嚴精簡規(guī)范哈希GKE 從 Pod 規(guī)范的基本運行時字段算出唯一哈希目標 Pod 必須算出相同的哈希。字段范圍包括containersname / image / command / args / workingDir / ports / volumeMounts / securityContext …、initContainers、volumes、dnsPolicy、runtimeClassName等等。硬件兼容目標 Pod 必須在相同機器系列 CPU 架構(gòu)的節(jié)點上 ——N2 只能到 N2G2 只能到 G2。版本兼容GKE Sandbox 內(nèi)核版本和GPU 驅(qū)動程序版本必須與快照捕獲時一致。rootfs-only 范圍松GKE 1.35.3-gke.1031000不計算、不比較精簡 Pod 規(guī)范哈?！?可以恢復到資源、環(huán)境或其他配置字段不同的目標 Pod底層容器映像和節(jié)點版本仍須兼容因為不恢復進程內(nèi)存可以跨機器系列恢復包括 E2。這就是兩個范圍的核心取舍whole-podrootfs-only恢復內(nèi)容進程內(nèi)存 文件系統(tǒng)只有文件系統(tǒng)匹配嚴格度嚴哈希 機器系列 內(nèi)核/驅(qū)動版本松跨機器系列??含 E2加速效果跳過模型加載只省掉文件系統(tǒng)準備如果你要的是跳過幾十 GB 權(quán)重加載必須用 whole-pod—— rootfs-only 不恢復進程內(nèi)存GPU 里的權(quán)重還得重新灌。九、硬性要求清單要跑起來這些條件一條都不能少項要求集群版本1.35.3-gke.1234000 或更高身份必須啟用Workload Identity Federation for GKEAutopilot 默認啟用沙箱Pod 必須在 GKE Sandbox 中運行快照依賴它提供的隔離環(huán)境。Autopilot 默認支持Standard 需創(chuàng)建或更新節(jié)點池GPU 支持范圍單 GPU Pod單 GPU / 多 GPU 節(jié)點均支持多 GPU Pod僅 L4g2-standard-*支持的機型g2-standard-4/8/12/16/321×L4、g2-standard-484×L4、g2-standard-968×L4、a2-highgpu-1g1×A100-40GB、a2-ultragpu-1g1×A100-80GB、a3-highgpu-1g1×H100-80GB啟用命令# Autopilot新建集群gcloud container clusters create-auto CLUSTER_NAME\--enable-pod-snapshots\--locationCONTROL_PLANE_LOCATION\--cluster-versionCLUSTER_VERSION# 已有集群先把版本升上去再開啟gcloud container clusters upgrade CLUSTER_NAME\--cluster-versionCLUSTER_VERSION\--locationCONTROL_PLANE_LOCATION gcloud container clusters update CLUSTER_NAME\--enable-pod-snapshots\--locationCONTROL_PLANE_LOCATION十、限制清單選型前先看這個限制說明E2 機型默認whole-pod 范圍不支持 E2文件系統(tǒng)快照rootfs-only支持MIG不支持多實例 GPUMIG共享Cloud Storage FUSE CSI邊車容器不支持Pod 快照TPU不支持Autopilot 默認機型GKE可能默認用不支持快照的機器類型。用 whole-pod 時官方建議用自定義 ComputeClass優(yōu)先兼容機型Autopilot 那條有個現(xiàn)成的坑你什么都不配Autopilot 可能給你調(diào)度到 E2 上然后快照功能直接不可用。官方的做法是定義一個ComputeClassapiVersion:cloud.google.com/v1kind:ComputeClassmetadata:name:non-e2-classspec:priorities:-machineFamily:n2-machineFamily:c3activeMigration:optimizeRulePriority:falsewhenUnsatisfiable:DoNotScaleUp然后在 Pod 里引用spec:nodeSelector:cloud.google.com/compute-class:non-e2-classwhenUnsatisfiable: DoNotScaleUp的意思是寧可擴容失敗也不要調(diào)度到不兼容的機器上。十一、多租戶場景的一個延遲問題如果你是多租戶每個租戶一個 ServiceAccount這里有個坑Pod 快照需要為每個 Pod 的 Kubernetes ServiceAccount 手動創(chuàng)建 IAM 綁定才能使用 Cloud Storage。手動 IAM 綁定可能需要一段時間才能傳播——如果你需要在創(chuàng)建 Pod 后立即拍攝快照這可能會成為問題。解法不用手動綁定改用節(jié)點服務賬號按需鑄造短期令牌。在PodSnapshotStorageConfig里用tokenSource字段取值行為podKSA默認Pod 的 ServiceAccount 與 Cloud Storage 存儲桶之間的手動 IAM 綁定federatedP4SA由節(jié)點服務賬號鑄造的、特定于路徑的令牌多租戶規(guī)模大的話federatedP4SA能省掉IAM 傳播等待這一環(huán)。小結(jié)把 GKE Pod 快照的要點濃縮成幾句它加速的不是加載是恢復—— 把已運行 Pod 的內(nèi)存整個存下來新副本從內(nèi)存快照 resume而不是 start。最大的坑是Running ≠ 可用—— 官方明說 LLM Pod 可能在 GPU 內(nèi)存還沒填滿時就響應網(wǎng)絡檢查默認 readiness 探針會誤報。必須用 TTFT 或能真正反映模型就緒的探針。GPU 狀態(tài)會寫進進程內(nèi)存會吃內(nèi)存限額—— 設(shè) memory limit 時要留出余量否則拍快照那一刻會被 OOM。whole-pod 與 rootfs-only 是兩條路—— 想跳過權(quán)重加載只能用 whole-pod但它匹配嚴格機器系列、內(nèi)核、驅(qū)動版本都要一致且不支持 E2。它不是萬能加速器—— 啟動本來就快的工作負載、TPU、MIG 共享、Cloud Storage FUSE 邊車都不適用。一句話選型如果你的痛點是幾十 GB 權(quán)重每次擴容都要重灌這個功能值得評估如果只是Pod 調(diào)度慢那不是它解決的問題。參考資料內(nèi)容來源核驗時間快照機制、包含/排除內(nèi)容、觸發(fā)方式、兼容性匹配、后臺加載、GPU 狀態(tài)、恢復后差異、要求與限制GKE Pod 快照簡介官方文檔 · 簡體中文2026-10-07集群版本要求、Workload Identity Federation、啟用命令、ComputeClass 示例準備使用 Pod 快照官方文檔 · 簡體中文2026-10-07CRD 字段參考PodSnapshot CustomResourceDefinition 參考文檔2026-10-07說明本文未引用任何第三方基準數(shù)字。InfoQ 有一篇帶性能數(shù)據(jù)的報道但其頁面返回HTTP 405人機驗證未能核對原文故不使用。標簽云原生/kubernetes、人工智能摘要≤256 字GKE Pod 快照通過保存正在運行 Pod 的完整內(nèi)存與文件系統(tǒng)狀態(tài)讓新副本從快照 resume 而非重新初始化用于緩解 AI 推理等重加載工作負載的擴容延遲。本文基于 Google 官方文檔梳理三個 CRD 的分工、快照包含與排除的內(nèi)容、工作負載觸發(fā)與手動觸發(fā)兩種方式、whole-pod 與 rootfs-only 兩種范圍的兼容性差異并重點說明三個易踩的坑 —— LLM Pod 可能顯示 Running 但 GPU 內(nèi)存未填充完、默認就緒探針會誤報須用 TTFT 衡量、GPU 狀態(tài)寫入進程內(nèi)存會推高內(nèi)存用量。另附集群版本、機型、Sandbox 等硬性要求與限制清單。