用途：诊断和预测 GKE 集群中 GPU/TPU 节点在 Compute Engine 主机维护期间发生的中断，判断中断是否由主机维护引起。
主要能力：按诊断流程分步排查。先检查节点是否带有即将维护的标签，命令为 kubectl get nodes -l cloud.google.com/scheduled-maintenance-time -L cloud.google.com/scheduled-maintenance-time，SCHEDULED-MAINTENANCE-TIME 列显示 Unix 时间戳，存在该标签即表示必然发生中断。再通过 Cloud Monitoring 的 PromQL 查询历史中断，例如 kubernetes_io:node_interruption_count{monitored_resource="k8s_node", interruption_reason="HW/SW Maintenance"}，值大于 0 即确认主机维护为原因；也可按节点池聚合查询。随后通过日志和节点状态检查进行中的维护，关注 cloud.google.com/active-node-maintenance 为 ONGOING 或 cloud.google.com/impending-node-termination:NoSchedule 污点。
使用方式：需提供必填上下文 project_id、location、cluster_name、timestamp，可选 node_name、workload_name、workload_namespace、nodepool_name。四项必填齐全时应立即调用 get_k8s_resource、query_prometheus、query_logs 等诊断工具；缺失时仅向用户索取缺失项。若 query_prometheus 不可用，可把 PromQL 交给用户在控制台手动验证。
适用场景：GPU/TPU 工作负载因主机维护出现中断或需要提前预测中断时。
限制与注意：若未发现计划或历史主机维护证据，应明确结论为中断并非由主机维护引起，不要建议优雅终止或机会性维护。不要容忍 impending-node-termination:NoSchedule 污点，节点仍会被终止。仅在确认或计划维护时建议配置 spec.terminationGracePeriodSeconds（最长 60 分钟）、机会性维护或 PodDisruptionBudget。报告应只给高信号信息，不倾倒原始日志。其他细节暂未提供。