#Обновление драйвера и self-healing

Начиная с v1.2.4, NPU Operator управляет жизненным циклом драйвера на каждом NPU-узле end-to-end. На этой странице описаны два потока, управляемые состоянием, которые он предоставляет:

• Обновление драйвера — поэтапное развертывание новой версии драйвера во всем кластере.
• Self-healing chip — автоматическое восстановление узла, у которого chip завис во время работы.

Оба потока проходят через один и тот же путь перезагрузки узла. Chip Ascend не поддерживают rmmod работающего драйвера — попытка заменить драйвер на месте приводит chip в невосстановимое состояние dev_num=0. Поэтому оператор всегда загружает новые модули после чистой загрузки, а не перегружает их внутри работающего kernel.

#Обновление драйвера

Обновление проходит через четыре упорядоченных шага: подготовка кластера, запуск повышения версии, подтверждение перезагрузки каждого узла и проверка нового драйвера. Не запускайте обновление, пока не завершен Шаг 1 — это самая частая причина зависшего rollout.

#Шаг 1: Подготовка перед запуском

Перед изменением spec.driver.version должны быть выполнены два условия. Оба обязательны; пропуск любого из них обычно приводит к зависанию обновления.

#1.1 Контрольный список перед обновлением

1. Новый образ драйвера присутствует в cluster registry для каждого профиля NPU-узла. Повторно используйте шаг skopeo copy из Шага 1.1 установки для каждой комбинации (chip, kernel, OS):

   # On a machine with internet access:
   NEW_VERSION=25.5.0
   
   for COMBO in 910b-6.6.0-145.0.4.135-oe2403sp3 310p-6.6.0-145.0.4.135-oe2403sp3; do
     skopeo copy --all \
       docker://docker.io/alaudadockerhub/ascend-driver:${NEW_VERSION}-$COMBO \
       docker://<your-cluster-registry>/mlops/ascend-driver:${NEW_VERSION}-$COMBO
   done

   Если ни один tag в исходном Docker Hub repo не соответствует kernel вашего узла, обратитесь в Customer Support — см. примечание по установке об отсутствующих tag.

2. ImageWhiteList обновлен и включает новый tag(и):

   kubectl edit imagewhitelist ascend-driver -n cpaas-system
   # add each new tag under spec.repoList

#1.2 Остановите NPU workloads

Перед продолжением сведите к нулю все Deployment / StatefulSet / training job, запрашивающие NPU. После завершения rollout восстановите их — см. Шаг 4.

# Examples — scale every NPU-using workload to zero
kubectl scale -n serving inferenceservice/my-model --replicas=0
kubectl scale -n training statefulset/llama-trainer --replicas=0

#Шаг 2: Запуск обновления

Отредактируйте экземпляр NPUOperatorCtl (созданный в конце Шага 5.3 установки) и обновите два поля в одном сохранении:

• spec.driver.version — новая версия драйвера (например, 25.5.0).
• spec.driver.upgradePolicy.autoUpgrade — оставьте значение по умолчанию false, чтобы подтверждать перезагрузку каждого узла вручную; установите true, чтобы оператор автоматически выполнил rollout по всему кластеру. Автоматический режим рекомендуется только для рутинных обновлений версии в bare-metal кластерах.

Через platform UI (рекомендуется):

1. Administrator > Marketplace > OperatorHub > Installed Operators > Alauda Build of NPU Operator.
2. Откройте вкладку NPUOperatorCtl и щелкните по экземпляру (имя по умолчанию npuoperatorctl-sample).
3. Edit YAML, измените оба поля, затем нажмите Save.

Через kubectl:

NEW_VERSION=25.5.0

kubectl -n npu-operator patch npuoperatorctl npuoperatorctl-sample --type=merge \
  -p "{\"spec\":{\"driver\":{\"version\":\"${NEW_VERSION}\",\"upgradePolicy\":{\"autoUpgrade\":false}}}}"

(Замените npu-operator на namespace установки и npuoperatorctl-sample на имя вашего экземпляра, если они отличаются.)

#Шаг 3: Подтверждение перезагрузки каждого узла

Пропустите этот шаг, если на Шаге 2 вы установили autoUpgrade: true — оператор перезагружает каждый узел автоматически.

В ручном режиме оператор ожидает, что администратор добавит к каждому NPU-узлу annotation npu.openfuyao.com/approve-reboot=true перед его перезагрузкой. Annotation можно задать в любое время — в том числе до Шага 2 — и оператор использует его один раз на каждую перезагрузку. Самый простой вариант — заранее одобрить все NPU-узлы одной командой:

kubectl get nodes -l openfuyao.com/npu.present -o name \
  | xargs -I{} kubectl annotate {} npu.openfuyao.com/approve-reboot=true --overwrite

Или одобрять по одному узлу в любом порядке:

kubectl annotate node ${nodeName} npu.openfuyao.com/approve-reboot=true

#Шаг 4: Проверка, что новый драйвер установлен

Rollout завершен, когда значение DRIVER-UPGRADE-STATE у каждого узла пустое. Сначала проверьте labels узлов:

kubectl get nodes -l openfuyao.com/npu.present \
  -o custom-columns=NAME:.metadata.name,DRIVER-UPGRADE-STATE:.metadata.labels.npu\.openfuyao\.com/driver-upgrade-state

Затем убедитесь, что каждый driver pod работает с новым image:

kubectl get pod -n npu-operator -l app=npu-driver-daemonset \
  -o jsonpath='{range .items[*]}{.spec.nodeName}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

Наконец, запустите npu-smi на host каждого NPU-узла (или подключитесь к узлу через node-debug / SSH workflow вашей platform) и убедитесь, что host сообщает новую версию:

LD_LIBRARY_PATH=/var/lib/Ascend/driver/lib64/driver:/var/lib/Ascend/driver/lib64/common \
  /var/lib/Ascend/driver/tools/npu-smi info | head -2

Теперь можно восстановить NPU workloads, которые вы остановили на Шаге 1.2.

#Self-healing chip

Некоторые сценарии развертывания Ascend — особенно 910B в VM с PCI passthrough — иногда могут приводить chip в состояние, при котором kernel modules загружены, но сам драйвер сообщает dev_num=0 и отклоняет вызовы DCMI. Для userspace это выглядит как «здоровый» host (все /dev/davinciN существуют, modules загружены), но каждый npu-smi info возвращает ошибку. Единственный способ восстановления — перезагрузка узла.

В v1.2.4 этот случай определяется автоматически:

• Driver pod запускает health-watch loop, который опрашивает каждый NPU с помощью npu-smi info каждые 60 секунд.
• После трех последовательных сбоев (≈3 минуты) loop определяет зависание во время работы: он снимает marker готовности драйвера (так что validator pod видит NotReady, а device plugin немедленно сообщает chip как Unhealthy) и записывает marker recovery для rebooter.
• Rebooter pod замечает marker в следующем 30-секундном цикле опроса.

#Автоматическое и ручное восстановление

Поведение на этом этапе определяется spec.driver.recoveryPolicy.autoRecover (независимо от autoUpgrade):

Когда автоматическое восстановление включено, chip self-heals без участия оператора — обычно это 3 минуты на обнаружение плюс несколько минут на перезагрузку. Когда оно выключено, та же annotation approve-reboot, которая используется для обновлений, разрешает перезагрузку восстановления.

Типичная конфигурация восстановления:

spec:
  driver:
    recoveryPolicy:
      autoRecover: true   # rebooter reboots automatically on detected wedge

#Пошаговый сценарий ручного восстановления

Если autoRecover: false и health-watch loop обнаружил зависание:

1. Найдите затронутые узлы и прочитайте причину marker:

   kubectl get nodes -l npu.openfuyao.com/reboot-required=true
   kubectl get events -A --field-selector reason=RebootRequired --sort-by=.lastTimestamp | tail

   Для self-healing сообщение Event содержит reason=recovery. (Для обновления драйвера используется reason=upgrade.)

2. При удобном случае подтвердите перезагрузку:

   kubectl annotate node ${nodeName} npu.openfuyao.com/approve-reboot=true

3. Rebooter перезагружает узел; после чистой загрузки driver pod корректно загружает modules, а validator pod повторно подтверждает готовность.

#Подавление ложноположительных срабатываний

Если chip восстанавливается самостоятельно до того, как сработает rebooter, health-watch loop очищает собственный marker, чтобы узел не был перезагружен без необходимости.