Настройка NVIDIA GPU Operator для Kubernetes

NVIDIA GPU Operator: где теряется выделение ускорителей

Кластер с ускорителями редко простаивает из-за нехватки железа — чаще простой ускорителей вызван тем, что выделение GPU в кластере не сходится с фактическим состоянием узлов. Узел помечен как содержащий карту, но драйвер не поднялся после обновления ядра, плагин устройства не зарегистрировал ресурс, и планировщик больше не видит свободных карт. Задачи при этом ждут в очереди, а ускорители стоят без нагрузки.

Корень обычно в ручной установке драйверов на узлах. На части машин другой набор библиотек, чем в образе; кто-то перезагрузил сервер и не вернул конфигурацию; на одном узле версия драйвера свежая, на другом — отставшая на несколько релизов. Чем больше узлов, тем быстрее накапливается расхождение, и тем чаще инженер вместо работы с моделью выясняет, почему конкретный узел перестал отдавать карту.

Второе узкое место в планировании задач — достоверность ресурсов. Планировщик распределяет только то, что заявлено узлом, поэтому без корректной регистрации карт нагрузка либо не стартует вовсе, либо несколько процессов делят одну карту и падают по памяти. Часть задач при этом уходит на узлы без ускорителя и завершается таймаутом уже после того, как потрачено время очереди.

NVIDIA GPU Operator переводит драйверы, регистрацию карт и маркировку узлов в декларативное состояние кластера: узел сам сообщает, чем располагает, а расхождение версий лечится штатным обновлением, а не ручными заходами на машину. Ниже разбираем, как это устроено и где остаются грабли — от совместимости драйвера с ядром до совместного доступа нескольких задач к одной карте.

Что меняется в кластере после автоматизации ускорителей

После того как NVIDIA GPU Operator берёт на себя жизненный цикл ускорителей, их выдача перестаёт быть набором ручных шагов. Драйвер, библиотеки и компоненты планирования встают на узел согласованно, кластер видит ускоритель как обычный ресурс и распределяет его между задачами. Подготовка нового узла укладывается в предсказуемое окно вместо последовательности, которую каждый инженер выполнял по своей памяти.

Ручных операций становится заметно меньше: обновление драйвера и выдача доступа к устройству описаны декларативно и применяются одинаково на всех узлах. Это снимает отдельный класс отказов — расхождение версий драйвера и библиотек между машинами, из-за которого задача либо не стартовала, либо теряла доступ к ускорителю уже в работе.

Наблюдаемость ускорителей перестаёт быть отдельной историей. Загрузка, ошибки и признаки перегрева собираются в том же контуре, что и метрики остального кластера, поэтому деградация видна до падения задач, а не после. Ответ на вопрос «какой узел ведёт себя нетипично» даёт график, а не журналы событий отдельной машины.

Обновления тоже управляемы: новая ветка драйвера прокатывается по узлам волнами, остальные продолжают обслуживать нагрузку, а возврат к прежней версии не требует пересборки кластера. Итого пять измеримых сдвигов — единая выдача ускорителей, предсказуемое время подготовки узла, меньше ручных операций, снятый класс отказов и контролируемые обновления.

Варианты развёртывания: ручная настройка или управляемый слой

Выбор между ручной установкой и управляемым слоем определяется не размером кластера, а тем, как часто меняются драйверы и сколько разных ускорителей живёт в одном пуле. NVIDIA GPU Operator собирает драйвер, device plugin, телеметрию и метки узлов в один декларативный объект, но добавляет собственный жизненный цикл, который тоже нужно сопровождать.

На практике выбор проверяется одним вопросом: сколько ручных действий останется при смене версии драйвера на всём парке. Если ответ «пересоздать узлы» — берём управляемый слой, если «ничего не менять» — ручная сборка проще в сопровождении. Гибридный режим оправдан на время миграции: он позволяет перевести под управление один пул, не трогая остальные, и откатиться на любом шаге.

Этапы внедрения: от аудита кластера до передачи вам

Порядок работ выстроен так, чтобы каждое изменение было проверяемым, а состояние кластера — возвратным. Начинаем с инвентаризации, заканчиваем передачей конфигураций и метрик вашей команде.

1. Аудит кластера. Собираем состав узлов с ускорителями, разметку, установленные драйверы и то, как планировщик распределяет устройства. Здесь же выявляем конфликты: старые драйверы, ручные настройки, забытые ограничения.
2. Схема размещения ускорителей. Договариваемся, какие задачи получают устройства и сколько, как делим узлы между командами, какие метки и ограничения не дают посторонним подам занять ускоритель.
3. Настройка оператора. Ставим драйверы, доступ к устройствам и телеметрию декларативно — параметры описаны в репозитории. Разделение одного ускорителя между задачами включаем только там, где это оправдано профилем нагрузки.
4. Проверка на реальной нагрузке. Прогоняем не синтетику, а рабочую модель или сервис: время выхода в готовность, утилизацию, поведение при вытеснении подов и на нескольких узлах одновременно.
5. План отката. Фиксируем порядок возврата к прежнему состоянию: вывод узлов из пула, снятие изменений, точки восстановления. Откат проверяем на стенде, а не описываем на словах.
6. Передача в эксплуатацию. Отдаём конфигурации, схему размещения, метрики и оповещения, инструкции по типовым операциям и обновлению драйверов.

Каждый шаг заканчивается проверяемым артефактом: схемой, конфигурацией, отчётом о нагрузочном прогоне. Поэтому результат не зависит от того, кто остался в команде после передачи.

Конфигурации, схемы и регламенты, которые остаются у вас

Комплект передаётся не как «папка с файлами», а как рабочая система: конфигурации в системе контроля версий с описанием отклонений от базовых значений, схемы, по которым новый инженер за час понимает, как трафик и задания доходят до ускорителей, и регламенты, по которым обновление проходит без остановки сервисов. Ниже — что именно остаётся у вас после сдачи.

• Конфигурации узлов с ускорителями — манифесты меток и отбора узлов, профили совместного использования ускорителя, параметры драйвера и плагина устройств. Отдельно фиксируем, какие значения изменены осознанно и почему, чтобы при следующем обновлении их не «затёрли» настройками по умолчанию.
• Схемы взаимодействия компонентов — от планирования задания до выделения устройства: какие службы участвуют, в каком порядке запускаются, где точка отказа. Схема привязана к именам объектов в кластере, а не к абстрактным блокам.
• Политики доступа и разграничение прав — роли для эксплуатации, разработки и наблюдаемости; кто может менять параметры ускорителей, кто только читает метрики. Права на изменение драйверов вынесены из прикладных учётных записей.
• Регламент обновления — порядок действий при выходе новой ветки: подготовка узлов, дренирование, проверка контрольных заданий, критерии отката. Откат описан отдельно и проверен на стенде до передачи.
• Документация по эксплуатации — типовые отказы (задание не видит ускоритель, узел помечен неготовым, не сходятся метрики), диагностические команды и что смотреть в первую очередь.
• Схема мониторинга и оповещений — какие показатели собираются, какие пороги считаются аварийными, кому и как приходит уведомление.
• Чек-лист приёмки и передачи смены — короткий список проверок после любых работ в кластере, чтобы изменения не оставались незамеченными.

Всё это хранится рядом с инфраструктурным кодом, а не в переписке, — поэтому обновление оператора и обновление драйверов перестают быть событием с неопределённым исходом.

Разбор проекта: кластер перестал простаивать

К нам пришёл кластер под обучение моделей и пакетную обработку данных: десятки задач в очереди, разнородные узлы с ускорителями разных поколений и устойчивое ощущение у команды, что половина запусков падает «не из-за кода».

Узкое место оказалось не в планировщике, а в слое между железом и кластером. Драйверы, библиотеки и плагин устройств ставились на каждый узел вручную, версии между машинами расходились, а после перезагрузки узел возвращался в строй без видимых ускорителей — задача падала уже на старте, съедая очередь и время инженеров.

Мы перевели подготовку узлов на NVIDIA GPU Operator. Оператор сам разворачивает драйверы, набор библиотек, плагин устройств и сбор метрик через DaemonSet, помечает машины по фактическому наличию ускорителя и приводит новый узел к рабочему состоянию без ручных шагов. Дополнительно настроили проверки готовности: узел попадает в расписание только когда ускоритель виден и уже протестирован.

Метрики до и после

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

Что делать, если GPU уже развёрнут, но задачи падают

Падают задачи обычно не из-за оператора, а из-за расхождения двух схем. На узлах, настроенных вручную, драйвер ставился пакетами, и метки там проставлены руками. Там, где работает NVIDIA GPU Operator, то же самое приезжает в контейнерах, а метками управляет оператор. Пока обе схемы живут рядом, поды попадают на узел, который их не принимает: ресурс GPU не опубликован, версия драйвера не совпадает, метки не отвечают селектору.

Диагностика начинается со статуса узлов и событий: видно, какие узлы отдают ресурс, а какие нет, где контейнер с драйвером перезапускается и уводит узел в неготовность. Дальше сверяем по узлам три вещи — метки, допуски и версию драйвера; расхождения именно здесь дают почти все падения при запуске.

Переводим поузлово, без остановки работ: узел закрывается для новых подов, его нагрузка переезжает на остальные, затем с него снимаются ручные метки и он подключается к общей схеме. После переключения публикацию ресурса проверяет пробный под, и только потом узел возвращается в строй. Ёмкость не проседает — из работы выведен один узел, а не весь пул.

Сведение схем в одну — это единый источник правды: версии драйвера, метки, допуски и политики приходят из одного места, ручные правки в них не вносятся. Частично настроенные узлы не дотягивают до остальных руками, а приводятся к тому же виду, что и управляемые, — так уходит класс отказов, когда задача падает из-за «не того» узла. Исходные метки и допуски сохраняем: откат — одна операция, а окно перевода измеряется минутами.

Технические сомнения: совместимость, обновления, откат

Разворачивание оператора затрагивает общие узлы кластера, поэтому сомнения по совместимости и возврату к прежней схеме закономерны. Ниже — ответы на то, что чаще всего проверяют до старта: с чем стыкуется текущий кластер, в каком порядке идут обновления и как выглядит откат.

В каком порядке идут обновления и можно ли работать в это время?

Обновление идёт волнами: сначала один узел, на нём проверяем нагрузку, затем остальные. Задачи с обновляемого узла переезжают на свободные, поэтому очереди и сервисы остаются доступными, а простой не планируется. Версия драйвера задаётся в кластере, а не правится вручную на каждом узле — расхождений между узлами не возникает.

Что с планом отката?

Прежняя схема установки драйверов сохраняется до конца работ, а конфигурация оператора хранится отдельным релизом с историей — возврат к предыдущему состоянию занимает один шаг. Снятие меток возвращает узлы в исходный режим. План отката фиксируем письменно до начала настройки.

Как разграничиваются права команд?

Администрирование оператора остаётся за инфраструктурной командой: обновления, метки узлов, политики. Продуктовые команды работают только в своих пространствах имён и запрашивают ускорители через заявку или квоту. Прямых прав на драйверы и системные компоненты у них нет.

Обсудим задачу: вернёмся с оценкой и планом работ

Оценка внедрения NVIDIA GPU Operator держится на трёх вещах: какие узлы отдаём под ускорители, как кластер устроен сейчас и что именно будет на этих ускорителях считаться. Опишите задачу в свободной форме — этого хватит, чтобы вернуться с планом, а не с уточняющими вопросами.

• схема кластера: сколько узлов и пулов, где стоят ускорители и сколько их на каждом
• как кластер управляется и что ограничивает: закрытый контур без внешней сети, частный реестр образов, свои политики доступа
• какие нагрузки займут ускорители и нужно ли делить их между командами
• что уже сделано: развёрнут ли драйвер вручную, какие попытки были и где остановились
• требования к изоляции и приоритетам: кто может занимать ускоритель и что важнее при нехватке
• окно работ: когда допустимо перезагружать узлы и насколько чувствителен простой

В ответ вы получаете рабочий документ, по которому можно запускать работы:

• схему развёртывания с разбиением узлов на пулы и ролью каждого
• состав работ по этапам: подготовка узлов, развёртывание оператора, проверка планирования задач, сбор метрик
• порядок выката с точками контроля и планом отката к текущему состоянию
• сроки внедрения и чек-лист приёмки: какие проверки подтверждают, что нагрузка реально пошла на ускорители
• что останется вашей команде: конфигурации, описание политик, инструкции по обслуживанию

Опишите задачу — вернёмся с оценкой и планом работ по вашему кластеру.