在Kubernetes中启用多节点NVLink的技术解析

原创

用户11764306

发布于 2026-01-21 11:31:47

910

在Kubernetes中为NVIDIA GB200 NVL72及后续平台启用多节点NVLink

NVIDIA GB200 NVL72将AI基础设施推向新的极限，使得训练大语言模型和运行可扩展、低延迟的推理工作负载成为可能。无论是在本地还是在云端，Kubernetes在高效部署和扩展这些工作负载方面扮演着越来越核心的角色。然而，快速演进的AI工作负载、基础设施需求以及新的硬件架构，给Kubernetes编排和资源管理带来了新的挑战。

本文介绍了一种名为ComputeDomains的新Kubernetes抽象，旨在隐藏确保多节点工作负载的每个工作节点能够通过多节点NVLink结构，跨节点边界执行安全的GPU到GPU内存操作所涉及的复杂性。

作为某中心GPU的DRA驱动程序的一部分提供，ComputeDomains将底层的GPU结构（NVIDIA NVLink和NVIDIA IMEX）与现代Kubernetes原生调度概念（动态资源分配，简称DRA）连接起来，为在现代GPU硬件上运行分布式、多节点工作负载提供了所需的基础支持。如果没有ComputeDomains，多节点NVLink设置将不得不手动定义并固定，这会限制Kubernetes旨在提供的灵活性，并以牺牲安全隔离、故障隔离和成本效益为代价。

虽然这项工作已在NVIDIA DGX GB200（某中心为GB200 NVL72系统制定的蓝图）上得到验证，但ComputeDomains的设计目标是推广到任何支持多节点NVLink的当前或未来架构，包括未来的NVL576系统。

本文主要关注基础知识：ComputeDomains是什么，它们为何重要，以及如何使用它们在Kubernetes上运行自己的分布式多节点工作负载。

从单节点到多节点GPU计算

要理解ComputeDomains的重要性，简要回顾一下GPU系统设计随时间的演变会很有帮助。

早期的NVIDIA DGX系统通过尽可能多地将GPU打包到一台通过高带宽NVLink连接的服务器中来最大化性能。这种设计提供了强大的节点内扩展能力，但仅限于能容纳在单个系统中的工作负载。随着NVIDIA多节点NVLink的引入，这个限制消失了。不同服务器中的GPU现在可以通过NVIDIA NVLink交换机以全NVLink带宽进行通信，将整个机架转变为单一、统一的GPU结构。这实现了跨节点的无缝性能扩展，并构成了超快速分布式训练和推理的基础。

GPU通信库（如NVIDIA NCCL和NVIDIA NVSHMEM）已得到扩展以利用此结构，而像PyTorch这样的框架则在此基础上构建，以实现快速的跨节点、跨GPU通信。这些库会自动检测并使用最快的可用结构（例如NVLink、RDMA、InfiniBand或以太网），因此无论拓扑如何，分布式应用程序无需更改代码即可实现最佳性能。

借助ComputeDomains，我们提供了在Kubernetes上支持多节点NVLink的推荐方式。因此，它已经作为通用层，在其之上构建了整体某中心Kubernetes堆栈中的几个更高级组件，包括KAI调度器、某中心Dynamo和某中心DGX Cloud Lepton。

下图描绘了DGX GB200系统使用的NVIDIA GB200 NVL72机架拓扑。这只是ComputeDomains在Kubernetes上启用的系统类型的一个例子。

图1. 一个DGX GB200系统，顶部有10个计算托盘，底部有8个计算托盘，通过中间的九个NVLink交换机连接，创建了一个通过多节点NVLink（芯片到芯片1.8 TB/s；累计带宽超过130 TB/s）完全连接的72个GPU网状结构。

在Kubernetes上支持多节点NVLink

那么，在Kubernetes上支持多节点NVLink需要什么，ComputeDomains如何帮助实现这一点？关键部分是NVIDIA节点间内存交换服务，这是GPU驱动程序级别的软件，允许GPU跨节点通信。通过IMEX，每个单独的GPU内存导出/导入操作都受到细粒度的访问控制。IMEX在一组被称为IMEX域的节点上运行。

请参考下图，以更好地理解多节点NVLink环境中NVLink域、IMEX域以及其他可能的GPU分区层次之间的关系。

图2. 多节点NVLink环境中可用的分区层级。

可以将ComputeDomains视为IMEX域的泛化。虽然IMEX域存在于驱动层并定义哪些节点可以通过NVLink通信，但ComputeDomains将这一概念泛化并扩展到Kubernetes中。它们代表了多节点工作负载的分布式工作节点之间的连接性（或可达性）的高级概念。IMEX在底层被用来启用这种连接性，这是一个实现细节。

本质上，ComputeDomains会随着多节点工作负载被调度到节点上并运行至完成，动态地创建、管理和拆除IMEX域。

ComputeDomains不需要静态、预配置的IMEX设置，而是实时响应调度事件，围绕分布式作业所落地的一组节点自动形成IMEX域。

IMES本质上提供了可重新配置的隔离边界，而ComputeDomains以一种流畅、透明的方式管理这些边界。借助ComputeDomains，每个工作负载都获得其自己的隔离IMEX域和共享IMEX通道，确保作业所有工作节点之间的GPU到GPU通信，同时安全地与其他作业隔离。ComputeDomain跟随工作负载，并随着工作负载的增长或收缩动态调整其拓扑。当工作负载完成时，其对应的IMEX域和通道会自动清理，释放资源供未来的作业使用。

在不影响利用率的前提下实现隔离

如上所述，IMEX原语旨在作为隐藏在ComputeDomain抽象之下的实现细节。尽管如此，我们认为，围绕工作负载动态形成IMEX域需要一个健壮的、经过实战检验的解决方案，这主要基于以下三个原因：

安全隔离：在零信任环境中，即使物理上通过NVLink连接，也需要对相邻的GPU作业进行安全隔离。
故障隔离：相邻的作业，即使受信任，也不能相互干扰。
成本效益：即使在（1）和（2）的前提下，也必须保持高资源利用率，这在多租户环境中尤其重要。

安全隔离或许可以通过静态NVLink分区来实现，但这将严重抑制资源利用率。

在受信任的环境中，安全隔离可能并不总是最受关注的问题。然而，作业可靠性始终是——因此，故障隔离也是。IMEX域是一个有状态的分布式系统，自然会受到可能导致状态降级或不一致的故障场景和瞬态条件的影响。特别是在大规模情况下，这种情况会以可感知的速率发生。在这些情况下，爆炸半径应仅限于单个作业。

从概念上讲，最大化故障隔离的最安全方法是，在时间和空间上将单个IMEX域仅与一个特定的工作负载绑定——这正是ComputeDomain实现在底层所确保的。

如果没有ComputeDomains，人们将不得不静态设置长期存在的IMEX域，从而在（1）和（2）上都做出妥协。任何用于动态编排IMEX域的自制解决方案最终都会演变成类似于ComputeDomains的东西，并且构建起来会很困难。通过提供一个通用解决方案，我们可以使用户免于自己进行这些努力，并集中汲取经验教训。

在Kubernetes中使用ComputeDomains

ComputeDomains由某中心GPU的DRA驱动程序提供。近期，DRA驱动程序将与某中心GPU Operator一同发布。目前，它需要通过Helm chart手动安装。

详细的安装说明和先决条件可以在此处找到。通常，需要Kubernetes 1.32或更高版本，并启用DRA API和CDI。请务必在安装DRA驱动程序时启用ComputeDomain支持（这是默认设置），并在已设置跨多节点的NVLink分区的环境中运行它（例如在GB200 NVL72机架中，或跨机架）。

该驱动程序正在大力开发中。我们建议关注我们的GitHub项目以保持最新状态；您可以在此处了解最新版本的信息。

部署工作负载

让我们通过一个示例来了解如何创建和使用ComputeDomain。以下Kubernetes规范声明了一个名为compute-domain-0的ComputeDomain：

apiVersion: resource.nvidia.com/v1beta1
kind: ComputeDomain
metadata:
  name: compute-domain-0
spec:
  numNodes: 0    # <-- 此字段已弃用，应始终设置为0
  channel:
    resourceClaimTemplate:
      name: compute-domain-0-rct

目前还没有工作负载引用这个ComputeDomain。此时，它只是一个API对象。ComputeDomain跟随工作负载：它只会在工作负载Pod实际调度到节点上时，及时围绕它们形成。

接下来，让我们指定一个工作负载，并通过在引用中使用compute-domain-0来将其投入使用。

假设我们想要在18个节点上运行一个分布式作业。目标是每个节点使用四个GPU，并在所涉及的所有72个GPU之间建立NVLink可达性。

为此，在本例中，我们将在每个节点上运行一个Kubernetes Pod。每个Pod请求：

四个GPU。
与此工作负载的所有其他Pod位于同一个NVLink分区中（以实现物理可达性）。
加入先前指定的ComputeDomain（实现逻辑可达性）。

以下Kubernetes部署规范示例实现了所有这些目标，关键概念在内联中解释：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-mnnvl-workload
spec:
  # 要求此部署由18个Pod组成。
  replicas: 18
  selector:
    matchLabels:
      job: ex1
  template:
    metadata:
      labels:
        job: ex1
    spec:
      # 将此部署中的所有Pod与先前创建的特定ComputeDomain关联。
      # 为此，请引用与该域关联的所谓资源声明模板。
      # 本例中该模板的名称在ComputeDomain API对象中定义为 `compute-domain-0-rct`。
      # 这里我们还定义了一个新名称 `cd-0`，供下面的容器规范使用。
      resourceClaims:
      - name: cd-0
        resourceClaimTemplateName: compute-domain-0-rct
      # 定义一个 `podAffinity` 规则，以确保所有Pod都调度到同一个NVLink分区中的节点上。
      # 具体来说，要求所有Pod调度到 `nvidia.com/gpu.clique` 节点标签具有*相同*值的节点上。
      # 此标签由某中心GPU Operator设置（基于静态NVLink配置状态）。
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: job
                operator: In
                values:
                - ex1
            topologyKey: nvidia.com/gpu.clique
      containers:
      - name: ctr
        image: ubuntu:22.04
        command: ["mnnvl-workload"]
        resources:
          claims:
          - name: cd-0  # 参见上面的 `resourceClaims`。
          limits:
            nvidia.com/gpu: 4  # 请求四个GPU。

为清晰起见，上面的示例通过声明resourceClaimTemplateName: compute-domain-0-rct来建立与先前指定的ComputeDomain的连接。现在，资源声明模板的概念可能更清晰了：在底层，此部署中的每个Pod都会生成一个唯一的资源声明。

上面的示例还展示了一种确保一组Pod被放置到都属于同一NVLink分区的节点上的典型方法（通过对齐nvidia.com/gpu.clique节点标签值）。当ComputeDomain需要扩展到单个NVLink分区之外时，需要移除或更改此约束。

完整和全面的示例可以在DRA驱动程序文档中找到。

已知限制和未来工作

某中心GPU DRA驱动程序版本包含了对ComputeDomains的重大改进。除此之外，更多旨在提高调度灵活性和易用性的增强功能已在路线图上。

以下是当前已知的两个限制以及计划用于缓解它们的工作：

目前，任何给定ComputeDomain每个节点只能有一个Pod。用户必须了解一个节点中有多少GPU可用，然后通常从单个工作负载Pod中获取所有这些GPU。该Pod中的应用程序然后需要在这些GPU之间细分其工作。我们计划取消此限制，以减少单个节点的相关性。届时，应用程序可以由许多单GPU Pod组成，这些Pod可能位于同一节点上，也可能不位于同一节点上。在这种模式下，关注单元是单个GPU，而不是单个节点——节点边界几乎变得透明。
目前，每个节点最多支持一个ComputeDomain。此约束基于为每个工作负载提供其专用IMEX域的选择（以及每个节点最多只能运行一个IMEX守护进程这一事实）。如果一个ComputeDomain仅占据节点GPU集合的一部分，则该节点中剩余的GPU不能成为任何其他ComputeDomain的一部分。例如，GB200机架中的六GPU ComputeDomain总是会使一定数量的GPU对其他ComputeDomain不可用（最好情况下两个，最坏情况下18个）。取消此约束一方面可以提高资源利用率，但另一方面可能会削弱工作负载之间的故障隔离。没有通用的补救措施，我们将允许用户在成本效益和隔离强度之间的权衡频谱上选择他们的最佳点。这项工作已计划并在此处跟踪。

其他计划正在进行中，例如，进一步增强大规模下的鲁棒性并改进整体可调试性。请关注GitHub上的问题跟踪器并浏览里程碑视图，以获取路线图的最新动态。我们也鼓励您通过问题跟踪器提交问题、错误报告和增强请求。

总结

随着像NVIDIA GB200 NVL72这样的先进多节点GPU架构开始推动高性能AI基础设施的极限，Kubernetes需要能够理解和管理这些现代GPU系统拓扑的抽象。ComputeDomains通过将NVLink和IMEX域等底层结构与Kubernetes原生调度和DRA连接起来，应对了这一挑战。

ComputeDomains随着工作负载在集群中移动，动态地形成、管理和拆除IMEX域，从而实现安全、高带宽的GPU到GPU连接，而无需手动设置。最新版本的某中心GPU DRA驱动程序通过弹性和容错能力扩展了此模型，允许ComputeDomains随着工作负载扩展或收缩，从节点丢失中自动恢复，并加速分布式作业的启动时间。

对于基础设施团队而言，这些变化意味着在GB200 NVL72或DGX GB200系统上进行多节点训练和推理只需最少的设置。对于开发人员而言，这意味着跨复杂、NVLink连接的GPU结构运行分布式训练或推理，现在感觉就像部署标准的Kubernetes工作负载一样简单。这些创新共同使ComputeDomains成为在NVIDIA GB200 NVL72及未来平台上进行可扩展、拓扑感知AI编排的基石。

请参见某中心GPU DRA驱动程序及其最新版本以开始使用。并查看以下其他资源：