浅聊 K8s 1.34 GA 的 DRA | 关于动态资源分配，你可能关心的 7 个问题

K8s 1.34 发布，DRA (Dynamic Resource Allocation) 终于 GA 了。

关于 DRA，大家最关心的问题无非是这几个：

1. DRA 到底解决了什么问题？
2. “动态分配”是指能给运行中的 Pod 动态挂载 GPU 吗？
3. 它有哪些新玩法？
4. 和 DevicePlugin 是什么关系？
5. 支持虚拟化了吗？HAMi 进度如何？
6. 还有哪些有意思的特性？
7. 离真正用上还要多久？

搞清楚这些问题之前，咱们先用一句话概括一下 DRA：

懂 HAMi + 懂 PV/PVC ≈ 懂 DRA

如果再细致一点，DRA 就是借用了 PV/PVC 的动态资源供应思路，通过结构化、标准化的抽象，来支持更加个性化、更加灵活的资源调度与分配。

说人话就是：以前基于 DevicePlugin 框架，上报的信息太少了。你想通过别的方式上报，调度器又看不懂。

DRA 的本质，就是解决信息量不够的问题。

这一点和 HAMi 基于 Node & Pod Annotations 的信息传递机制如出一辙：多上报点信息，让调度器多知道点信息，好做判断。

技术演进：从”拉扯”到”直给”

早期的 DRA 方案其实很”拧巴”。它用的是对调度器不透明的参数（设备驱动自己的 CRD）。

调度器既不知道全局有什么资源，也看不懂这些参数，只能把皮球踢给驱动：

1. 调度器选几个候选节点。
2. 驱动看一眼，把不行的踢掉。
3. 调度器再挑一个。
4. 驱动分配。
5. 调度器绑定。

这条链路在 K8s 1.26 Alpha 时期写得很清楚。但凡中间任何一步出现资源竞争或状态过期，就会触发回滚重试。结果就是：API Server 热点、驱动压力大、长尾调度严重。

而且，因为调度器没法自己判断，Cluster Autoscaler 这种自动扩缩容组件更是两眼一抹黑，完全没法预测该扩什么节点。

所以，社区最终废弃了那套方案，改用了结构化参数（Structured Parameters）。

现在，调度器和 CA 可以直接看懂资源数据，直接参与决策，不再依赖驱动的黑盒判断。

---

好，背景铺垫完了，直接回答那 7 个问题。

1. 到底解决了什么问题？

解决了”DevicePlugin 上报的信息太少，用别的方式上报了，原生调度器又不知道”的问题。

它打通了设备信息和原生调度器之间的”语言障碍”。

2. “动态”是指给运行中的 Pod 挂 GPU？还是原地扩缩容？

都不是。

DRA 的”动态”，实际上是指在调度层可以灵活地按声明去做设备筛选，绑定和卸载设备前后可以灵活动态地做一些必要的准备或收尾。

我觉得叫”灵活资源分配”可能更贴切。

3. 有什么新玩法？

先快速理解 DRA 的四个核心概念：

• DeviceClass ≈ StorageClass
• ResourceClaim ≈ PVC
• ResourceClaimTemplate ≈ VolumeClaimTemplate（或者理解为云平台的规格）
• ResourceSlice ≈ DevicePlugin 上报信息的 Plus 版（可以扩展各种属性，就是个信息丰富的总库存）

显而易见，上层平台在做库存管理和规格管理时，可以用更原生的方式接入了。 至于更多玩法，其实都在那些 Alpha/Beta 特性里（见第 6 点）。

4. 和 DevicePlugin 是什么关系？

前同事交接的关系。 DRA 的到来就是为了干掉 DevicePlugin。

为了让交接更丝滑，社区搞了个 KEP-5004，允许通过 DeviceClass 把 DRA 驱动注册的设备映射为扩展资源（比如继续用 nvidia.com/gpu）。

也就是说，你可以在同一个集群里混用 DevicePlugin 和 DRA，逐步迁移。但同一个节点上，肯定不能两个都跑。

5. GPU 虚拟化支持得怎么样？HAMi 呢？

• 固定模板切分（类 MIG）：看看 KEP-4815 (DRA Partitionable Devices)。
• 灵活切分（HAMi 这种）：社区正在开发 KEP-5075 (DRA Consumable Capacity)。

HAMi 已经跟上了。基础功能在社区周会上演示过（感谢 @Shouren 的贡献）。

感兴趣的可以去看看代码 demo： Project-HAMi/k8s-dra-driver (demo branch)

6. 还有哪些有意思的特性？

除了上面提到的 KEP-5004 (兼容迁移)、KEP-4815 (类 MIG 切分)、KEP-5075 (容量复用/显存切分)，我还期待这几个：

• KEP-4816 (Prioritized Alternatives)：给设备请求加优先级。“好的设备没有，差一点的也能接受”，或者”尽量先用差一点的设备”。
• KEP-4680 (Resource Health Status)：设备坏了，健康状态直接写到 Pod Status 上。这比以前两眼一抹黑强多了。
• KEP-5055 (Device Taints and Tolerations)：设备也能打污点了。比如这张卡快淘汰了，或者要检修了，打个污点，新 Pod 就不调度上去了。

7. 真正用上还要多久？

我觉得规模化生产，通常得等 Beta 稳定，以及生态驱动跟进。

国内厂商目前只了解到昇腾有相关进展。保守估计，至少还要 8 到 16 个月吧。