Kubernetes管理着运行在节点上的内容，而管理节点本身才是真正的挑战：内核设置、系统软件包、存储布局、安全代理，以及GPU工作负载所依赖的主机级调优。许多团队通过Ansible脚本、自定义脚本和人工操作手册来管理这些工作。这种方式在一切正常时还算可行，但一旦新集群在不同地区上线、内核升级导致RDMA故障，或者本周必须在整个集群范围内修复某个CVE漏洞，问题就会暴露出来。
GPU基础设施让这一挑战变得更加复杂。你不能简单地丢弃一个GPU节点然后重新启动一个新的。硬件资源稀缺，更换可能需要数小时，而长时间运行的训练任务也无法简单地重新调度。因此，运维层面真正的问题不是如何修改单个节点，而是如何在不中断训练任务的情况下修改所有节点。如今，这个问题的答案通常是一张表格、一个维护窗口，以及一位在凌晨三点盯着终端的工程师。
英伟达DSX平台帮助用户设计和运营AI工厂，将整个设施视为一个统一系统，而非一堆独立的机器。主机配置遵循同样的逻辑：变更的单位是整个集群，而不是单个节点。英伟达DSX OS是这一理念下的开源软件层，而NodeWright则是其中负责配置和更新底层主机操作系统的项目。
从脚本到声明式节点管理
DSX OS通过一套模块化的开源项目组合来应对这一挑战，涵盖AI就绪基础层、资源与工作负载编排，以及生产级AI服务。AI就绪基础层负责定义、配置、验证并保障加速型Kubernetes基础设施的可靠性。英伟达GPU Operator、英伟达Network Operator、Topograph、面向英伟达GPU的DRA驱动、NodeWright、英伟达集群就绪引擎（NVCRE）以及NVSentinel共同提供支撑性的基础设施能力。
NodeWright能够以声明式方式配置并安全更新Kubernetes节点操作系统，且不会中断工作负载。它是一个开源的、原生适配Kubernetes的软件包管理工具，用于在大规模环境下修改和维护主机基础设施。可以把NodeWright想象成整个集群的apt或yum：它能感知工作负载状态，了解中断预算，并能在整个集群范围内逐步推进变更。
NodeWright此前已作为Skyhook在英伟达内部投入生产使用，现已开源发布。本文正式介绍NodeWright这一名称。
为什么Kubernetes需要专属的软件包管理工具
用于配置机器的优秀工具早已存在，Ansible和Puppet多年来一直在做这件事。但它们的设计初衷是针对逐台管理机器的场景，而不是针对正在运行敏感工作负载的集群成员。
当你需要在200个GPU节点上更新一个内核参数时，真正困难的不是运行脚本本身，而是在不干扰这些节点上训练任务的前提下完成更新。传统配置管理工具并不了解Kubernetes：它不会在修改前先隔离节点，不会等待关键Pod运行结束，也不会在重启前先清空工作负载。它也无法在集群内部追踪操作的成败情况，而集群内部恰恰是你其他可观测性数据所在的地方。
NodeWright正是填补了这一空白。它管理主机级变更的完整生命周期，从安装、配置、升级到卸载，全程遵循工作负载已经依赖的Kubernetes原语：PodDisruptionBudget（Pod中断预算）、节点选择器、污点与容忍度。NodeWright的软件包以自定义资源的形式定义，因此它们的部署方式与集群中其他组件完全一致：通过kubectl、Helm、Argo CD、Flux，或者你已经在使用的任何GitOps工具。
NodeWright的工作原理
NodeWright主要由三部分组成：操作器（operator）、自定义资源和软件包。
操作器是一个Kubernetes控制器，负责监听NodeWright自定义资源，并管理节点变更的整个生命周期。软件包是承载实际修改内容的容器镜像，包括脚本、配置文件和二进制文件。软件包还包含验证脚本，一旦某项修改出错，验证脚本就会暴露问题并停止后续的部署推进。
当你应用一个NodeWright自定义资源时，操作器会在每个目标节点上按顺序执行一系列谨慎操作。整个流程包括：
隔离：将节点标记为不可调度状态，确保没有新的工作负载被分配到该节点。
等待：让关键工作负载优雅地完成任务。用户可以通过标签声明哪些Pod绝不能被中断。
清空：驱逐节点上剩余的Pod，默认遵循PodDisruptionBudget规则，若默认设置不够用，也支持自定义清空行为。
应用与配置：执行软件包中的操作，设置内核参数、安装代理、配置系统服务。
中断：如变更需要，重启服务或重启节点。
恢复调度：将节点重新纳入集群，使其可以接收工作负载。
这一整套流程，正是"因内核更新损失半个训练任务"与"在不中断工作负载的前提下完成整个集群更新"之间的关键区别。
NodeWright的软件包可以执行许多通常需要root权限、且无需重建节点的主机级操作。它们可以设置sysctl和GRUB参数、配置崩溃转储收集、创建逻辑卷、安装安全代理、修复CVE漏洞，以及执行其他系统级配置任务。NodeWright会追踪每个节点上每个软件包的状态和语义化版本号，从而能够区分全新安装、升级和降级操作。软件包之间还可以声明依赖关系，NodeWright据此确定正确的执行顺序。
验证机制被内置于软件包生命周期的各个环节。应用、配置、升级、卸载以及中断后的操作，都可以配套相应的检查项，用以验证节点是否达到预期状态，并通过Kubernetes将失败情况暴露出来。举例来说，一个用于修复CVE漏洞的软件包可以检测某个存在漏洞的内核模块是否仍处于加载状态，如果检测到问题，就会将该软件包标记为失败，让运维人员第一时间获知受影响的节点，而不必等到工作负载出现故障后才发现问题。
同样的模式也适用于集群扩容时的节点就绪管理。否则，新配置的节点可能在完成必要的配置和调优之前就变得可调度。NodeWright可以要求新节点在加入集群时带有Kubernetes污点标记，只有完成所需的软件包操作和验证检查后，污点才会被移除。这就建立了一条从"已配置资源"到"已完成配置"再到"已通过验证"最终到"可调度"的受控路径，确保新增容量在真正准备好之前不会承接生产工作负载。
大规模环境下的安全部署
将变更推送到单个节点并不复杂，但要将同样的变更推送到运行着生产训练任务的上千个GPU节点，则是另一个层面的问题。
NodeWright的DeploymentPolicy资源提供了渐进式部署策略，用于控制变更在整个集群中的推进方式。用户可以定义多个"隔间"（compartment），即通过标签选定的节点分组，每个分组都拥有各自独立的中断预算和部署策略。目前提供三种策略：
固定批量：批次大小恒定不变，每次更新固定数量的节点，例如每次五个。
线性递增：按固定增量扩大批次规模。从1开始，逐步增加到2、3，随着信心积累逐步推进。
指数增长：按增长因子倍增批次规模。从1开始，依次增加到2、4、8，一旦建立信任，速度会明显加快。
每种策略都包含一个批次阈值，即进入下一批次前所需达到的最低成功率。此外还可以设置一个可选的失败阈值，一旦某个隔间内连续失败的批次过多，就会自动停止该隔间的后续操作。风险容忍度由用户设定，NodeWright负责严格执行。
这意味着你可以先用单个金丝雀节点启动一次全集群范围的内核更新，验证其状态健康后，再让整个部署过程自动加速推进。
如果出现问题，更新会立即停止，而不会持续蔓延扩散。NodeWright会在其状态信息中报告错误，标记失败的任务，并为每个受影响的节点添加相应的标签和状态条件。用户可以通过Kubernetes API快速定位并排查问题原因。
NodeWright软件包与英伟达AI集群运行时
NodeWright本身是一个功能全面的软件包管理平台。由于软件包所执行的操作需要root级别权限，主机修改直接依赖于原生的Kubernetes原语：细粒度的RBAC控制用户权限，准入控制器负责验证配置规范，集成的验证检查则确保每一步操作后的状态一致性。公开的软件包仓库提供了模块化的基础组件，用于执行shell命令、管理绑定挂载，以及建立内核崩溃转储收集器。
英伟达同时发布了一系列基于其内部团队在大规模运营GPU集群过程中积累的实践经验所开发的软件包。
调优类软件包采用基于意图的模型。用户无需指定具体的配置文件名称，只需声明所使用的加速器类型以及使用场景，例如英伟达Blackwell GPU与多节点训练任务，软件包便会自动组装出合适的配置方案：包括内核参数、电源管理和系统设置等。目前覆盖范围包括英伟达Hopper和Blackwell GPU，并为任意英伟达GPU提供通用基线配置，同时针对不同云环境提供相应变体。此外还有专门的软件包，用于覆盖运行容器优化操作系统（Container-Optimized OS）的谷歌Kubernetes引擎（GKE）节点，这类节点通常无法使用常规的调优工具链。
节点初始化类软件包能够自动完成特定云环境与加速器组合下的引导启动步骤，例如为搭载英伟达Hopper或Blackwell GPU的亚马逊弹性Kubernetes服务（Amazon EKS）集群处理内核版本管理以及弹性光纤适配器（EFA）驱动的安装。
这些软件包是一项更广泛工作的一部分。NodeWright与英伟达AI集群运行时（AICR）实现了集成。AICR负责捕获驱动、Operator、内核和系统配置之间已验证的最佳组合，并将其发布为版本锁定的配置方案。其组件目录同时固定了NodeWright操作器以及承载特定环境调优内容的NodeWright自定义配置，然后将其渲染为可直接部署的软件包，适配Helm、Argo CD、Flux或Helmfile等工具。NodeWright则负责将这些配置方案中涉及主机层的部分应用到实际运行的节点上。
另外两个配套的英伟达开源项目——NVCRE和NVSentinel——共同构成了完整的生态系统。NVCRE负责工作负载运行前的验证，确认加速型基础设施已具备生产就绪状态；而NVSentinel则负责监控运行时故障，并协助执行隔离、清空和修复操作。这些工具与NodeWright共同协作，为GPU加速型Kubernetes集群提供资源配置、维护和自我修复能力的支持。
需要明确说明的是：NodeWright并不能替代英伟达GPU Operator或英伟达Network Operator，它管理的是这些组件之下的主机操作系统层。
如何开始使用
NodeWright可以通过Helm安装到任意Kubernetes集群中。该Helm Chart以OCI镜像形式分发，因此无需添加任何仓库源即可直接安装使用。
安装完成后，只需定义一个包含所需软件包的NodeWright自定义资源，通过标签选定目标节点，剩余的工作将由操作器自动完成。
相关资源包括：NodeWright代码仓库（提供源代码、问题反馈与讨论区）、软件包仓库（包含英伟达官方及社区贡献的软件包）、NodeWright官方文档（涵盖架构说明、命令行工具参考和部署策略）,以及英伟达AI集群运行时（更广泛的已验证配置系统）。
参与共建
NodeWright采用Apache 2.0许可协议，是DSX OS的一部分。DSX OS是一套模块化的开源项目组合，涵盖AI就绪基础层、资源与工作负载编排以及生产级AI服务。用户可以选择采用其中某一个项目，也可以整合多个项目，或将它们组合成一个完整的平台。其价值在于开放的接口设计、独立可采用性，以及连贯一致的生命周期管理，而不在于打造一个封闭的单体系统。
在客户规模的实际环境中运行这套技术栈，能够更早地发现潜在故障模式，英伟达团队也会将这些观察和经验分享给社区。软件包仓库正是NodeWright项目中承载这类分享的场所。NodeWright团队尤为关注目前软件包目录尚未覆盖的硬件与云环境组合，以及来自实际运营者、涉及团队尚未充分掌握的配置场景的调优方案。
Kubernetes改变了团队管理工作负载的方式，但底层节点——尤其是运行高负载AI工作的GPU节点——目前仍然依赖脚本和人工操作手册进行管理。NodeWright将同样声明式、自动化、安全可靠的管理理念延伸到了主机层面。用户可以按需采用，也可以参与共建，共同塑造这一项目的未来方向。
Q&A
Q1：NodeWright是什么？
A：NodeWright是英伟达DSX OS中的一个开源项目，它是一个原生适配Kubernetes的软件包管理工具，能够以声明式方式配置和安全更新Kubernetes节点的操作系统，且不会中断正在运行的工作负载。
Q2：NodeWright如何避免更新时中断训练任务？
A：NodeWright会按照隔离、等待、清空、应用配置、中断、恢复调度的严格顺序在节点上执行变更，并遵循Kubernetes的PodDisruptionBudget等原语，用户可以声明哪些工作负载绝不能被中断，从而在更新过程中保护关键训练任务不受影响。
Q3：NodeWright能否替代英伟达GPU Operator？
A：不能。NodeWright管理的是GPU Operator和Network Operator之下的主机操作系统层，并不会替代这两个组件，三者共同协作支撑加速型Kubernetes基础设施。
