Kubernetes 1.37 DRA 资源分配升级：Extended Resource 兼容与设备级验收清单

Kubernetes 1.37 的 Dynamic Resource Allocation（DRA）又向前走了一步：DRA Extended Resource support 已经 GA，设备污点与容忍也进入稳定状态。对集群管理员来说，最实用的变化不是“又多了几个 API”，而是旧工作负载可以继续使用传统 extended resource 名称，底层分配逻辑却能逐步迁移到 DRA。本文按实际排查顺序解释这次变化，并给出上线前的验证清单。

Kubernetes 1.37 DRA 架构关系图

一、DRA 解决的到底是什么问题

传统 device plugin 通常让 Pod 直接请求某种扩展资源，例如 example.com/gpu。这种方式简单，但设备筛选、共享和复杂拓扑表达能力有限。DRA 把设备分成 DeviceClass、ResourceClaim、ResourceSlice 等对象：驱动描述设备，管理员定义类别，工作负载声明需求，调度器负责把声明与可用设备匹配起来。

可以把它理解成“先定义可选设备目录，再按条件下单”，而不是把硬件型号和数量硬编码在每个容器里。

二、1.37 最值得关注的 GA 能力

第一项是 DRA Extended Resource support。DeviceClass 可以直接设置扩展资源名称，Pod 仍按传统资源 API 发起请求，不需要在工作负载侧额外创建 ResourceClaim。这样，已有清单不用一次性大改，驱动和集群侧可以先完成迁移。

第二项是设备污点与容忍。DRA 驱动或管理员可以把某个设备标记为 tainted，新的 Pod 不再分配到它；如果设备已经被使用，还可以根据规则驱逐相关 Pod。它的思路与节点 taint/toleration 相似，但作用范围缩小到了单个设备，适合维护、降级和隔离故障硬件。

此外，ResourceClaim 状态增加了更标准化的设备信息，网络设备可以报告接口名、MAC 地址和 IP 地址；resource.kubernetes.io/numaNode 也成为共享属性名，减少不同驱动各说各话。

三、先确认集群版本和 API 能力

kubectl version
kubectl get --raw /apis/resource.k8s.io/v1
kubectl api-resources | grep -E 'DeviceClass|ResourceClaim|ResourceSlice'

这里不要只看客户端版本。真正决定能力的是 apiserver、scheduler、kubelet 和 DRA driver 的组合。若 API 不存在，先查控制面版本和相关组件日志；不要把一个客户端升级命令当成完整升级方案。

四、传统 extended resource 如何接入

迁移前先确认驱动已经发布 ResourceSlice，并在 DeviceClass 中声明扩展资源名。工作负载侧可以保留原有资源请求，例如：

apiVersion: v1
kind: Pod
metadata:
  name: accelerator-demo
spec:
  containers:
  - name: app
    image: registry.example/app:1.0
    resources:
      limits:
        example.com/gpu: "1"

示例中的镜像和资源名只是占位符。实际名称必须以驱动文档为准。发布后分别检查 Pod 事件、ResourceClaim（如果该驱动的实现需要）和 ResourceSlice，确认不是“Pod Running 了但设备没有真正挂载”。

五、设备污点的安全上线方式

建议先用不驱逐的效果做观察，再切换到需要驱逐的策略。先记录设备选择范围和已有分配数量，确认不会误伤整台节点：

kubectl get deviceslices -A -o yaml
kubectl get pods -A -o wide
kubectl describe pod accelerator-demo

维护单个设备时，优先验证新 Pod 不再选择它；对已经运行的 Pod，先明确业务是否能重建，再考虑 NoExecute 类似的驱逐效果。设备级策略的风险仍然是真实的，名字里带“taint”不代表可以闭眼敲回车。

六、Beta 和 Alpha 能力不要混用

1.37 同时推进了 Workload ResourceClaims、Device Attributes Downward API、设备兼容组、资源池状态查询等能力。但 Beta 或 Alpha 并不等于默认开启，更不等于所有发行版都已集成。部署前先读 feature gate：

kubectl get pod -n kube-system kube-apiserver-$(hostname) -o yaml
kubectl get pod -n kube-system kube-scheduler-$(hostname) -o yaml

不同发行版的控制面 Pod 名称可能不同，命令需要按实际环境调整。生产环境应把 feature gate、驱动版本和回滚方式写入变更单，避免只在一台测试节点上“看起来能跑”。

七、故障排查表

现象	优先检查	常见原因
Pod Pending	事件、ResourceSlice、DeviceClass	无匹配设备或驱动未上报
API 找不到	控制面版本与 CRD/API	组件未升级或能力未启用
设备状态空	ResourceClaim status、driver 日志	驱动未填充状态或版本不兼容
维护后仍分配旧设备	taint 规则、调度缓存	规则范围不对或旧 Pod 未重建

八、四层验收，不要只看 Pod Running

DRA 四层验收清单

验收建议分四层：API 层确认对象可见；调度层确认声明成功、事件正常；设备层确认节点、属性和分配状态准确；运行层确认容器能看到并实际使用设备。最后一层最容易被漏掉：调度成功不代表应用真的拿到了预期能力。

kubectl describe pod accelerator-demo
kubectl get resourceclaims -A -o yaml
kubectl get resourceslices -A -o yaml
kubectl logs -n kube-system deploy/your-dra-driver

九、结论

Kubernetes 1.37 的 DRA 更适合渐进式采用：先利用 GA 的 extended resource 兼容能力降低迁移成本，再根据设备维护、共享和拓扑需求引入更细粒度的声明。Beta/Alpha 功能先在测试集群验证，生产环境把版本、feature gate、驱动状态和回滚路径一起纳入变更记录。这样升级才是工程变更，不是给集群换个更酷的 YAML。