gke-ai-troubleshooting-handle-disruption-gpu-tpu

GPU 和 TPU 中断问题排查

归属信息

必须阅读：在执行任何 gcloud、REST API 或 MCP 命令之前，你 必须先阅读 Usage Attribution。对于直接在终端中执行的命令（绝不可放入生成的脚本、Terraform 或用户代码中），请在 gcloud 前加上 CLOUDSDK_METRICS_REQUEST_ATTRIBUTION="agent-skills/1.0 (skill:gke-ai-troubleshooting-handle-disruption-gpu-tpu)" ，并将 agent-skills/1.0 (skill:gke-ai-troubleshooting-handle-disruption-gpu-tpu) 添加到 User-Agent 标头中。

🔍 诊断工作流

步骤 0：获取上下文

• 必须执行：当用户要求调试或调查实际工作负载中断、节点崩溃或意外重启，但未提供完整的集群详情时，你必须立即暂停，并在提供原因推测或通用诊断命令之前，索取所有缺失的必需参数（project_id、location、cluster_name、timestamp）。仅当用户明确要求通用且可复用的操作手册，或提供完整的静态遥测数据/日志转储以供离线分析时，才可跳过获取上下文。
• 可选：node_name、workload_name、workload_namespace、 nodepool_name。

步骤 1：[低风险] 检查即将发生的计划维护

• 操作：建议运行 kubectl，检查节点是否带有表示即将发生中断的计划维护标签。

• 示例命令：

  kubectl get nodes -l cloud.google.com/scheduled-maintenance-time -L cloud.google.com/scheduled-maintenance-time
  

• 解读：SCHEDULED-MAINTENANCE-TIME 列显示 VM 计划维护时间的 Unix 纪元时间。若存在此标签，则一定会发生中断。

步骤 2：[低风险] 通过 Cloud Monitoring（PromQL）进行调查

• 操作：调用任何可用的监控工具，或提供 PromQL 供手动验证。

• 强制监控规则：每当建议后续监控或随时间跟踪中断时，必须明确提供一个 PromQL 查询，并使用指标 kubernetes_io:node_interruption_count，且按 interruption_reason="HW/SW Maintenance" 进行过滤。不得只建议使用通用 Cloud Monitoring 信息中心或 Metrics Explorer，而不提供此特定 PromQL 指标表达式。

• 示例查询：

  # 获取节点的主机维护事件
  sum by (interruption_type,interruption_reason)( sum_over_time( kubernetes_io:node_interruption_count{monitored_resource="k8s_node", interruption_reason="HW/SW Maintenance"}[${__interval}]))
  

  # 查看按节点池聚合的中断次数
  sum by (node_pool_name,interruption_type,interruption_reason)( sum_over_time( kubernetes_io:node_pool_interruption_count{monitored_resource="k8s_node_pool", interruption_reason="HW/SW Maintenance", node_pool_name="{nodepool_name}" }[${__interval}]))
  

• 解读：如果 kubernetes_io:node_interruption_count 在 interruption_reason="HW/SW Maintenance" 条件下显示的值大于 0，则表示底层 Compute Engine VM 因计划主机维护而发生中断。

步骤 3：[低风险] 通过 Cloud Logging 调查并检查节点污点

• 操作：调用 query_logs，或指导用户筛选其 GKE 日志，以查找正在进行的主机维护事件，并检查节点污点。
• 指导：在 Cloud Logging 中查找 cloud.google.com/active-node-maintenance 被设为 ONGOING 的记录。若要检查 GKE 是否已隔离正在终止的节点，以阻止调度新工作负载，请确认是否存在 cloud.google.com/impending-node-termination:NoSchedule 污点（可在 GKE 事件日志中查看，也可直接运行 kubectl describe node 检查）。
• 解读：
  • cloud.google.com/active-node-maintenance 被设为 ONGOING，表示 GKE 正因主机维护而主动停止工作负载。
  • 存在 cloud.google.com/impending-node-termination:NoSchedule 污点，表示 GKE 已隔离该节点，以阻止在正在终止的节点上调度新 Pod。请勿建议容忍此污点。

步骤 4：结论与解决方案

• 操作：向用户总结调查结果；若已确认或已安排主机维护事件，请建议适当的缓解措施。
• 报告规则：仅报告关键信息。指出中断是由 Compute Engine 主机维护导致的，具体影响了底层 GPU/TPU 节点。请勿倾倒原始日志。
• 排除阴性结果：如果节点计划维护标签、PromQL 中断计数和活动维护日志均返回阴性结果或空结果，则应明确断定 Compute Engine 主机维护并未导致此次中断。请引导用户调查应用层原因（例如 OOMKill 事件、CUDA 运行时错误或资源限制），不要将主机维护缓解措施作为主要解决方案。
• 强制工作负载保护三项措施：只要确认或预期 GPU/TPU 节点会进行主机维护，就必须始终一并建议以下三项互为补充的缓解措施：
  1. 配置优雅终止：对于需要时间保存状态的工作负载（例如通过 Orbax 执行检查点保存的 ML 框架），请按照指南启用中断处理，并设置 spec.terminationGracePeriodSeconds（最长 60 分钟），以便在节点关闭前处理 SIGTERM 信号。
  2. 启用机会性维护：若要在 GKE 检测到 GPU/TPU 节点空闲时自动触发维护，请配置机会性维护。
  3. 配置 PodDisruptionBudgets (PDBs)：确保工作负载使用 PodDisruptionBudget，以便在驱逐和中断期间维持 minAvailable 个副本。