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，并从拍摄快照时的时间点恢复执行。

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

快照内容

下表介绍了 Pod 快照中包含和不包含的内容：

类别 快照中包含的内容 快照中不包含的内容
应用状态 应用状态的全部内容：所有打开的文件描述符、线程、CPU 寄存器和内存。
文件系统 容器根文件系统 (rootfs)、EmptyDir 卷和 tmpfs 装载。 上一列未涵盖的任何内容。最值得注意的是，系统不会对 永久性卷进行检查点操作。
网络 环回连接、监听套接字和 Unix 网域套接字。 系统不会恢复外部连接（恢复时会终止这些连接）。系统不会恢复用户添加的规则（例如 iptables 或 nftables）和路由。

自定义资源定义

Pod 快照使用以下 CRD 以声明方式进行配置：

  • PodSnapshotStorageConfig：指定快照的存储位置。仅支持 Cloud Storage 存储分区 。
  • PodSnapshotPolicy：根据 Kubernetes 标签选择器定义要拍摄快照的 Pod。此资源包含该功能的大部分配置选项，包括如何触发快照和保留政策。
  • PodSnapshotManualTrigger：（可选）如果未使用工作负载触发器，则定义手动触发器以针对特定 Pod 创建快照。

快照触发器

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

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

快照匹配

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

精简操作仅保留关键运行时字段（例如 image），同时移除非必要字段（例如 nodeName 或 nodeSelector），从而简化 Pod 规范。您必须确保用于检查点的 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 找到兼容的快照，则 GKE 会从该快照恢复新 Pod。如果不存在兼容的快照，则 Pod 会正常启动。

恢复就绪状态和后台加载

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

如果应用尝试访问尚未加载的内存部分，则会发生页面错误。gVisor 会拦截此错误，暂停应用线程，并立即从存储空间提取所需的内存页。此按需提取的优先级高于后台流。

由于此后台加载，如果应用需要尚未流式传输的内存，则在恢复后的前几秒钟内，内存访问可能会出现少量延迟。当内存状态完全同步后，此延迟会消失。

此后台加载行为也适用于 GPU 状态。例如，即使大型语言模型 (LLM) Pod 的 GPU 内存仍在填充，它也可能会显示为 Running 状态并响应网络检查。在 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 地址。所有接口和路由都会重新配置。在拍摄快照时存在的活跃网络连接会在恢复时关闭。监听套接字、环回连接和 Unix 网域套接字连接会继续运行。
  • 主机名：恢复的 Pod 会采用新身份并收到新主机名。
  • 实际时间：实际时间会跳到当前时间。
  • 应用状态：应用状态对于每个 Pod 必须是唯一的，例如实验 ID 或随机数种子，并且必须在恢复后重新初始化。
  • Secret ：必须重新创建在拍摄快照之前创建的加密密钥和证书。
  • 环境变量：您可以在快照和恢复之间更改环境变量。但是，由于环境变量存储在应用内存中，因此 GKE Sandbox 无法可靠地查找和替换它们。如果您的工作负载在恢复后依赖于新的环境变量，则 Pod 必须手动刷新这些变量。新的环境变量位于 /proc/gvisor/spec_environ 文件中。文件格式与 /proc/<pid>/environ 相同。

多租户和身份

Pod 快照需要为每个 Pod 的 Kubernetes ServiceAccount (KSA) 手动进行 IAM 绑定，才能访问 Cloud Storage。手动 IAM 绑定可能需要一段时间才能传播，如果您需要在创建 Pod 后立即拍摄快照，这可能会成为一个问题。

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

  • podKSA （默认值）：将 Pod 的 KSA 手动 IAM 绑定到 Cloud Storage 存储桶。
  • federatedP4SA：使用由节点服务帐号生成的路径专用令牌。

限制和要求

GKE Pod 快照存在以下限制：

  • Pod 必须在 GKE Sandbox 中运行，因为 Pod 快照依赖于 GKE Sandbox 提供的 gVisor 容器运行时。
  • Pod 快照不支持 E2 机器类型。
  • Pod 快照的 GPU 支持具有以下要求和限制：
    • 单 GPU Pod 在单 GPU 节点和多 GPU 节点上均受支持。
    • 多 GPU Pod 仅在 L4 GPU（g2-standard-* 机器类型）上受支持。
    • 不支持使用多实例 GPU (MIG) 进行 GPU 共享。
    • 在 GKE 1.35.0-gke.1738000 及更早版本中，在多 GPU 节点上运行的 Pod 必须使用该节点上的所有 GPU。在 1.35.0-gke.1738000 及更高版本中，Pod 可以使用节点上的部分 GPU。
    • Pod 快照支持以下机器类型：
      • 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)
  • 不支持将 Cloud Storage FUSE CSI 驱动程序边车容器与 Pod 快照搭配使用。
  • Pod 快照不支持 TPU 机器类型。

后续步骤