Google 会使用 AI 技术将内容翻译成您偏好的语言。AI 翻译可能包含错误。

GKE Pod 快照简介

Autopilot Standard

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

本文档可帮助您了解 GKE Pod 快照的工作方式，并评估您的工作负载是否可以从中受益。

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

如需准备并使用集群中的 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 架构（例如，从 N2 到 N2，或从 G2 到 G2）。
版本兼容性：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 后立即拍摄快照，这可能会成为问题。

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

podKSA（默认）：使用 Pod 的 ServiceAccount 对象与 Cloud Storage 存储桶之间的手动 IAM 绑定。
federatedP4SA：使用由节点服务账号铸造的特定于路径的令牌。

要求

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

Pod 必须在 GKE Sandbox 中运行，因为 Pod 快照依赖于 GKE Sandbox 提供的隔离环境。
如需将 GPU 与 Pod 快照搭配使用，您必须满足以下要求：
- 单 GPU Pod 在单 GPU 节点和多 GPU 节点上均受支持。
- 多 GPU Pod 仅在 L4 GPU（g2-standard-* 机器类型）上受支持。
- 在 GKE 版本 1.35.0-gke.1738000 及更低版本中，在多 GPU 节点上运行的 Pod 必须使用该节点上的所有可用 GPU。在 1.35.0-gke.1738000 及更高版本中，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 个 A100-40GB）
  - a2-ultragpu-1g（1 个 A100-80GB）
  - a3-highgpu-1g (1 x H100-80GB)

限制

GKE Pod 快照具有以下限制：

使用默认 whole-pod 快照范围时，Pod 快照不支持 E2 机器类型。文件系统快照 (rootfs-only) 支持 E2 机器类型。
不支持使用多实例 GPU (MIG) 进行 GPU 共享。
Cloud Storage FUSE CSI 驱动程序边车容器不支持 Pod 快照。
Pod 快照不支持 TPU。

后续步骤

了解如何为 Pod 快照做好准备。

GKE Pod 快照简介 使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。