Kubernetes v1.36：更多驱动程序、新特性以及下一代 DRA
动态资源分配（DRA）从根本上改变了平台管理员在 Kubernetes 中处理硬件加速器和专用资源的方式。 在 Kubernetes v1.36 中，DRA 继续走向成熟，带来了多项特性进阶、重要的可用性改进， 以及一些新的能力，包括将 DRA 的灵活性扩展到内存和 CPU 这类原生资源， 并支持在 PodGroup 中使用 ResourceClaim。
驱动程序的可用性也在持续扩展。除了专用计算加速器之外， 这一生态系统也已经支持网络设备及其他硬件类型， 这反映出它正迈向更稳健、不过度绑定特定硬件的基础设施。
无论你是在管理大规模 GPU 资源池，需要更好地处理故障， 还是只是希望找到更好的方式来定义资源候选/回退选项， DRA 在 v1.36 中的升级都会对你有所帮助。 下面我们来看看这些新特性和进阶内容。
特性进阶
社区一直在努力稳定 DRA 的核心概念。 在 Kubernetes 1.36 中，多项备受期待的特性已经进入 Beta 和稳定阶段。
按优先级排序的列表（Stable）
硬件异构是大多数集群中的现实情况。使用按优先级排序的列表 特性，你可以在请求设备时明确指定回退偏好。 你无需将对特定设备型号的请求硬编码，而是可以指定一个有序的偏好列表 （例如，“给我一块 H100，如果没有可用的，就回退到 A100”）。 调度器会按顺序评估这些请求，从而显著提升调度灵活性和集群利用率。
扩展资源支持（Beta）
随着 DRA 成为资源分配的标准，弥合与既有机制之间的差距就变得至关重要。 DRA 的扩展资源 特性允许用户通过 Pod 上传统的扩展资源方式来请求资源。 这使得向 DRA 的过渡可以循序渐进，也就是说，集群运维人员可以将集群迁移到 DRA， 而让应用开发者按照自己的节奏采用 ResourceClaim API。
可切分设备（Beta）
硬件加速器能力强大，而有时单个工作负载并不需要整个设备。 可切分设备 特性为 DRA 原生提供了支持，能够根据工作负载需求，将物理硬件动态切分为更小的逻辑实例 （例如多实例 GPU）。 这使管理员能够在多个 Pod 之间安全且高效地共享昂贵的加速器。
设备污点（Beta）
正如你可以为 Kubernetes Node 添加污点一样， 你也可以直接为特定 DRA 设备添加污点。 设备污点和容忍度 让集群管理员能够更高效地管理硬件。 你可以为故障设备打上污点，使其不会被普通 ResourceClaim 申领占用； 也可以把特定硬件预留给专属团队、专用工作负载或实验场景。 这样，只有具有匹配容忍度的 Pod 才允许申领这些带污点的设备。
设备绑定状况（Beta）
为了提升调度可靠性，Kubernetes 调度器可以使用绑定状况 特性，在 Pod 所需的外部资源（例如可挂接设备或 FPGA）完全就绪之前，推迟将 Pod 绑定到节点。 通过显式地对资源就绪状态建模，这一特性能够防止过早分配导致 Pod 失败， 从而确保部署过程更加稳健且可预测。
资源健康状态（Beta）
对于运行在专用硬件上的工作负载来说，知道设备何时故障或变得不健康至关重要。 借助资源健康状态， Kubernetes 直接在 Pod 状态中暴露设备健康信息， 为用户和控制器提供了关键的可见性，以便快速识别并响应硬件故障。 该特性还支持易于阅读的健康状态消息，使问题诊断变得容易得多， 而无需深入复杂的驱动日志。
新特性
除了稳定现有能力之外，v1.36 还引入了一些基础性的新特性，进一步扩展了 DRA 能支持的场景。 这些特性目前均处于 Alpha 阶段，并由默认关闭的特性门控控制。
面向工作负载的 ResourceClaim 支持
为了优化依赖严格拓扑调度的大规模 AI/ML 工作负载， 面向工作负载的 ResourceClaim 支持 特性使 Kubernetes 能够在大规模 Pod 集合之间统一管理共享资源。 通过将 ResourceClaim 或 ResourceClaimTemplate 与 PodGroup 关联起来， 该特性消除了此前的扩展性瓶颈，例如可共享某个申领的 Pod 数量限制， 同时也减轻了专用编排器手动管理申领的负担。
节点可分配资源
为什么 DRA 只能用于外部加速器呢？在 v1.36 中，我们引入了使用 DRA API 管理 节点可分配基础设施资源（如 CPU 和内存）的第一版实现。 通过 DRA 的节点可分配资源 特性，将 CPU 和内存分配纳入 DRA 体系之下， 用户就可以将 DRA 的高级放置能力、NUMA 感知和优先级语义应用到标准计算资源上， 从而为极细粒度的性能调优铺平道路。
DRA 资源可用性可见性
集群管理员最常提出的需求之一，就是希望更好地了解硬件容量。
全新的资源池状态
特性允许你查询 DRA 资源池中的设备可用性。
通过创建 ResourcePoolStatusRequest 对象，
你可以获得某个驱动所管理的每个资源池在某一时刻的设备数量快照，
包括总数、已分配、可用和不可用。
这有助于更好地集成仪表板和容量规划工具。
属性的列表类型
ResourceClaim 的约束求值机制已经调整，以便更好地处理标量值和列表值：
matchAttribute 现在检查是否存在非空交集，
而 distinctAttribute 则检查值是否两两不相交。
同时，CEL 中还引入了一个 includes() 函数，
这使设备选择器在某个属性于标量表示和列表表示之间变化时，
仍可更容易地保持可用。
（includes() 函数仅可用于 DRA 表达式求值上下文。）
确定性设备选择
Kubernetes 调度器已更新：在评估设备时，会按资源池与 ResourceSlice 名称的字典序进行比较。 这样一来，驱动可以更主动地影响调度过程，有助于提高吞吐量并做出更优的调度决策。 ResourceSlice 控制器工具包还会自动生成名称，使其与驱动作者在实现里声明的设备先后次序一致。
容器中可被发现的设备元数据
运行在带有 DRA 设备的节点上的工作负载，通常需要在不查询 Kubernetes API 的情况下， 发现其已分配设备的详细信息，例如 PCI 总线地址或网络接口配置。 借助设备元数据， Kubernetes 定义了一套标准协议，用于规定 DRA 驱动如何以带版本的 JSON 文件形式， 在约定路径下向容器暴露设备属性。 使用 DRA kubelet plugin library 构建的驱动可以无需额外处理即可获得这一能力；它们只需要提供元数据，其余如文件布局、 CDI bind-mount、版本控制和生命周期管理，都由该库负责处理。 这为应用提供了一种一致、与驱动无关的方式来发现和使用设备元数据， 从而无需再借助自定义控制器或查询 ResourceSlice 对象并从其属性中获取元数据。
后续计划
这一版本引入了大量新的动态资源分配（DRA）特性，而且相关工作仍在持续推进。 展望未来，我们的路线图将聚焦于推动现有特性走向 Beta 和稳定发布阶段， 同时进一步夯实 DRA 的性能、可扩展性和可靠性。 在接下来的几个迭代周期中，一个关键优先事项将是与 工作负载感知调度 和 拓扑感知调度 的深度集成。
我们的一个重要目标，是推动用户从设备插件迁移到 DRA，而我们也希望你参与其中。 无论你当前正在维护某个驱动，还是刚开始探索这些可能性， 你的意见都至关重要。与我们一起塑造下一代资源管理能力。 现在就联系我们，一起协作开发、分享反馈，或者开始构建你的第一个 DRA 驱动程序。
参与其中
一个不错的起点，是加入 WG Device Management 的 Slack 频道 和会议， 这些会议分别安排在适合 Americas/EMEA 和 EMEA/APAC 的时间段举行。
并非所有增强想法目前都已经作为 Issue 进行跟踪， 因此，如果你想提供帮助，或者你自己也有一些想法，欢迎来和我们交流。 我们在各个层面都有工作要做，从高难度核心变更，到 kubectl 的易用性增强， 其中一些工作也很适合新贡献者上手。