Device Plugin честно отработал свою эпоху: он научил Kubernetes видеть GPU и выдавать их подам. Но с бурным ростом AI-нагрузок GPU превратились в общий ресурс для десятков команд. Теперь недостаточно просто запустить задачу — нужны жёсткая изоляция, топология и высокая утилизация. Старая модель достигла предела. Чтобы обойти её ограничения, команды вынуждены создавать поверх Kubernetes «второй Kubernetes». Это дорого, нестабильно и плохо масштабируется.

Именно поэтому индустрия обращает внимание на DRA (Dynamic Resource Allocation) — встроенный в Kubernetes механизм, доступный по умолчанию с версии 1.35. DRA переносит сложную логику выделения и управления устройствами в ядро системы, заменяя конструктор из сторонних инструментов единым, предсказуемым API.

Разберём, почему старые подходы перестали справляться с современными AI-нагрузками, на какие проблемы уже наступили команды в продакшене и зачем изучать DRA, даже если пока не планируете переходить.

Как всё начинается: «дай мне один GPU, и поехали»

Типичный сценарий интеграции GPU в Kubernetes:

1. Устанавливается NVIDIA Device Plugin — вручную или через GPU Operator.
2. В манифесте пода указывается resources.limits: nvidia.com/gpu: 1.
3. Pod размещается на GPU-узле, и контейнер получает доступ к устройству.

На этом этапе кажется, что интеграция завершена. И для многих сценариев этого действительно достаточно.

Но в реальной эксплуатации всё усложняется: появляется больше команд, разнородных нагрузок, требований к изоляции, стабильности и предсказуемости. Возникает вопрос: «Почему именно эта GPU, а не любая другая?».

Умножим на продакшен: коммунальный H100-кластер

Рассмотрим типичный AI-кластер, характерный для многих реальных инфраструктур:

• 8 GPU-узлов;
• по 8 NVIDIA H100 на каждом;
• всего 64 GPU;
• общие ресурсы для нескольких команд и типов нагрузок.

В таком кластере обычно сосуществуют три типа рабочих нагрузок.

1. Продовый инференс

Сервисы, обрабатывающие реальный трафик: vLLM, Triton, LLM-API, embedding/rerank, мультимодальные модели. Для крупных моделей типичный паттерн — одна реплика на один узел целиком: 8 GPU, tensor-parallel-size=8, предсказуемая латентность. vLLM, например, рекомендует использовать количество GPU в узле как размер tensor parallel.

Здесь инференс — не эксперимент, а сервис, который не терпит сюрпризов.

2. ML-обучение и эксперименты

Второй сегмент — обучение моделей. Здесь типичный запрос: «нужно 32 GPU на четырёх узлах, и все должны стартовать одновременно».

Без gang scheduling и специализированных batch-шедулеров такие задачи легко приводят к фрагментации: часть подов запускается, часть зависает в ожидании. Поэтому в экосистеме часто появляются инструменты вроде Volcano — нативный batch-шедулер для Kubernetes, ориентированный на AI/ML и HPC.

3. «Мелочь», которая съедает половину кластера

Третий слой — задачи, которые в отдельности кажутся незначительными, но в сумме создают серьёзную нагрузку на инфраструктуру:

• короткие CUDA-тесты и CI-задачи;
• профилировщики и утилиты;
• небольшие инференс-сервисы (embeddings, STT/TTS), которым не нужен целый H100;
• спорадические нагрузки: «нужно на 5 минут».

Если выделять под них целые GPU, утилизация падает. А это прямое влияние на бюджет, SLO и нервы инженеров. Вопрос перехода на DRA перестаёт быть теоретическим — он становится экономическим и операционным.

Device Plugin: контракт между kubelet и драйвером

Device Plugin — это фреймворк расширения kubelet, позволяющий подключить внешний процесс (обычно в виде DaemonSet) для:

• обнаружения устройств;
• сообщения kubelet о доступных устройствах;
• обработки запросов на выделение устройств (Allocate).

Ключевой момент: Device Plugin работает на уровне kubelet, а не scheduler. Планировщик видит только абстракцию: «на узле есть nvidia.com/gpu: 8». Реальное распределение происходит уже на узле.

Работа по шагам:

• PodSpec запрашивает nvidia.com/gpu: 1;
• планировщик выбирает узел по целочисленному ресурсу;
• kubelet вызывает Allocate у Device Plugin;
• плагин возвращает параметры: какие устройства примонтировать, переменные окружения, девайсы;
• runtime (containerd или CRI-O) запускает контейнер.

Где это живёт на узле

Kubelet использует директорию /var/lib/kubelet/device-plugins/. Туда Device Plugin помещает свой Unix-сокет и регистрируется через kubelet.sock.

Работа по gRPC:

1. Device Plugin запускает gRPC-сервис и создаёт сокет в /var/lib/kubelet/device-plugins/;
2. Регистрируется в kubelet через /var/lib/kubelet/device-plugins/kubelet.sock.

Какие gRPC-методы есть у Device Plugin

Интерфейс включает:

• GetDevicePluginOptions() — возможности плагина;
• ListAndWatch() — потоковое обновление списка устройств;
• Allocate() — выделение устройств при создании контейнера;
• опционально GetPreferredAllocation() и PreStartContainer().

Kubelet также предоставляет Registration-сервис с методом Register(). Важно: плагин должен начать обслуживать запросы до регистрации.

Что происходит при рестарте kubelet

При старте kubelet удаляет все сокеты в /var/lib/kubelet/device-plugins/. Device Plugin обязан пережить это и перерегистрироваться. Это ожидаемое поведение, описанное в документации.

На практике это объясняет частые проблемы: «обновили kubelet — и GPU пропали». Причина — не в мистике, а в жизненном цикле сокетов и совместимости компонентов.

Почему Device Plugin перестаёт справляться

Device Plugin не плох. Он эффективно решает задачу эксклюзивного выделения целых устройств.

Но с ростом AI-нагрузок ожидания изменились:

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

Главная проблема: в Kubernetes с Device Plugin GPU остаётся extended resource — внешней сущностью. Платформа знает только количество, но не понимает внутреннюю структуру устройства.

Ограничения extended resources

Для nvidia.com/gpu действуют строгие правила:

• если указан limits, он считается и за requests;
• если указаны оба — они должны совпадать;
• requests без limits запрещены.

Ресурс — целочисленный, неделимый и не может быть выделен нескольким контейнерам.

В коммунальном кластере это приводит к проблемам:

• инференс забирает узлы целиком;
• обучение требует пачки GPU одновременно;
• мелкие задачи вынуждены занимать целые GPU, снижая утилизацию.

Квоты тоже работают поштучно. Это ограничивает гибкость управления ресурсами.

Когда нужен не целый GPU, а его часть, индустрия прибегает к костылям: time-slicing, MPS, MIG, vGPU, SR-IOV, кастомные шедулеры.

Популярные практики разделения GPU

Практика 1. GPU Operator: device plugin — это только верхушка

Установка Device Plugin — лишь часть инфраструктуры. Полноценный GPU-контур включает драйверы, container runtime, мониторинг, MIG-менеджер, NFD-лейблы.

GPU Operator объединяет эти компоненты, но имеет ограничения: требует интернета, ограниченная кастомизация. Некоторые команды предпочитают ручную сборку.

Device Plugin решает выделение GPU, но не покрывает жизненный цикл инфраструктуры на узле.

Практика 2. Time-slicing: видимость большего количества GPU

Реализуется через конфигурацию Device Plugin: он публикует увеличенное количество nvidia.com/gpu. Несколько подов делят один GPU по времени.

Проверка:

• kubectl describe node <gpu-node> — смотрим Capacity/Allocatable;
• запускаем несколько подов с nvidia.com/gpu: 1 — они стартуют на одном узле.

Грабли:

• нет изоляции памяти и сбоев;
• нет гарантии пропорциональной производительности;
• метрики DCGM не разделяются по контейнерам;
• изменения конфигурации не всегда подхватываются автоматически — может потребоваться перезапуск DaemonSet.

Практика 3. MIG: аппаратная нарезка с высокой стоимостью эксплуатации

MIG (Multi-Instance GPU) даёт аппаратную изоляцию. Но требует сложного управления:

• конфигурация применяется на узле;
• требуется остановка подов и иногда перезагрузка;
• нужно синхронизировать с Kubernetes-ресурсами.

В GPU Operator за это отвечает MIG Manager — привилегированный DaemonSet, который:

• следит за лейблом nvidia.com/mig.config;
• останавливает поды и хостовые процессы;
• применяет новую конфигурацию через mig-parted;
• может требовать перезагрузки.

Проблемы:

• логика управления — в shell-скрипте из ConfigMap;
• в образе MIG Manager есть kubectl — нестандартно для контроллера;
• обновление ConfigMap не всегда отражается в поде из-за кэширования файла.

Грабли:

• переконфигурация требует остановки нагрузок;
• баги драйверов (например, зависание задач при смешанном использовании MIG и целых GPU);
• ошибки в топологии — высокая цена при динамическом управлении.

Практика 4. vGPU: два мира

4.1 NVIDIA vGPU — решение для виртуализации, ориентированное на виртуальные машины (например, KubeVirt). Требует лицензирования и не является Kubernetes-native.

4.2 vGPU для контейнеров — реализуется через Volcano + HAMi, где:

• HAMi-core — программная виртуализация через hijacking CUDA API;
• Dynamic MIG — динамическое создание MIG-инстансов.

Появляются:

• отдельный планировщик (Volcano);
• новые ресурсы (например, volcano.sh/vgpu-);
• свой механизм распределения.

Грабли:

• это отдельная экосистема, а не пара YAML;
• настройка через конфиг-файл не работает — device plugin читает только аргументы командной строки;
• конфликты плагинов на узле — рекомендуется один GPU device plugin.

Практика 5. Топология: не любой GPU подойдёт

Теперь важно не только количество, но и качество GPU:

• NVLink между картами;
• одна NUMA-область;
• конкретный SKU;
• связь с NIC для RDMA;
• избежание конфликтов по PCIe.

Device Plugin может передавать topology hints (например, NUMA-аффинити), и Kubernetes поддерживает это через Topology Manager. Но это не решает проблему полностью.

На практике команды используют:

• лейблы и taints;
• nodeAffinity;
• отдельные пулы узлов;
• кастомные шедулеры;
• ручные проверки NVLink.

Это второй аргумент в пользу DRA: хочется описывать требования через атрибуты устройства, а не угадывать подходящие узлы.

Эксплуатация: GPU внезапно исчезают

Операционные проблемы — частая боль. Device Plugin должен переживать рестарты kubelet, перерегистрироваться, следить за сокетами. Но обновления идут непрерывно:

• kubelet;
• containerd/CRI-O;
• ядро;
• драйверы NVIDIA;
• container toolkit;
• операторы;
• политики безопасности.

Несовместимости, баги или неправильный порядок обновления могут привести к исчезновению GPU.

Требования к платформе растут:

• устройства должны быть проверены до начала работы;
• выделение — детерминированное;
• состояние драйверов и железа — полностью наблюдаемо;
• должен быть понятный механизм вывода узлов в обслуживание;
• обновления не должны быть лотереей.

Всё это выходит за рамки изначальной концепции Device Plugin.

Итоги: где Device Plugin хорош, а где начинаются разDRAжения

Device Plugin отлично справляется с:

• эксклюзивной выдачей целых устройств;
• вендор-специфичной подготовкой устройств в Allocate;
• сигнализацией о состоянии устройств и их видимостью для kubelet.

Device Plugin упирается в потолок, когда нужны:

• гибкое и предсказуемое разделение устройств;
• описание запросов через атрибуты (SKU, память, топология, fabric и т.д.);
• управление жизненным циклом устройства как полноценного объекта платформы;
• унифицированная модель для GPU, сетевых адаптеров, FPGA и разных вендоров.

Ощущение, что Device Plugin перестал быть достаточным, возникает не из-за его неисправности, а потому что индустрия вышла за рамки его изначального назначения.

Именно поэтому появляется DRA — следующий шаг в эволюции управления устройствами в Kubernetes.

Device Plugin честно отработал свою эпоху: он научил Kubernetes видеть GPU и выдавать их подам. Но с AI‑бумом GPU превратились в общий ресурс для десятков команд. Тут уже не «лишь бы запустилось», а нужны жёсткая изоляция, топология и утилизация. Старая модель упёрлась в потолок. Чтобы обойти её ограничения, команды вынуждены городить поверх «второй Kubernetes». А это дорого, часто ломается и плохо масштабируется.

Именно поэтому индустрия смотрит на DRA (Dynamic Resource Allocation). Это встроенный в Kubernetes механизм (начиная с версии 1.35 включён по умолчанию), который зашивает всю сложную логику выделения устройств и управления ими прямо в ядро, чтобы вместо конструктора из сторонних инструментов получать единый, предсказуемый API.

В статье разбираем, почему старые методы уже не тянут современные AI‑нагрузки, на какие грабли уже наступили команды в реальном проде и зачем понимать, как устроен DRA, даже если переходить на него пока нет в планах.

Привет, Хабр! Я Александр Подмосковный, менеджер продукта в команде Deckhouse Kubernetes Platform, где развиваю направление ML/AI. В коммерческой разработке с 2011 года, с 2020 года плотно занимаюсь DevOps и Kubernetes, а с 2024 года — ещё и инфраструктурой для AI. Сейчас меня больше всего затягивает стык трёх направлений: надёжной инфраструктуры, инференс-сервисов и прикладных AI‑сценариев, которые должны не просто красиво выглядеть на демо, а нормально жить в production.

Как обычно всё начинается: «дай мне один GPU, и поехали»

Типичная точка входа в Kubernetes‑GPU выглядит так:

1. Устанавливается NVIDIA device plugin (часто через GPU Operator, реже руками).
2. В манифесте пода добавляется resources.limits: nvidia.com/gpu: 1.
3. Под уезжает на GPU‑узел и внутри контейнера появляется доступ к устройству.

Пример (минимальный, чтобы проверить, что вообще работает):

На этом этапе кажется, что вопрос интеграции GPU в Kubernetes закрыт. И для множества сценариев так и есть.

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

Теперь умножим это на прод: коммунальный H100‑кластер

Чтобы не обсуждать DRA абстрактно, дальше я буду использовать один и тот же пример. Он типичен не потому, что «модно», а потому, что именно так сейчас выглядит реальность многих AI‑контуров.

Представим коммунальный кластер:

• 8 GPU-узлов;
• на каждом по 8×NVIDIA H100;
• итого 64 GPU;
• и все они общие — не под одну команду, а под несколько команд и классов нагрузок. H100 здесь не случайный выбор: это один из самых распространённых вариантов для тяжёлых AI‑задач.

Внутри этого кластера почти всегда живут три разных мира.

1. Продовый инференс

Первый — сервисы, которые держат продовый трафик: vLLM, Triton, свои inference-воркеры, LLM‑API, embedding/rerank, мультимодальные сервисы. Для больших моделей нормальным паттерном становится «одна реплика — один узел целиком»: 8 GPU на узле,tensor-parallel-size=8, предсказуемая латентность и меньше сюрпризов с размещением. vLLM прямо описывает это в документации: он поддерживает tensor parallel и multi-node inference, а типовой способ думать о конфигурации — брать tensor parallel size равным числу GPU в узле.

Условный фрагмент такого сервиса:

Смысл здесь простой: инференс здесь не «пилот», а сервис, и он очень не любит сюрпризы.

2. ML-обучение и эксперименты

Второй мир — обучение. Там вполне нормальный запрос звучит так:  нужно 32 GPU на четырёх узлах по 8, и желательно, чтобы они стартовали вместе, а не по частям.

Условный train job выглядит примерно так:

И тут начинается тонкая материя: без gang scheduling и отдельного взгляда на batch‑нагрузки такая история легко превращается в ситуацию, когда часть подов уехала, часть ждёт, ресурсы фрагментировались, а соседи недовольны. Поэтому рядом с GPU‑экосистемой почти всегда всплывают batch‑шедулеры и очереди.Volcano, например, прямо позиционируется как Kubernetes‑native batch scheduling system для AI/ML/HPC‑нагрузок.

3. «Мелочь», которая в сумме съедает половину кластера

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

• короткие CUDA‑тесты и CI‑задачи (Jobs);
• профилировщики и утилиты;
• небольшие inference‑сервисы вроде embeddings, rerank, STT/TTS, которым часто не нужен целый H100;
• спорадические нагрузки: «сейчас нужно 5 минут, потом исчезаю».

Если под такие задачи выделять по целой GPU, утилизация почти гарантированно падает: дорогие ресурсы простаивают. И вопрос о переходе на DRA перестаёт быть теоретическим — он становится вопросом денег, SLO и нервов команды.

device plugin — это контракт между kubelet и драйвером устройства

Перед разговором про DRA полезно честно разложить, что делает device plugin.

Kubernetes device plugin — это фреймворк расширения kubelet, который позволяет подключить к узлу внешний процесс (обычно в виде DaemonSet) и через него:

• обнаруживать устройства;
• сообщать kubelet о доступных устройствах и их состоянии;
• отвечать на запрос kubelet на выделение конкретных устройств для контейнера (Allocate).

И ключевой момент здесь такой:device plugin работает на уровне kubelet, а не scheduler. Планировщик видит только абстракцию вида «на этом узле естьnvidia.com/gpu: 8». Всё реальное устройство‑специфичное распределение и подготовка происходят уже на узле. Это и есть базоваялогика работы device plugin framework.

• PodSpecсlimits nvidia.com/gpu=1;
• планировщик выбирает узел по целочисленному ресурсу;
• kubelet на узле вызываетAllocateу device plugin
• плагин возвращает параметры: какие устройства примонтировать, какие переменные окружения установить, какие девайсы пробросить;
• runtime (containerd или CRI‑O) запускает контейнер с подготовленными ресурсами.

Как device plugin работает технически (сокеты, gRPC, kubelet)

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

Где это живёт на узле

Kubelet использует директорию/var/lib/kubelet/device-plugins/.

В неё device plugin кладёт свой Unix‑socket, и туда же kubelet поднимает свой socket для регистрации. Документация Kubernetes прямо описывает workflow так:

1. Device plugin запускает gRPC‑сервис и создаёт Unix‑socket под/var/lib/kubelet/device-plugins/
2. Затем регистрируется в kubelet через socket/var/lib/kubelet/device-plugins/kubelet.sock

На практике у NVIDIA device plugin можно увидеть.../nvidia-gpu.sock. Пример и логи есть даже в прикладных гайдахпо запуску GTA-VC в кубере(я тоже так делал, поэтому не мог обойти увлекательную статью).

Команды для самопроверки на узле:

Какие gRPC-методы есть у device plugin

В документации Kubernetes приведён интерфейсDevicePlugin, который включает (суть):

• GetDevicePluginOptions()— какие опции и возможности у плагина;
• ListAndWatch()— потоковая передача списка устройств и их состояния;
• Allocate()— вызывается при создании контейнера, чтобы сделать девайс доступным;
• опциональноGetPreferredAllocation()иPreStartContainer().

И отдельно kubelet экспортирует Registration‑сервис с методомRegister(), через который plugin «представляется» системе.

Важно, что Kubernetes отдельно подчёркивает порядок действий:сначала plugin должен начать обслуживать gRPC-запросы и только потом регистрироваться.

Что делает kubelet при рестарте

Один из самых недооценённых моментов:при старте kubelet  удаляет существующие Unix‑сокеты под/var/lib/kubelet/device-plugins, и plugin должен это пережить и перерегистрироваться. Это явно описано в документации как ожидаемое поведение.

Отсюда вытекает практический вывод: ситуации вроде «обновили kubelet/узел/CRI — и вдруг пропали GPU» часто упираются не в мистику, а в очень конкретный жизненный цикл сокетов, регистрации и совместимости компонентов.

Почему ощущение, что device plugin уже не справляется, стало массовым

Сам по себе device plugin не плохой. Он честно решаетзадачу эксклюзивного выделения device‑единицы.

Проблема в том, что реальные ожидания от GPU в кластере за последние годы с бумом ИИ сильно изменились:

• GPU перестали быть редким узлом под один эксперимент.
• GPU стали частью продуктовых платформ (инференс, batch, аналитика, R&D‑песочницы).
• Возникла потребность делить, изолировать нагрузки, совмещать с сетями/топологией и проводить обслуживание без сбоев.

И тут мы приходим к главному:в Kubernetes с device plugin устройство остаётся «extended resource», то есть внешней сущностью, где платформа знает только число и имя ресурса, но не понимает, что именно внутри.

GPU как extended resource: целые числа и жёсткий контракт

На уровне Kubernetesnvidia.com/gpu— это extended resource. И у этой модели есть важные ограничения.

Для GPU Kubernetes прямоговорит:

• можно указатьlimitsбезrequests, и тогдаlimitsбудут считаться как requests;
• если указываете иrequests, иlimits, они должны совпадать;
• requestsбезlimitsдля GPU указывать нельзя.

А для extended resources в целом устройство живёт какцелочисленный ресурс, который нельзя выделять больше, чем есть физически, и нельзя делить между контейнерами. Это тоже важный пункт в документации device plugin.

В нашем коммунальном примере это проявляется мгновенно:

• продовый vLLM забирает узлы целиком, потому что так проще жить;
• обучение просит «пачку GPU» и хочет, чтобы эта пачка приехала целиком;
• а «мелочь» начинает жечь по одной GPU на узел либо нужно идти настраивать разделение ресурсов.

Квоты на таком ресурсе тоже выглядят поштучно. Официальная документация поResourceQuotaдаже приводит пример именно дляrequests.nvidia.com/gpu:

Это иллюстрирует тот самый целочисленный контракт для extended resources.

И вот тут появляется первая платформенная боль: есть задачи, которым нужен не целый (1) GPU, а его кусочек.

Kubernetes в модели device plugin не умеет отдавать «кусочки». Поэтому индустрия пошла в костыли: time‑slicing, MPS, MIG, MxGPU, SR-IOV, vGPU‑плагины, кастомные шедулеры.

Популярные практики и инструменты 2025–2026: как команды реально делят GPU

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

1. Неравномерные нагрузки и желание утилизировать GPU плотнее.
2. Требования не просто дать N GPU, а дать правильные GPU— с нужной памятью, режимом, топологией, иногда вообще в связке с сетью.

И вот здесь начинается набор практик, каждая из которых полезна, но каждая же увеличивает сложность общей системы.

Практика 1. GPU Operator, потому что device plugin — это только верхушка

Многие начинают с установки device plugin, полагая, что этого достаточно. А потом выясняется, что GPU в Kubernetes обычно включает пачку вещей: драйвер, container runtime hooks, мониторинг, MIG‑менеджер, NFD‑лейблы. Пока всё стабильно, масштаб этого айсберга не видно; первый же сбой или нетипичный сценарий быстро показывает, что device plugin — это только его верхушка.

Это хорошо видно на практике: естьслучаи, где после обновления кластера приходится собирать полноценный GPU‑контур.

Есть и обратныекейсы: команды упираются в ограничения GPU Operator (например, необходимость интернета, ограниченная кастомизация) и сознательно идут в ручную сборку или собственную автоматизацию.

Моральdevice plugin решает задачу выделения GPU, но не закрывает жизненный цикл инфраструктуры на узле.

Практика 2. Time‑slicing: создаём видимость, что GPU больше, чем есть

Это очень распространённый путь быстро поделить один GPU между несколькими workload. Его часто выбирают, когда:

• есть много небольших задач;
• нужно больше параллельности по времени, чем по устройствам.

По факту несколько подовделят один и тот же физический GPU по времени, без аппаратной изоляции памяти.

Технически это реализуется через конфигурацию NVIDIA device plugin: надо задать, сколько реплик сделать для ресурса, и device plugin начинает публиковать в kubelet/NodeStatus увеличенную ёмкость.

Дальше этот ConfigMap подключается в конфигурацию device plugin (в случае GPU Operator это делается черезClusterPolicy). В результате kubelet начинает показывать, что GPU стало больше.

Как проверить:

• kubectl describe node и смотримCapacity/Allocatableпоnvidia.com/gpu.
• Запускаем несколько подов, каждый просит 1 GPU, и убеждаемся, что они реально попадают на один и тот же узел и стартуют параллельно.

Грабли, которые обычно всплывают:

1. Нет изоляции памяти и изоляции сбоев (fault isolation).Это официально указано как ограничение: time‑slicing даёт разделение по времени, но не делает из GPU много маленьких независимых GPU в аппаратном смысле.

2. Запрос нескольких долей GPU не гарантирует пропорциональной мощности.Не обязательно. Если вы запросите, например, две time‑sliced-карты, это не значит, что вы получите ровно вдвое больше ресурсов.

3. Проблемы с метриками.Стандартный DCGM Exporter в схеме time‑slicing не умеет корректно разбивать нагрузку по контейнерам. Привычные графики «сколько GPU потребляет этот под» здесь будут работать с погрешностью или вообще не отобразят реальное потребление.

4. Изменения конфигурации не всегда подхватываются автоматически.GPU Operator не мониторит автоматически изменения в ConfigMap с конфигом device plugin. На практике часто приходится перезапускать DaemonSet device plugin.

Практика 3. MIG: аппаратная нарезка с тяжёлым жизненным циклом

MIG (Multi‑Instance GPU) часто встречают с облегчением: ну наконец-то нормальная изоляция. И действительно, аппаратная нарезка даёт более предсказуемые границы.

Но за изоляцию платят эксплуатацией:

• конфигурация MIG должна быть применена на узле;
• нужно следить, чтобы она совпадала с ожидаемой моделью ресурсов в Kubernetes;
• в зависимости от сценария может потребоваться reset/reconfigure, что плохо сочетается с работающим продовым инференсом.

Если в кластере используется NVIDIA GPU Operator, то ключевой персонаж тут —MIG Manager.

• следит за лейбломnvidia.com/mig.configна узле;
• при изменении лейбла останавливает GPU‑поды;
• при необходимости останавливает и хостовые GPU‑клиенты;
• применяет новую геометрию MIG (черезmig-parted);
• иногда может потребовать перезагрузить узел;
• только потом возвращает экосистему в «Готово к работе».

Типичный триггервыглядит так:

А состояние удобно смотреть поnvidia.com/mig.config.state(pending/rebooting/success/failed).

Почему это многим кажется тяжёлым (и да, там есть kubectl в контейнере):

1. MIG Manager в GPU Operator —это DaemonSet, который запускается привилегированно, сhostPID/hostIPC, монтирует host filesystem и выполняет скрипт из ConfigMap как entrypoint.

В манифесте прямым текстом видно, что контейнер стартует/bin/entrypoint.sh, а самentrypoint.shмонтируется из ConfigMapnvidia-mig-manager-entrypointчерезsubPath.

То есть да:логика управления MIG в значимой части живёт в shell‑скрипте, приехавшем через ConfigMap в под.

2. В образ mig‑manager кладут kubectl.Это видно по слоям образа на Docker Hub: там есть копирование kubectl в/usr/bin/kubectl.

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

3. Есть реальные эксплуатационные нюансы на уровне ConfigMap.В issues GPU Operator встречается сценарий, когда поменяли custom MIG configmap, а внутри mig‑manager всё ещё старое содержимое, потому что в поде примонтирован старый файл.

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

1. MIG‑переконфигурация требует остановить пользовательские нагрузки.Это официальное требование: при нарезке/перенарезке нельзя оставлять активные workload’ы на тех GPU, которые затрагиваются. Иногда ещё и ребут нужен, поэтому узел стоит cordon’ить заранее.

2. Реальные баги драйверов.В документации GPU Operator зафиксирована проблема для некоторых версий драйвера 570: на узлах, где одновременно используются MIG‑слайсы и «цельные» GPU, задачи могут зависать в состоянии Pending. Как обходное решение предлагается временно откатиться на более старую версию драйвера.

3. Чем глубже топология, тем выше цена ошибки.Если делать MIG на лету, важно точно понимать: кто имеет право менять геометрию, когда, по каким правилам и что происходит с уже запущенными задачами.

Практика 4. vGPU в Kubernetes: «железная» и «софтверная» реальности

ТерминvGPUв инфраструктуре часто используют как зонтик, но в Kubernetes под ним обычно встречаются два разных мира.

4.1 NVIDIA vGPU (как продукт для виртуализации)

Это решение ориентировано в первую очередь на виртуальные машины, например KubeVirt, и требует отдельного лицензирования, что усложняет деплой и не является Kubernetes-native. Важно: даже в документации по time‑slicing упоминаются сценарии, где решение может работать ВМ с NVIDIA vGPU.

Для Kubernetes‑платформы это обычно означает запуск кластера внутри виртуальной машины с размеченными как vGPU ресурсами, что влечёт за собой отдельную ветку требований и поддержки.

4.2 vGPU для контейнеров в продакшене: Volcano + HAMi (hami‑core / Dynamic MIG)

Если речь идёт о решениях для разделения GPU между подами в кластерах, на практике часто выбирают связку HAMi с планировщиком — Volcano или KAI-Scheduler.

Volcano описывает две модели виртуализации GPU:

• HAMI‑core— программная виртуализация на уровне CUDA API hijacking, VCUDA‑подход;
• Dynamic MIG— динамическое создание MIG‑инстансов.

Это уже выходит за рамки обычного device plugin. Там появляются:

• отдельный планировщик (Volcano);
• свои extended resources (volcano.sh/vgpu-*);
• свой механизм распределения виртуализированных ресурсов GPU.

Грабли vGPU‑мира:

1. Это уже другая экосистема, а не пара YAML-файлов.Volcano требует своего планировщика и конфигурации.

2. Настройки и эксплуатация.В статьепро Volcano есть конкретная боль: попытка настроить vGPU-плагин через конфиг‑файл не работает, потому что device plugin читает только параметры командной строки.

3. Конфликты плагинов на узле.В той же статье отдельно упоминается, что на узле обычно рекомендуют запускать один GPU device plugin, иначе они начинают конфликтовать.

Практика 5. Топология: когда любой GPU уже не подходит

Следующий класс проблем появляется, когда важны не только количество GPU, но и то,какие именноу насGPU:

• две карты должны быть связаны через NVLink;
• две карты должны быть в одной NUMA‑области;
• нужен конкретный SKU;
• вместе с GPU нужен конкретный NIC под RDMA;
• нужно избежать конфликтов по PCIe‑топологии.

Device plugin частично может отдаватьtopology hints(NUMA‑аффинити) и Kubernetes умеет работать с этим через Topology Manager, это описанов документации. Но «частично» здесь ключевое слово: это не превращается автоматически в удобный язык требований для пользователя.

И в итоге команды снова оказываются в знакомой зоне:

• лейблы/taints на узлах;
• nodeAffinity;
• отдельные пулы узлов;
• кастомные планировщики;
• ручная проверка, что NVLink есть, с последующей фиксацией конфигурации.

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

Эксплуатация: плагин установлен, но GPU внезапно исчезают

Операционный слой часто оказывается самым болезненным местом. Kubernetes ожидает, что device plugin корректно переживает рестарты kubelet, перерегистрируется, отслеживает сокеты. Но на практике обновления идут непрерывным потоком:

• kubelet;
• containerd/CRI‑O;
• kernel;
• драйверы NVIDIA;
• container toolkit;
• операторы;
• политики безопасности.

И где-то в этом стеке может быть несовместимость, скрытый баг или просто некорректный порядок обновления. В итоге требования к платформе смещаются от простого запуска пода с GPU к более строгим условиям:

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

Всё это уже выходит за рамки исходной задумки device plugin.

Итоги: где device plugin хорош, а где начинаются разDRAжения

Если коротко (но честно):

Device Plugin отлично справляется с тремя задачами:

• эксклюзивная выдача целых устройств на конкретном узле;
• вендор‑специфичная подготовка в Allocate (если плагин это реализует);
• сигнализация о здоровье устройств и их базовая видимость для kubelet.

Device Plugin системно упирается в потолок, когда появляются следующие требования:

• гибкое и предсказуемое разделение устройств вместо настройки реплик;
• описание запросов в терминах атрибутов (SKU, память, топология, fabric‑attached и т. д.);
• управление жизненным циклом устройства как полноценным объектом платформы;
• унифицированная модель для разных типов устройств (GPU, сетевые адаптеры, FPGA) и вендоров.

Ощущение, что device plugin перестал быть достаточным, возникает не потому, что он сломался, а потому, чтоиндустрия перестала использовать его по изначальному назначению.

И вот тут появляется DRA.

Продолжение следует

Скоро выйдет материал, в котором я расскажу,что именно Kubernetes добавил вместе с DRA, почему в документации DRA уже отмечен как stable (и включён по умолчанию) начиная с Kubernetes 1.35 и какие части DRA сейчас в каком состоянии по версиям (потому что там действительно много фич и не все они одинаково зрелые).

Читайте также в нашем блоге:

• Распределённый инференс и шардирование LLM. Часть 1: настройка GPU, проброс в Proxmox и настройка Kubernetes
• Распределённый инференс и шардирование LLM. Часть 2: скрипт vLLM, Ray Serve для вывода API и настройка KubeRay Cluster
• Распределённый инференс и шардирование LLM. Часть 3: настройка авторизации и интеграция с Open WebUI