K8S ComputeDomains部署实操：5分钟搞定高效算力

各位跨境实战精英们，大家好！作为一名深耕跨境多年的老兵，今天新媒网跨境获悉了一个重磅消息，这对于我们驾驭大规模AI算力，尤其是NVIDIA GB200这样的顶级硬件来说，无疑是如虎添翼。我们要聊的是一个叫“ComputeDomains”的新概念，它正在彻底改变我们在Kubernetes上部署和管理多节点GPU工作负载的方式。

想象一下，我们正在构建一个全球AI服务平台，处理海量的语言模型训练或低延迟推理。这背后离不开强大的GPU集群，而Kubernetes作为我们高效部署和扩展这些工作负载的利器，其重要性不言而喻。然而，随着AI技术日新月异，硬件架构不断升级，传统的Kubernetes编排和资源管理也面临着新的挑战。

ComputeDomains的出现，正是为了解决这个痛点。它是一个全新的Kubernetes抽象层，其核心使命就是简化多节点工作负载的部署和管理。它能帮助我们自动创建和管理IMEX域，确保多节点工作负载中的每个“打工人”（worker）都能安全、高效地通过多节点NVLink结构，跨节点完成GPU到GPU的内存操作，而无需我们手动去配置那些复杂的底层设置。

简单来说，ComputeDomains将NVLink和IMEX这些底层的GPU技术，与Kubernetes原生的动态资源分配（DRA）概念巧妙地结合起来。它为现代GPU硬件上运行分布式、多节点工作负载提供了坚实的基础。过去，如果没有ComputeDomains，多节点NVLink的配置工作量巨大，而且一旦设定就很难灵活变动，这不仅限制了Kubernetes本该提供的灵活性，还可能在安全隔离、故障隔离和成本效益方面大打折扣。

虽然这项技术已在NVIDIA DGX GB200系统上得到了验证，但ComputeDomains的设计初衷是为了能够通用地支持任何当前或未来支持多节点NVLink的架构，包括未来的NVL576系统。今天，我们就来深入探讨ComputeDomains到底是什么，它为何如此重要，以及我们如何在Kubernetes上利用它来运行自己的分布式、多节点工作负载。

从单节点到多节点GPU算力：一场技术飞跃

要理解ComputeDomains的重要性，我们不妨简单回顾一下GPU系统设计的演进历程。早期的NVIDIA DGX系统，为了追求极致性能，通常会将尽可能多的GPU塞进一台服务器，并通过高带宽的NVLink进行连接。这种设计在单个系统内部实现了强大的性能扩展，但其应用场景也仅限于能在一台机器内完成的工作负载。

而NVIDIA多节点NVLink（MNNVL）的引入，彻底打破了这一限制。现在，不同服务器中的GPU可以通过NVIDIA NVLink交换机实现全带宽通信，这就像把整个机架变成了一个统一的、超大的GPU算力“工厂”。这种设计让性能可以无缝地跨节点扩展，为超高速分布式训练和推理奠定了基础。

为了充分利用这一强大的架构，NVIDIA NCCL和NVIDIA NVSHMEM等GPU通信库也进行了扩展，而像PyTorch这样的主流框架则在其之上构建，实现了快速的跨节点、跨GPU通信。这些库能够智能地自动检测并使用最快的可用互连（比如NVLink、RDMA、InfiniBand或以太网），确保分布式应用无论拓扑结构如何，都能获得最佳性能，而且无需修改代码。新媒网跨境认为，ComputeDomains正是支持Kubernetes上多节点NVLink的最佳实践方式。它已经成为NVIDIA Kubernetes整体堆栈中多个上层组件（如KAI调度器、NVIDIA Dynamo和NVIDIA DGX Cloud Lepton）的通用底层支撑。

下图展示了DGX GB200系统使用的NVIDIA GB200 NVL72机架拓扑结构。这只是ComputeDomains在Kubernetes上能够释放强大潜力的一个典型例子。
A DGX GB200 system with 10 compute trays on top, eight compute trays on bottom, connected through nine NVLink switches in the middle, creating a fully connected mesh of 72 GPUs connected via multi-node NVLink (1.8 TB/s chip-to-chip; over 130 TB/s cumulative bandwidth).

Kubernetes如何支持多节点NVLink：ComputeDomains的魔法

那么，Kubernetes是如何支持多节点NVLink的呢？ComputeDomains又在其中扮演了怎样的角色？这里的关键是NVIDIA的节点间内存交换服务（IMEX）。IMEX是GPU驱动程序层面的软件，它让不同节点间的GPU能够相互通信。通过IMEX，每一个独立的GPU内存导出/导入操作都受到精细的访问控制。

IMEX在一个由节点组成的“IMEX域”内运行。请看下图，以便更好地理解NVLink域、IMEX域以及多节点NVLink环境中其他可能的GPU分区层级之间的关系。
A diagram showing layers of partitioning available in a multi-node NVLink environment.

我们可以将ComputeDomains看作是IMEX域的一种高级抽象和泛化。IMEX域存在于驱动层，定义了哪些节点可以通过NVLink进行通信；而ComputeDomains则将这个概念扩展到了Kubernetes。它代表了多节点工作负载分布式“打工人”之间更高级别的连接性（或可达性）概念。至于底层使用IMEX来实现这种连接，那只是一个实现细节，我们开发者不必过多操心。

本质上，ComputeDomains会随着多节点工作负载被调度到节点并运行结束，动态地创建、管理和销毁IMEX域。它不再需要静态、预先配置的IMEX设置，而是能够实时响应调度事件，自动围绕分布式作业所处的节点集合形成IMEX域。IMEX本质上提供了可重配置的隔离边界——而ComputeDomains则以流畅、透明的方式管理这些边界。通过ComputeDomains，每个工作负载都拥有自己独立的IMEX域和共享IMEX通道，确保作业中所有“打工人”之间的GPU到GPU通信，同时又与其他作业安全隔离。ComputeDomain会跟随工作负载的生命周期，并随着工作负载的增长或缩小动态调整其拓扑结构。当工作负载完成时，其相应的IMEX域和通道会被自动清理，释放资源供未来的作业使用。

隔离性与利用率的双赢

前面我们提到，IMEX原语在ComputeDomain抽象层之下，是隐藏的实现细节。但我们必须强调，要动态地围绕工作负载形成IMEX域，一个健壮且经过实战考验的解决方案是至关重要的，这主要有三个原因：

安全隔离： 在一个零信任的环境中，即使物理上通过NVLink相连，相邻的GPU作业之间也需要有清晰的安全隔离，这是确保数据安全和业务稳定的基石。
故障隔离： 即使是相互信任的相邻作业，也绝不能互相干扰。一个作业出现问题，不能影响到其他作业的正常运行。
成本效益： 在实现了安全和故障隔离的前提下，资源利用率仍然要保持高水平，尤其是在多租户环境中，这是我们运营降本增效的关键。

或许有人会说，安全隔离可以通过静态的NVLink分区来实现，但这会极大地牺牲资源利用率。在一个完全信任的环境中，安全隔离可能不是最重要的考量，但作业的可靠性永远是！因此，故障隔离也同样重要。

IMEX域本质上是一个有状态的分布式系统。它必然会面临各种故障场景和瞬态条件，可能导致状态降级或不一致。尤其是在大规模部署时，这种情况发生的概率会明显增加。在这种情况下，影响范围必须被限制在一个单独的作业之内。

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

如果没有ComputeDomains，我们可能不得不静态设置长期存在的IMEX域，从而在安全和故障隔离上做出妥协。任何自己摸索出来的动态编排IMEX域的方案，最终都会演变成类似ComputeDomains的东西，而且开发难度会非常大。通过提供一个通用的解决方案，我们可以帮助用户省去大量的重复工作，并集中吸取经验教训。

在Kubernetes中使用ComputeDomains：手把手实战

ComputeDomains是作为NVIDIA DRA driver for GPUs的一部分提供的。在不久的将来，DRA驱动程序将随NVIDIA 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个节点上。我们的目标是每个节点使用4个GPU，并在所有涉及的72个GPU之间建立（所有到所有）的NVLink可达性。为此，在这个例子中，我们将在每个节点上运行一个Kubernetes Pod。每个Pod会请求：

4个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`
      # 节点标签值相同的节点上。
      # 这个标签由NVIDIA 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 # 请求4个GPU。

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

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

完整的、综合性的示例（包括一组可运行的验收测试，用于验证ComputeDomains是否设置并正常工作）可以在DRA驱动程序的文档中找到，建议大家多去“抄作业”。

已知局限与未来展望：未雨绸缪

NVIDIA DRA Driver for GPUs的v25.8.0版本对ComputeDomains进行了重大改进。除此之外，未来路线图上还有更多增强功能，旨在实现更灵活的调度和更易用的操作。

以下是目前已知的两个局限以及计划中的改进工作：

目前，每个节点只能有一个Pod属于任何给定的ComputeDomain。 用户必须清楚每个节点有多少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连接，而无需进行任何手动设置。NVIDIA DRA driver for GPUs最新的v25.8.0版本进一步扩展了这一模型，增加了弹性和容错能力，允许ComputeDomains随工作负载的扩展或收缩而调整，自动从节点故障中恢复，并加速分布式作业的启动时间。

对于基础设施团队来说，这意味着在GB200 NVL72或DGX GB200系统上进行多节点训练和推理所需的设置工作将降至最低。对于开发人员来说，在复杂、NVLink连接的GPU结构上运行分布式训练或推理，现在感觉就像部署一个标准的Kubernetes工作负载一样简单。

总而言之，这些创新共同使ComputeDomains成为NVIDIA GB200 NVL72及未来平台上可扩展、拓扑感知的AI编排的基石。赶紧查看NVIDIA DRA driver for GPUs及其最新的v25.8.0版本，开启您的AI算力新篇章吧！

新媒网（公号: 新媒网跨境发布），是一个专业的跨境电商、游戏、支付、贸易和广告社区平台，为百万跨境人传递最新的海外淘金精准资讯情报。

本文来源：新媒网 https://nmedialink.com/posts/k8s-computedoamins-boost-compute-5min.html