Kubernetes（容器编排平台） 管理节点上运行的内容。管理节点本身才是挑战所在：内核设置、系统软件包、存储布局、安全智能体，以及 GPU（图形处理器） 工作负载所依赖的主机级调优。许多团队通过 Ansible playbook、自定义脚本和手动运行手册来管理这些内容。这种方式在以下情况出现之前一直有效：新集群在不同区域上线、内核升级破坏了 RDMA，或者本周必须在整个集群中修复某个 CVE。

GPU 基础设施让这一挑战更加严峻。你不能简单地丢弃一个 GPU 节点再启动一个新的。硬件稀缺，更换可能需要数小时，长时间运行的训练任务无法简单地重新调度。因此，运维问题不是如何更改一个节点，而是如何在不中断训练任务的情况下更改所有节点。如今，这个问题的答案通常是一张电子表格、一个维护窗口，以及一位在凌晨 3 点盯着终端的工程师。

NVIDIA DSX 平台帮助你设计和运营 AI 工厂，其中整个设施被视为一个单一系统，而不是一组机器的集合。主机配置遵循同样的逻辑：变更的单位是整个集群，而不是单个节点。NVIDIA DSX OS 是开源软件层，NodeWright 是其中负责配置和更新底层主机操作系统的项目。

从脚本到声明式节点管理

DSX OS 通过一个模块化的开源项目组合来应对这一挑战，涵盖 AI 就绪基础、资源与工作负载编排，以及生产级 AI 服务。AI 就绪基础定义、配置、验证并保障加速 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。它不会在更改之前封锁节点、等待关键 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 展示了完整序列以及受保护工作负载如何暂停该序列。

• Cordon。将节点标记为不可调度，使新工作负载不会落到该节点上。

• Wait。让关键工作负载优雅完成。你通过标签声明哪些 pod 绝不能被中断。

• Drain。驱逐剩余 pod，默认遵循 PodDisruptionBudgets，当默认行为不足时可配置 drain 行为。

• Apply and configure。运行包：设置内核参数、安装 agent、配置系统服务。

• Interrupt。如果变更需要，重启服务或重启节点。

• Uncordon。将节点返回集群，准备好承载工作负载。

这一序列决定了是因内核更新损失一半训练运行，还是在不中断工作负载的情况下将同一更新部署到整个集群。

NodeWright 包可以执行许多通常需要 root 访问权限的主机级操作，而无需回收节点。它们可以设置 sysctl 和 GRUB 参数、配置崩溃转储收集、创建逻辑卷、安装安全 agent、修复 CVE，以及执行其他系统级配置任务。NodeWright 跟踪每个节点上每个包的状态和语义版本，使其能够区分全新安装、升级和降级。包还可以声明依赖关系，NodeWright 利用这些依赖关系确定正确的执行顺序。

验证已内置于包的生命周期中。应用、配置、升级、卸载和中断后工作都可以与检查配对，以验证预期的节点状态，并通过 Kubernetes 暴露失败。例如，CVE 修复包可以检测易受攻击的内核模块是否仍处于加载状态，并将该包标记为失败，使运维人员能够立即了解受影响的节点，而不是让他们之后通过工作负载故障才发现问题。

随着集群扩展，这一模型同样可扩展到节点就绪状态。新配置的节点可能会在所需配置和调优应用之前就变为可调度。NodeWright 可以要求新节点以 Kubernetes taint 加入集群，完成所需的包操作和验证检查，并且仅在节点通过后才移除该 taint。这创建了一条从已配置到已配置完成、再到已验证、最后到可调度的受控路径，确保新容量在真正就绪之前不会接受生产工作负载。

大规模安全滚动发布

将变更推送到一个节点很简单。将其推送到一千个运行生产训练作业的 GPU 节点则是另一个问题。

NodeWright DeploymentPolicy 资源提供渐进式滚动发布策略，用于控制变更如何在集群中传播。你可以定义 compartment，即通过标签选择的命名节点组，每个组都有自己的中断预算和滚动发布策略。图 2 展示了三种可用策略。

• Fixed。固定批次大小。每次更新五个节点。

• Linear。按固定增量增加批次。从 1 开始，然后 2，然后 3，逐步建立信心。

• Exponential。将批次乘以增长因子。从 1 开始，然后 2，然后 4，然后 8。一旦信任它，速度就很快。

每个策略都包含一个批次阈值，即进入下一批次前所需的最低成功百分比。可选的失败阈值会在连续失败批次过多时停止该分区。您设定风险容忍度，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 operator 和携带环境特定调优的 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\
  --namespace nodewright \
  --create-namespace

接下来，定义一个 NodeWright 自定义资源（Custom Resource），指定要应用的软件包，通过标签定位目标节点，其余工作由 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 软件包仓库。

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：NVIDIA Technical Blog

原创地址：https://developer.nvidia.com/blog/manage-kubernetes-node-fleets-with-nodewright/