聚焦 WG Device Management

AI、边缘计算和电信工作负载在 Kubernetes 上日益普及，对硬件管理提出了新的需求。 我们现在需要的硬件规格已经超出了 CPU 时间和内存分配的范畴。 这包括分配 GPU、TPU、网络接口和其他硬件，有时在 Pod 启动之后分配，有时通过分时共享。

高效管理这些专用硬件是 Device Management 工作组 的使命。他们的核心项目 动态资源分配（DRA） 最近已正式 GA，标志着该项目在大规模处理硬件密集型工作负载方面的根本性转变。

在本期聚焦中，我们与工作组主席 Kevin Klues、Patrick Ohly 和 John Belamaric 坐下来讨论了传统设备模型的局限性、 调度中的 NP 难 挑战，以及他们如何为 Kubernetes 构建一个更可编程、更具硬件感知能力的未来。

介绍 Device Management

Natalie Fisher：能否介绍一下你自己、你的角色，以及你是如何参与 Device Management 工作组的？

Kevin Klues： 我叫 Kevin Klues，是 NVIDIA 的杰出工程师。 自 2024 年 KubeCon EU 工作组成立以来，我一直担任 Device Management 工作组的联合主席。 我从 2019/2020 年 DRA（工作组的主要成果）诞生之初就参与其中。 我从 2019 年起还担任 kubelet 维护者，专注于其设备管理器、CPU 管理器和拓扑管理器子组件。 我们在为依赖外部加速器（例如 GPU）的工作负载使用这些组件时遇到的挑战，正是促使我们开始研发 DRA 的原因。

Patrick Ohly： 我是 Intel 的首席工程师。 在 Kubernetes 中，我是 SIG Testing 和 SIG Instrumentation 的技术负责人， 同时也是 Device Management WG 的联合主席。我曾担任 WG Structured Logging 的联合主席，也是指导委员会成员。 我早期对 Kubernetes 的贡献包括临时 CSI 卷和存储容量跟踪， 所以我有一些 API 设计、实现和调度方面的经验。我们知道为加速器引入一个重要的新 API 将是困难的。 我在 2020 年有些冒失地接受了这个挑战，编写了最初的 DRA KEP（现在被称为"经典 DRA"）并实现了其大部分功能， 然后从头开始编写了第二个 KEP，也就是今天的"结构化参数 DRA"。最初，说服维护者认为这项工作是必要的是一场艰难的斗争。 直到 2023 年左右，人们对 DRA 的兴趣才开始增长，最终促成了工作组的成立。

John Belamaric： 我是 Google 的高级软件工程师，同样自工作组成立以来担任 WG Device Management 的第三位联合主席。 自 2019 年以来，我也是 SIG Architecture 的联合主席。正如 Patrick 提到的，2023 年末，人们对 DRA 的兴趣真正增长起来。 最初的实现使自动扩缩容变得非常困难，因此社区对将其推进到 Beta 阶段存在一些担忧。 我参与进来试图帮助解决这些问题，我们三人与 Tim Hockin 在接下来的几个月中努力围绕新设计达成了共识。 为了促进这种合作，我们在 2024 年巴黎 KubeCon 讨论后成立了这个工作组。

问题与解决方案

该工作组源于对 Kubernetes 如何与专用硬件交互的根本性重新思考。 这一演进的核心是动态资源分配（DRA）。 DRA 不再将设备视为简单的整数，而是提供了一个结构化框架，将设备管理分为四个不同的阶段：

• 建模： 供应商使用 ResourceSlice API 来发布其硬件的细粒度能力和容量。
• 请求： 用户通过 ResourceClaim API 定义其特定的硬件需求——例如 GPU 内存或互连要求。
• 调度： Kubernetes 调度器使用这些 API 智能地将工作负载需求与可用硬件进行匹配。
• 执行： 一旦匹配完成，系统处理"握手"过程，为 Pod 准备和保护设备。

NF：对于可能不太熟悉的读者，什么是 Device Management 工作组，它试图解决什么问题？

KK： Device Management 工作组的使命是实现跨 Kubernetes 工作负载的加速器和其他专用硬件的简单高效配置、共享和分配。 想想 GPU、TPU、FPGA 以及类似的不能很好地融入 Kubernetes 传统资源模型的设备。

我们着手解决的问题是，传统的 Device Plugin API（一直是在 Kubernetes 中暴露硬件加速器的主要机制）存在根本性的限制。 它将设备视为不透明的整数：你可以请求"2 个 GPU"，但无法表达你需要哪些 GPU、它们之间应如何连接、是否可以共享或应如何分区等有意义的信息。 这对于简单场景是足够的，但现代 AI/ML 工作负载绝非简单。 它们跨越多个节点，需要特定的互连拓扑，并且越来越需要动态共享或分区硬件。

工作组的主要成果是动态资源分配（DRA），这是一个用灵活的声明式 API 替代僵化的设备插件模型的新框架。 通过 DRA，工作负载可以描述其硬件需求（例如 GPU 类型、内存容量、互连拓扑、期望的分区）， 驱动程序可以发布细粒度的设备属性供调度器使用。 DRA 在 Kubernetes 1.34 中正式 GA， 围绕它的生态系统（例如驱动程序、工具和新的 API 扩展）正在快速增长。

PO： 正如 Kevin 所说，工作组是围绕现有的 DRA 开发工作成立的。 最初的工作只有少数人积极参与，也许也只有在这样的设置下才能成功完成。 但由于它涉及 Kubernetes 的众多不同领域，我们还需要一个地方来讨论这些问题， 并让更广泛的 Kubernetes 维护者、设备供应商以及（在较小程度上）最终用户社区参与进来。 工作组提供了这样的场所，定期在线会议（一个时段面向美洲/EMEA，一个面向 EMEA/亚洲）以及 KubeCon 上的讨论。

JB： DRA 是工作组解决的第一个问题。它专注于设备的选择、分配和配置。 我们将问题分解为四个部分：供应商如何对设备建模并发布容量、用户如何请求设备、 我们如何在已发布的容量之上调度该请求，以及我们如何执行该结果（即如何使设备准备好并可供 Pod 使用）。

我们采取的方法中有一个根本性的认识，那就是硬件的多样性令人难以置信，而且硬件行业的变化速度也极快。 我们知道，如果 Kubernetes API 必须为每种类型的硬件而改变，我们就无法跟上这种变化。 相反，我们创建了一种通用方法，来处理对 Kubernetes 重要的硬件方面。 到目前为止，我们的工作重点是设备的调度和配置方面。 我们构建了一个设备建模 API（ResourceSlice API），供应商用它来描述其设备的调度特性， 并允许用户向这些设备传递任意配置。 通过这样做，Kubernetes 可以被"编程"来理解设备的这些方面，而无需自身被修改。

但目前的 DRA 非常专注于调度。设备管理还有其他方面属于工作组的范围。 特别是，我们正在研究设备故障检测和缓解，以及我们是否可以在 Kubernetes 中构建更好的支持来帮助解决这些问题。

此外，正如 Kevin 提到的，设备通常是以组的形式分配和使用的，而不是单独使用。 选择正确的设备在组中协同工作取决于它们的互连方式； 例如，NVIDIA GPU 可能在 NVLINK 域中采用任意对任意的 fabric 排列，而 TPU 可能采用 3D 环面互连。 这会影响设备的"选择、分配和配置"，我们还有大量工作要做来解决这些使用场景。

跨 SIG 协作

由于设备管理涉及调度、节点操作、自动扩缩容、网络和 API 设计，这项工作自然跨越了 Kubernetes 项目中的多个 SIG。

NF：跨 SIG 协作在实践中是如何运作的，为什么是必要的？

KK： 设备管理几乎涉及 Kubernetes 栈的每一层，这就是为什么工作组从一开始就被定位为跨 SIG 的协作。 我们有五个利益相关的 SIG：sig-node、sig-scheduling、sig-autoscaling、sig-network 和 sig-architecture。

在实践中，工作组充当协调层。我们不直接拥有代码；相反，我们的成果以 KEP 和实现的形式存在于各自的 SIG 中。 我们提供的是一个统一的论坛，让构建调度器、kubelet、自动扩缩器和网络平面的人能够协同设计，而不是各自为政。

为什么这是必要的？考虑一个简单的例子：用户请求一组需要通过 NVLink 通信的 GPU。 该需求涉及调度器（将 Pod 放置在正确的节点上）、kubelet（配置设备并将其暴露给容器）以及可能的自动扩缩容（如果不存在合适的节点则配置正确的节点类型）。

如果这三个团队独立设计，你最终会得到不一致的抽象、重复的逻辑以及只在生产环境中才会暴露的集成缺陷。 工作组确保单一一致的 API 和数据模型贯穿所有这些组件。

跨 SIG 模型还意味着设计决策会从多个角度进行审查。 sig-scheduling 的人会发现 sig-node 贡献者可能忽视的调度器复杂性，反之亦然。 这会稍微减慢单个决策的速度，但会产生更健壮的结果。

当前重点领域

随着 DRA 正式 GA，工作组的重点已扩展到支持更高级的调度模型、共享语义、运维可见性以及对日益复杂的硬件拓扑的支持。

NF：工作组目前聚焦的一些关键举措或成果是什么？

KK： 我们在 Kubernetes 项目看板上维护着一个项目看板， 实时跟踪我们的举措及其进展。

PO： 核心 DRA 的范围和功能集是有意限制的，以便在合理的时间内晋级到 GA。 额外的 KEP 按照各自的计划添加更多功能。这些大致分为三类：

1. 扩展 DRA 的表达能力以支持更复杂的设备和调度场景。
2. 支持_第二天（Day 2）_运维操作，如健康监控。
3. 改善多节点支持，主要通过与工作负载感知调度集成。

除了项目看板，我们还维护了一个表格来汇总所有当前正在进行的 KEP。 以下是 1.36 的状态；1.37 可能会添加更多：

NF：核心挑战之一是高效的设备利用和共享。这方面取得了什么进展？

JB： 好问题。一种思考方式是看我们在两个主要 API 中正在做什么：ResourceClaim 和 ResourceSlice。

ResourceClaim API 是用户请求设备的方式。 我们构建了一些功能，允许用户在请求中更加灵活。 例如，用户可以请求具有至少一定内存量的 GPU，而不是请求特定型号的 GPU。 或者他们可以请求一个备选列表："我想要一个 A100（80GB）GPU，但如果没有，我可以接受 2 个 A100（40GB）GPU。" 这为调度器提供了满足请求的选项，可以带来更好的硬件可获得性和利用率，否则这些硬件不会被选择。

ResourceClaim API 允许用户显式共享设备。 你可以将多个容器（在相同或不同的 Pod 中）指向一个 ResourceClaim； 这允许该声明分配的设备在所有这些容器中使用，前提是设备支持此操作。

ResourceSlice API 是供应商建模和发布其设备的方式。这是我们实现对其他共享模型支持的地方。 例如，我们有一种表示"重叠分区"的方式，使调度器能够动态选择 MIG 分区，并自动使任何重叠的 MIG 分区不可用。 这与"给我任何具有 20GB 或更多内存的 GPU"这样的请求配合使用效果很好——调度器可以用 MIG 或真实 GPU 来满足该请求。

有些功能需要两者同时修改。我们还有另一种共享方式叫做"可消耗容量"（consumable capacity）。 在上述显式共享场景中，用户需要将容器指向同一个 ResourceClaim；有一个 ResourceClaim 在多个容器和 Pod 之间共享。 而对于可消耗容量，设备共享的方式更像 Pod 共享节点的方式。 用户创建一个 ResourceClaim 来请求一定量的资源，例如，"我需要一个具有 2Gbps 带宽的网卡"。 调度器知道有一个 40Gbps 带宽的网卡可用，因此它从 40Gbps 中分配 2Gbps 给该 ResourceClaim。 在这种情况下，每个 Pod 都有自己的 ResourceClaim，但底层设备在这些声明之间共享。 节点上的 DRA 驱动程序负责为这种共享正确设置设备（对于网卡，可能通过创建子接口）。 我们称之为"平台介导的共享"，以区别于显式的"用户介导的共享"。

实际影响

虽然大部分工作是深度技术性的，但其根本目标是实用的：使 Kubernetes 能够更好地大规模支持实际的 AI/ML 和硬件密集型工作负载。

NF：当前用户在 Kubernetes 上运行硬件密集型工作负载（如 AI/ML）时面临的最大挑战是什么？

PO： 这类工作负载在几个方面不同于传统容器工作负载：它们可能由多个需要同时运行的通信 Pod 组成（"组调度"）。 它们通常是长时间运行且初始化成本高昂的，其性能对运行位置很敏感（节点内的拓扑以及多 Pod 之间的节点间互连）。 Kubernetes 调度器传统上对这两者的支持都不好，因为它一次调度一个 Pod 并且不了解节点内的拓扑。 一些外部调度器试图填补这个空白，但这通常并不理想，特别是当 Kubernetes 调度器将其他 Pod 调度到同一集群时。

NF：平台工程师在设计 Kubernetes 平台时应该如何考虑设备管理？

JB： 我们还在学习中，但 DRA 的一个理念是实现向更"需求驱动"规格的转变。 这可以减少编写工作负载规格的最终用户和设置集群的集群管理员之间的耦合。 用户不必商定标签约定或要求用户了解集群拓扑，而是可以指定其工作负载需要什么，调度器来决定如何满足。 如果我们能使其工作，即使是复杂的工作负载也可以更容易地在集群之间移植。

挑战和权衡

与 Kubernetes 的许多领域一样，增加灵活性和表达能力也引入了新的复杂性层次，特别是在调度和优化方面。

NF：工作组目前正在解决的最难的技术挑战有哪些？

PO： 灵活性和调度复杂性之间存在固有的冲突。 当前的实现侧重于找到满足所请求资源的某种解决方案，但它不一定是最佳方案——无论"最佳"意味着什么——这一点也并不总是清晰的。 另一个大挑战是将节点可分配资源（RAM、CPU）作为带有额外元数据的设备暴露出来； 这对于精细调优需要在节点上完美对齐以获得最佳性能的工作负载的调度是必要的。

JB： Patrick 的列表很好。复杂设备建模很困难，确保我们构建正确的语义使其适用于多种不同硬件始终是棘手的。

除此之外，调度本身就非常复杂，是一个 NP 难问题。 DRA 添加的所有元数据和灵活性给调度器更多选项，这有优点也有缺点。 如果你的选择受限，更多选项是有帮助的，因为这意味着你可以调度原本无法调度的内容。 但这也意味着当给定集群中有很多可能性时，找到最优解决方案变得更加困难。 DRA 在我们常见的用例中目前运行良好，但我们还有大量工作要做，以提高所选调度方案的最优性并确保做出选择的性能。

展望未来

尽管面临挑战，工作组的贡献者们对创新的步伐和围绕 Kubernetes 设备管理形成的不断壮大的社区仍然感到兴奋。

NF：展望未来，你对 Kubernetes 设备管理的未来最感兴趣的是什么？

KK： NVIDIA 最近将其 GPU 的 DRA 驱动程序捐赠给了 Kubernetes 项目。 我个人很期待看到更多社区成员开始为项目做贡献并定义其未来方向。

PO： 对我来说，主要是新贡献者的数量和站出来帮忙的人。 这带来了围绕审查提案和帮助开发者实现和合并代码的新挑战。 看到别人成功是令人愉快和有意义的，这对未来也是一个好兆头，因为更多人熟悉了这个主题。

JB： 我对很多事情感到兴奋。社区确实在壮大，有许多有趣的功能正在开发中， 以支持更复杂设备的建模，以及更好地对多节点设备建模。

我真的很期待看到人们以创造性的方式使用这些 API。 它们主要是为"设备"而设计的，但就像 Unix/Linux 中"一切皆文件"一样，这些 API 本身对于它们建模的内容是相当灵活的。 它们确实构建了一个更可编程的调度器，这可以有有趣的应用。 例如，我最近做了一个原型，使用 DRA 将 Pod 调度到已本地缓存了大型 AI 模型的节点上。 它确实非常灵活，我对社区的创造力有很大的信心，所以我认为我们会在生态系统中看到一些意想不到的解决方案。

参与贡献

NF：贡献者如何参与 Device Management 工作组？

KK： 最简单的第一步是加入我们的邮件列表 wg-device-management@kubernetes.io。 订阅后会自动将我们双周会议的日历邀请添加到你的日历中。

我们有两个会议时段以适应不同的时区：

• 欧洲/美洲：每两周二 太平洋时间上午 8:30
• 亚洲/欧洲：每两周三 中欧时间上午 9:00

会议记录、议程和录像都是公开可访问的（链接可从设备管理页面获取）。 你可以在参加第一次会议之前了解正在进行的工作。

在 Slack 上，你可以在 Kubernetes Slack 工作区的 #wg-device-management 频道找到我们。 那是快速提问或自我介绍的最佳地方。

对于更实际的贡献，NVIDIA GPU 的 DRA 驱动程序现在是一个社区项目，也是一个很好的起点。 它是一个真实的、生产级的实现，更广泛的社区现在正在共同塑造。

我们欢迎各级别的贡献者——无论你对 API 设计、调度器内部机制、驱动程序开发还是文档感兴趣。来打个招呼吧。

总结

随着 Kubernetes 不断发展以支持 AI/ML 革命和高性能计算，WG Device Management 中正在进行的工作正在成为现代工作负载如何大规模调度和运行的基础。

从动态资源分配（DRA）正式 GA 到健康监控和拓扑感知调度的下一个前沿，该工作组实际上正在重写软件和硬件之间的"握手"。

如果你有兴趣塑造硬件感知编排的未来，现在是参与的最佳时机。 无论你是想帮助完善 API、构建驱动程序还是改进文档，工作组欢迎来自社区各个层次的经验和观点。

• ←上一页
• 下一页→