NVIDIA发布NodeWright：用Kubernetes原生方式管理GPU节点主机层
NVIDIA在技术博客中正式介绍NodeWright，一个开源、Kubernetes原生的软件包管理器，用于声明式配置和更新节点操作系统。该项目已在NVIDIA内部以Skyhook名义投入生产运行。
AI解读：NVIDIA把NodeWright定位成“整个集群的apt或yum”，解决的是GPU节点主机层配置难以规模化变更的问题。传统Ansible、Puppet等工具面向单机，不知道节点上正跑着训练任务，更新内核参数时不会先cordon、等待关键Pod结束或排水。
它的做法是把主机变更包装成Kubernetes自定义资源和容器镜像包，由operator按cordon、等待、排水、应用、必要时重启、uncordon的顺序逐个节点执行，并遵循PodDisruptionBudgets、污点和容忍等已有机制。
对管理大规模GPU集群的团队来说，真正的变化是：内核升级、CVE修复、安全代理安装这类操作可以像部署应用一样通过kubectl、Helm或GitOps工具推进，并按批量和成功阈值控制风险；失败时停止滚动而不是级联到整个机队。
不过NodeWright只管GPU Operator和网络Operator之下的主机操作系统层，不替代它们；它处理的是节点本身，不涉及工作负载编排。包目前以NVIDIA官方仓库为主，官方也在征集尚未覆盖的硬件与云组合以及社区调优配置。
NVIDIA在 4 月发布的技术博客中正式介绍了NodeWright，一个开源、Kubernetes原生的软件包管理器，用于声明式地配置和更新Kubernetes节点的操作系统，且不中断工作负载。此前该项目在NVIDIA内部以Skyhook的名义已在生产环境运行。
NodeWright属于NVIDIA DSX OS开源软件层，而DSX平台的目标是把整个AI工厂当作单一系统来设计和运营。NVIDIA称，主机配置遵循同样的逻辑：变更的单位是机队，而不是单个节点。
为什么Kubernetes需要自己的包管理器
NVIDIA博客指出，Kubernetes负责管理节点上运行的内容，但管理节点本身——内核设置、系统软件包、存储布局、安全代理，以及GPU工作负载依赖的主机级调优——才是挑战。许多团队目前用Ansible playbook、自定义脚本和人工操作手册应对，直到新集群出现在另一个区域、内核升级破坏RDMA，或者某个CVE必须在当周修复到整个机队。
GPU基础设施让问题更难。博客称，GPU节点不能像普通节点那样直接丢弃重建：硬件稀缺、更换可能需要数小时，长时间运行的训练作业也不能简单重新调度。因此运维问题不是如何改一个节点，而是如何在不杀死训练任务的前提下改所有节点。NVIDIA形容目前的答案通常是电子表格、维护窗口，以及凌晨 3 点盯着终端的工程师。
NodeWright被定位为“整个集群的apt或yum”：感知工作负载、感知中断预算，并能跨机队渐进式推送变更。NVIDIA表示，Ansible和Puppet等工具是为单独管理机器而设计的，不理解Kubernetes，不会在变更前cordon节点、等待关键Pod完成或重启前排空工作负载，也不会在集群内跟踪成功或失败。NodeWright声称可以管理主机级变更的完整生命周期——安装、配置、升级和卸载，同时遵守PodDisruptionBudgets、节点选择器、污点和容忍。
组件、执行顺序与验证机制
NodeWright有三个主要组件：operator、自定义资源和包。operator是一个Kubernetes控制器，监视NodeWright自定义资源并管理跨节点的变更生命周期。包是容器镜像，携带实际的修改内容——脚本、配置和二进制文件，并包含验证脚本，在修改不正确时暴露故障并停止滚动。
当应用一个NodeWright自定义资源时，operator在每个目标节点上编排一个谨慎的序列：先cordon，将节点标记为不可调度，使新工作负载无法落入；然后等待，让关键工作负载优雅结束，用户通过标签声明哪些Pod绝不能被中断；接着drain，驱逐剩余Pod，默认遵守PodDisruptionBudgets；然后应用和配置，运行包中的内核参数设置、代理安装或系统服务配置；如有需要则中断，重启服务或重启节点；最后uncordon，将节点返回集群。
博客给出的示例自定义资源中包含nodeSelectors、interruptionBudget（百分比 33）、podNonInterruptLabels（workload: long-running-training）以及nvidia-tuned包，版本 0.9.0。
NodeWright包可以执行通常需要root权限的主机级操作而不回收节点，包括设置sysctl和GRUB参数、配置崩溃转储收集、创建逻辑卷、安装安全代理、修复CVE等。它跟踪每个节点上每个包的状态和语义版本，区分全新安装、升级和降级，并支持包声明依赖关系以确定执行顺序。
验证内置于包生命周期：应用、配置、升级、卸载和中断后工作都可以配对检查，验证节点预期状态并通过Kubernetes暴露失败。例如，一个CVE修复包可以检测有漏洞的内核模块是否仍被加载，并将该包标记为失败，让运维人员立即看到受影响的节点。
对于集群扩展时的节点就绪问题，NodeWright可以要求新节点带Kubernetes污点加入集群，完成必需的包操作和验证检查后，才移除污点。NVIDIA称这创建了从已配置到已验证到可调度的受控路径，确保新容量在接受生产工作负载前真正就绪。
批量滚动策略与生态集成
NodeWright的DeploymentPolicy资源提供渐进式滚动策略，控制变更如何在机队中传播。用户定义compartments——按标签选择的命名节点组，每组有自己的中断预算和滚动策略。
三种滚动策略包括：Fixed，固定批量大小，例如每次更新 5 个节点；Linear，按固定增量增加批量，从 1 开始到 2 再到 3；Exponential，按增长因子倍增批量，从 1 到 2 到 4 到 8。每种策略包含批量阈值，即推进到下一批之前所需的最低成功率，以及可选的失败阈值，在连续太多批失败时停止该compartment。
如果出错，更新会停止而不是级联。NodeWright在状态中报告错误，标记失败的Job，并在每个受影响的节点上添加标签和条件，运维人员可以通过Kubernetes API快速定位和分类原因。
包执行需要root级权限的操作，因此主机修改依赖原生Kubernetes原语：细粒度RBAC控制用户权限，准入控制器验证规格，集成验证检查确保每一步状态一致。公共包仓库提供模块化基础组件，用于运行shell命令、管理绑定挂载和建立内核崩溃转储收集器。
NVIDIA还发布基于其团队在规模化运行GPU集群时积累的运维知识的包。调优包采用基于意图的模型：用户声明加速器和用途，例如NVIDIA Blackwell GPU和多节点训练，而不需要指定具体的profile名称；包自动组装正确的kernel参数、电源管理和系统设置。覆盖范围包括NVIDIA Hopper和Blackwell GPU，有面向任意NVIDIA GPU的通用基线配置，以及针对不同云环境的变体。
有一个专门的包覆盖运行Container-Optimized OS的Google Kubernetes Engine（GKE）节点，因为常规调优栈在该环境中不可用。节点设置包则为特定云和加速器组合自动化引导步骤，包括为运行NVIDIA Hopper或Blackwell GPU的Amazon EKS集群处理内核版本管理和Elastic Fabric Adapter（EFA）驱动安装。
与AICR、NVCRE、NVSentinel的配合及范围界定
NodeWright与NVIDIA AI Cluster Runtime（AICR）集成。AICR捕获驱动、operator、内核和系统配置的已知良好组合，并发布为版本锁定的配方。其组件目录锁定NodeWright operator和携带环境特定调优的NodeWright定制项，然后渲染成部署就绪的捆绑包，供Helm、Argo CD、Flux或Helmfile使用。NodeWright负责将这些配方中的主机级部分应用到运行中的节点。
两个配套的NVIDIA开源项目补全生态：NVCRE处理工作负载前验证，确认加速基础设施已为生产就绪；NVSentinel监控运行时故障，并协助cordon、drain和修复操作。NVIDIA表示，三者共同支持GPU加速Kubernetes集群的供给、维护和自愈。
NVIDIA明确界定范围：NodeWright不替代NVIDIA GPU Operator或NVIDIA Network Operator，它管理的是它们之下的主机操作系统层。
安装方面，NodeWright通过Helm安装到任意Kubernetes集群，chart以OCI artifact形式分发，无需添加仓库。NVIDIA给出的命令为helm install nodewright oci://ghcr.io/nvidia/nodewright/charts/nodewright --version --namespace nodewright --create-namespace。之后定义包含所需包的NodeWright自定义资源，按标签指定目标节点，operator处理其余部分。
许可证与社区参与
NodeWright以Apache 2.0许可证发布，属于DSX OS。NVIDIA称DSX OS是模块化开源项目组合，覆盖AI就绪基础、资源与工作负载编排以及生产AI服务；用户可以只采用一个项目，也可以集成多个或组合成平台。
NVIDIA表示，在客户规模上运行这套技术栈能提前暴露故障模式，团队会与社区分享观察结果，NodeWright的包仓库正是这一过程发生的地方。NodeWright团队特别希望获得目录尚未覆盖的硬件和云组合的包，以及来自运行团队尚未表征过的配置的调优profile。