GKE Pod 快照简介

Google Kubernetes Engine (GKE) Pod 快照通过恢复正在运行的 Pod 的快照，帮助缩短工作负载启动延迟时间。Pod 快照会保存整个 Pod 状态，包括内存和文件系统更改。当您创建新副本时，它们会从快照中恢复，从而让工作负载恢复运行，而不是从新状态开始。此功能有助于横向伸缩工作负载，例如将大权重加载到内存中的 AI 推理模型或加载大量依赖项的应用。

通过本文档，您可以了解 GKE Pod 快照的工作原理，并评估您的工作负载是否可以从中受益。

平台管理员、运维人员和应用开发者可以使用本文档评估工作负载兼容性、规划快照存储政策，以及了解 GKE 如何管理检查点和恢复。如需详细了解我们在Google Cloud 内容中提及的常见角色和示例任务，请参阅常见的 GKE 用户角色和任务。

如需在集群中准备和使用 Pod 快照，请参阅以下指南：

  1. 准备 Pod 快照
  2. 触发 Pod 快照
  3. 从 Pod 快照恢复工作负载

何时使用 Pod 快照

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

Pod 快照的工作原理

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

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

快照内容

下表列出了 Pod 快照包含和不包含的内容：

类别 已包含 已排除
应用状态
  • 进程内存
  • 执行线程
  • CPU 寄存器
  • 打开的文件描述符
 无（所有内存中进程状态都会被捕获）
文件系统
  • 容器根文件系统 (rootfs)
  • emptyDir 卷
  • tmpfs 个装载
  • PersistentVolumeClaim 对象
  • 未列为包含在内的任何其他卷或存储类型
网络
  • 环回连接
  • 监听套接字
  • Unix 网域套接字
  • 活跃的外部连接（在恢复时关闭）
  • 自定义路由
  • 用户定义的规则（iptables、nftables）

自定义资源

如需以声明方式配置 Pod 快照，请使用以下自定义资源：

  • PodSnapshotStorageConfig：指定快照的存储位置。仅支持 Cloud Storage 存储桶。
  • PodSnapshotPolicy：根据 Kubernetes 标签选择器定义要创建快照的 Pod。此自定义资源包含该功能的大多数配置选项，包括快照的触发方式、快照范围和保留政策。
  • PodSnapshotManualTrigger（可选）：如果您不使用工作负载触发器，请定义一个手动触发器，以便为特定 Pod 创建快照。

如需了解参考规范，请参阅 PodSnapshot CustomResourceDefinition 参考文档。

快照触发器

您可以通过以下方式触发 Pod 快照：

  • 工作负载触发器：Pod 内的应用向 GKE 代理发出信号，表明它已准备好创建快照。此类触发器在工作负载周期内执行一次，例如在工作负载就绪状态下执行。此方法最适合缩短横向伸缩工作负载的启动延迟时间。
  • 手动触发器：您可以通过创建 PodSnapshotManualTrigger 自定义资源，按需为特定 Pod 触发快照。此类触发器可以根据需要执行任意次数。如果您无法修改应用来发出就绪信号，则此方法最适合。

快照匹配和兼容性

为确保快照与恢复的工作负载兼容，GKE 会在原始检查点 Pod 与目标 Pod 之间执行兼容性匹配。

GKE 使用以下规则来确定兼容性：

  • 选择顺序：默认情况下，GKE 会从与 Pod 的命名空间和配置匹配的最新 PodSnapshot 自定义资源中恢复工作负载。
  • 匹配条件：兼容性检查取决于 PodSnapshotPolicy 自定义资源（whole-pod 或 rootfs-only）中配置的快照范围。

whole-pod 范围匹配（默认）

对于具有默认 whole-pod 范围的政策，GKE 会检查以下内容：

  • 提炼的规范哈希：GKE 会根据 Pod 规范中的基本运行时字段生成唯一哈希。为了成功恢复，目标 Pod 必须从其提取的规范中生成相同的哈希。此检查会验证已设置检查点和已恢复的 Pod 在运行时配置方面是否相同。

    Pod 对象中的以下字段是精简规范的一部分，会影响唯一哈希：

    • metadata:
      • annotations：仅与 GKE Sandbox 相关的注解（例如以 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 供应商和 CPU 特征集（CPUID 标志）的节点上运行。例如，两个节点必须使用相同的 N2 或 G2 系列以及相同的 Intel 或 AMD 处理器功能。GKE Sandbox 会在恢复进程内存和 CPU 状态之前验证 CPU 功能，因此具有 whole-pod 范围的快照无法恢复到具有不同 CPU 功能的节点上。

  • 版本兼容性：GKE Sandbox 内核版本和 GPU 驱动程序版本必须与原始快照中捕获的版本一致。

rootfs-only 个范围匹配

使用 rootfs-only 范围（在 GKE 1.35.3-gke.1031000 版及更高版本中提供）配置政策时，匹配要求不那么严格：

  • GKE 不会计算或比较提炼后的 Pod 规范哈希。通过这种宽松匹配，您可以将快照恢复到具有不同资源、环境或其他配置字段的目标 Pod。但是，底层容器映像和节点版本必须兼容。
  • 由于进程内存不会恢复，因此您可以将一个机器家族上创建的快照恢复到其他机器家族（包括 E2 机器类型）。

匹配的分组规则

如果政策使用 snapshotGroupingRules 字段按特定标签值（例如租户或环境）对快照进行分组，则恢复的 Pod 必须具有匹配的标签键和值。Pod 快照控制器仅从匹配组中选择快照。如需详细了解如何设置分组标签，请参阅配置其他 Pod 快照政策设置。

恢复准备状态和后台加载

从快照恢复 Pod 时，系统会先恢复 GKE Sandbox 内核，这通常需要几秒钟的时间。为了最大限度地缩短启动延迟时间，应用会在内核恢复后立即恢复。它不会等待应用内存完全加载。应用内存会使用后台流式传输机制进行恢复。

如果应用尝试读取尚未加载的内存部分，则会发生缺页错误。GKE Sandbox 会拦截此故障，暂停应用线程，并立即从存储空间中提取所需的内存页。这种按需提取的优先级高于后台流。

由于这种后台加载，如果应用请求未流式传输的内存，则在恢复后的前几秒内，内存访问可能会出现短暂的延迟。当内存状态完全同步时，此延迟时间会消失。

这种后台加载行为也适用于 GPU 状态。例如，大语言模型 (LLM) Pod 可能会显示为 Running 状态并响应网络检查，即使其 GPU 内存仍在填充中。在 GPU 状态完全恢复之前，模型无法完全响应推理。由于存在这种延迟，因此在衡量恢复速度时，请务必在模型服务器准备好处理请求时进行衡量。您可以使用首个词元生成时间 (TTFT) 或 Pod 就绪性探测等指标来验证模型服务器就绪情况。

GPU 状态

Pod 快照支持捕获 GPU 的状态。当您为使用 GPU 的 Pod 触发快照时，NVIDIA cuda-checkpoint 工具会将 GPU 状态保存到进程内存中。此步骤有助于确保 GPU 上存储的数据（例如模型权重）包含在快照中。GKE 会暂停 Pod 并创建快照。在恢复期间，GKE 会反向执行此操作。

由于 GPU 状态会写入进程内存，因此在快照和恢复操作期间，Pod 内存用量会增加。在为 Pod 设置内存限制时，请考虑这一额外的内存要求。

恢复的 Pod 的注意事项

从 Kubernetes API 的角度来看，系统会创建一个新的 Pod 对象。 Pod 启动时，如果 Pod 有对应的快照，则 GKE 会从该快照恢复 Pod，包括原始内存和进程状态。不过，Pod 状态的某些方面必须发生变化，才能作为新的唯一实例运行。

请考虑恢复后的以下状态变化：

  • 网络接口：恢复的 Pod 会收到新的 IP 地址。所有接口和路由都会重新配置。在恢复时，快照时存在的活动网络连接会关闭。监听套接字、环回连接和 Unix 网域套接字连接会继续运行。
  • 主机名：恢复的 Pod 会采用新身份并接收新主机名。
  • 实际用时：实际用时会跳到当前时间。
  • 应用状态：每个 Pod 的应用状态必须是唯一的（例如实验 ID 或随机数种子），并且必须在恢复后重新初始化。
  • Secret：必须重新创建在创建快照之前创建的加密密钥和证书。
  • 环境变量：您可以在快照和恢复之间更改环境变量。不过，由于环境变量存储在应用内存中，因此 GKE Sandbox 无法可靠地找到并替换它们。如果您的工作负载在恢复后依赖于新的环境变量，则 Pod 必须手动刷新这些变量。新环境变量可在 /proc/gvisor/spec_environ 文件中找到。文件格式与 /proc/<pid>/environ 相同。

多租户和身份

Pod 快照需要为每个 Pod 的 Kubernetes ServiceAccount 对象手动绑定 Identity and Access Management (IAM)，才能使用 Cloud Storage。手动 IAM 绑定可能需要一些时间才能传播，如果您需要在创建 Pod 后立即创建快照，这可能会是一个问题。

为了解决延迟问题并简化多租户管理，您可以使用 GKE 节点服务账号按需创建短期令牌，而不是手动将 IAM 绑定到 ServiceAccount 对象。如需使用此方法配置 Pod 快照，请在 PodSnapshotStorageConfig 自定义资源中使用 tokenSource 字段，并指定以下值之一：

  • podKSA（默认）：在 Pod 的 ServiceAccount 对象和 Cloud Storage 存储桶之间使用手动 IAM 绑定。
  • federatedP4SA：使用由节点服务账号创建的路径专用令牌。

要求

如需使用 GKE Pod 快照，请确保您满足以下要求：

  • Pod 必须在 GKE Sandbox 中运行，因为 Pod 快照依赖于 GKE Sandbox 提供的隔离环境。
  • 对于默认的 whole-pod 快照范围，Pod 恢复到的节点必须与创建快照的节点具有相同的机器系列、CPU 供应商和 CPU 功能。仅限 CPU 的工作负载可以使用 GKE Sandbox 支持的任何非 E2 机器系列，只要满足这些硬件兼容性要求即可。如需了解详情，请参阅限制。
  • 如需将 GPU 与 Pod 快照搭配使用，您还必须满足以下要求：
    • 单 GPU Pod 在单 GPU 节点和多 GPU 节点上均受支持。
    • 只有 L4 GPU（g2-standard-* 机器类型）支持多 GPU Pod。
    • 在 GKE 1.35.0-gke.1738000 版及更早版本中，在多 GPU 节点上运行的 Pod 必须使用该节点上可用的所有 GPU。在 1.35.0-gke.1738000 及更高版本中，Pod 可以使用节点上的部分 GPU。
    • 对于 GPU 工作负载，您必须使用以下受支持的 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 x A100-80GB)
      • a3-highgpu-1g (1 x H100-80GB)

限制

GKE Pod 快照存在以下限制：

  • 使用默认 whole-pod 快照范围时，快照无法恢复到 CPU 功能（CPUID 标志）与创建快照的虚拟机不同的 Compute Engine 虚拟机上：
    • 具有 whole-pod 范围的 Pod 快照不支持 E2 机器系列，也不支持动态混合 Intel 和 AMD 处理器或 CPU 代系的其他机器系列。文件系统快照（rootfs-only 范围）支持 E2 机器系列。
    • 即使在同一非 E2 机器系列和 CPU 供应商中，Compute Engine 也可能会预配具有不同 CPU 平台或每个虚拟机 CPU 特征集的虚拟机。如果 Pod 被调度到 CPU 特征不匹配的节点上，则恢复具有 whole-pod 范围的快照会失败。
  • 不支持通过多实例 GPU (MIG) 进行 GPU 共享。
  • Pod 快照不支持 Cloud Storage FUSE CSI 驱动程序边车容器。
  • Pod 快照不支持 TPU。

后续步骤