Kubernetes GPU 故障检测与自愈实践指南(初级版)-Kubernetes-Docker中文

本文介绍 Kubernetes 集群中 GPU 硬件故障的检测、诊断和自动恢复方案，综合字节跳动火山、微软 AKS 和 NVIDIA 的公开的一些生产实践，为 AI Infra 工程师和 SRE 提供系统性的故障处理思路。这块实践经验较少，如有出入还请指出。

为什么需要 GPU 故障自愈

在大规模 GPU 集群中运行 AI 训练和推理任务时，硬件故障是不可避免的：

训练中断损失大
一次掉卡可能导致几天甚至几周的训练工作丢失
人工运维成本高
凌晨收到告警，手动登录节点排查，影响睡眠和工作效率
误判影响可用性
过于激进的故障响应会导致健康节点被错误下线
资源浪费严重
故障 GPU 继续分配给新任务，导致任务反复失败

核心目标：在保证集群健康的前提下，最小化对运行中任务的影响，自动化故障发现和恢复流程。

一些常见 GPU 故障

根据生产环境统计，GPU 故障主要分为四类：

故障码查询可以看官网 https://docs.nvidia.com/deploy/xid-errors/analyzing-xid-catalog.html。下面仅仅列举几个常见错误，更多故障现象原因分析可以参考官网。

1. 掉卡故障（最严重）

现象：

GPU 从 nvidia-smi 输出中消失
驱动报告 "GPU has fallen off the bus"
XID 79（ROBUST_CHANNEL_GPU_HAS_FALLEN_OFF_THE_BUS）错误出现在内核日志中

原因：

PCIe 链路不稳定（服务器散热、电源问题）
硬件故障（GPU 本身损坏）
驱动崩溃

影响：使用该 GPU 的所有容器立即失败，训练任务中断

2. 链路故障（多卡训练杀手）

现象：

NVLink 带宽下降
XID 74 （NVLINK_ERROR）错误（NVLink 训练/初始化错误）
多 GPU 通信性能显著降低

原因：

NVLink 物理连接问题
Fabric Manager 配置错误
GPU 拓扑变化

影响：分布式训练性能下降 50% 以上，甚至训练无法收敛

3. 内存故障（数据正确性风险）

XID 类型	含义	是否 ECC 相关	处理建议

XID 92

High single-bit ECC error rate

是

持续监控 & 排查硬件

XID 94

Contained ECC error

是

仅当前应用受影响，可重启应用

XID 95

Uncontained ECC error

是

GPU 必须重置或重启节点

现象：

XID 92、94、95 错误
或者GPU 内存重映射事件
训练 loss 出现 NaN 或异常波动

原因：

硬件内存缺陷
过热
电压不稳定

影响：计算结果不可信，训练可能产生错误的模型

4. 驱动故障（最常见但易恢复）

现象：

NVML API 调用超时或失败
容器运行时报告设备插件错误
Pod 卡在 ContainerCreating 状态

原因：

驱动版本不兼容
内核模块崩溃
Device Plugin 重启

影响：新任务无法调度到该节点，但通常重启服务即可恢复

故障检测方案

核心工具：DCGM Exporter

NVIDIA Data Center GPU Manager (DCGM) 是生产环境 GPU 监控的事实标准。

可以结合下文内容 https://openobserve.ai/blog/how-to-monitor-nvidia-gpu/ 介绍了 OpenObserve 和 DCGM Exporter 相结合的文档。

新工具 NVSentinel

https://github.com/NVIDIA/NVSentinel/

NVSentinel 是 NVIDIA 开源的 面向 Kubernetes GPU 集群的故障检测与自动恢复系统，主要用于提升 GPU 节点的可靠性、可观测性和自愈能力。它可以持续监控节点健康状况，并在检测到硬件或软件故障时自动执行应对措施（例如隔离节点、清空工作负载、触发修复工作流等）。

全面监控：实时检测 GPU、NVSwitch 及系统级故障
自动化修复：智能故障处理，包含电网、排水和故障修复工作流程
模块化架构：可插拔健康监测器，配备标准化 gRPC 接口
高可用性：Kubernetes 原生设计，支持复制品和领导者选举
实时处理：具有即时故障响应的事件驱动架构
持久存储：基于 MongoDB 的事件存储，具有实时更新的变更流
优雅处理：协调工作量驱逐，并可配置超时
元数据丰富：通过云提供商和节点元数据自动增强健康事件

需要注意的是，该项目目前处于 实验预览阶段（experimental preview release），不建议在关键生产环境直接使用，需要在非生产环境充分验证后再评估部署

辅助工具：Node Problem Detector

用于将 GPU 故障转换为 Kubernetes 原生的 NodeCondition。

可以参考 Azure 的实践经验 https://learn.microsoft.com/en-us/azure/aks/gpu-health-monitoring

Kube 社区新工具 Node Readiness Controller

https://github.com/kubernetes-sigs/node-readiness-controller

一个为节点提供细粒度声明准备的 Kubernetes 控制器。它确保节点只有在所有必要组件（如网络代理、GPU 驱动、存储驱动或自定义健康检查）完全准备好时才接受工作负载。

定义工作负载的自定义准备度
根据状态自动污染和清除节点
支持持续准备执行，阻止熔断情景的调度
与现有的问题检测器如 NPD 或任何自定义守护进程/节点插件集成，以实现报告准备度

下面是设计稿中的例子如下：

// Need GPU ready
apiVersion: v1
kind: Pod
metadata: 
 name: gpu-app-1
spec: 
 nodeReadinessRequirements: 
 - conditionType: "network.kubernetes.io/NetworkProxyReady"  
  status: "True" 
 - conditionType: "nvidia.com/GPUDriversReady"  
  status: "True" 
 containers: 
  ...

此外，这个项目和 Draino https://github.com/planetlabs/draino 有一些类似的效果，但是 DRAINO 有五年不更新了。

其他工具

https://github.com/kubernetes-sigs/node-feature-discovery

三层故障语义模型

将底层硬件信号转换为 Kubernetes 可操作的语义，是自愈的关键。

第一层：NodeCondition（节点级）

用途：控制调度器行为，防止新任务被分配到问题节点

标准 Condition 类型：（参考微软 AKS）

GPUHealthy
GPU 子系统整体健康状态
NVLinkHealthy
NVLink 连接状态
GPUDriverHealthy
驱动和 NVML 可用性
GPUMemoryHealthy
ECC 错误在阈值内

触发动作：

自动添加 Taint: gpu.health/unhealthy=true:NoSchedule
调度器过滤该节点
触发告警通知运维团队

第二层：DeviceCondition/DeviceStatus（设备级）

用途：在多 GPU 节点上隔离单个故障 GPU，避免"整机下线"

设计思路：使用 DRA 的 ResourceClaim 的 Device Status 能力：https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#resourceclaim-device-status （1.33 Beta，默认开启），或者创建 GPUDevice CRD 追踪每个 GPU 的健康状态（DRA 方案还不成熟的话，可以尝试这个方案）

收益：

8 卡节点中 1 卡故障，其他 7 卡仍可用
减少"爆炸半径"
支持 MIG 场景的细粒度隔离

第三层：WorkloadCondition（作业级）

用途：将硬件故障映射到训练框架语义，支持自动重试/恢复

与训练框架集成, 这个方向我没有具体实践，这里是一个设想

自动替换故障 worker
利用弹性训练机制继续
利用一些原地重启能力触发任务全部 Pod 重启或者重调度

渐进式自愈策略

核心原则：从低影响到高影响逐步升级，每一步都有验证和回滚机制。

六级自愈动作（设想）

级别  动作                    影响范围        恢复时间    风险
------------------------------------------------------------------
L0   检测告警                无              -           无
L1   Cordon + Taint         新调度阻止      < 1 分钟     极低
L2   重启服务               设备插件重启    1-2 分钟     低
     (device-plugin/
      DRA)
L3   设备隔离               单 GPU 下线     < 1 分钟     低
L4   GPU Reset             使用该 GPU 的    5-10 分钟    中
     (nvidia-smi -r)       容器被杀
L5   Node Drain + Reboot   整个节点下线    10-30 分钟   高
L6   节点替换               节点永久下线    数小时       高

策略引擎关键要素

1. 多信号融合（避免误判）

下面是一些小例子

XID 79 出现 + nvidia-smi 失败 + DCGM 健康检查失败
→ 置信度 0.99 → 立即执行 L1 (Cordon)

ECC 错误数上升但 < 阈值
→ 置信度 0.6 → 仅告警监控

2. 迟滞与冷却（避免抖动）

故障需持续 5 分钟才升级到 Unhealthy（类似 kubelet 和 KCM 标注节点状态的逻辑）
执行动作后 30 分钟内不再对同一节点执行相同动作
短时 XID 尖峰进入 Suspect 状态观察

3. 爆炸半径控制（避免雪崩）

每个机架同时最多 10% 节点处于 remediation 状态（类似 Kube 调度器的驱逐熔断设计）
每个 Availability Zone 限制 5% 节点同时重启
NVSwitch domain 内限制 1 个节点操作

4. 工作负载感知

训练任务：更宽松的阈值，优先尝试设备隔离
推理服务：更激进的恢复，快速替换 Pod
尊重 PodDisruptionBudget 设置

故障感知调度

让调度器"知道"哪些节点更健康，避免新任务被分配到风险节点。

Scheduler Plugin & Kueue 集成

健康度评分算法：

GPU Health Score = 1.0
  × (1 - 0.4 × XID错误权重)      # 40% 权重
  × (0.7 + 0.3 × NVLink带宽比)  # 30% 权重
  × (1 - 0.2 × ECC错误权重)     # 20% 权重
  × 温度衰减因子                # 10% 权重

最终调度分数 = 健康度评分 × 100

感兴趣可以参考 KEP-5471: Extended Toleration Operators for Threshold-Based Placement，目前已经支持 SLA Based Scheduling，可以结合这里的错误率进行调度方面的优化。

效果：

健康节点（score > 0.9）优先获得关键训练任务
中等健康节点（score 0.7-0.9）用于推理或低优先级任务
低健康节点（score < 0.7）仅用于可中断任务

DRA 健康属性

在 Dynamic Resource Allocation 时代，健康度成为设备选择的一等属性，建议尝试该方案。

apiVersion: resource.k8s.io/v1
kind: ResourceClaim
spec:
 devices: 
    requests:
    - deviceClassName: gpu.nvidia.com
      selectors:
      - cel:
         expression: |
           device.health.score > 0.9 &&
           device.health.xidErrors == 0 &&
           device.health.nvlinkStatus == "active"