Kubernetes 管理节点上运行的内容。管理节点本身才是挑战所在：内核设置、系统软件包、存储布局、安全代理，以及 GPU 工作负载所依赖的主机级调优。许多团队通过 Ansible playbook、自定义脚本和手动运行手册来管理这些内容。这在新的集群在不同区域上线、内核升级破坏 RDMA，或者本周必须在整个机群中修复某个 CVE 之前，都还算行得通。
GPU 基础设施让这一挑战更加艰巨。你不能简单地丢弃一个 GPU 节点再启动一个新的。硬件稀缺，更换可能需要数小时，而长时间运行的训练作业无法简单地重新调度。因此，运维问题不是如何更改一个节点，而是如何在不中断训练运行的情况下更改所有节点。如今，这个答案通常是一张电子表格、一个维护窗口，以及一位凌晨三点盯着终端的工程师。
NVIDIA DSX 平台帮助你设计和运营 AI 工厂，在这里，整个设施被视为一个单一系统，而不是一组机器的集合。主机配置遵循同样的逻辑：变更的单位是机群，而不是节点。NVIDIA DSX OS 是开源软件层，而 NodeWright 是其中负责配置和更新底层主机操作系统的项目。
从脚本到声明式节点管理
DSX OS 通过一个模块化的开源项目组合来应对这一挑战，涵盖 AI 就绪基础、资源与工作负载编排，以及生产 AI 服务。AI 就绪基础定义、配置、验证并保障加速 Kubernetes 基础设施。NVIDIA GPU Operator、NVIDIA Network Operator、Topograph、NVIDIA GPU 的 DRA 驱动、NodeWright、NVIDIA 集群就绪引擎（NVCRE）以及 NVSentinel 提供了配套的基础设施能力。
NodeWright 以声明式方式配置并安全更新 Kubernetes 节点操作系统，而不会中断工作负载。它是一个开源、Kubernetes 原生的软件包管理器，用于大规模修改和维护主机基础设施。可以把 NodeWright 想象成整个集群的 apt 或 yum：感知工作负载、感知中断预算，并能够在机群中逐步推出变更。
NodeWright 已在 NVIDIA 以 Skyhook 之名投入生产运行，并已作为开源提供。本文正式介绍 NodeWright 这一名称。
为什么 Kubernetes 需要自己的软件包管理器
配置机器已经有出色的工具。Ansible 和 Puppet 已经做了很多年。它们被设计用于一个机器被单独管理的世界，而不是作为正在运行敏感工作负载的集群的一部分。
当你需要在 200 个 GPU 节点上更新一个内核参数时，困难的部分不是运行脚本，而是在不中断这些节点上训练任务的情况下完成更新。传统的配置管理并不感知 Kubernetes。它不会在做出更改前封锁节点、等待关键 Pod 完成，或在重启前驱逐工作负载。它也不会在集群内部跟踪成功或失败，而你的其他可观测性数据早已在那里。
NodeWright 填补了这一空白。它管理主机级变更的完整生命周期，从安装到配置、升级和卸载。在此过程中，它尊重你的工作负载已经依赖的 Kubernetes 原语：PodDisruptionBudgets
、节点选择器、污点和容忍。NodeWright 包被定义为自定义资源，因此它们的部署方式与集群中其他所有内容一样：通过 kubectl、Helm、Argo CD、Flux，或你已经在使用的任何 GitOps 工具。
NodeWright 的工作原理
NodeWright 有三个主要组件：operator、自定义资源和包。
Operator 是一个 Kubernetes 控制器，它监视 NodeWright 自定义资源并管理跨节点的变更生命周期。包是携带实际修改的容器镜像：脚本、配置和二进制文件。包还包括验证脚本，当修改不正确时，这些脚本会暴露失败并停止滚动更新。
apiVersion: nodewright.nvidia.com/v1alpha1
kind: NodeWright
metadata:
name: gpu-node-tuning
spec:
nodeSelectors:
matchLabels:
nodepool: gpu
interruptionBudget:
percent: 33
podNonInterruptLabels:
matchLabels:
workload: long-running-training
packages:
nvidia-tuned:
version: 0.9.0
image: ghcr.io/nvidia/nodewright-packages/nvidia-tuned
当你应用一个 NodeWright 自定义资源时，operator 会在每个目标节点上编排一个谨慎的执行序列。图 1 展示了完整序列，以及受保护的工作负载如何将其暂停。
图 1. operator 在做出任何更改之前先对节点执行 cordon，并且只有在更改完成后才对其执行 uncordon。被标记为不可中断的 Pod 会使序列停留在 wait 阶段，因此正在运行的训练作业会在节点被中断之前完成或迁移
Cordon。将节点标记为不可调度，使没有新的工作负载落到其上。Wait。让关键工作负载优雅完成。你通过标签声明哪些 Pod 绝不能被中断。Drain。驱逐剩余的 Pod，默认遵循 PodDisruptionBudgets，当默认行为不足时可配置 drain 行为。Apply and configure。运行软件包：设置内核参数、安装代理并配置系统服务。Interrupt。如果更改需要，则重启服务或重启节点。Uncordon。将节点归还给集群，准备好承载工作负载。
这一序列正是因内核更新而损失一半训练运行，与在整个机群中落地同一更新而不中断工作负载之间的区别。
NodeWright 软件包可以执行许多通常需要 root 访问权限的主机级操作，而无需回收节点。它们可以设置 sysctl
和 GRUB
参数、配置崩溃转储收集、创建逻辑卷、安装安全代理、修复 CVE，以及执行其他系统级配置任务。NodeWright 跟踪每个节点上每个软件包的状态和语义版本，使其能够区分全新安装、升级和降级。软件包还可以声明依赖关系，NodeWright 使用这些依赖关系来确定正确的执行顺序。
验证已内置于软件包生命周期中。应用、配置、升级、卸载以及中断后工作都可以与一项检查配对，该检查验证预期的节点状态，并通过 Kubernetes 暴露失败。例如，一个 CVE 修复软件包可以检测某个存在漏洞的内核模块是否仍处于加载状态，并将该软件包标记为失败，使运维人员能够立即了解受影响的节点，而不是让他们之后通过工作负载故障才发现问题。
随着集群规模扩大，这一模型同样延伸到节点就绪状态。新配置的节点否则可能会在所需配置和调优应用之前就变为可调度。NodeWright 可以要求新节点以 Kubernetes taint 加入集群，完成所需的软件包操作和验证检查，并且只有在节点通过后才移除该 taint。这创建了一条从已配置到已配置完成到已验证到可调度的受控路径，确保新容量在真正就绪之前不会接受生产工作负载。
大规模安全发布
将一项更改推送到一个节点很简单。将其推送到一千个运行生产训练作业的 GPU 节点则是另一个问题。
NodeWright 的 DeploymentPolicy
resource 提供了渐进式发布策略，用于控制变更如何在整个集群中传播。你定义 compartment，即通过标签选择的命名节点组，每个组都有自己的中断预算和发布策略。图 2 展示了三种可用的策略。
图 2。Compartment 将集群分区，每个 compartment 携带自己的策略和预算。批次阈值设定发布推进所需的成功率，失败阈值则在连续过多批次失败时停止该 compartment
固定。恒定批次大小。每次更新五个节点，每次都如此。线性。按固定增量增加批次。从 1 开始，然后 2，然后 3，逐步建立信心。指数。将批次乘以增长因子。从 1 开始，然后 2，然后 4，然后 8。一旦信任它，速度就很快。
每种策略都包含一个批次阈值，即推进到下一批次所需的最低成功百分比。可选的失败阈值会在连续过多批次失败时停止该 compartment。你设定风险容忍度。NodeWright 强制执行它。
这意味着你可以用单个金丝雀节点启动全集群内核更新，验证其健康，然后让发布自动加速。
如果出现问题，更新会停止而不是级联扩散。NodeWright 在其状态中报告错误，标记失败的 Job，并向每个受影响的节点添加标签和条件。你可以通过 Kubernetes API 快速识别并分类原因。
NodeWright 软件包与 NVIDIA AI Cluster Runtime
NodeWright 作为一个多功能的软件包管理平台运行。由于软件包执行需要 root 级权限的操作，主机修改直接依赖原生 Kubernetes 原语：细粒度 RBAC 控制用户权限，准入控制器验证规范，集成验证检查确保每一步的状态一致性。公共软件包仓库提供模块化的基础组件，用于运行 shell 命令、管理绑定挂载和建立内核崩溃转储收集器。
NVIDIA 还发布软件包，这些软件包基于 NVIDIA 团队在大规模运行 GPU 集群时积累的运维知识。
调优软件包使用基于意图的模型。你无需指定配置文件名称，而是声明你的加速器以及你用它做什么，例如 NVIDIA Blackwell GPU 和多节点训练。软件包会自动组装正确的配置文件：内核参数、电源管理和系统设置。覆盖范围涵盖 NVIDIA Hopper 和 Blackwell GPU，并为任何 NVIDIA GPU 提供通用基线配置文件，以及针对不同云环境的变体。一个专用软件包覆盖运行 Container-Optimized OS 的 Google Kubernetes Engine (GKE) 节点，在这些节点上通常的调优栈不可用。
节点设置软件包为特定的云和加速器组合自动化引导步骤，处理内核版本管理以及为带有 NVIDIA Hopper 或 Blackwell GPU 的 Amazon Elastic Kubernetes Service (Amazon EKS) 集群安装 Elastic Fabric Adapter (EFA) 驱动。
这些软件包是一项更广泛工作的一部分。NodeWright 与 NVIDIA AI Cluster Runtime（AICR）集成。AICR 收录了驱动程序、算子、内核和系统配置的已知良好组合，并将其发布为版本锁定的配方。其组件目录同时固定了 NodeWright 算子以及承载环境特定调优的 NodeWright 定制项，然后将它们渲染为可直接部署的捆绑包，供 Helm、Argo CD、Flux 或 Helmfile 使用。NodeWright 将这些配方中主机层面的部分应用到正在运行的节点上。
两个配套的 NVIDIA 开源项目——NVCRE 和 NVSentinel——完善了整个生态系统。NVCRE 负责工作负载前的验证，以确认加速基础设施已具备生产就绪状态，而 NVSentinel 则监控运行时故障，并协助执行 cordon、drain 和修复操作。这些工具与 NodeWright 一起，为 GPU 加速的 Kubernetes 集群提供配置、维护和自愈支持。
需要明确范围：NodeWright 并不取代 NVIDIA GPU Operator 或 NVIDIA Network Operator。它管理的是它们下方的主机操作系统层。
开始使用
NodeWright 可通过 Helm 安装到任何 Kubernetes 集群中。该 chart 以 OCI 制品的形式分发，因此无需添加仓库：
helm install nodewright oci://ghcr.io/nvidia/nodewright/charts/nodewright \
--version <chart-version> \
--namespace nodewright \
--create-namespace
在此基础上，定义一个 NodeWright 自定义资源，包含你想要应用的软件包，通过标签定位你的节点，剩下的由 operator 处理。
NodeWright 仓库：源代码、问题和讨论软件包仓库：NVIDIA 和社区软件包NodeWright 文档：架构、CLI 参考和部署策略NVIDIA AI Cluster Runtime：更广泛的经验证配置系统
参与其中
NodeWright 采用 Apache 2.0 许可证，是 DSX OS 的一部分，DSX OS 是一个模块化的开源项目组合，涵盖 AI 就绪基础、资源和工作负载编排以及生产 AI 服务。采用一个项目、集成几个项目，或将它们组合成一个平台。价值在于开放接口、独立采用和一致的生命周期，而非单体式堆栈。
在客户规模下运行此堆栈会及早暴露故障模式，NVIDIA 团队会与社区分享这些观察结果。软件包仓库正是 NodeWright 实现这一目标的地方。NodeWright 团队特别感兴趣的是目录尚未覆盖的硬件和云组合的软件包，以及来自运行团队尚未表征的配置的运维人员的调优配置文件。
Kubernetes 改变了团队管理工作负载的方式。底层节点——尤其是运行高要求 AI 工作负载的 GPU 节点——仍然依赖脚本和手动运行手册。NodeWright 将相同的声明式、自动化、安全的方法带到主机层。按需采用。帮助塑造未来。
项目参考： NodeWright 仓库**和 NodeWright 软件包仓库。