Kubernetes 1.37 中，动态资源分配（Dynamic Resource Allocation，DRA）已经不再只是 ResourceClaim 的新接口。DRA Extended Resource 支持进入 GA 后，现有工作负载仍可通过 example.com/gpu 这类传统扩展资源申请设备，而集群底层可以改由 DRA 驱动完成发现、筛选和分配。这给生产集群提供了一条风险更低的迁移路径：先替换设备管理后端，再逐步让应用使用 DRA 的高级能力。
GA 能力改变了 DRA 的落地顺序
过去迁移到 DRA 往往意味着同时改动驱动、调度配置和工作负载清单。Kubernetes 1.37 稳定的 Extended Resource 支持把这些步骤拆开了。
管理员可以在 DeviceClass 上声明扩展资源名。Pod 继续请求熟悉的扩展资源，调度器则通过 DRA 为它匹配设备，工作负载本身不需要创建或引用 ResourceClaim，也不必为了兼容旧接口而并行运行一套 Device Plugin。
这项能力从 1.35 的 Alpha、1.36 的 Beta 演进到 1.37 的 GA，实际价值不只是 API 稳定，而是明确了迁移边界：
- 应用团队可以暂时保留现有 Pod、Deployment 和 Helm Chart。
- 平台团队可以独立迁移设备驱动与资源发布方式。
- 需要共享 Claim、设备属性或复杂组合选择时，再按工作负载逐步采用原生 DRA API。
1.37 还稳定了设备污点与容忍机制。DRA 驱动可以把单个设备标记为不可用于新调度，管理员也可以通过 DeviceTaintRule 在集群范围施加规则。与节点污点相比，它的隔离粒度落到了具体 GPU、NIC 或其他设备，不必仅因一块卡需要维护就封锁整台节点。已使用该设备的 Pod 还可以按策略被驱逐，除非对应 ResourceClaim 明确容忍该污点。
另一个稳定改进是标准属性 resource.kubernetes.io/numaNode。不同厂商驱动可以用同一属性描述 NUMA 位置，为 GPU、网卡和 CPU 拓扑协同调度提供统一比较依据。
状态可见性与工作负载级 Claim
ResourceClaim 的 .status 增加了设备级状态表达能力。网络设备可报告接口名、MAC 地址和 IP 地址，用户及控制器因此能看到设备完成配置后的结果。网络服务不再只能依赖额外控制器猜测或转抄分配信息，而可以围绕驱动报告的实际地址构建后续流程。
进入 Beta 的工作负载 ResourceClaim 支持解决了另一类规模问题。在启用默认关闭的 DRAWorkloadResourceClaims 特性门后，Workload 和 PodGroup 可以直接引用 Claim，使一组 Pod 共享同一资源声明，不再受旧式逐 Pod 预留方式最多 256 个 Pod 的限制。
Device Attributes Downward API 同样进入 Beta。驱动在准备 Claim 时写入元数据，框架通过 CDI 将 JSON 文件挂载到容器中。KubeVirt 虚拟机或普通容器可读取 PCI 总线地址、MAC 地址等属性，而不必部署专门监听 ResourceClaim 与 ResourceSlice 的转换控制器。
这些接口适合构建自动化，但状态字段应当被视为驱动报告的数据，而不是永远不变的资产数据库。控制器需要处理字段暂时缺失、设备重新准备和 Pod 重建等情况。
可以这样验证扩展资源迁移
下面是一个可改造的最小示例。假设集群已经安装名为 gpu.example.com 的 DRA 驱动，并且该驱动会发布可匹配的 ResourceSlice。请把驱动名、镜像和扩展资源域名替换成集群中的真实值。
apiVersion: resource.k8s.io/v1
kind: DeviceClass
metadata:
name: example-gpu
spec:
extendedResourceName: gpu.example.com/device
selectors:
- cel:
expression: 'device.driver == "gpu.example.com"'
---
apiVersion: v1
kind: Pod
metadata:
name: extended-resource-dra-demo
spec:
restartPolicy: Never
containers:
- name: workload
image: busybox:1.36
command: ["sh", "-c", "echo device allocated; sleep 3600"]
resources:
requests:
gpu.example.com/device: "1"
limits:
gpu.example.com/device: "1"
保存为 dra-extended-resource.yaml 后，可以这样部署和检查：
kubectl apply -f dra-extended-resource.yaml
kubectl get deviceclass example-gpu -o yaml
kubectl get resourceslices.resource.k8s.io -o wide
kubectl describe pod extended-resource-dra-demo
kubectl get resourceclaims.resource.k8s.io -A
重点检查三个结果：DeviceClass 是否接受了 extendedResourceName，驱动是否发布了 ResourceSlice，以及 Pod 事件中是否出现设备匹配或分配错误。示例只能验证 API 链路；容器能否真正访问设备，仍取决于驱动的节点侧实现、CDI 配置和运行时支持。
如果升级后只想盘点 API，而不立刻创建工作负载，可以先运行：
kubectl api-resources | grep -E 'deviceclass|resourceclaim|resourceslice|devicetaintrule'
kubectl get deviceclasses.resource.k8s.io
kubectl get resourceslices.resource.k8s.io -A
Alpha 功能瞄准组合调度和规模瓶颈
1.37 的 Alpha 能力主要集中在表达能力、容量核算与调度性能上。
属性列表进入第二个 Alpha 版本后，一个设备属性可以包含多个值。例如，CPU 可以同时邻近多个 PCIe Root，选择器因此可以比较集合是否重叠，而不必把拓扑关系压缩成一个难以查询的字符串。
Derived Attributes 更进一步，允许在清单中使用 CEL 派生属性。如果 GPU 驱动使用 numa，NIC 驱动使用 numaNode，管理员可以建立自己的映射规则，而不必等待两个厂商统一命名。CEL 还可用于从复合拓扑字符串提取标识，或者按容量划分性能等级。它提高了互操作性，也把一部分调度规则转移到了集群配置中，因此表达式需要版本管理、测试和审查。
Device Compatibility Groups 让驱动标记设备分区的兼容组，例如同一 GPU 上的 MIG 与 vGPU 配置。调度器可以提前拒绝不兼容组合，而不是等到节点准备阶段才失败。该能力由默认关闭的 DRADeviceCompatibilityGroups 特性门控制。
Node allocatable resource requests 进入 Alpha 2，目标是让 DRA 管理的 CPU、内存等节点资源参与常规可分配容量核算，避免用户同时在 ResourceClaim 和 Pod 资源字段中重复声明，也降低节点超卖风险。
资源可用性快照通过 ResourcePoolStatusRequest 提供，但它不是持续监控 API。需要刷新时必须删除并重新创建请求，因此不应把它当作高频指标采集接口。
调度性能方面，Alpha 的 PreQueueingHint 扩展点利用 Pod informer 索引，只重新排队真正受 ResourceClaim 事件影响的 Pod。它将原先大规模扩容时可能出现的 O(N²) 扫描路径缩小到 O(1) 定位；早期基准测试显示调度吞吐量约可翻倍。此能力受 SchedulerPreQueueingHints 特性门控制，生产启用前仍需用自身工作负载验证。
此外，Optional Node Operations 允许无需节点本地设置的分配跳过 kubelet 的 prepare/unprepare 调用；Consumable Capacity 则通过 Beta 特性门 DRAFractionalCapacityRange 支持分数容量范围，为细粒度设备容量分配提供基础。
升级与采用清单
生产环境不宜一次启用所有 DRA 能力。更稳妥的顺序是先升级控制面和节点组件，确认驱动明确支持 Kubernetes 1.37，再迁移扩展资源后端。
- 优先使用 GA 的 Extended Resource、设备污点和标准 NUMA 属性。
- 保留现有工作负载清单，通过 DeviceClass 验证无侵入迁移。
- 仅在确实需要跨 Pod 共享 Claim 时评估
DRAWorkloadResourceClaims。 - 对 Beta 和 Alpha 特性记录控制面、调度器及 kubelet 的特性门配置，避免组件状态不一致。
- 为设备耗尽、污点驱逐、驱动不可用和节点重启建立故障演练。
- 将 ResourceSlice、ResourceClaim 状态和调度失败事件接入可观测系统，但不要把快照 API误作实时监控。
- 在启用 Derived Attributes 或兼容组前，用真实的异构设备组合建立调度测试矩阵。
Kubernetes 1.37 的关键进展，是让 DRA 可以先从集群内部接管设备分配，而不强迫所有应用同时改写。GA 能力适合建立迁移基线，Beta 功能适合受控试点，Alpha 功能则应留在测试集群验证。这样既能利用新的设备模型，也能把升级风险限制在平台团队可以观察和回滚的范围内。