1 сентября 2025 года Dynamic Resource Allocation, или DRA, стал в Kubernetes стабильной функцией и включается по умолчанию. Весной 2026-го Nvidia и Google уже отдали сообществу драйверы под эту модель для GPU и TPU. Для команд, которые держат AI-нагрузки на смешанных кластерах, DRA в Kubernetes выглядит не как еще одна аббревиатура из мира CNCF, а как шанс перестать вручную угадывать, на какой ноде вообще есть подходящий ускоритель.
По данным The New Stack, главная перемена в том, что Kubernetes наконец учится просить не просто «одну GPU», а конкретный тип устройства с понятными характеристиками. Старая схема через Device Plugin была терпимой, пока приложению хватало записи вроде nvidia.com/gpu: 1. Но как только в кластере появляются ускорители разных поколений, разный объем VRAM, MIG-профили, NVLink и требования к топологии, начинается знакомый аттракцион: node labels, nodeSelector, affinity-правила, ручные исключения и вечный поиск ноды, которая не занята и при этом действительно подходит задаче.
DRA меняет эту механику на уровне API. У платформенной команды появляется DeviceClass, то есть абстракция для классов устройств вроде GPU с большим объемом памяти. Драйвер публикует ResourceSlice, фактический инвентарь железа, где видны уже не только штуки GPU на узле, но и память, модель, NUMA-привязка, PCIe-топология и другие атрибуты. А приложение оформляет ResourceClaim: не ищет нужную ноду само, а описывает, что ему нужен, например, один ускоритель из класса high-memory-gpu или устройство минимум с 40 GiB памяти. Дальше выбор делает планировщик, а не человек с открытым kubectl и списком хостнеймов в заметках.
Показательный пример, который разбирает источник, связан с inference-сервером vLLM. В старой схеме разработчик либо просит абстрактную GPU и надеется на лучшее, либо вшивает в YAML привязку к конкретным узлам. С DRA администратор один раз описывает класс high-memory-gpu через CEL-фильтр, а сервис просто просит устройство из этого класса. Если завтра в пуле появляются новые карты с нужным объемом памяти, манифест приложения переписывать не надо. Для продуктовых команд это редкий случай, когда инфраструктурная абстракция действительно убирает рутину, а не добавляет еще один слой конфигурации.
Контекст у этой истории длиннее, чем кажется по бодрому заголовку. DRA впервые появился в Kubernetes 1.26 как alpha-функция, затем был заметно переработан в 1.31, вышел в beta в 1.32 и дошел до general availability 1 сентября 2025 года в релизе Kubernetes 1.34. Именно с 1.34 базовые API группы resource.k8s.io стали стабильными и включенными по умолчанию. Параллельно проект получает более тонкие сценарии работы с устройствами: в 1.34, например, появились alpha-механизмы consumable capacity, которые готовят почву для более аккуратного шаринга ресурсов внутри одного устройства. Иначе говоря, речь уже не о том, можно ли жить без старого Device Plugin, а о том, как быстро экосистема догонит новый API.
Рынок отреагировал довольно однозначно. На KubeCon Europe 24-25 марта 2026 года Nvidia передала GPU-драйвер DRA в CNCF, а Google объявила об open-source-релизе DRA-драйвера для TPU. Когда два крупнейших игрока в AI-железе подписываются под одной моделью управления ресурсами, это уже не эксперимент для энтузиастов. Тем более что DRA фигурирует и в программе Kubernetes AI Conformance: для вендоров и облаков это становится не опцией «для продвинутых», а частью базового контракта AI-ready платформы.
Для разработчиков, продактов и IT-директоров вывод довольно практичный. GPU в 2026 году все еще дорогой и дефицитный ресурс, а ошибка планировщика быстро превращается в прямые потери: мощная карта простаивает, модель стартует на неподходящем узле, команда держит запас по железу просто из страха. DRA в Kubernetes не создает новые ускорители из воздуха, но помогает уменьшать фрагментацию кластера и снижать число ситуаций, когда дорогая карта достается задаче, которой хватило бы более скромного профиля. При этом магии нет: нужны драйверы, нужна нормальная таксономия DeviceClass, нужно аккуратно развести права на ResourceClaim и админские режимы доступа. Но по меркам Kubernetes это уже хороший признак: вместо шаманства с лейблами появляется внятный контракт между платформой и нагрузкой.
Вопрос уже не в том, заменит ли DRA старый подход, а в том, сколько релизов и сколько вендорской дисциплины понадобится, чтобы ручная охота за GPU стала таким же анахронизмом, как ручная разметка дисков; исходный разбор опубликован в .