#Введение

Kubernetes предоставляет доступ к специализированному оборудованию, такому как Ascend NPU, через интерфейс Device Plugin, но настройка узла NPU «от начала до конца» действительно сложна: драйвер и прошивка должны соответствовать ядру, контейнерный runtime должен знать, как внедрять устройства в контейнеры рабочих нагрузок, а device plugin должен сообщать о чипах планировщику.

Alauda Build of NPU Operator объединяет все это в единый operator, который согласует весь программный стек — драйвер и прошивку Ascend, конфигурацию container runtime, device plugin MindCluster и необязательный NPU exporter — на основе одного пользовательского ресурса NPUOperatorCtl. После установки AI training и inference workload могут запрашивать huawei.com/Ascend910 (или Ascend310P) так же, как и любой другой ресурс Kubernetes.

#Что нового в v1.2.4

v1.2.4 — это первый выпуск, собранный для неизменяемой ОС KubeOS, и он поставляется как набор operator bundle OLM, а не как cluster plugin. Основные изменения, заметные пользователю:

• Поддержка KubeOS / immutable OS. Узлы NPU worker больше не ограничены традиционными дистрибутивами Linux. Operator прозрачно обрабатывает ограничения KubeOS, связанные с доступом только для чтения к /usr и отсутствием package manager — нет необходимости заранее устанавливать kernel headers, DKMS или какой-либо host package.
• Предкомпилированный образ драйвера. Драйвер, прошивка и tooling runtime поставляются как container image, идентифицируемый по <HDK>-<chip>-<kernel>-<os>, и загружаются в kernel хоста из выполняющегося pod. Устаревший конвейер .run package + DKMS больше не используется. См. Установка для получения информации о prerequisite для image.
• Passthrough для предварительно установленного драйвера. Для хостов, на которых уже установлен драйвер Huawei .run вне оркестрации (например, bare-metal кластеров с независимым управлением жизненным циклом драйвера), задайте spec.driver.enabled=false: operator полностью пропускает staging и upgrade драйвера и настраивает CDI / device-plugin / runtime на основе существующего дерева /var/lib/Ascend/driver или /usr/local/Ascend/driver на хосте.
• Внедрение устройств через CDI. Контейнерам workload больше не нужен runtimeClassName: ascend. Достаточно запросить huawei.com/Ascend910 (или Ascend310P) — operator настраивает Container Device Interface так, чтобы containerd автоматически подключал /dev/davinciN и пользовательские библиотеки драйвера в контейнер.
• Жизненный цикл обновления драйвера. Изменение NPUOperatorCtl.spec.driver.version теперь запускает поузловое rolling upgrade: cordon → drain → перезагрузка node → загрузка нового драйвера → проверка → снятие cordon. Фаза перезагрузки обязательна, поскольку чипы Ascend не допускают rmmod работающего драйвера. Поддерживаются как режим auto-roll, так и режим ручного подтверждения. См. Обновление драйвера и self-healing.
• Самовосстановление чипов. Цикл health-watch внутри pod драйвера опрашивает каждый NPU каждую минуту; если чип во время работы переходит в зависшее состояние, он записывает marker восстановления, чтобы node можно было перезагрузить для восстановления. Включается через spec.driver.recoveryPolicy.autoRecover.
• Стек MindCluster v7.3.0. Включает ветку v7.3.0 для ascend-k8sdeviceplugin, ascend-operator, ascend-docker-runtime, noded, clusterd и npu-exporter. Версия драйвера по умолчанию повышается до 25.5.0.
• Исправление ошибки: ServiceMonitor для NPU exporter. Теперь exporter автоматически собирается платформенным Prometheus — ручной ServiceMonitor больше не нужен.

Полный список изменений см. в Release notes, а чтобы начать работу, откройте Установка.

Дополнительные сведения об upstream-проекте см. в openFuyao NPU Operator.