Kubernetes v1.35 中，Dynamic Resource Allocation（DRA）进入 GA。这个变化的意义不只是“又多了一个 API”，而是 Kubernetes 开始用更细粒度的方式描述和分配设备资源：GPU、网卡、加速卡、带拓扑约束的硬件，都可以从简单的 nvidia.com/gpu: 1 走向“我要哪类设备、带什么属性、如何绑定给 Pod”。
同时，NVIDIA 将 dra-driver-nvidia-gpu 移入 Kubernetes SIGs，也让 GPU 场景的试用和生态协作更值得关注。下面我们从开发者和平台工程师的角度，看 DRA 到底改变了什么，以及可以怎样在集群里摸一摸它。
从扩展资源到“声明式设备申请”
传统 Kubernetes 里，GPU 常见写法是：
resources:
limits:
nvidia.com/gpu: 1
它足够简单，但表达能力有限。你能说“我要 1 张 GPU”，却很难自然表达：
- 我要某一类 GPU，比如 A100、H100 或带特定能力的卡；
- 我要和某个 NUMA、PCIe 拓扑更匹配的设备；
- 我要一组需要一起分配的设备；
- 调度器需要在 Pod 绑定前就理解设备约束。
DRA 的核心思路是把“资源需求”抽成 Kubernetes API 对象。Pod 不再只在 container resources.limits 里写一个整数，而是引用一个 ResourceClaim 或 ResourceClaimTemplate。设备驱动负责暴露可分配资源，调度器和 kubelet 参与完成选择、绑定和交付。
这更像 PVC 之于存储：Pod 声明“我需要什么”，底层实现决定“如何满足”。
GA 之后，平台团队该关注什么
DRA 进入 GA 意味着 API 和行为预期更稳定，适合平台团队开始做 PoC、灰度和标准化封装。但这不等于所有 GPU 集群都应该立刻替换现有写法。
更现实的落地路径通常是：
- 新建一组实验节点，安装支持 DRA 的设备驱动；
- 用少量 AI 训练、推理或批处理任务验证调度结果；
- 将 DRA 封装进内部模板，例如 Helm chart、Kustomize base 或平台表单；
- 对比原来的 device plugin 模式，观察可观测性、失败排查和调度稳定性。
NVIDIA 的 DRA GPU 驱动移入 Kubernetes SIGs 是一个信号：GPU DRA 不只是厂商侧的实验项目，而是在向 Kubernetes 社区协作的方向靠拢。不过，具体字段、设备属性、DeviceClass 名称仍要以你安装的驱动版本为准。
可以这样实践：先看集群是否已经具备 DRA API
下面命令可以直接在 Kubernetes v1.35 或启用了 DRA API 的集群上运行。它不会创建资源，只用于确认 API 是否可见。
kubectl version --short
kubectl api-resources --api-group=resource.k8s.io
kubectl explain resourceclaim.spec
kubectl explain resourceclaimtemplate.spec
kubectl explain pod.spec.resourceClaims
如果能看到 resourceclaims、resourceclaimtemplates、deviceclasses 等资源，说明 API 层面已经具备 DRA 相关对象。接下来还需要确认节点上是否安装了对应的 DRA 驱动，例如 GPU 驱动。
kubectl get deviceclasses
kubectl get resourceclaims -A
kubectl get pods -A | grep -i dra || true
如果 deviceclasses 为空，不代表 Kubernetes 不支持 DRA；它通常表示还没有设备驱动向集群注册可用设备类别。
一个可改造的 DRA Pod 示例
下面示例展示了 DRA 的基本形状：用 ResourceClaimTemplate 描述“每个 Pod 都需要一份 GPU 申请”，Pod 再通过 resourceClaims 引用它。
注意：deviceClassName、选择器字段和设备属性需要按你安装的 DRA 驱动调整。以下 YAML 是一个最小改造模板，不保证在没有 DRA GPU 驱动的集群上直接成功调度。
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
name: one-gpu
spec:
spec:
devices:
requests:
- name: gpu
deviceClassName: gpu.nvidia.com
count: 1
---
apiVersion: v1
kind: Pod
metadata:
name: dra-gpu-demo
spec:
restartPolicy: Never
resourceClaims:
- name: gpu
resourceClaimTemplateName: one-gpu
containers:
- name: app
image: nvidia/cuda:12.4.1-base-ubuntu22.04
command: ['bash', '-lc']
args:
- |
echo 'checking GPU from inside the container'
nvidia-smi || true
resources:
claims:
- name: gpu
保存为 dra-gpu-demo.yaml 后可以这样试：
kubectl apply -f dra-gpu-demo.yaml
kubectl get resourceclaims
kubectl describe pod dra-gpu-demo
kubectl logs dra-gpu-demo
如果 Pod Pending，重点看两处：
kubectl describe pod dra-gpu-demo
kubectl describe resourceclaim $(kubectl get resourceclaim -o name | head -n 1)
常见原因包括：没有安装 DRA 驱动、deviceClassName 不存在、节点没有可用设备、驱动暴露的属性和 YAML 里声明的不一致。
和旧 GPU 写法怎么共存
DRA 不一定要“一刀切”替换扩展资源。对很多团队来说，旧写法仍然适合简单批处理任务：
resources:
limits:
nvidia.com/gpu: 1
DRA 更适合这些场景：
- 任务对设备型号、能力或拓扑敏感；
- 多种硬件加速器混部，平台需要统一抽象；
- 调度前必须明确设备约束，而不是运行时才失败；
- 想把设备申请做成可审计、可复用的 Kubernetes 对象。
它的代价也很明确：你需要理解新的 API，需要驱动支持，需要更新平台模板和排障手册。对只跑少量 GPU Job 的团队，这些复杂度未必立刻值得。
采用建议：从“可观测的试点”开始
我的建议是把 DRA 当成平台能力演进，而不是单个应用的 YAML 小改动。可以按这个清单推进：
- 确认集群版本至少达到 v1.35，或清楚当前版本的 DRA 支持状态；
- 在隔离节点池安装 DRA 设备驱动；
- 用
kubectl api-resources和kubectl explain固化排查步骤； - 为 GPU 任务准备一套 DRA 示例模板和一套传统扩展资源模板；
- 记录 Pending、Claim 分配失败、设备不可见等常见问题；
- 等驱动、监控、调度策略稳定后，再扩大到生产工作负载。
DRA 的价值不在于把 nvidia.com/gpu: 1 换成更长的 YAML，而在于让 Kubernetes 能理解“设备”这件事本身。对于 GPU 密集型、硬件异构、调度约束复杂的集群，v1.35 GA 是一个值得认真评估的时间点。