Dynamic Resource Allocation в Managed Kubernetes от VK Cloud: GPU становятся гибче

Device plugin передаёт планировщику одно значение: сколько GPU свободно на узле. Extended resources в Kubernetes можно запрашивать только целыми числами, а requests и limits для них должны совпадать, если заданы оба.

Поэтому задачу, которой хватило бы половины GPU, нельзя выразить обычным запросом nvidia.com/gpu. То же относится к требованиям к конкретной модели ускорителя или паре устройств с общей шиной: под получает устройство, которое ему выделил планировщик, и получает его целиком.

Dynamic Resource Allocation, или DRA, переносит на устройства декларативную модель, знакомую по работе с хранилищем. В основе механизма лежат четыре объекта API-группы resource.k8s.io/v1. DRA получил статус stable в Kubernetes 1.34 и включён по умолчанию с этой же версии.

Разберём, чем DRA отличается от device plugin, какие сценарии уже доступны, что пока остаётся в beta и как механизм соотносится с GPU-нагрузками в Managed Kubernetes от VK Cloud.

Чем ограничен device plugin

Device plugin регистрирует устройства на узле и сообщает планировщику их количество. Под запрашивает целое число ускорителей через nvidia.com/gpu и получает их целиком.

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

Совместное использование одной карты несколькими подами тоже задаётся не в манифесте приложения, а настройками узла и GPU-аддона.

Четыре объекта DRA вместо счётчика

DRA строится на четырёх объектах API-группы resource.k8s.io/v1:

• ResourceSlice — инвентарь устройств. Он описывает, какие устройства подключены к узлам и какими атрибутами обладают. Слайсы создаёт и обновляет драйвер устройства.
• DeviceClass — категория устройств и правила отбора. В нём определяют атрибуты, которые Kubernetes проверяет при обработке заявок.
• ResourceClaim — заявка рабочей нагрузки. В ней указывают, сколько устройств требуется, какими свойствами они должны обладать и на каких условиях предоставляется доступ.
• ResourceClaimTemplate — шаблон, по которому Kubernetes создаёт отдельный ResourceClaim для каждого пода нагрузки.

Планировщик сопоставляет заявку с опубликованным инвентарём и размещает под на узле, где требование можно выполнить. Отбор по атрибутам задаётся CEL-выражением внутри класса или заявки, поэтому метки на узлах для такого сценария не нужны.

DRA часто сравнивают с динамическим выделением томов. В этой аналогии ResourceClaim похож на PersistentVolumeClaim, а DeviceClass — на StorageClass.

Но аналогия не полная. ResourceSlice не соответствует PersistentVolume: он не выделяется под конкретную заявку, а публикуется драйвером как инвентарь пула устройств. Планировщик выбирает из этого пула уже существующее устройство.

Что DRA меняет для GPU-нагрузок

Выбор ускорителя в манифесте

ML-команда может указать в заявке требования к GPU: объём видеопамяти, поколение ускорителя или конкретную модель. Планировщик найдёт узел с подходящим устройством. Отбор по атрибутам входит в стабильное ядро DRA и доступен с Kubernetes 1.34.

Совместное использование одной карты

В DRA есть три механизма совместного использования GPU, но их зрелость различается.

Ссылка нескольких подов на один общий ResourceClaim входит в стабильное ядро механизма. Разделение ёмкости устройства между независимыми заявками через DRAConsumableCapacity и нарезка карты на логические экземпляры через DRAPartitionableDevices остаются в beta.

Эти возможности стали beta в Kubernetes 1.36. В Kubernetes 1.35 и более ранних версиях они имели статус alpha и были выключены по умолчанию.

Считать DRA заменой MIG пока рано: сценарии дележа и нарезки GPU ещё не достигли стабильного статуса.

Единый язык для устройств

DRA даёт единый декларативный синтаксис для разных типов оборудования: GPU, сетевых адаптеров, FPGA и других устройств.

Вместо отдельных моделей заявок для каждого устройства Kubernetes использует общие объекты ResourceSlice, DeviceClass и ResourceClaim.

Device plugin остаётся в Kubernetes

DRA не отменяет device plugin. Механизм device plugin имеет статус stable с Kubernetes 1.26, и документация не объявляет его устаревшим.

Поддержка DRA-устройств через extended resources, DRAExtendedResource, стала stable в Kubernetes 1.37. Она рассчитана на смешанные кластеры, где на части узлов однотипные устройства обслуживаются device plugin, а на других — DRA.

В таком сценарии манифесты приложений не приходится переписывать.

Ограничение с приоритетами

Перед тем как строить очередь обучения на PriorityClass, нужно учесть ограничение: Kubernetes Scheduler не поддерживает вытеснение для DRA-ресурсов.

Высокоприоритетный под не вытеснит низкоприоритетный workload, который уже занял устройство. Он останется в Pending и будет ждать освобождения ресурса.

GPU в Managed Kubernetes от VK Cloud

GPU-нагрузки в сервисе запускаются на группах узлов с GPU-флейворами и через аддон GPU Operator. GPU-флейворы доступны только для worker-узлов, а сервис Cloud GPU подключается по заявке.

В состав GPU Operator входит NVIDIA device plugin, поэтому текущий контракт нагрузки остаётся прежним: под запрашивает GPU через nvidia.com/gpu.

Дележ карты включается на стороне узла: через метки, настройки MPS или MIG. В модели DRA режим работы устройства описывается в заявке нагрузки, а не в конфигурации узла и аддона.

Масштабирование GPU-групп

Для отдельной группы worker-узлов можно задать от 1 до 500 узлов. Автоматическое удаление узлов работает только до установленного минимума.

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

Окна обучения стоит планировать вместе с жизненным циклом GPU-группы и её настройками автомасштабирования.

Версия Kubernetes и DRA

Доступные версии Managed Kubernetes проходят по границе появления DRA: 1.35.6, 1.34.2, 1.33.3, 1.32.1 и 1.31.4.

• В Kubernetes 1.31 и 1.32 стабильного ядра DRA нет или оно выключено.
• В Kubernetes 1.33 DRA находится в beta и по умолчанию выключен.
• В Kubernetes 1.34 DRA стабилен и включён по умолчанию.
• Начиная с Kubernetes 1.35 feature gate заблокирован во включённом состоянии: отключить DRA флагом нельзя.

Версия кластера определяет, доступен ли команде API DRA.

VK Cloud готовит поддержку DRA в Managed Kubernetes.

Статус DRA в Kubernetes

Feature gate DynamicResourceAllocation проходил несколько стадий развития:

Ранняя ветка DRA, существовавшая в Kubernetes 1.26–1.31, закрыта. Её feature gate DRAControlPlaneController имеет статус removed, поэтому ориентироваться на старые примеры и документацию этой ветки не стоит.

Статус stable означает, что API зафиксирован. В Kubernetes 1.34 основной стала стабильная версия resource.k8s.io/v1, и с переходом на неё механизм включили по умолчанию.

DRA входит в upstream Kubernetes. API одинаков для всех дистрибутивов, а специфика конкретного оборудования задаётся в конфигурации драйвера и заявках на устройство.

Драйвер NVIDIA для GPU передали сообществу Kubernetes на KubeCon + CloudNativeCon Europe 2026. Он развивается в репозитории kubernetes-sigs/dra-driver-nvidia-gpu.

Сейчас в драйвере официально поддерживается часть ComputeDomains. GPU-функции доступны для экспериментов, но официальной поддержки пока не имеют. Kubelet-плагин GPU по умолчанию выключен в Helm-чарте.

Заключение

Device plugin подходит для распределения GPU, пока достаточно счётчика целых карт. DRA расширяет эту модель: позволяет выбирать устройства по атрибутам и использовать общий декларативный синтаксис для GPU, сетевых адаптеров и FPGA.

Отбор по атрибутам и базовые объекты API стабилизировались в Kubernetes 1.34. Деление ёмкости GPU между независимыми заявками и нарезка устройств пока остаются beta-функциями.

Первое, что стоит проверить перед экспериментами с DRA, — версию Kubernetes в GPU-кластере. До Kubernetes 1.33 стабильного API механизма нет. Начиная с версии 1.34 он включён по умолчанию и доступен для тестирования.