NVIDIA DSX OS 配置认证运维 Kubernetes GPU 集群

使用 NVIDIA DSX OS 配置、认证并运行 Kubernetes GPU 集群

2026年11月5日

单张性能不达标的 GPU 就可能拖慢整个分布式训练任务。该节点可能通过基础健康检查并显示正常的利用率，导致运维人员只能在负载实际运行后才发现问题。

此类问题可能在集群生命周期的任何阶段出现。交付时通过就绪性检查的 GPU 集群，会随着节点更换、驱动补丁更新以及容量扩容而发生变化。若缺乏持续验证，最初的认证结果将不再反映集群的实际状态。

这种可见性盲区会导致故障节点的算力被白白浪费，同时出于谨慎起见，健康节点也会被迫闲置。利用率指标往往会掩盖这些损失。有效吞吐量（Goodput）即成功完成的工作量，能提供更准确的集群效率衡量标准。维持集群就绪状态需要在整个运营生命周期中进行验证——包括配置变更后、容量扩展期间，以及修复节点重新上线前。

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

配置：NVIDIA AI Cluster Runtime (AICR)

NVIDIA AI Cluster Runtime (AICR) 为针对 GPU 优化的 Kubernetes 基础设施建立可复现的基线。

• 为网络、存储和驱动等组件定义版本锁定的配置配方。
• 将配置配方渲染为现有部署工具可用的软件包。

认证：NVIDIA Cluster Readiness Engine (NVCRE)

NVIDIA Cluster Readiness Engine (NVCRE) 验证集群是否已准备好运行生产级负载。

• 使用 AI 负载和诊断工具测试 GPU、网络和存储。
• 记录认证结果，并协助识别故障节点。

运行：NVSentinel

NVSentinel 监控集群健康状况，支持故障修复与重新验证。

• 基于 GPU、节点和网络健康状况发布节点状态。
• 配置后，可将不健康节点标记为不可调度或添加污点，排空负载并修复故障。
• 可在节点重新投入服务前触发 NVCRE 重新验证。

上述三个项目均为采用 Apache 2.0 许可证的开源项目，并欢迎外部贡献。

开始之前，请参照安装指南安装并配置 AICR、NVCRE 和 NVSentinel。示例假设您已访问一个 Kubernetes GPU 集群，其中包含所需的命令行工具（CLI）、控制器、依赖项以及已配置的 NVCRE 测试提供程序。

本指南将跟随单个集群经历完整生命周期：从配方进行配置、投产前认证、运行中监控，以及修复后重新认证。每条命令均对应流程中的一个步骤。

配置：可复现的基线

AICR 通过版本控制文件定义集群的软件基线，并将其渲染为现有部署工具可直接应用的制品。AICR 负责生成与校验，而部署器负责应用与状态对齐。声明式模板有助于检测因手动修改导致的配置漂移，并在修复后保持节点配置的一致性。

你只需描述目标环境。AICR 会将其与经过验证的覆盖层库进行比对解析，并输出配方（Recipe）：

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 Application 清单、Flux 资源、Helmfile 发布图或原生 Helm 命令。你可以保留现有的部署工具链，仅使用 AICR 来生成其所需的配置制品。

由于配方以文件形式存在，你可以借助版本历史、代码审查和漂移检测功能来管理基线。

# Check a live cluster against the recipe's constraints
aicr validate --recipe recipe.yaml

# Compare a golden baseline against the live cluster, non-zero exit on drift
aicr diff --baseline ./golden.yaml --target cm://default/aicr-snapshot --fail-on-drift

--fail-on-drift 参数会将漂移检查转变为持续集成（CI）门禁，而非仅仅生成报告。

Certify：证明集群能够运行作业

集群现已构建至已知基线状态，但仍需进行工作负载验证。标准健康检查仅能确认基础服务正在运行，无法证明集群在互联网络上执行高负载多节点作业时不会发生停滞。NVCRE 通过运行训练作业和 NVIDIA Collective Communication Library（NCCL）测试来验证工作负载就绪状态。

NVSentinel 负责管理验证请求、调度门禁、隔离与修复，而 NVCRE 则执行测试并记录结果。表 1 展示了这些职责如何融入节点验证生命周期。

表 1. 节点验证职责、操作与结果

认证配置用于指定待测节点、运行类别以及判定测试通过或失败的阈值：

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

报告将显示每个类别的状态、运行时间、实测带宽以及失败节点的原因。

阈值使认证成为性能门禁。默认情况下未配置任何阈值。若省略上述 options.thresholds 代码块，运行过程仅会报告测量数据，并在测试无法启动时标记为失败。在此情况下，性能低于目标的节点仍可能通过。设置阈值有助于及时发现性能衰退，而非仅仅检测故障。

该目录涵盖 NCCL 通信变体、NVIDIA 数据中心 GPU 管理器（DCGM）第 4 级诊断套件，以及使用 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 默认以监控模式安装：它将故障上报为节点条件，不会执行节点隔离（cordon）、驱逐（evict）或修复操作。您可以在生产集群上部署并评估其报告，待确认信号可靠后，再启用隔离、排空与自动修复功能。

检测模块会发布健康事件，故障隔离规则集则决定节点的具体处置方式。规则集在您的 values 文件中采用通用表达式语言（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"

节点隔离（cordon）或污点（taint）机制可提供明确信号，使您的调度器、告警系统及生命周期管理工具无需直接集成 NVSentinel 即可进行响应。

断路器通过限制滑动窗口内可隔离的 GPU 节点数量来控制影响范围。故障隔离配置指南详细介绍了边界设置及其他规则集选项。

并非所有故障的处理路径都相同。已知的致命错误会直接进入修复流程。健康事件分析器则通过分析节点的历史故障模式来处理其他情况，因此重复发生故障的节点将基于累积记录而非单次事件进入调查队列。

若健康事件的推荐操作为 CONTACT_SUPPORT，则需要人工介入调查或联系技术支持。

闭环机制：如何使就绪状态持续化

节点故障并经修复后需重新加入节点池。在节点恢复服务前执行验证可闭合运维闭环，但人工交接可能中断该过程。手动认证仅能生成瞬时结果，日常运维极易使其失效。运维人员需主动发现集群变更、重新执行验证，随后解读输出结果并采取相应措施。NVSentinel 与 NVCRE 可协助实现此流程的自动化。

配置完成后，两个生命周期事件会自动触发重新验证。NVSentinel 生命周期控制器会在节点加入集群时创建 ValidationRequest，并在节点修复完成后再次创建。它通过封锁（cordon）或污点（taint）来拦截节点的调度请求，随后调用 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 Chart 用于启用新节点验证；fault-quarantine 标志则单独开启修复后的验证流程。schedulingGate.cordon 将封锁操作设为验证阶段的调度拦截器，而 remove: true 表示测试通过后自动解除该节点的封锁状态。

原地驱动升级、Operator 升级或互联架构变更的处理流程则有所不同。此类变更不会自动触发验证。由于基线以文件形式存在，当在线集群偏离预设配置清单时，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 可在节点重新投入服务前协调修复与测试工作，从而减少人工交接环节。表 2 概述了这些工具的处理范围以及运维人员仍需负责的内容。

表 2. AICR、NVCRE 与 NVSentinel 如何改变运维任务，以及哪些职责仍由运维人员承担

快速入门

请从以下项目仓库获取安装说明与示例：

• NVIDIA AI Cluster Runtime (AICR)
• NVIDIA Cluster Readiness Engine (NVCRE)
• NVSentinel

您还可以：

• 在北美 KubeCon + CloudNativeCon 同期举办的 NVIDIA DSX OS AI Inference and Contributor Workshop 中，您可以动手实践这些工具。活动需单独报名，名额有限。
• 欢迎前往 KubeCon 的 NVIDIA 170 号展台，参与更多 Kubernetes 深度解析与现场演示。
• 加入 DSX AI Factory Slack 社区，继续交流探讨。
• 访问 NVIDIA DSX AI Factory GitHub 仓库，探索开源且模块化的组件。