Kubernetes 管理的是节点上运行的东西，而管理节点本身才是难题：内核设置、系统软件包、存储布局、安全代理，以及 GPU 工作负载所依赖的主机级调优。许多团队靠 Ansible playbook、自定义脚本和手工运维手册来管理这些。这种做法能撑到某个新集群在另一个区域上线、某次内核升级弄坏了 RDMA，或者本周必须在整个机群上修复某个 CVE 的时候。
GPU 基础设施让这个难题更加棘手。你不能简单地丢掉一个 GPU 节点再拉起一个新的。硬件稀缺，更换可能要几个小时，长时间运行的训练任务也无法随便重新调度。所以，运维上的问题不是如何改动一个节点，而是如何在不终止训练的前提下改动所有节点。如今，这个答案通常是一张电子表格、一个维护窗口，以及一位凌晨 3 点盯着终端的工程师。
NVIDIA DSX 平台帮助你设计和运营 AI 工厂，在 AI 工厂中，整个设施被视为一个单一系统，而不是一堆机器的集合。主机配置遵循同样的逻辑：变更的单位是机群，而不是节点。NVIDIA DSX OS 是其中的开源软件层，而 NodeWright 是其中负责配置和更新底层主机操作系统的项目。
从脚本到声明式节点管理
DSX OS 通过一组模块化的开源项目组合来应对这一挑战，涵盖 AI 就绪基础、资源与工作负载编排，以及生产级 AI 服务。AI 就绪基础（AI-Ready Foundation）负责定义、配置、验证并保障加速的 Kubernetes 基础设施。NVIDIA GPU Operator、NVIDIA Network Operator、Topograph、DRA Driver for NVIDIA GPUs、NodeWright、NVIDIA Cluster Readiness Engine（NVCRE）和 NVSentinel 提供相应的基础设施支撑能力。
NodeWright 以声明式方式配置并安全更新 Kubernetes 节点操作系统，而不会干扰工作负载。它是一个开源的、Kubernetes 原生的包管理器，用于大规模修改和维护主机基础设施。可以把 NodeWright 想象成面向整个集群的 apt 或 yum：了解工作负载，了解中断预算，并且能在整个机群中渐进式地推出变更。
NodeWright 已在 NVIDIA 内部以 Skyhook 之名投入生产使用，现已开源。本文正式介绍 NodeWright 这一名称。
为什么 Kubernetes 需要自己的包管理器
配置机器的优秀工具早已存在。Ansible 和 Puppet 已经做了很多年。它们是为这样一个世界设计的：机器被单独管理，而不是作为正在运行敏感工作负载的集群的一部分。
当你需要在 200 个 GPU 节点上更新一个内核参数时，难点不在于运行脚本，而在于如何在不干扰这些节点上训练任务的情况下完成。传统的配置管理并不了解 Kubernetes。它不会在改动前先隔离（cordon）节点，不会等待关键 Pod 运行结束，也不会在重启前排空（drain）工作负载。它也不会在集群内部跟踪成功或失败，而你其余的可观测性工具恰恰就在集群里。
NodeWright 填补了这一空白。它管理主机级变更的完整生命周期，从安装到配置、升级再到卸载。同时，它尊重你的工作负载已经依赖的 Kubernetes 原语：PodDisruptionBudgets、节点选择器、污点（taint）和容忍（toleration）。NodeWright 包被定义为自定义资源（Custom Resource），因此它们的部署方式与集群中的其他一切相同：通过 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 展示了完整流程，以及受保护的工作负载如何使其暂停。
- 隔离（Cordon）。将节点标记为不可调度，使新的工作负载不会落到它上面。
- 等待（Wait）。让关键工作负载平稳完成。你通过标签声明哪些 Pod 绝不能被中断。
- 排空（Drain）。驱逐剩余的 Pod，默认遵循 PodDisruptionBudget，在默认设置不够用时可配置排空行为。
- 应用与配置（Apply and configure）。运行软件包：设置内核参数、安装代理并配置系统服务。
- 中断（Interrupt）。如果变更需要，则重启某个服务或重启节点。
- 取消隔离（Uncordon）。让节点回到集群中，准备好接收工作负载。
这套流程的意义在于：一次内核更新可能让你损失半个训练任务，也可能在整个机群上顺利落地同样的更新而不干扰工作负载。
NodeWright 软件包可以在无需轮换节点的情况下执行许多通常需要 root 权限的主机级操作。它们可以设置 sysctl 和 GRUB 参数、配置崩溃转储收集、创建逻辑卷、安装安全代理、修复 CVE，并执行其他系统级配置任务。NodeWright 会跟踪每个节点上每个软件包的状态和语义化版本，从而能够区分全新安装、升级和降级。软件包还可以声明依赖关系，NodeWright 据此确定正确的执行顺序。
验证内置于软件包的生命周期中。应用、配置、升级、卸载以及中断之后的工作，都可以各自配上一项检查，用来验证预期的节点状态，并通过 Kubernetes 暴露失败。例如，CVE 修复软件包可以检测存在漏洞的内核模块是否仍被加载，并将该软件包标记为失败，让运维人员立即看到受影响的节点，而不是等到以后因工作负载故障才发现问题。
随着集群规模扩大，同样的模型也适用于节点就绪性。否则，新供应的节点可能在所需的配置和调优完成之前就变得可调度。NodeWright 可以要求新节点带着一个 Kubernetes 污点加入集群，完成所需的软件包操作和验证检查，并且只有在节点通过后才移除该污点。这就形成了一条受控的路径：已供应、已配置、已验证、可调度，确保新增容量在真正就绪之前不会接收生产工作负载。
大规模下的安全发布
把一项变更推到一个节点上很简单，而把它推到一千个正在运行生产训练任务的 GPU 节点上，则是另一回事。
NodeWright 的 DeploymentPolicy 资源提供渐进式发布策略，用来控制变更如何在机群中传播。你可以定义分区（compartment），即通过标签选出的、具名的节点组，每个分区都有自己的中断预算和发布策略。图 2 展示了三种可用策略。
- 固定（Fixed）。批次大小恒定。每次都一次更新五个节点。
- 线性（Linear）。按固定增量增大批次。从 1 个开始，然后 2 个、3 个，逐步建立信心。
- 指数（Exponential）。按增长系数成倍增大批次。从 1 个开始，然后 2 个、4 个、8 个。一旦信任它，速度就很快。
每种策略都包含一个批次阈值，即推进到下一批次之前所需的最低成功百分比。还可以设置可选的失败阈值，当连续失败的批次过多时停止该分区。风险容忍度由你来设定，NodeWright 负责强制执行。
这意味着你可以先用单个金丝雀节点启动全机群的内核更新，验证它是否健康，然后让发布自动加速。
如果出了问题，更新会停止，而不是层层扩散。NodeWright 会在其状态中报告错误，将失败的 Job 标记出来，并为每个受影响的节点添加标签和状况（condition）。你可以通过 Kubernetes API 快速识别并分诊原因。
NodeWright 软件包与 NVIDIA AI Cluster Runtime
NodeWright 是一个多用途的包管理平台。由于软件包执行的操作需要 root 级权限，主机修改直接依赖 Kubernetes 原生原语：细粒度的 RBAC 控制用户权限，准入控制器（admission controller）校验规约，集成的验证检查则确保每一步的状态一致。公共软件包仓库提供模块化的基础组件，用于运行 shell 命令、管理绑定挂载（bind mount），以及建立内核崩溃转储收集器。
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 记录经过验证的驱动、operator、内核和系统配置组合，并将它们发布为版本锁定的配方（recipe）。其组件目录同时固定了 NodeWright operator 和承载特定环境调优的 NodeWright 定制内容，然后将它们渲染成可直接部署的 Helm、Argo CD、Flux 或 Helmfile 包。NodeWright 则把这些配方中属于主机层面的部分应用到正在运行的节点上。
两个配套的 NVIDIA 开源项目——NVCRE 和 NVSentinel——完善了整个生态。NVCRE 负责工作负载运行前的验证，确认加速基础设施已具备生产就绪条件；NVSentinel 则监控运行时故障，并协助执行隔离、排空和修复操作。与 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 仓库：源代码、issue 和讨论
- 软件包仓库：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 软件包仓库。