Kubernetes调度GPU任务：Device Plugin、资源声明、节点标签与Pending排障

Kubernetes不会自动识别GPU

Kubernetes通过厂商Device Plugin发现和分配GPU。节点宿主机驱动、容器运行时GPU配置和插件DaemonSet缺一不可。插件正常后，节点`capacity/allocatable`才会出现`nvidia.com/gpu`或`amd.com/gpu`等扩展资源。

从节点外到节点内检查

kubectl get nodes -o wide
kubectl describe node GPU_NODE | sed -n '/Capacity:/,/System Info:/p'
kubectl get pods -A -o wide | grep -Ei 'device-plugin|gpu-operator'
kubectl get events -A --sort-by=.lastTimestamp | tail -n 50

如果资源数量为零，登录目标节点验证宿主机GPU和容器运行时。Device Plugin日志往往会直接显示驱动库、设备节点或健康检查错误。

GPU资源声明规则

GPU通常写在`limits`中；只写limits时，Kubernetes会用同值作为request。若同时写requests与limits，两者必须相等。不能只写GPU requests。

apiVersion: v1
kind: Pod
metadata:
  name: gpu-check
spec:
  restartPolicy: Never
  containers:
  - name: cuda
    image: nvidia/cuda:12.4.1-base-ubuntu22.04
    command: ["bash","-lc","nvidia-smi && sleep 20"]
    resources:
      limits:
        nvidia.com/gpu: 1

kubectl apply -f gpu-check.yaml
kubectl get pod gpu-check -o wide
kubectl describe pod gpu-check
kubectl logs gpu-check
kubectl delete pod gpu-check

删除后再次检查节点可分配资源，确认设备能够回收。

异构GPU必须显式标记

集群混有不同显存、架构或厂商时，只申请`nvidia.com/gpu: 1`无法表达需要80GB还是24GB。使用可信的节点标签或Node Feature Discovery标记型号、显存等级、互联和用途，并用nodeAffinity选择。标签必须由管理员控制，不能允许普通工作负载伪造。

污点与容忍用于阻止普通Pod占用GPU节点；资源配额限制命名空间GPU数量；PriorityClass需要防止低价值批任务阻塞在线服务。GPU是整数扩展资源，默认不能像CPU一样任意小数共享；MIG、time-slicing或vGPU需要厂商方案和额外隔离验证。

Pod Pending怎样定位

先看`kubectl describe pod`底部Events：Insufficient GPU表示没有满足资源的节点；affinity不匹配说明标签条件错误；untolerated taint说明缺少容忍；未绑定PVC或镜像拉取问题也可能让任务看似“GPU调度失败”。

若节点显示有GPU但Pod启动后无设备，检查kubelet、容器运行时、插件注册目录和运行时类。不要通过privileged作为永久修复。

上线前的恢复演练

重启Device Plugin Pod，确认资源短暂变化不会错误分配；排空一个GPU节点，确认任务能否在另一节点恢复；模拟模型目录不可用，确保健康检查不会把空服务加入流量。对训练任务还应测试检查点恢复，对推理任务验证滚动更新期间的容量与连接中断。

最终监控必须能把GPU UUID关联到节点、Pod、命名空间和业务任务，否则只能看到“某张卡满载”，却无法找到责任工作负载。