Kubernetes 管理的是节点上跑什么，真正麻烦的是节点本身：内核参数、系统软件包、存储布局、安全代理，以及 GPU 负载依赖的主机级调优。不少团队仍用 Ansible 剧本、自研脚本和手工操作手册来维护这些内容，直到新集群开在另一个区域、一次内核升级弄坏 RDMA，或者某个 CVE 必须在本周内修完整个机群。GPU 基础设施让问题更棘手——GPU 节点不能像普通实例那样丢弃重建，硬件稀缺、更换要等数小时，长时间训练也不能随便重排。
NVIDIA 给出的答案是 NodeWright：一个开源、Kubernetes 原生的包管理器，用来大规模修改和维护主机基础设施。它此前以 Skyhook 的名字在 NVIDIA 内部生产环境运行，这次正式以 NodeWright 开源发布。用 NVIDIA 的说法，它更像整个集群的 apt 或 yum——知道工作负载在哪、知道中断预算，并能把变更逐步推到整个机群。它属于 NVIDIA DSX OS 开源软件层，负责配置和更新底层主机操作系统。
NodeWright 由三部分组成：监听自定义资源并管理节点变更生命周期的 operator；承载实际修改内容（脚本、配置、二进制）的包镜像，包内还包含校验脚本，一旦修改不正确就会暴露失败并中止推进；以及描述目标节点、中断预算与包列表的自定义资源。由于包以自定义资源定义，部署方式与集群里其他组件一致，可以用 kubectl、Helm、Argo CD、Flux 或现有 GitOps 工具下发。
对每台目标节点，operator 会按固定顺序推进：先 cordon 标记为不可调度，避免新负载落上来；再等待被标记为不可中断的关键 Pod 自然结束；随后 drain 驱逐其余 Pod，默认遵守 PodDisruptionBudget；然后执行包，设置内核参数、安装代理、配置系统服务；需要时重启服务或节点；最后 uncordon 让节点回到集群。示例资源里用 interruptionBudget 的 percent 字段把中断比例限制在 33%，并用 podNonInterruptLabels 声明哪些 Pod 绝不能被中断。
规模化变更由 DeploymentPolicy 控制。管理员可以按标签把机群划分成若干 compartment，每个分区有独立的中断预算与推进策略：fixed 保持固定批大小，linear 每批按固定增量增长，exponential 按倍数扩张；每种策略都带批成功率阈值，低于阈值不再前进，还可以设置连续失败批次上限，一旦触发就停止该分区，避免故障级联。包在安装、配置、升级、卸载与重启后都可以配对校验脚本，例如某个 CVE 修复包会检查有漏洞的内核模块是否仍被加载，若仍存在就把包标记为失败，让问题在 Kubernetes 里直接可见。
NodeWright 还把节点就绪纳入同一模型：新节点可以先带 taint 加入集群，完成必需的包操作与校验后再摘掉 taint，形成“已交付—已配置—已验证—可调度”的受控路径。由于包要以 root 权限改主机，它依赖 Kubernetes 原生机制做权限约束——细粒度 RBAC、准入控制器校验规格、以及各阶段的内置校验。它与 AICR 配合，把经过验证的驱动、operator、内核与系统配置固化成版本锁定配方；与 NVCRE（投产前验证）、NVSentinel（运行时故障监控与隔离）分工互补。NVIDIA 也明确，NodeWright 管理的是 GPU Operator 与 Network Operator 之下的主机 OS 层，不替代这两个组件。
WeChat
Profile