Kubernetes Resource Health Status：GPU 和设备故障排查为什么更清晰了？
Kubernetes 1.36 推进 Resource Health Status，帮助运维人员把 Pod 异常与底层设备健康状态关联起来，尤其适合 GPU、网卡和专用加速卡场景。
在传统 Kubernetes 集群里，Pod 崩溃经常只能看到容器退出、节点事件或应用日志。对于 GPU、RDMA 网卡、专用推理卡这类设备，真正的问题可能在驱动、固件、温度、ECC 错误或设备插件层，但这些信息很难直接反映到工作负载状态里。
Resource Health Status 的价值就在这里：它让集群可以把已分配设备的健康信息和 Pod 关联起来。对于运维工程师来说，这意味着排查路径从“猜应用还是节点问题”，变成“先看容器，再看声明资源，再看设备健康”。
运维要关注什么
第一，要把设备监控和 Kubernetes 事件连起来。GPU 节点不能只看 nvidia-smi，还要关注 kubelet、device plugin、DRA driver、Pod event 和监控指标之间是否能互相印证。
第二，要区分“调度失败”和“运行后故障”。调度失败通常和资源声明、配额、节点标签、驱动可用性有关；运行后故障则更可能与设备健康、容器运行时、应用参数或资源争抢有关。
第三，要建立标准化现场保留流程。出现 AI 训练任务失败时，至少保留 Pod YAML、事件、节点状态、设备插件日志、驱动版本、容器运行时版本和最近一次节点维护记录。
推荐排查顺序
- 查看 Pod 事件，确认是否是调度阶段失败。
- 查看节点条件和设备插件 Pod 状态。
- 检查 DRA ResourceClaim 或设备分配记录。
- 对照 GPU/DCGM 指标，确认是否存在温度、显存、ECC 或 XID 错误。
- 检查 kubelet 和容器运行时日志。
- 最后再进入业务容器分析框架日志。
这个顺序的好处是先排基础设施，再排应用。否则很容易让算法同学和运维同学互相等日志，问题却卡在驱动或设备层。
对学习者的意义
未来的 Kubernetes 运维不只是会创建 Deployment 和 Service。AI 基础设施进入生产后，运维人员还要理解设备插件、DRA、GPU 监控、队列调度和资源隔离。Resource Health Status 正是这个方向上的重要能力。