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