Alauda Container Platform
  • 简体中文

    • 发版日志

    目录

    v1.2.4破坏性变更新特性Bug 修复v1.1.3

    v1.2.4

    基于 openFuyao npu-operator 1.2.0 社区版本。v1.2.4 是首个面向 Alauda OS 不可变操作系统构建的版本，并重新设计了驱动的交付方式、设备接入 workload 的方式，以及 operator 管理驱动生命周期的方式。

    破坏性变更

    • 交付模式已从集群插件改为 operator。 早期版本的 Alauda Build of NPU Operator 作为集群插件交付，可从 Marketplace > Cluster Plugins 安装。从 v1.2.4 开始，本项目被打包为 OLM operator bundle，并可从 Marketplace > OperatorHub 安装。

      WARNING

      不支持从 v1.1.3（或任何更早的集群插件版本）就地升级。要迁移到 v1.2.4，请先卸载旧的集群插件，然后重新安装新的 operator：

      1. 从 Marketplace > Cluster Plugins 卸载现有的 Alauda Build of NPU Operator 集群插件。
      2. 如果主机上不再需要驱动，请在每个 NPU 节点上运行： 
        /usr/local/Ascend/driver/script/uninstall.sh
      3. 按照 Installation 页面，从 Marketplace > OperatorHub 安装 v1.2.4。

    • 驱动现在以容器镜像形式交付，不再是 .run 包。 默认情况下，驱动、firmware 和 runtime 工具链会随 mlops/ascend-driver:<HDK>-<chip>-<kernel>-<os-stem> 一并提供，并从运行中的 pod 加载到主机 kernel 中。v1.1.x 中列出的传统 DKMS / kernel-headers / make 主机依赖不再需要（即使存在也不会再被使用）。对于离线集群，匹配的驱动镜像必须在安装前预先同步到集群仓库中——请参见 Step 1: Sync driver images。如果集群中的节点已经带有主机安装的 .run 驱动，也可以通过设置 spec.driver.enabled=false 选择不使用该驱动（见下方 新特性）。

    • OS 支持模型已改为按 kernel 绑定，而不是按发行版绑定。 v1.2.4 不 受限于特定发行版。只要存在与节点 kernel 匹配的驱动镜像，任何运行 containerd 的 arm64 Linux 都受支持，驱动镜像位于 docker.io/alaudadockerhub/ascend-driver —— 该驱动镜像独立于 operator bundle 交付，并按需构建。如果你的 kernel 目前还不在 tag 列表中，请联系 Customer Support 申请构建并发布新的 tag。本版本已进行冒烟测试的环境包括：Alauda OS 6.6 上的 310P + 910B，以及 openEuler 22.03 LTS SP3 裸金属上的 910B。v1.1.x 的 DKMS 主机侧流程已经移除——现在由容器镜像模型替代。

    • workload 不再需要 runtimeClassName: ascend。 v1.2.4 中的设备注入由 Container Device Interface（CDI）驱动。只要请求 huawei.com/Ascend910（或 Ascend310P）即可——containerd 会自动将 /dev/davinciN 和驱动的 userspace libraries 绑定到容器中。现有仍设置 runtimeClassName: ascend 的 pod 仍可继续工作；保留旧的 RuntimeClass 以向后兼容。

    新特性

    • 支持 Alauda OS / 不可变 OS。 运行 Alauda OS 的 NPU 节点现已获得完整支持。operator 会将驱动目录树放置在 /var/lib/Ascend / /var/lib/ascend / /home/bios/driver 下（在 Alauda OS 上这些目录都位于可写分区），直接从 driver pod 插入 kernel module，并且不会写入 /usr，也不会依赖 package manager。

    • 已预装驱动直通（spec.driver.enabled=false）。 对于 NPU 主机上已经安装了 Huawei .run 驱动的集群——通常是运行独立驱动生命周期管理的裸金属环境——现在可以让 operator 完全退出驱动管理。安装时禁用 Driver（或之后在 NPUOperatorCtl 上将其设为 false），operator 将跳过驱动镜像同步（installation Step 1），不再部署 driver / rebooter DaemonSets，并将 CDI / device-plugin / runtime 指向主机上已有的驱动目录 /var/lib/Ascend/driver 或 /usr/local/Ascend/driver（由 toolkit 自动检测）。随后，驱动升级和芯片恢复重启将由主机侧 operator 负责。

    • 驱动升级生命周期。 编辑 NPUOperatorCtl.spec.driver.version 现在会触发按节点滚动升级。operator 会按以下状态依次推进每个节点：upgrade-required → cordon-required → wait-for-jobs-required → pod-deletion-required → drain-required → node-reboot-required → pod-restart-required → validation-required → uncordon-required → upgrade-done，升级推进节奏受以下参数控制：

      • spec.driver.upgradePolicy.autoUpgrade — 设置为 true 表示全自动滚动升级，设置为 false（默认）表示在每次重启前等待每个节点上的 npu.openfuyao.com/approve-reboot=true 注解。
      • spec.driver.upgradePolicy.maxParallelUpgrades 和 maxUnavailable — 并发上限。
      • spec.driver.upgradePolicy.drainSpec、podDeletion、waitForCompletion — drain 和驱逐策略字段，参考上游 k8s-operator-libs schema 建模。

      节点重启始终是必须的，因为在运行中的 Ascend driver 上执行 rmmod 会使芯片进入不可恢复状态。新的 rebooter 组件通过 sysrq b（panic-reboot）执行重启，以避免 PCI-passthrough VM 上的 VFIO/AER deadlock。完整流程请参见 Driver upgrade and self-healing。

    • 芯片自愈。 driver pod 内部的 health-watch 循环每 60 秒运行一次 npu-smi info. 连续三次失败后（约 3 分钟），该循环会检测到运行时芯片卡死状态，删除 driver-ready 标记（从而使 device plugin 将芯片报告为 Unhealthy），并为 rebooter 写入恢复标记。在 spec.driver.recoveryPolicy.autoRecover: true 时，rebooter 会自动重启节点以恢复芯片；在 false（默认）时，则等待与升级相同的 approve-reboot 注解。

    • CDI device injection。 替代 v1.1.x 的 ascend-docker-hook 机制。现在 Ascend Docker Runtime 表单开关会部署 npu-container-toolkit generate-cdi --watch 作为边车，生成位于 /var/run/cdi/ascend.com-npu.yaml 的 CDI spec。CDI kind 为 huawei.com/ascend；device plugin 关联到 pod 的 annotation key 为 cdi.k8s.io/ascend-device-plugin。

    • Validator DaemonSet。 新增 npu-validator DaemonSet，与 driver 一同运行。升级状态机在继续推进到 validation-required 之后，会等待 driver pod 和 validator pod 都报告 PodReady，因此即使某个 driver pod 自报 ready，但其 ready 文件实际上对其他主机消费者不可见，也不会再误导升级流程。

    • 考虑 drain 的 device-plugin。 MindCluster device plugin 现在会监听 npu.openfuyao.com/driver-upgrade-state 和 reboot-required 节点标签，只要其中任意一个被设置，就会将该节点上的所有 NPU 报告为 Unhealthy。因此，scheduler 会停止向即将被下线的节点调度新的 NPU workload。

    • 主机上按节点提供 npu-smi 访问。 driver pod 会将 npu-smi 放置到 /var/lib/Ascend/driver/tools/npu-smi。operator 不会把它加入主机的 PATH（Alauda OS 会保持 /usr 为只读）；请使用匹配的 LD_LIBRARY_PATH 调用，或将其封装在 /opt/bin/ 下的脚本中。请参见 Installation FAQ。

    • MindCluster / Ascend 组件栈升级到 v7.3.0。 引入 v7.3.0 版本线的 ascend-docker-runtime、ascend-operator、ascend-k8sdeviceplugin、noded、vc-controller-manager、vc-scheduler、clusterd 和 npu-exporter。驱动和 firmware 的默认 HDK 版本提升到 25.5.0。25.3.RC1 作为受共同支持的替代版本提供。

    Bug 修复

    • 修复 npu-exporter 的 ServiceMonitor 不生效的问题：此前它被创建在错误的 namespace 中，并且缺少 Prometheus selector labels，导致平台的 Prometheus 从未抓取该 exporter。现在 operator 会在自身 namespace 中交付正确的 ServiceMonitor，包含正确的 prometheus: kube-prometheus label 和 honorLabels: true。无需手动创建 ServiceMonitor。

    • 修复仅将 driver pod 的 readinessProbe 作为信号时，operator 无法将升级状态机推进到 validation-required 之后的问题：现在会通过一个独立的 validator pod 确认 driver-ready 标记对其他主机消费者可见。

    • 修复在 driver pod 运行期间、当芯片已经卡死时，runtime-init.sh 在半安装状态下快速跳过的问题：现在 fast-skip 谓词中加入了芯片健康探测（通过 PCI sysfs 的 davinci_dev_num > 0），因此“已加载但已卡死”的芯片会进入恢复路径。

    • （Community）修复未安装 NPU 卡的节点上的安装 / 检测逻辑。

    • （Community）修复环境变量指示器未去重的问题。

    v1.1.3

    基于 openFuyao npu-operator 1.1.1 社区版本。基于 MindCluster / Ascend v7.2.RC1 组件栈，并作为集群插件交付。