排查 Pod 快照问题

Autopilot Standard

本文档介绍了如何解决 GKE Pod 快照及其关联资源的常见问题。

对于使用 Pod 快照来检查点和恢复工作负载的应用开发者、平台管理员和运维人员来说，此信息非常重要。如需详细了解我们在 Cloud de Confiance by S3NS 内容中提及的常见角色和示例任务，请参阅常见的 GKE 用户角色和任务。

使用 PVC 时检查点后的突变风险

如果您的 Pod 使用永久性卷声明 (PVC)，则在“检查点和恢复”工作流期间会发生重大风险：如果您将工作负载配置为在检查点后立即恢复（通过使用 postCheckpoint: resume 字段），则应用在检查点后仍保持活跃状态，并且可以修改 PVC。

安全关停问题：在检查点和恢复周期之后，当您删除 Pod 时，Kubernetes 会通过向容器中的主进程发送 SIGTERM 信号来启动安全关停序列。许多应用都会实现安全关停逻辑，在此期间，它们可能会触发清理例程，以删除或更新 PVC 上的临时文件。
恢复失败：如果这些更改是在拍摄 Pod 快照后在 PVC 上发生的，恢复过程将期望 PVC 状态与检查点那一刻的状态完全一致，从而可能导致恢复失败或数据不一致。
建议的缓解措施：如果工作负载必须使用 PVC，请不要在检查点后恢复工作负载。在 PodSnapshotPolicy 中使用配置 postCheckpoint: stop。此配置有助于确保进程在检查点创建阶段完成后不会有机会执行辅助写入或状态更改。

ConfigMap 装载和目录屏蔽

将配置数据集成到容器中时，装载方法可能会影响快照的完整性。

如果使用标准卷挂载来挂载 ConfigMap，Kubernetes 会将整个目标目录视为外部挂载。由于在拍摄快照期间会跳过外部装载，因此整个目录都会从快照中排除。

在以下示例中，/etc/my-app/ 目录中的任何更改都不会在快照中捕获，因为整个目录都是外部装载：

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  config.json: |
    {
      "mode": "local"
    }
---
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  runtimeClassName: gvisor
  containers:
    - name: my-app-container
      image: my-app-image
      volumeMounts:
        - mountPath: /etc/my-app
          name: config-volume
  volumes:
    - name: config-volume
      configMap:
        name: my-config

如需解决此问题，请使用 subPath。subPath 有助于确保仅将特定配置文件视为外部装载。此配置以确切的文件为目标，可让父级目录中的其余文件和结构保留在容器的本地文件系统中，并在检查点创建过程中正确捕获。

以下示例展示了使用 subPath 的 volumeMounts 配置：

      volumeMounts:
        - mountPath: /etc/my-app/config.json
          name: config-volume
          subPath: config.json

隐式匿名卷

某些容器映像通过 Dockerfile 中的 VOLUME 指令在其元数据中定义了卷。即使您的 Pod 规范未定义卷，Kubernetes 也会自动为基本映像中定义为卷的任何路径创建匿名卷。例如，alpine/git 映像将 /git 定义为隐式卷。

这些匿名卷会被视为外部装载，并且与 PVC 一样，不会进行检查点设置。检查基本映像，确保关键数据未存储在隐式卷中。