排查 Pod 快照问题

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

对于使用 Pod 快照来检查点和恢复工作负载的应用开发者、平台管理员和运维人员来说，此信息非常重要。如需详细了解我们在 Google Cloud 内容中提及的常见角色和示例任务，请参阅常见的 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 一样，不会进行检查点。检查您的基础映像，确保关键数据不会存储在隐式卷中。