2026-09-28
每日一文 · 长文精读
GKE Pod Snapshots Cut Model Load Times, and Move the Work to Snapshot Lifecycle Management
GKE Pod 快照缩短模型加载时间，并将工作转移到快照生命周期管理
作者：Steef-Jan Wiggers · InfoQ 原文
摘要：Google 发布 GKE Pod 快照基准测试，显示启动延迟最高降低 89%，70B 模型 37 秒加载，8B 模型 15 秒。该功能保存工作负载状态并按需恢复，五月正式可用。文章介绍其工作原理（基于 gVisor，需在 GKE Sandbox 运行）、配置、客户案例（Codeway 启动时间从一分钟降至 8 秒），以及社区对快照失效和重新水化的关注。还讨论硬件限制、治理问题、Agent Sandbox 与 Agent Substrate 的区别，并指出团队需管理快照生命周期。
Google has published benchmark results for GKE Pod snapshots, reporting startup latency reductions of as much as 89%, with a 70B parameter model loading in 37 seconds and an 8B model in 15 seconds.
Google 发布了 GKE Pod 快照的基准测试结果，报告启动延迟最高降低 89%，70B 参数模型加载需 37 秒，8B 模型需 15 秒。
The feature saves the running state of a workload, including CPU and GPU memory, and restores it on demand.
该功能保存工作负载的运行状态（包括 CPU 和 GPU 内存），并按需恢复。
It reached general availability in May on clusters running version 1.35.3-gke.1234000 or later.
它于五月在运行 1.35.3-gke.1234000 或更高版本的集群上正式可用。
This is checkpoint and restore, not caching.
这是检查点与恢复，而非缓存。
The snapshot holds everything the application had running: open file descriptors, threads, CPU registers, memory.
快照保存了应用程序运行时的所有状态：打开的文件描述符、线程、CPU 寄存器、内存。
It never runs the initialization that loads the model, which is where most of the startup time goes on large models.
它从不运行加载模型的初始化过程，而大型模型的启动时间主要消耗在此。
gVisor is what makes that possible, and it comes with a condition.
gVisor 使这一切成为可能，但它附带一个条件。
Pods have to run in GKE Sandbox, since that is where the gVisor runtime lives.
Pod 必须在 GKE Sandbox 中运行，因为那是 gVisor 运行时的所在。
Standard clusters need a node pool with gVisor turned on.
标准集群需要启用 gVisor 的节点池。
An agent on each node handles the snapshot lifecycle.
每个节点上的代理处理快照生命周期。
Two custom resources do the configuring.
两个自定义资源负责配置。
Google's customer example is Codeway.
Google 的客户示例是 Codeway。
Lead DevOps engineer Ahmet Furkan Çomak said Pod snapshots cut that to "just 8 seconds".
首席 DevOps 工程师 Ahmet Furkan Çomak 表示，Pod 快照将其缩短到“仅 8 秒”。
Practitioner reaction has centered less on the capture than on what happens afterward.
从业者的反应更多集中在捕获之后的事情，而非捕获本身。
Responding to a LinkedIn analysis of the release by Suresh Rajashekaraiah, Mohana Narasimha G., a senior DevOps and MLOps engineer, wrote:
针对 Suresh Rajashekaraiah 对此次发布的 LinkedIn 分析，高级 DevOps 和 MLOps 工程师 Mohana Narasimha G. 写道：
The restore path is compelling, but I suspect snapshot invalidation will be the harder platform problem than capture itself.
恢复路径很吸引人，但我怀疑快照失效将是比捕获本身更难的平台问题。
Are you treating snapshots as immutable artifacts with an admission check before scheduling?
你们是否将快照视为不可变工件，并在调度前进行准入检查？
Google's documentation answers the first half of that.
Google 的文档回答了前一半问题。
GKE builds a hash from the Pod's essential runtime fields, which it calls the distilled Pod spec, and embeds it in the snapshot; a Pod restoring from it must produce an identical hash.
GKE 从 Pod 的基本运行时字段构建一个哈希，称为精简 Pod 规范，并将其嵌入快照中；从中恢复的 Pod 必须产生相同的哈希。
The target node must have an identical machine series and CPU architecture (N2 to N2 or G2 to G2), and the gVisor kernel version and GPU driver version must match those captured.
目标节点必须具有相同的机器系列和 CPU 架构（N2 到 N2 或 G2 到 G2），并且 gVisor 内核版本和 GPU 驱动程序版本必须与捕获时的版本匹配。
A rootfs-only scope relaxes the rules.
仅根文件系统（rootfs-only）范围放宽了规则。
The rehydration half remains with the application, and the documentation is specific about it.
重新水化（rehydration）的一半责任在于应用程序，文档对此有具体说明。
Encryption keys and certificates created before a snapshot must be re-created afterward, since the restored process resumes holding what it held when frozen.
快照前创建的加密密钥和证书必须在之后重新创建，因为恢复的进程会继续持有冻结时所持有的内容。
Environment variables live in application memory, where gVisor cannot reliably find and replace them, so a workload depending on new values has to read them from a file at /proc/gvisor/spec_environ.
环境变量存在于应用程序内存中，gVisor 无法可靠地查找和替换它们，因此依赖新值的工作负载必须从 /proc/gvisor/spec_environ 文件读取它们。
External connections are terminated on restore, persistent volumes are not checkpointed, and user-added iptables or nftables rules and routes are not restored.
外部连接在恢复时终止，持久性卷不会被检查点化，用户添加的 iptables 或 nftables 规则和路由不会被恢复。
If that reaction is representative, the work moves to managing snapshots rather than turning the feature on.
如果这种反应具有代表性，那么工作就转向管理快照，而非仅仅开启该功能。
Upgrade a node pool and the gVisor kernel or GPU driver version may change.
升级节点池后，gVisor 内核或 GPU 驱动程序版本可能会改变。
Existing snapshots no longer match.
现有快照不再匹配。
The Pod then starts normally, per the documented fallback, and nothing errors.
Pod 随后正常启动，按照文档中的回退机制，不会出错。
The benefit is just gone.
好处就这么消失了。
Restore is not instant either, whatever the headline numbers suggest.
恢复也并非即时，无论标题数字如何暗示。
Hardware support is narrower than the framing suggests: whole-pod snapshots do not work on E2 machine types, multi-GPU Pods are supported only on L4 GPUs, and GPU sharing with Multi-Instance GPU is not supported.
硬件支持比宣传的更窄：整 Pod 快照在 E2 机器类型上不起作用，多 GPU Pod 仅支持 L4 GPU，并且不支持与 Multi-Instance GPU 共享 GPU。
The governance question follows from what a snapshot contains.
治理问题源于快照所包含的内容。
Access rests on Workload Identity Federation and IAM bindings for each Pod's service account, which Google notes can take time to propagate.
访问依赖于 Workload Identity Federation 和每个 Pod 服务账户的 IAM 绑定，Google 指出这可能需要时间才能传播。
GKE Agent Sandbox reached general availability in May, with a warm pool Google says allocates up to 300 sandboxes per second per cluster, 90% of them within 200 milliseconds, and it uses Pod snapshots to suspend idle agents rather than hold compute warm.
GKE Agent Sandbox 于五月正式可用，其 warm pool 据 Google 称每个集群每秒可分配多达 300 个沙箱，其中 90% 在 200 毫秒内完成，并且它使用 Pod 快照来挂起空闲代理，而不是保持计算预热。
Agent Substrate, the open-source project Google introduced at the same time, explores the same suspend and resume multiplexing at higher density, and its repository states it is not ready for production.
Agent Substrate 是 Google 同时引入的开源项目，探索更高密度的相同挂起和恢复复用，其仓库声明尚未准备好用于生产。
Meet Shah, AVP of cloud platform and AI engineering, who drew the line between them:
云平台和 AI 工程副总裁 Meet Shah 划定了两者之间的界限：
Agent Sandbox GA is the foundation you can plan against for secure execution.
Agent Sandbox GA 是你可以规划安全执行的基础。
Google describes the feature as workload-agnostic, naming Java applications, game servers and legacy monoliths alongside AI inference.
Google 将该功能描述为与工作负载无关，列举了 Java 应用程序、游戏服务器和传统单体应用以及 AI 推理。
The decisions it leaves to teams are which node pools run gVisor, which bucket holds the snapshots and who can read it, how long snapshots persist, and what the workload refreshes when it resumes from a state it did not expect to be frozen in.
它留给团队的决定包括：哪些节点池运行 gVisor、哪个桶保存快照以及谁可以读取、快照保留多长时间，以及工作负载从意外冻结状态恢复时需要刷新哪些内容。
阅读理解
1. What is the primary benefit of GKE Pod Snapshots according to the article?
2. According to Mohana Narasimha G., what is the harder platform problem?
3. What happens when a node pool is upgraded and the gVisor kernel version changes?