使用NVIDIA DSX OS配置、认证和运维Kubernetes GPU集群-AI基础设施-至顶网

一块性能不达标的GPU就可能拖慢整个分布式训练任务的速度。该节点可能通过了基本健康检查，利用率显示正常，导致运维人员只有在工作负载运行后才发现问题。

这类问题可能出现在集群生命周期的任何阶段。一个在交付时通过就绪检查的GPU集群，会随着节点更换、驱动程序补丁更新和容量扩充而发生变化。如果不进行反复验证，最初的认证结果将不再反映集群的实际状况。

这种可见性缺口会导致故障节点浪费算力，也会使健康节点出于谨慎而闲置。利用率指标可能掩盖这些损失。有效产出（Goodput，即成功完成的工作量）是衡量集群效率更有用的指标。要维持集群的就绪状态，需要在整个运维生命周期中进行验证——包括配置变更后、容量增长时，以及修复后的节点重新投入使用之前。

NVIDIA DSX AI工厂平台汇聚了用于设计、构建和运维高效、具备弹性的AI工厂所需的各项技术。其开源软件层NVIDIA DSX OS包含了用于配置、认证以及维护加速型Kubernetes基础设施健康状态的工具。

配置：NVIDIA AI集群运行时（AICR）为GPU优化的Kubernetes基础设施建立了一个可复现的基线。它为网络、存储、驱动程序等组件定义了版本锁定的配置方案，并将这些方案渲染为可供现有部署工具使用的软件包。

认证：NVIDIA集群就绪引擎（NVCRE）验证集群是否已准备好运行生产工作负载。它使用AI工作负载和诊断工具测试GPU、网络和存储，记录认证结果并帮助识别故障节点。

运维：NVSentinel负责监控集群健康状况，并支持故障修复与重新验证。它会根据GPU、节点和网络的健康状况发布节点状态信息。在配置完成后，它可以隔离或标记不健康的节点、清空工作负载并修复故障，还能在节点重新投入使用前触发NVCRE进行重新验证。

以上三个项目均为基于Apache 2.0许可证的开源项目，欢迎外部贡献。

在开始之前，请使用各自的安装指南安装并配置AICR、NVCRE和NVSentinel。以下示例假设您已拥有一个配置好所需CLI工具、控制器、依赖项和NVCRE测试提供者的Kubernetes GPU集群。

本文将跟随一个集群走完其整个生命周期：从配方进行配置、生产使用前的认证、运行期间的监控，以及修复后的重新认证。每条命令都是这一流程中的一个步骤。

配置：可复现的基线

AICR以版本控制的文件形式定义集群的软件基线，并将其渲染为现有部署工具可以应用的产物。它负责生成和验证，部署工具负责应用和协调。声明式模板有助于检测因手动更改而产生的配置偏差，并在修复后保持节点配置的一致性。

您只需描述目标环境，AICR会根据已验证的覆盖层库进行解析，并生成一份配方：

```

aicr recipe --service eks --accelerator h100 --os ubuntu \ --intent inference --platform dynamo -o recipe.yaml

```

生成的配方中每个组件条目都锁定了版本号，并声明了该组件安装前必须处于健康状态的依赖项：

```

apiVersion: aicr.run/v1alpha2 componentRefs: - name: dynamo-platform chart: dynamo-platform namespace: dynamo-system source: https://helm.ngc.nvidia.com/nvidia/ai-dynamo type: Helm version: 1.4.2 valuesFile: components/dynamo-platform/values.yaml dependencyRefs: - grove - cert-manager - kube-prometheus-stack - gpu-operator - kai-scheduler

```

该配方包含三个关键特性：

版本锁定：版本号是固定的，有助于复现软件配置并排查故障。相比之下，浮动标签可能随时间指向不同的软件版本，使故障难以复现。

依赖关系图：dependencyRefs声明了必须先安装并保持健康状态的组件。AICR在渲染软件包时会解析该依赖图，因此部署顺序已编码在部署工具所应用的产物中。您无需指定cert-manager必须在NVSentinel之前安装，后续添加组件也不需要重新编号。

逐组件的健康断言：每个条目都包含一个healthCheckAsserts模块，该模块在安装后运行，检查组件是否满足所配置的健康标准。Kubernetes可能会将处于CrashLoopBackOff状态的pod报告为Running，因此仅基于pod阶段的检查可能会漏掉损坏的组件。随附的断言会基于容器的等待原因进行过滤，而非仅依赖pod阶段。

渲染配方是一个独立的步骤，用于将AICR与您现有的流水线连接起来：

```

aicr bundle --recipe recipe.yaml --deployer argocd --output ./bundles

```

--deployer参数接受helm、argocd、argocd-helm、flux或helmfile，因此同一份已验证的配方可以转化为Argo CD应用程序清单、Flux资源、Helmfile发布图，或普通的Helm命令。您可以保留现有的部署工具，利用AICR生成其所需的配置产物。

由于配方是以文件形式存在的，您可以利用版本历史记录、代码审查和偏差检测来管理基线。

```

# 根据配方约束检查实时集群 aicr validate --recipe recipe.yaml # 将黄金基线与实时集群进行比较，若存在偏差则以非零状态退出 aicr diff --baseline ./golden.yaml --target cm://default/aicr-snapshot --fail-on-drift

```

--fail-on-drift参数将偏差检测转变为持续集成（CI）环节中的一道关卡，而不仅仅是一份报告。

认证：证明集群能够胜任任务

此时集群已按照既定基线构建完成，但仍需进行工作负载验证。标准健康检查只能确认基础服务正在运行，无法确认集群能否在其互连网络上顺畸地运行要求苛刻的多节点任务而不发生停滞。NVCRE通过运行训练任务和NVIDIA集合通信库（NCCL）测试来验证工作负载的就绪状态。

NVSentinel负责管理验证请求、调度门控、隔离和修复，而NVCRE负责运行测试并记录结果。下表展示了这些职责在节点验证生命周期中的分工。

一份认证文件指定了待测试的节点、要运行的测试类别以及决定测试通过或失败的阈值：

```

apiVersion: nvcre.nvidia.com/v1alpha1 kind: Certification metadata: name: gpu-cluster-cert spec: target: nodeSelector: nvidia.com/gpu.present: "true" categories: - domain: communication variant: nccl-all-reduce - domain: training variant: nemotron5-8b options: thresholds: busBandwidthGBps: "value >= 300"

```

nvcrectl certification run --cert-file certification.yaml --wait nvcrectl certification report gpu-cluster-cert -n <namespace>

```

该报告展示了每个测试类别的状态、运行时间、测得的带宽以及任何失败节点的原因。

阈值使认证成为一道性能关卡。默认情况下未配置任何阈值。如果没有上述的options.thresholds模块，运行结果只会报告测量数据，仅在测试无法启动时才会判定失败。表现略低于目标值的节点仍可能通过。阈值有助于捕捉性能下降的情况，而非仅仅是硬件故障。

测试目录涵盖了NCCL通信变体、NVIDIA数据中心GPU管理器（DCGM）四级诊断套件，以及使用NVIDIA NeMo框架的80亿参数和560亿参数模型进行的预训练工作负载测试。WorkloadRun资源可以将您自己的容器化测试转变为一项认证检查。NVCRE会从目标节点推断出其余信息，因此清单文件在任何受支持的平台上都能保持简洁。

这些测试有助于识别在遥测数据中并不明显的性能问题。一块性能略低于目标值的GPU可能不会产生Xid错误、不会突破监控阈值，也不会使节点指标显得异常。但正是这一块GPU就可能将同步训练任务拖慢到最慢的那个等级，而运维人员可能要等数小时后才发现，甚至要等到用户投诉才知晓。NCCL带宽测试可以揭示这种性能下降问题。

隔离故障原因同样重要。如果一个64节点的all-reduce操作产生了较差的带宽，每个节点都有嫌疑，而手动逐一排查可能相当耗时。NVCRE会将失败的组进行拆分并重新运行测试，直到达到最小分组规模，然后报告出有嫌疑的节点并说明各自的原因。

应在将集群或新增容量交付给租户之前，以及修复后的硬件重新加入资源池之前，运行NVCRE。

运维：负载下的检测与修复

经过认证的集群现在正在运行工作负载，需要保持健康状态。AICR和NVCRE提供的是时间点验证。NVSentinel则在工作负载运行期间持续运行。

NVSentinel监控集群已经产生的各类信号：DCGM健康检查、Xid错误、网络接口卡（NIC）状态以及云服务商的维护事件。它不消耗GPU时间，使GPU可持续用于工作负载。

NVSentinel默认以监控模式安装：它会将故障报告为节点状态，但不会隔离、驱逐或修复节点。您可以在实时集群上部署该工具，同时评估其报告内容。在确信所报告的信号可靠后，您可以启用隔离、清空和修复功能。

检测会发布一个健康事件；故障隔离规则集决定了该节点将面临的处理方式。规则集在配置文件中使用通用表达式语言（CEL）表达式：

```

fault-quarantine: ruleSets: - enabled: true version: "1" name: "GPU fatal error ruleset" priority: 100 match: all: - kind: "HealthEvent" expression: "event.agent == 'gpu-health-monitor' && event.componentClass == 'GPU' && event.isFatal == true" - kind: "Node" expression: | !('k8saas.nvidia.com/ManagedByNVSentinel' in node.metadata.labels && node.metadata.labels['k8saas.nvidia.com/ManagedByNVSentinel'] == "false") cordon: shouldCordon: true taint: key: "nvidia.com/gpu-error" value: "fatal" effect: "NoSchedule"

```

隔离或标记操作会提供一个信号，供您的调度器、告警系统和生命周期管理工具使用，而无需直接与NVSentinel集成。

断路器机制通过限制在一个滑动时间窗口内可被隔离的GPU节点数量来控制影响范围。故障隔离配置指南详细说明了限制范围以及其余的规则集选项。

并非每个故障都走相同的处理路径。已知的致命错误会直接进入修复流程。健康事件分析器通过检测节点故障历史中的模式来处理其他情况，因此一个反复发生故障的节点会基于累积的记录（而非单一事件）被纳入调查范围。

带有CONTACT_SUPPORT建议操作标签的健康事件需要人工调查或技术支持介入。

闭环：就绪状态如何实现持续化

一个节点发生故障、经过修复后需要重新加入资源池。节点重新投入使用前的验证可以闭合这一运维环节，但人工交接可能会打断这一流程。人工认证只能产生某一时间点的结果，而常规运维操作可能使其过时。必须有人注意到集群发生了变化，重新运行验证，然后读取输出结果并采取相应行动。NVSentinel和NVCRE可以帮助实现这一流程的自动化。

两类生命周期事件在配置完成后会自动触发重新验证。NVSentinel生命周期控制器会在节点加入集群时以及节点经过修复重新上线时创建一个ValidationRequest（验证请求）。它会使用隔离或标记手段对该节点的调度进行门控，然后使用NVCRE运行测试并记录结果。控制器会评估这些结果，并在测试通过后移除门控，因此一个仍未通过验证的节点无法悄然重新加入资源池。当您将nvcre-provider配置为其测试提供者时，这些测试就是通过NVCRE运行的NCCL或NVIDIA Nemotron测试：

```

global: lifecycleManager: enabled: true fault-quarantine: validation: enabled: true lifecycle-manager: config: schedulingGate: cordon: remove: true

```

lifecycle-manager配置图启用了新节点验证功能；fault-quarantine标志则单独选择启用修复后的验证功能。schedulingGate.cordon将隔离设置为验证的调度门控，而remove: true则会在节点测试通过后取消隔离。

对于就地驱动程序升级、运维工具升级或网络结构变更而言，处理流程有所不同。这些变更不会自动触发验证。由于基线是以文件形式存在的，aicr diff --fail-on-drift命令会在实时集群偏离其配方时使流水线阶段失败，从而在进行变更的同一流水线中触发认证运行。

先隔离受影响的节点，然后创建一个指定这些节点及待运行测试的验证请求：

```

apiVersion: nvsentinel.nvidia.com/v1alpha1 kind: ValidationRequest metadata: name: post-driver-upgrade spec: nodes: - name: node-a - name: node-b tests: - nccl-all-reduce - nemotron-5b

```

控制器同样会根据结果采取行动。如果请求通过，一旦没有其他测试占用该节点，控制器就会移除调度门控。如果测试在重试后仍失败，该节点将保持隔离状态。

故障也可能在验证期间显现：例如GPU可能在训练测试过程中开始出现热节流现象。此时NVSentinel会隔离该节点，控制器会在修复后重新运行测试。该节点将保持门控状态，直至通过验证。

验证请求和节点都带有可供查询的状态信息：

```

kubectl get validationrequests kubectl get nodes -l nvsentinel.nvidia.com/validation-state=validation-failed

```

恢复过程无需手动编辑节点：之后一次通过相同测试的请求会清除失败记录并移除门控。删除所有引用该节点的失败验证请求也可以释放该节点，而无需重新运行验证。

两者之间的职责边界十分清晰。NVCRE的职责止步于归因，即记录哪些节点失败以及失败的原因；而NVSentinel则负责隔离和修复。如果两个系统同时对同一节点进行隔离，可能会导致重复隔离和清理不同步的问题。

这种职责分离同样使您可以使用自己的节点生命周期管理工具。平台团队可以使用相同的认证结果，并承担起NVSentinel的角色。扩展这套技术栈只需编写一个规则集或策略即可，而无需分叉（fork）整个项目。

这对运维人员意味着什么

AICR、NVCRE和NVSentinel帮助运维人员使配置、验证和恢复流程变得可复现。在启用修复和生命周期验证功能后，NVSentinel可以在节点重新投入使用前协调修复和测试工作，减少人工交接环节。下表概述了这些工具所涵盖的工作范围，以及仍需运维人员管理的内容。