Kubernetes 新调度能力影响 GPU 任务时先看哪些配置

如果 Kubernetes 升级后 GPU Pod 突然 Pending，先别急着改 nodeSelector。Kubernetes 1.37 把 DRA（Dynamic Resource Allocation）的扩展资源支持推进到稳定，同时让设备污点与 DeviceTaintRule 进入稳定状态。真正影响任务的，不是“集群里有没有 GPU”这一句，而是 GPU 当前由哪种分配路径管理、DeviceClass 有没有接住资源名，以及设备污点是否被 ResourceClaim 容忍。

官方地址：https://kubernetes.io/

判断顺序可以固定为：版本与分配路径 → DeviceClass 资源映射 → 设备污点与 ResourceClaim 容忍 → 小范围验证。只有四项都对上，GPU 任务才算真正吃到了新的调度能力。

先判定 GPU 走哪条分配路径

Kubernetes 原有的 GPU 使用方式通常依赖厂商驱动和 device plugin，节点会暴露类似 nvidia.com/gpu 的扩展资源，Pod 在容器资源字段中申请它。DRA 则通过 ResourceSlice、DeviceClass、ResourceClaim 和驱动协作，把设备属性、共享方式或设备级配置带进调度过程。两者可以在同一个集群的不同节点共存，但不能把旧路径的可见资源数量当成 DRA 已经生效。

# 查看版本与 DRA 资源对象，先确认当前集群到底走哪条路径
kubectl version
kubectl get deviceclasses
kubectl get resourceslices
kubectl get resourceclaims -A
kubectl get devicetaintrules

如果只能看到节点上的扩展资源和 device plugin 对象，却没有 DRA 驱动发布的 ResourceSlice 或可用的 DeviceClass，这次升级对该 GPU Pod 的调度语义基本没有直接改变。此时优先看厂商驱动的 DRA 支持说明，而不是给业务 YAML 盲目增加 resourceClaims。

DeviceClass 映射决定旧 YAML 能否继续工作

1.37 的关键变化是：DeviceClass 可以设置 extendedResourceName，调度器据此用 DRA 设备满足传统扩展资源请求，业务 Pod 不必为了切换后端立即改成 ResourceClaim 写法。下面是官方文档中的同类结构改写成的最小示意，驱动名、属性名和资源名必须换成实际驱动提供的值。

apiVersion: resource.k8s.io/v1
kind: DeviceClass
metadata:
  name: gpu-general
spec:
  # 选择器必须能匹配驱动发布到 ResourceSlice 的 GPU 属性
  selectors:
  - cel:
      expression: device.driver == 'gpu.example.com' && device.attributes['gpu.example.com'].type == 'gpu'
  # 让传统扩展资源请求可以由 DRA 设备满足
  extendedResourceName: example.com/gpu

这里要看三处：第一，extendedResourceName 是否与工作负载申请的资源名完全一致；第二，CEL 选择器引用的驱动、属性键和值是否真的出现在 ResourceSlice；第三，同一资源名在同一节点是否被旧 device plugin 和 DRA 重复提供。资源名对不上时，Pod 看起来像“有 GPU 却调度不上”；选择器写错时，问题会更像“DRA 没有可用设备”。

如果应用需要精确筛选显存、拓扑或共享能力，仍应使用 ResourceClaim 的设备请求，不要为了保持旧 YAML 而把所有条件压缩成一个扩展资源名。DRA 的价值就在于把设备属性和申请条件分开描述。

设备污点会让“有 GPU”仍然 Pending

升级后最容易漏掉的是设备级污点。DRA 的污点作用在使用该设备的 ResourceClaim，并通过 Claim 影响引用它的 Pod；它不是节点污点的别名。NoSchedule 会阻止不具备容忍的请求使用该设备，NoExecute 还会触发设备污点驱逐控制器删除已经运行的相关 Pod。

apiVersion: resource.k8s.io/v1
kind: DeviceTaintRule
metadata:
  name: gpu-maintenance
spec:
  # 选择范围要足够窄，避免把整套 GPU 驱动的设备都标记掉
  deviceSelector:
    driver: gpu.example.com
    pool: worker-gpu-a
  taint:
    key: gpu.example.com/maintenance
    value: planned
    effect: NoSchedule

排查时先确认规则是否选中了目标设备，再看 Claim 是否声明了匹配的设备容忍。不要直接复制节点 tolerations 到 Pod 就认为有效：DRA 的容忍写在设备请求的 ResourceClaim 中，且应只放行确实需要维护中设备的工作负载。对于 NoExecute，还要明确是否允许延迟驱逐，否则 GPU 任务可能在调度成功一段时间后被删除。

升级 GPU 集群时按四项清单落地

1. 版本：确认控制面、调度器、控制器管理器和 kubelet 的版本组合，DRA 扩展资源与设备污点分别由对应版本提供。
2. 驱动：确认 GPU 驱动能发布 DRA 所需的 ResourceSlice，并能在节点侧完成设备准备；没有驱动支持，单开配置没有意义。
3. 映射：核对 DeviceClass、选择器、扩展资源名和节点上的旧资源提供者，先选一组 GPU 节点做灰度。
4. 恢复：准备删除 DeviceTaintRule、回退工作负载资源名或切回旧 device plugin 的方案，并观察 Pending 原因和 Claim 状态。

可以把官方事实入口留给值班同学复核：DRA API 对象说明为 https://kubernetes.io/docs/concepts/resource-management/dynamic-resource-allocation/dra-api/，设备污点说明为 https://kubernetes.io/docs/concepts/resource-management/dynamic-resource-allocation/device-taints/。这类能力会随版本继续演进，升级时应以目标版本文档和实际驱动说明为准。

常见问题

只升级到 Kubernetes 1.37，旧的 nvidia.com/gpu Pod 会自动使用 DRA 吗？

不会。只有存在可匹配的 DRA 驱动和 DeviceClass 映射时，扩展资源请求才可能由 DRA 满足；否则仍是原来的 device plugin 路径。

GPU 节点有空闲卡，Pod 为什么仍然 Pending？

先查 DeviceClass 选择器、资源名和设备污点。节点容量可见只说明节点层面有资源，不代表该 Claim 能通过设备属性和污点策略。

能不能给 Pod 加一个 toleration 解决 DRA 设备污点？

不能简单照搬节点污点写法。应在实际 ResourceClaim 的设备请求中声明精确容忍，并评估 NoExecute 对运行中任务的驱逐影响。