Kubernetes v1.37 DRA GA 迁移 ResourceClaim 要检查什么

Kubernetes v1.37 的 DRA 迁移，最容易误判的地方是把“DRA 扩展资源支持 GA”和“工作负载直接引用 ResourceClaim”当成同一件事。前者已经稳定，旧的 example.com/gpu 请求可以逐步交给 DRA 驱动处理；后者在 v1.37 仍是 Beta，需要显式打开 DRAWorkloadResourceClaims。所以迁移检查的重点不是立刻改 YAML，而是先确认每个 ResourceClaim 的声明、分配状态和消费者关系都闭合。

官方资料：https://kubernetes.io/blog/2026/09/03/kubernetes-v1-37-dra-updates/

API 参考：https://kubernetes.io/docs/reference/kubernetes-api/resource/resource-claim-v1/

迁移前先分清“扩展资源兼容”与“ResourceClaim 引用”

我会先把迁移拆成两条路径。第一条是保留 Pod 中原来的扩展资源请求，让 DeviceClass 暴露同名资源，调度和分配改由 DRA 驱动完成；这是 v1.37 已 GA 的兼容方式，适合先验证驱动和节点侧行为。第二条是让 Pod、Workload 或 PodGroup 显式引用 ResourceClaim，它能表达更细的设备属性，但工作负载引用能力在 v1.37 还是 Beta，不能当成默认可用的生产开关。

因此，看到集群升级成功并不代表迁移已经完成。先记录旧请求的资源名、Pod 数量、设备是否允许共享，再决定是否引入 Claim。两条路径不要在同一批工作负载里重复申请同一块设备。

先核对 ResourceClaim 的 API、spec 和 status

ResourceClaim 的稳定 API 是 resource.k8s.io/v1。迁移时先看对象是否被正确创建，再看它是否真的获得了分配结果；只看 metadata.name 或“对象存在”是不够的。

# 先确认对象、API 版本和声明状态；命令只读，不会改变 Claim
kubectl get resourceclaim -n inference gpu-claim -o yaml

# 只提取迁移决策需要的字段，避免把整份对象复制进工单
kubectl get resourceclaim -n inference gpu-claim \
  -o jsonpath='{.apiVersion}{"\n"}{.spec.devices}{"\n"}{.status.allocation}{"\n"}{.status.reservedFor}{"\n"}'

核对结果可以按三层记录：apiVersion 是否为 resource.k8s.io/v1；spec.devices 是否表达了目标设备请求；status.allocation 是否已经出现分配结果。若 Claim 已经被占用，还要检查 reservedFor，确认允许使用它的 Pod 或其他消费者没有超过预期。

再把 DeviceClass、驱动和 Pod 的关系对上

Claim 不是孤立的配置文件。它依赖 DeviceClass 的选择规则，由 DRA 驱动从资源池中完成分配，最后还要被 Pod 或更高层工作负载引用。迁移排查时我会同时看四个对象：Claim 请求了什么、DeviceClass 匹配什么、驱动名是否一致、Pod 是否真的引用了这个 Claim。

这里尤其要注意“DRA 驱动已经安装”和“这个 Claim 能被调度”不是同一个结论。ResourceClaim API 参考中，status.allocation 出现后才说明分配结果已写入；设备的驱动、资源池和设备名还必须能组成一致的标识。

用一份灰度清单验证迁移结果

第一次灰度不要覆盖所有 GPU 或网络设备。我更建议选一个节点、一个命名空间和一个可重启的工作负载，按下面顺序记录结果：

1. 确认控制面和节点版本都已进入目标版本，记录 DRA 相关 feature gate 的实际值。
2. 先用一个 Claim 验证分配，再确认 Pod 的引用方式只走一条路径。
3. 检查 Claim 的 status.allocation、消费者列表和 Pod 事件，三者一致后再扩大范围。
4. 若出现未分配、重复占用或节点准备失败，停止扩大灰度，保留旧扩展资源路径。
5. 回滚时先缩小工作负载，再按消费者关系清理 Claim，避免删除仍被保留的资源声明。

v1.37 还把 DRA 设备污点与容忍度提升到稳定，并统一了 resource.kubernetes.io/numaNode 属性名。这些能力有助于维护和拓扑选择，但不替代 Claim 本身的分配检查。迁移完成的判据应该是“请求、分配、消费者和节点行为都能对上”，而不是“API 对象创建成功”。

相关问题

升级到 Kubernetes v1.37 后必须把 Pod 改成 ResourceClaim 吗？

不必须。已有扩展资源工作负载可以先沿用原请求，让 DRA 承担后端分配；只有需要设备属性、共享 Claim 或更细粒度约束时，才评估显式引用 ResourceClaim。

ResourceClaim 已创建但 Pod 仍然 Pending 怎么看？

先查 status.allocation，再查 DeviceClass 匹配、驱动日志、节点可用设备和 reservedFor。Claim 存在只能说明声明被接受，不能证明设备已经分配给当前 Pod。

结论：Kubernetes v1.37 的 DRA 迁移适合分阶段推进。先用 GA 的扩展资源兼容路径验证驱动，再为确有需要的工作负载引入 ResourceClaim；每一步都把 API、spec、status、消费者和节点行为一起核对，迁移才有可回退的边界。