DRAматургия GPU в Kubernetes: зачем нужен DRA, если Device Plugin работает? Разбираем грабли AI-инфраструктуры / Хабр

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 выглядит так:

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

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

apiVersion: v1
kind: Pod
metadata:
  name: gpu-smoke
spec:
  restartPolicy: Never
  containers:
  - name: cuda
    image: nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda12.5.0
    resources:
      limits:
        nvidia.com/gpu: 1
  tolerations:
  - key: nvidia.com/gpu
    operator: Exists
    effect: NoSchedule

На этом этапе кажется, что вопрос интеграции 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 в узле.

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

apiVersion: apps/v1
kind: Deployment
metadata:
  name: llm-prod
  namespace: inference-prod
spec:
  replicas: 2
  selector:
    matchLabels:
      app: llm-prod
  template:
    metadata:
      labels:
        app: llm-prod
    spec:
      nodeSelector:
        node-role/gpu: ""
      tolerations:
      - key: node-role
        operator: Equal
        value: gpu
        effect: NoSchedule
      containers:
      - name: vllm
        image: vllm/vllm-openai:latest
        args:
        - "--model"
        - "meta-llama/Llama-3.1-70B-Instruct"
        - "--tensor-parallel-size"
        - "8"
        - "--max-model-len"
        - "8192"
        resources:
          limits:
            nvidia.com/gpu: 8
            cpu: "16"
            memory: "128Gi"

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

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

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

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

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: train-llm
  namespace: ml-train
spec:
  serviceName: train-llm
  replicas: 4
  podManagementPolicy: Parallel
  selector:
    matchLabels:
      app: train-llm
  template:
    metadata:
      labels:
        app: train-llm
    spec:
      nodeSelector:
        node-role/gpu: ""
      tolerations:
      - key: node-role
        operator: Equal
        value: gpu
        effect: NoSchedule
      containers:
      - name: trainer
        image: nvcr.io/nvidia/pytorch:24.12-py3
        command: ["bash","-lc"]
        args:
        - |
          torchrun \
            --nnodes=4 \
            --nproc_per_node=8 \
            --rdzv_backend=c10d \
            --rdzv_endpoint=train-llm-0.train-llm:29500 \
            train.py
        resources:
          limits:
            nvidia.com/gpu: 8
            cpu: "32"
            memory: "256Gi"

И тут начинается тонкая материя: без 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)

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

Сокеты, gRPC‑методы, обработка рестартов kubelet

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

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

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

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

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

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

[root@dkp-ce-w3-gpu ~]# sudo ls -la /var/lib/kubelet/device-plugins/
total 12
drwxr-xr-x.  2 root root 4096 Feb 18 14:14 .
drwx------. 10 root root 4096 Feb 18 14:15 ..
-rw-------.  1 root root 1371 Feb 18 14:14 kubelet_internal_checkpoint
srwxr-xr-x.  1 root root    0 Jan 29 11:28 kubelet.sock
srwxr-xr-x.  1 root root    0 Feb 15 10:10 nvidia-gpu.sock
[root@dkp-ce-w3-gpu ~]# sudo ss -xl | grep device-plugins
u_str LISTEN 0      1000                                         /var/lib/kubelet/device-plugins/kubelet.sock 530382               * 0

Какие 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: целые числа и жёсткий контракт

На уровне Kubernetes nvidia.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:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: quota-gpu
spec:
  hard:
    requests.nvidia.com/gpu: "4"

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

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

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

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

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

Неравномерные нагрузки и желание утилизировать GPU плотнее.
Требования не просто дать 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 по времени, без аппаратной изоляции памяти.

Как это устроено в Kubernetes

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

Пример:

apiVersion: v1
kind: ConfigMap
metadata:
  name: gpu-sharing
  namespace: gpu-operator
data:
  config.yaml: |-
    version: v1
    sharing:
      timeSlicing:
        resources:
          - name: nvidia.com/gpu
            replicas: 4

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

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

kubectl describe node <gpu-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, что плохо сочетается с работающим продовым инференсом.

И вот здесь начинается любимая часть инженера, который любит смотреть, как оно реально сделано в Open Source.

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

Он:

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

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

kubectl label node <node> nvidia.com/mig.config=all-1g.10gb --overwrite

А состояние удобно смотреть по 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 монтируется из ConfigMap nvidia-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.

Пример:

apiVersion: v1
kind: Pod
metadata:
  name: vgpu-demo
  annotations:
    volcano.sh/vgpu-mode: "hami-core"
spec:
  schedulerName: volcano
  containers:
    - name: cuda
      image: nvidia/cuda:12.4.1-base-ubuntu22.04
      command: ["bash","-lc","nvidia-smi && sleep 3600"]
      resources:
        limits:
          volcano.sh/vgpu-number: "1"
          volcano.sh/vgpu-cores: "50"
          volcano.sh/vgpu-memory: "8192"

Грабли 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 сейчас в каком состоянии по версиям (потому что там действительно много фич и не все они одинаково зрелые).

P. S.

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

DRAматургия GPU в Kubernetes: зачем нужен DRA, если Device Plugin работает? Разбираем грабли AI-инфраструктуры