Dynamic Resource Allocation（即 DRA）不会废除 Kubernetes 中用于 GPU 共享的 HAMi 项目，但会改变两者之间的职责分配。随着 DRA 在 Kubernetes v1.34 中达到普遍可用状态，并自 v1.35 起默认启用，Kubernetes 已能够原生理解并调度设备资源的部分配额请求。而在容器内部、针对 CUDA 调用强制执行这些配额，并非 DRA 的职责，这正是 HAMi-core 仍然发挥关键作用的地方。
由 Mesut Oezdil 撰写的 CNCF 文章分析了这两个阶段之间的差异，并解释了 HAMi 如何在 DRA 之上重建其部分生态系统，而不是放弃该项目。作者指出，问题并不是两个项目中的哪一个会取代另一个，而是 HAMi 的哪些功能已经由 Kubernetes 的原生能力覆盖。
为什么 GPU 共享需要专门的解决方案？
Kubernetes 的 Device Plugin 接口原本主要能够统计设备数量。传统请求，例如 nvidia.com/gpu: 1，意味着预留一张完整的显卡，但没有原生语言来请求一张显卡的 8,000 MB 内存或 10% 的计算能力。
为了解决这一问题，HAMi 使用 nvidia.com/gpumem 和 nvidia.com/gpucores 等扩展资源。不过，Kubernetes 默认调度器会将这些值视为不透明的数字；它不知道内存和计算能力必须来自同一块物理显卡，也无法单独确定多个配额是否会超出某张显卡的容量。
因此，传统路径依赖 webhook 修改请求、依赖调度器扩展筛选节点并选择设备 ID，然后将决策记录在 annotation 中。Device Plugin 随后读取该决策，以注入 CUDA_DEVICE_MEMORY_LIMIT_0=8000m 和 CUDA_DEVICE_SM_LIMIT=10 等限制，同时预加载 libvgpu.so 库来强制执行这些限制。
根据文章，DaoCloud 已通过这种方式在 10 多个数据中心运行了超过 10,000 个 GPU。不过，其架构仍然依赖特定的 annotation 格式和 HAMi 能够理解的组件，而这正是 DRA 旨在解决的缺口。
DRA 增加了什么？
DRA 用声明模型取代了设备计数模型，在 resource.k8s.io/v1 接口中包含四个主要对象：
- ResourceSlice：由设备驱动发布，用于描述每个节点上的实际硬件，包括型号、内存和架构。
- DeviceClass：使用 CEL 表达式定义设备类别及其筛选条件。
- ResourceClaim：由工作负载所有者创建，用于根据类别、选择器和约束请求设备。
- ResourceClaimTemplate：为工作负载的每个副本创建独立的声明。
调度器会在绑定容器之前为声明分配特定设备，结果则以结构化 API 对象的形式出现在 ResourceClaim 状态中。这样，决策便有了原生存放位置：kubectl 可以读取它，RBAC 可以保护它，其他控制器也可以基于它构建，而不必将其作为字符串存储在 annotation 中。
不过，基础 DRA 本身不足以实现 HAMi 风格的内存共享。这里的重要扩展是 Consumable Capacity，该功能在 v1.34 中通过 DRAConsumableCapacity 门控以实验性方式出现，并自 v1.36 起转为实验性且默认启用。该扩展允许驱动声明设备可以接受多个分配，同时允许声明请求设备上某个命名资源的特定数量，例如内存或计算能力。
这样一来，HAMi 的资源匹配几乎可以直接映射：gpumem 转换为内存容量请求，gpucores 转换为计算容量请求，而判断显卡是否仍有足够容量的工作，则从 HAMi 的调度扩展转移到了 Kubernetes 调度器本身。
调度并不等于强制执行限制
分析强调，DRA 会跟踪调度器作出的承诺，但不会阻止容器在运行期间超出这些承诺。CUDA 调用并不知道 ResourceClaim 的内容，贪婪的工作负载可能会尝试消耗额外内存，从而影响另一个容器。
HAMi-core 通过 C 库 libvgpu.so 承担这一职能。该库会拦截 CUDA 和 NVIDIA Management Library 调用，并在用户空间实施限制。根据文章中的示例，如果两个容器各自获得 8,000 MB，那么超出配额的容器会在其限制处收到 CUDA 内存不足错误，而另一个容器会继续运行。
在敌对多租户环境中，这种软件保护并不能替代硬件隔离。绕过库预加载、使用静态链接的 CUDA 驱动，或利用 CUDA_DISABLE_CONTROL 等设置的工作负载，可能会逃过拦截。作者指出，NVIDIA Multi-Instance GPU（即 MIG）更适合硬件隔离；相比固定的 MIG 配置文件，软件拦截则能提供更细的精度，内存步长可达 1 MB，计算能力步长可达 1%。
HAMi 如何在 DRA 之上重建其生态系统？
新架构分布在三个承担不同职能的代码库中：
- k8s-dra-driver：在 ResourceSlices 中将每个 GPU 的内存和计算能力发布为可消耗容量，运行 kubelet 插件，并通过 CDI 连接容器，同时附加 HAMi-core 的强制执行机制。
- HAMi-DRA：一个准入修改 webhook，用于从请求中移除传统扩展资源并创建等效的 ResourceClaims，同时保留用于 UUID 目标选择和设备类型的 annotation。根据文章，HAMi-DRA v0.2.0 已与 HAMi v2.9 一起达到生产就绪状态，随后版本系列进入 v0.2.1。
- HAMi：自 v2.8 起将 DRA 模式记录为安装选项，同时默认启用监控组件，并通过 Prometheus 在 31995 端口提供每个容器的设备指标。
HAMi-DRA 的一项优势在于，它将调度工作交给管理集群的调度器，因此无需添加 HAMi 专用集成，即可使用 Volcano、KAI Scheduler 或任何理解 DRA 的其他调度器。但这一选择也有代价：HAMi-DRA 没有自己的调度器，因此无法保证具备拓扑感知能力的决策，例如选择一对通过 NVLink 连接的 GPU。
要求与实际选择
DRA 模式要求 Kubernetes v1.34 或更高版本，并启用 DRAConsumableCapacity。在 v1.34 和 v1.35 中，该门控处于实验性状态且默认禁用，这可能会阻止在不允许修改 API 服务器设置的托管服务中使用它。而在 v1.36 中，它已处于实验性状态并默认启用。此外，还需要支持 CDI 的运行时，例如启用 CDI 的 containerd 或 CRI-O，需要 440 或更高版本的 NVIDIA 驱动，以及适用于相应加速器类型的 DRA 驱动。
文章将 NVIDIA 路线描述为最成熟的路线，同时也提到了对 Ascend 和 Enflame 的支持，以及通过 k8s-dcu-dra-driver 对 Hygon DCU 的记录。相比之下，自 v2.9 起，HAMi 传统模式覆盖了 12 个以上的设备系列，包括 Cambricon MLUs、Iluvatar、MetaX、Moore Threads、Kunlunxin、AWS Neuron 和 Vastai。因此，在 DRA 驱动覆盖范围扩大之前，多供应商集群仍可能继续采用传统路线。
不应在同一集群中同时启用 DRA 模式和传统 Device Plugin 模式，因为两个调度系统看起来会在管理同一容量，却看不到另一个系统的承诺。根据作者的评估，传统模式适合不提供特性门控的受管理集群、较旧版本以及多供应商集群。至于控制 Kubernetes 控制平面的 NVIDIA 集群，尤其是运行 v1.36 的集群，可以在测试环境中尝试 DRA 模式，从 HAMi-DRA 开始，以避免修改现有的部署文件。
Consumable Capacity 在 Kubernetes 中仍然完全不稳定，k8s-dra-driver 的 Helm 图表也仍被标记为正在开发中，而 DRA 方面的供应商覆盖范围仍低于传统模式。文章的结论是，DRA 负责请求和调度语言，而 HAMi-core 保留容器内的执行能力；也就是说，两者的关系趋向于集成，而非替代。