K8s集群GPU温度监控排错：从DCGM到告警完整流程

K8s集群里GPU温度失控往往不是单一原因，可能是驱动、容器运行时、监控组件或调度策略任一环节出问题。
本文按“先能看数据、再能定位、最后能告警”的顺序，带你从零搭好GPU温度监控链路，并给出常见故障的排查路径。

先确认前提：节点、驱动与容器运行时

动手部署监控前，先确保宿主机层面GPU可被正常识别。
登录到每台GPU节点执行：

nvidia-smi -q -d TEMPERATURE

能正常输出GPU温度和风扇转速，说明驱动和硬件通信正常。
如果报错“NVIDIA-SMI has failed”，先解决驱动问题，监控组件装了也没用。

接着检查容器运行时是否已配置NVIDIA支持：

nvidia-container-cli -k -d /dev/tty info

输出中能看到GPU设备信息即可。
如果命令不存在，需要先安装nvidia-container-toolkit并重启容器运行时。

部署DCGM Exporter采集温度指标

DCGM Exporter是NVIDIA官方推荐的指标导出组件，它以DaemonSet方式运行在每个GPU节点上，将GPU温度、功耗、显存等指标暴露为Prometheus格式。

使用Helm安装：

helm repo add gpu-helm-charts https://nvidia.github.io/dcgm-exporter/helm-charts
helm repo update
helm install dcgm-exporter gpu-helm-charts/dcgm-exporter -n gpu-monitoring --create-namespace

安装后确认Pod状态：

kubectl get pods -n gpu-monitoring -o wide

每个GPU节点上应有一个Running状态的Pod。
如果Pod频繁重启或Pending，优先检查节点污点、资源限制和镜像拉取是否正常。

验证温度指标是否可抓取

DCGM Exporter默认监听9400端口。
先手动验证指标输出：

kubectl port-forward -n gpu-monitoring svc/dcgm-exporter 9400:9400

另开终端执行：

curl -s localhost:9400/metrics | grep DCGM_FI_DEV_GPU_TEMP

看到类似DCGM_FI_DEV_GPU_TEMP{gpu="0",...} 45的输出，说明温度指标正常暴露。
如果没有输出，检查Exporter Pod日志：

kubectl logs -n gpu-monitoring  --tail=100

常见报错包括Failed to initialize NVML（驱动或权限问题）和connection refused（端口未监听）。

配置Prometheus抓取与告警规则

在Prometheus的配置中添加抓取任务：

scrape_configs:
  - job_name: 'dcgm-exporter'
    kubernetes_sd_configs:
      - role: pod
        namespaces:
          names: ['gpu-monitoring']
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_label_app]
        regex: dcgm-exporter
        action: keep

重载Prometheus配置后，在Prometheus UI的Status > Targets中确认dcgm-exporter的target为UP状态。

告警规则示例，当GPU温度持续超过阈值时触发：

groups:
  - name: gpu-temperature
    rules:
      - alert: GPUTemperatureHigh
        expr: DCGM_FI_DEV_GPU_TEMP > 80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "GPU温度过高 (实例 {{ $labels.instance }})"
          description: "GPU {{ $labels.gpu }} 当前温度 {{ $value }}°C，已持续5分钟"

温度阈值需结合GPU型号调整，数据中心卡和消费卡的安全范围不同，不要照搬固定数字。

温度异常时的排查顺序

当收到温度告警，按以下顺序定位：

1. 确认是单卡还是整机：用nvidia-smi -q -d TEMPERATURE对比同一节点多张卡的温度。单卡偏高通常是散热风道或硅脂问题，整机偏高则是机箱环境或风扇策略问题。
2. 检查是否有异常进程占满GPU：nvidia-smi查看进程列表，长时间满载的推理或训练任务会持续推高温度。
3. 确认DCGM指标与nvidia-smi是否一致：如果Prometheus显示的数值和宿主机相差超过5°C，检查Exporter版本是否与驱动匹配。
4. 查看节点风扇和进风温度：通过IPMI或BMC读取风扇转速和进风口温度，风扇未提速或进风温度过高都会导致GPU散热不足。

容易踩的坑

• Exporter Pod没有调度到GPU节点：DaemonSet默认调度所有节点，但如果GPU节点有污点且未配置容忍，Pod不会运行。检查kubectl describe pod的Events。
• 指标名记错：DCGM Exporter不同版本指标名可能有差异，用curl localhost:9400/metrics | grep -i temp确认实际暴露的指标名，不要凭记忆写查询语句。
• 告警阈值一刀切：不同型号GPU的降频温度和上限不同，建议先观察一周正常负载下的温度基线，再设置合理阈值。
• 只监控不记录：温度是趋势指标，建议将数据保留至少30天，便于回溯是渐进恶化还是突发异常。

验证监控是否真正生效

完成配置后，做一次端到端验证：在GPU节点上运行一个短时高负载任务（如python -c "import torch; a=torch.randn(10000,10000).cuda(); b=a@a"），观察Prometheus中温度曲线是否在1-2分钟内上升，任务结束后是否回落。
曲线能实时反映负载变化，说明整条监控链路可用。

如果曲线始终平直不动，回到抓取配置和Exporter日志逐步排查，不要跳过验证直接依赖告警。

常见疑问

DCGM Exporter和nvidia-smi的读数为什么偶尔不一致？

两者采样时机和读取方式不同，短时波动属正常。
如果持续偏差超过5°C，检查Exporter版本与驱动版本是否兼容。

没有Prometheus可以用其他方案吗？

可以。
DCGM Exporter暴露的是标准Prometheus格式指标，任何支持该格式的采集端都能接入。
也可以直接用nvidia-smi --query-gpu=temperature.gpu --format=csv写脚本做简单轮询，但缺少历史趋势和多节点聚合能力。

GPU温度监控需要额外授权吗？

DCGM Exporter以特权容器运行才能访问NVML接口，部署时需确认集群的Pod安全策略允许。
如果使用了PSP或OPA等策略引擎，需要为gpu-monitoring命名空间放行。