NVIDIA Network Operator 将驱动、设备插件和相关网络组件以 Kubernetes 方式管理，升级看似只需更新 Chart 或 Operator 镜像，实际可能改变 CRD、默认值、组件版本和节点处理顺序。控制器成功滚动不代表数据面已经稳定，正在运行的 RDMA 作业、节点资源注册和网络附件都可能受到影响。评审要同时覆盖集群 API、节点操作和业务通信。
先导出当前声明与实际状态
保存 Operator、Chart、CRD、相关自定义资源、Helm 值、组件镜像摘要、节点标签和容忍配置，同时记录各节点实际驱动、设备插件、资源数量和网络附件。声明式配置与运行状态可能已有漂移，只备份 values 文件无法完整回退。敏感信息应单独保护，不写入普通报告。
CRD 变化需要先验证 API 兼容
新版本可能增加字段、调整默认值或弃用旧接口。应比较 CRD schema 和现有自定义资源，确认升级、转换和回退行为。GitOps 或自动化控制器是否理解新字段也要测试，避免它在升级后不断把资源改回旧结构。任何默认值变化都应转为显式配置，降低不同环境产生差异。
驱动与节点组件决定维护影响
若目标版本包含驱动容器、OFED、设备插件或 CNI 变化，节点可能需要排空、模块重载或重启。升级计划要列出每个组件的更新顺序和业务影响，不能让 Operator 同时改动所有 GPU/RDMA 节点。正在运行的通信任务是否会中断，应以隔离环境测试为准；无法无损更新时，应明确维护窗口。
资源重新注册是关键门禁
组件更新后，节点 Ready 仍可能缺少 RDMA 扩展资源，或者资源数量与设备不一致。应比较宿主设备、插件上报、调度器可分配与测试 Pod 可见性。网络附件、VF 和接口身份也要核对。只有基础资源和代表性跨节点通信通过后，节点才可解除隔离。
集群中的共存组件也要纳入差异
Network Operator 往往与 GPU Operator、Multus、SR-IOV 组件、集群发行版网络插件和策略控制器共存。它们可能管理相邻的驱动、节点标签、资源或网络附件。升级前要列出所有控制器的所有权边界，检查是否有两个组件同时修改同一对象。预发布验证应使用与生产相同的共存组合，不能在只有单个 Operator 的空白集群得出结论。
若企业通过 GitOps 管理资源，还要确认升级期间的临时字段、Webhook 和转换不会被旧仓库状态反复覆盖。控制器事件、API Server 错误与调和队列需要进入观察面板。升级完成的标准不仅是 Pod 可用，还包括持续一段时间没有重复调和、资源漂移或批量重启。
多节点池要按真实差异分组
集群可能同时存在不同内核、网卡、GPU 拓扑和用途的节点池。灰度样本应覆盖每种仍受支持的组合，并验证选择器不会把驱动或插件部署到错误节点。某一节点池通过，不能直接放行全部节点；不在支持范围的旧节点应先隔离、升级或制定退役计划。
回退不能只降 Operator 镜像
CRD、节点驱动和其他 DaemonSet 若已经升级，单独回退控制器可能形成不受支持的混合状态。回退计划应明确 CRD 是否可逆、旧镜像与 Chart 是否保留、节点组件如何恢复，以及现有工作负载何时重新调度。先在非生产集群实际执行一次回退，确认备份可以使用。
更新步骤
- 阅读目标版本与中间版本说明，形成 CRD、默认值、镜像和节点动作差异。
- 备份声明和运行状态，在预发布集群验证升级与回退。
- 按节点池灰度，先排空，再更新底层组件，验证后才重新放行。
- 检查设备、资源、网络附件、跨节点 RDMA 和真实训练通信。
- 观察控制器错误与节点稳定窗口，确认 GitOps 不会产生配置争夺。
Network Operator 与各网络组件的当前安装、版本和平台信息应从 NVIDIA Networking Documentation进入对应 Kubernetes/Network Operator 文档核对。本文不声称所有版本都包含相同组件或需要节点重启，实际影响必须根据版本差异和集群配置确认。
WeChat
Profile