介绍

Kubernetes 通过 Device Plugin 接口暴露 Ascend NPU 等专用硬件，但要端到端完成一个 NPU 节点的配置实际上非常复杂：驱动和固件必须与内核匹配，容器运行时必须知道如何将设备注入到工作负载容器中，而 device plugin 还必须将芯片上报给调度器。

Alauda Build of NPU Operator 将这些全部整合到一个 operator 中，它可以通过单个 NPUOperatorCtl 自定义资源来协调整套软件栈——Ascend 驱动和固件、容器运行时配置、MindCluster device plugin，以及可选的 NPU exporter。安装完成后，AI 训练和推理工作负载可以像请求其他任何 Kubernetes 资源一样请求 huawei.com/Ascend910（或 Ascend310P）。

支持 Alauda OS / 不可变 OS。NPU worker 节点不再局限于传统 Linux 发行版。operator 可透明处理 Alauda OS 的只读 /usr 和缺失包管理器等约束——无需预先安装 kernel headers、DKMS 或任何主机软件包。
预编译驱动镜像。驱动、固件和运行时工具以容器镜像形式提供，镜像标签格式为 <HDK>-<chip>-<kernel>-<os>，并从正在运行的 pod 中加载到主机内核。旧的 .run 包 + DKMS 流程已经移除。镜像前置条件请参见安装。
已预安装驱动直通。对于已经在带外安装了 Huawei .run 驱动的主机（例如，由独立驱动生命周期管理的裸金属集群），将 spec.driver.enabled=false：operator 会完全跳过驱动部署和升级，并基于主机现有的 /var/lib/Ascend/driver 或 /usr/local/Ascend/driver 目录树配置 CDI / device-plugin / runtime。
CDI 设备注入。工作负载 pod 不再需要 runtimeClassName: ascend。只需请求 huawei.com/Ascend910（或 Ascend310P）即可——operator 会配置 Container Device Interface，使 containerd 自动将 /dev/davinciN 和驱动用户态库绑定到容器中。
驱动升级生命周期。提升 NPUOperatorCtl.spec.driver.version 现在会触发按节点滚动升级：cordon → drain → node 重启 → 加载新驱动 → 验证 → uncordon。由于 Ascend 芯片无法容忍运行中驱动执行 rmmod，因此必须包含重启阶段。当前同时支持自动滚动和手动批准两种模式。参见驱动升级和自愈。
芯片自愈。驱动 pod 内的健康监测循环每分钟探测一次每个 NPU；如果芯片在运行时进入卡死状态，它会写入恢复标记，以便通过重启节点完成恢复。可通过 spec.driver.recoveryPolicy.autoRecover 启用。
MindCluster v7.3.0 技术栈。采用 ascend-k8sdeviceplugin、ascend-operator、ascend-docker-runtime、noded、clusterd 和 npu-exporter 的 v7.3.0 版本。默认驱动版本升级为 25.5.0。
Bug 修复：NPU exporter ServiceMonitor。现在平台的 Prometheus 会自动抓取 exporter——不再需要手动创建 ServiceMonitor。

完整变更列表请参见 release notes，并参见安装开始使用。

有关上游项目的更多详情，请参阅 openFuyao NPU Operator。

#介绍

#目录

#v1.2.4 有哪些新变化

介绍

目录

v1.2.4 有哪些新变化