GKE Pod 快照简介

标准

Google Kubernetes Engine (GKE) Pod 快照通过恢复正在运行的 Pod 的快照来帮助缩短工作负载启动延迟时间。Pod 快照会保存整个 Pod 状态，包括内存和文件系统更改。创建新副本时，系统会从快照恢复这些副本，从而使工作负载能够恢复，而不是从新状态开始。

本文档从概念上简要介绍了 GKE Pod 快照。如需了解如何启用和使用此功能，请参阅从 Pod 快照恢复。

何时使用 Pod 快照

对于初始化时间较长的工作负载，请使用 Pod 快照，例如将大型模型加载到 CPU 或 GPU 内存中的 AI 推理工作负载，或加载许多库和依赖项的大型应用。启动时间已经很短的工作负载通常不会受益于 Pod 快照。

Pod 快照的工作原理

GKE Pod 快照用于存储 Pod 在特定时间点的确切进程状态副本。创建新副本时，Pod 不会从全新状态进行初始化，而是从快照恢复，并从拍摄快照时开始恢复执行。

如需使用 Pod 快照，您需要创建 Kubernetes 自定义资源定义 (CRD) 以声明性方式配置快照行为。在每个 GKE 节点上运行的代理会管理快照生命周期。根据您定义的政策，代理会确定何时创建新快照，以及何时使用现有快照来恢复新 Pod。在 GKE 控制平面上运行的控制器会清理过时的快照并解决问题。Cloud Storage 会存储您的 Pod 快照。

自定义资源定义

Pod 快照通过两个 CRD 以声明方式进行配置：

PodSnapshotStorageConfig：指定快照的存储位置。仅支持 Cloud Storage 存储桶。
PodSnapshotPolicy：根据 Kubernetes 标签选择器定义要拍摄快照的 Pod。此资源包含该功能的大部分配置选项，包括快照触发器和保留政策。

快照匹配

Pod 匹配用于确定 Pod 快照是否与特定 Pod 兼容。这种匹配是通过从 Pod 的基本运行时规范（也称为精简 Pod 规范）创建唯一哈希来实现的。然后，此哈希会嵌入到 Pod 快照中。为了使后续 Pod 可以从该 Pod 快照恢复，它必须从自己的精简 Pod 规范中生成相同的哈希。此过程有助于确保检查点 Pod 和恢复的 Pod 在运行时配置方面完全相同。

精简通过仅保留关键的运行时字段（例如 image）来简化 Pod 规范，同时移除 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 地址。所有网络接口和路由都会重新配置。在拍摄快照时存在的有效网络连接会在恢复时关闭。监听套接字继续正常运行。
主机名：恢复的 Pod 会采用新身份并接收新主机名。
应用状态：必须为每个 Pod 保持唯一性的应用状态（例如实验 ID 或随机数种子）必须在恢复后重新初始化。
Secret：在拍摄快照之前创建的加密密钥和证书必须重新创建。
环境变量：您可以在快照和恢复之间更改环境变量。不过，由于环境变量存储在应用内存中，因此 GKE 沙盒无法可靠地查找和替换它们。如果工作负载在恢复后依赖于新的环境变量，则必须手动刷新 Pod。新环境变量可在 /proc/gvisor/spec_environ 文件中使用。文件格式与 /proc/<pid>/environ 相同。

恢复后发生变化的状态

恢复时不会保留所有状态。Pod 状态的以下部分会发生变化，以便 Pod 可以采用新身份：

网络接口：恢复的 Pod 会收到新的 IP 地址。所有接口和路由都会重新配置。在恢复时，系统会关闭快照拍摄时存在的有效网络连接。监听套接字、环回连接和 Unix 网域套接字连接会继续正常运行。
主机名：恢复的 Pod 会采用新身份并接收新主机名。
实际用时：实际用时会跳到当前时间。

限制和要求

GKE Pod 快照具有以下限制：

Pod 必须在 GKE Sandbox 中运行，因为 Pod 快照依赖于 GKE Sandbox 提供的 gVisor 容器运行时。
Pod 快照不支持 E2 机器类型。
Pod 快照适用于单 GPU Pod。仅支持以下多 GPU 配置：
- 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 x A100-40GB)
- a2-ultragpu-1g（1 个 A100-80GB）
- a3-highgpu-1g（1 个 H100-80GB）
不支持部分 GPU 使用。如果节点有多个 GPU，Pod 必须使用所有这些 GPU。例如，您无法在四 GPU 机器上使用 Pod 快照来处理四个 Pod，每个 Pod 使用一个 GPU。
不支持将 Cloud Storage FUSE CSI 驱动程序边车容器与 Pod 快照搭配使用。

后续步骤

如需了解如何使用 Pod 快照，请参阅从 Pod 快照恢复。