Kubernetes DRA для GPU: ResourceClaim, DeviceClass и безопасный rollout

Почему обычного nvidia.com/gpu становится мало

Классический Device Plugin публикует расширенный ресурс, а Pod просит целое число устройств через limits. Эта модель понятна, поддерживается большинством дистрибутивов и остаётся разумным выбором для однородного пула. Проблема появляется, когда под одним именем ресурса скрываются ускорители с разным объёмом памяти, поколением, NVLink-связностью или режимом разделения.

Представьте inference-кластер из полноразмерных GPU и нескольких MIG-конфигураций. Небольшому embedding-сервису достаточно компактного профиля, а LLM с длинным контекстом нужна карта с большим объёмом памяти. Запрос «один GPU» не выражает эту разницу. Команда компенсирует её node labels, affinity, отдельными resource names и ручными пулами. Через полгода правила образуют вторую, плохо наблюдаемую систему планирования.

DRA переносит описание устройства в стандартные Kubernetes-объекты. Workload создаёт или получает ResourceClaim, запрос ссылается на DeviceClass, а DRA-драйвер публикует доступные устройства через ResourceSlice. Планировщик выбирает устройство вместе с узлом, после чего kubelet и драйвер готовят его для контейнера. Подробная модель зафиксирована в официальной документации Kubernetes DRA.

Это не означает, что DRA автоматически увеличит utilization. Если workload всё равно требует целый GPU, свободная память на занятой карте не превращается в доступный ресурс. DRA даёт более точный контракт и расширяемый lifecycle; фактическое sharing обеспечивают аппаратные разделы, MPS или возможности конкретного драйвера. Для сравнения организационных стратегий полезен разбор GPU scheduling между inference, training и batch-задачами.

Четыре объекта DRA и их жизненный цикл

DeviceClass — кластерный каталог категории устройств. Его обычно создаёт администратор или поставщик драйвера. Класс может содержать selectors и конфигурацию, но приложение не должно угадывать внутренние имена PCIe-устройств. Хорошая граница ответственности выглядит так: платформа публикует понятные классы, команда приложения выбирает требуемый класс и дополнительные свойства.

ResourceClaim похож на PVC не потому, что GPU становится хранилищем, а из-за жизненного цикла. Claim существует в namespace, получает allocation status и может быть явно разделён несколькими Pod, если это поддерживает драйвер. Если claim ещё не создан или не может быть удовлетворён, Pod остаётся Pending. Это полезнее молчаливого запуска на неподходящей карте: ошибка видна до старта модели.

ResourceClaimTemplate подходит Deployment и Job, где каждому Pod нужен отдельный, одинаково описанный ресурс. Kubernetes создаёт claim на Pod и удаляет его вместе с владельцем. Ручной ResourceClaim, напротив, нужен, когда несколько контейнеров должны ссылаться на один ресурс или allocation должен пережить конкретный Pod. Официальная задача Allocate Devices to Workloads with DRA прямо разделяет эти сценарии.

ResourceSlice — взгляд драйвера на inventory. В нём появляются device attributes, capacities и привязка к узлам или topology. Пользователь обычно не создаёт slices вручную, но SRE обязан уметь их читать. Типичный инцидент: GPU виден через nvidia-smi, но драйвер не опубликовал его в ResourceSlice; сколько ни правь selectors у claim, scheduler не найдёт кандидата. Проверяли ли вы совпадение inventory DRA с физическим inventory после перезагрузки драйвера?

Версии Kubernetes и зрелость NVIDIA DRA

Core DRA API стал GA в Kubernetes 1.34 и использует стабильную группу resource.k8s.io/v1. В Kubernetes 1.36 базовая модель остаётся stable и включена по умолчанию, но вокруг неё продолжают появляться beta и alpha-возможности. Поэтому фраза «DRA уже GA» верна только для ядра: она не делает автоматически стабильными consumable capacity, dynamic MIG, device metadata или workload-level claims.

По состоянию на дату подготовки статьи актуальная документация NVIDIA GPU Operator описывает DRA Driver for NVIDIA GPUs v0.5.0 и GPU Operator 26.7. Для полноразмерных GPU и существующих MIG-устройств заявлен GA-уровень поддержки, тогда как DynamicMIG, MPS, ConsumableShares, PassthroughSupport и ряд health-функций остаются alpha и выключены по умолчанию. Всегда сверяйте матрицу в документации NVIDIA DRA Driver: версии драйвера, Kubernetes и runtime рассматриваются одной связкой.

Есть и ограничение с большим влиянием на production: Kubernetes не поддерживает preemption DRA-ресурсов так, как многие ожидают от CPU и memory. Высокоприоритетный Pod не обязательно вытеснит низкоприоритетный workload и немедленно получит его GPU. Если очередь обучения конкурирует с latency-sensitive inference, одной PriorityClass недостаточно; потребуется admission-политика, отдельные пулы или внешний менеджер очередей.

Не смешивайте версии YAML из старых статей. Для Kubernetes 1.32 встречается resource.k8s.io/v1beta1, а актуальные 1.34+ примеры используют v1. Ошибка выглядит как проблема драйвера, хотя API server просто не знает схему. Перед rollout фиксируйте support matrix: Kubernetes minor, container runtime, GPU Operator, host driver и DRA driver.

Когда DRA оправдан, а когда Device Plugin лучше оставить

DRA приносит наибольшую пользу неоднородному пулу, где workload действительно выбирает устройства по свойствам: объёму памяти, профилю, topology или vendor-конфигурации. Второй сильный сценарий — контролируемый жизненный цикл ресурса, который должен быть виден как отдельный объект, проходить allocation и reservation и оставлять понятный audit trail. Третий — multi-node hardware abstractions, например ComputeDomains, когда одного целого числа GPU принципиально недостаточно.

Оставьте Device Plugin, если кластер однороден, приложения просят только целые карты, а операционная команда уже имеет надёжные node pools, квоты и мониторинг. Миграция ради современного API добавит CRD, driver components, claims, finalizers и новую диагностику, но не создаст бизнес-эффект. Это нормально: зрелая инфраструктура не обязана применять каждую новую возможность.

Составьте decision record из пяти вопросов. Нужен ли выбор по device attributes? Требуется ли совместное использование одного claim? Поддерживает ли драйвер нужную функцию на GA или хотя бы beta-уровне? Есть ли CDI и проверенный runtime? Готова ли команда наблюдать claims и ResourceSlices 24/7? Если три ответа отрицательные, DRA пока является исследовательским проектом.

Наконец, оцените стоимость двойного пути на время миграции. Extended resources и DRA могут требовать специального feature gate, а GPU Operator конкретной версии накладывает ограничения на сосуществование control objects. Если rollback означает переустановку всего accelerator stack, выделите отдельный canary-пул. Один изолированный GPU-сервер дешевле простоя inference-кластера и даёт честный ответ, подходит ли новая модель вашему workload.

Аудит кластера до установки драйвера

Начинайте не с Helm upgrade, а с инвентаризации. Нужны версии control plane и kubelet, состояние CDI в containerd или CRI-O, host driver, существующий Device Plugin, MIG Manager, DCGM Exporter и политики NetworkPolicy. Если один GPU-пул обновляется отдельно, запишите labels и taints: именно они станут границей canary.

Минимальный read-only аудит показывает, доступен ли stable DRA API, какие DeviceClass уже существуют и не остались ли claims после предыдущего эксперимента. На реальном инциденте часто полезна последняя команда: claim может быть allocated и reserved, пока связанный Pod уже исчезает.

kubectl version
kubectl api-resources --api-group=resource.k8s.io
kubectl get deviceclasses
kubectl get resourceslices -o wide
kubectl get resourceclaims -A
kubectl get nodes -l nvidia.com/gpu.present=true -L nvidia.com/gpu.product
kubectl get pods -A -o wide | grep -E 'gpu-operator|nvidia|dra'

Сравните число и тип устройств в ResourceSlice с GFD labels и данными nvidia-smi -L на выбранных узлах. Расхождение означает, что rollout ещё не начался: сначала восстановите единый inventory. Для multi-GPU inference дополнительно проверьте NUMA и PCIe topology, иначе корректно выделенный GPU может оказаться медленным из-за удалённой памяти или неудачного пути данных.

Если работает GPU Operator с ClusterPolicy и Device Plugin, заранее изучите ограничение выбранной версии: современный режим DRA через GPUCluster не должен бездумно сосуществовать с прежним control object. Нужен документированный переход и rollback, а не второй набор operands поверх первого. Для общей архитектуры полезен материал про Kubernetes, GPU Operator, KServe и autoscaling.

Установка NVIDIA DRA через изолированный canary-пул

Выберите один или два GPU-узла без критичных workload, пометьте отдельным label и удерживайте обычные приложения taint-ом. Canary должен быть похож на production: та же ОС, kernel, container runtime и поколение GPU. Лабораторный узел с другой картой проверит Helm, но не проверит реальный scheduling contract.

kubectl label node gpu-canary-01 nvidia.com/dra-kubelet-plugin=true
kubectl label node gpu-canary-01 platform.kingservers.example/dra-canary=true
kubectl taint node gpu-canary-01 platform.kingservers.example/dra-canary=true:NoSchedule

kubectl get node gpu-canary-01 --show-labels
kubectl get pods -n gpu-operator -o wide

Конкретные Helm flags берите из документации вашей версии NVIDIA: они менялись между отдельными chart и интеграцией в GPU Operator. Для версии 26.7 документация использует GPUCluster и отдельное управление NVIDIADriver. Не переносите команду из старой статьи, где GPU allocation имела Technology Preview: это другой operational contract.

После установки дождитесь не только Running у operator pods. Проверьте, что DRA kubelet plugin работает именно на canary, DeviceClass опубликован, ResourceSlice содержит ожидаемые устройства, а CDI может инжектировать их в контейнер. Затем запустите короткий CUDA smoke test с toleration и node selector. Если workload стартует только после ручного рестарта containerd, это не PASS, а зависимость для runbook.

Rollback репетируется до первого production workload: удалить тестовые claims и pods, дождаться unprepare, удалить DRA operands в рекомендованном порядке, вернуть Device Plugin и убедиться, что extended resources снова allocatable. NVIDIA предупреждает не использовать Helm uninstall с --no-hooks: можно оставить GPUCluster и ResourceClaim с finalizers.

Практический ResourceClaimTemplate для AI-пода

Начните с простого требования: один GPU из опубликованного класса, без alpha sharing и dynamic reconfiguration. Имя DeviceClass зависит от драйвера; сначала получите его через kubectl get deviceclasses. Каркас показывает форму stable API, но selector attributes сверяются с вашими ResourceSlice — Kubernetes не стандартизирует vendor namespace.

apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: llm-gpu
  namespace: ai-inference
spec:
  spec:
    devices:
      requests:
        - name: accelerator
          exactly:
            deviceClassName: gpu.nvidia.com
            allocationMode: ExactCount
            count: 1
---
apiVersion: v1
kind: Pod
metadata:
  name: llm-smoke
  namespace: ai-inference
spec:
  restartPolicy: Never
  resourceClaims:
    - name: gpu
      resourceClaimTemplateName: llm-gpu
  containers:
    - name: cuda-check
      image: nvidia/cuda:13.0.0-base-ubuntu24.04
      command: ["bash", "-lc", "nvidia-smi -L"]
      resources:
        claims:
          - name: gpu
            request: accelerator

Не копируйте image tag и DeviceClass вслепую: registry policy может требовать digest, а драйвер — другое имя класса. Суть примера в связи трёх мест: request внутри template, ссылка Pod на template и container resources.claims. Если забыть последнее, scheduler способен зарезервировать устройство, но контейнер его не получит.

Для Deployment template создаёт отдельный claim на каждый Pod. Для общего устройства нескольких Pod нужен явный ResourceClaim, однако sharing должен быть сознательным: процессы конкурируют за память, CUDA context и bandwidth. Если цель — multi-tenant разделение, сначала разберите MIG, MPS, квоты и наблюдаемость, затем переносите политику в DRA.

Selectors, topology и sharing: где чаще всего переоценивают DRA

CEL selectors позволяют описать свойства устройства, но каждое условие сужает множество кандидатов. Команда начинает с идеи «нужна карта с достаточной памятью», а заканчивает точным совпадением модели, firmware и topology label. После ремонта один атрибут меняется, и Deployment остаётся Pending. Используйте только требования, без которых workload действительно не работает.

В Kubernetes 1.36 stable prioritized list позволяет задать альтернативы: сначала один большой ускоритель, затем два меньших. Это полезно лишь тогда, когда приложение работает в обоих режимах. Scheduler не перепишет tensor parallelism и параметры inference-сервера. Если запасной вариант требует другой команды запуска, оформите два workload profiles.

Topology остаётся общей задачей scheduler, драйвера и приложения. DRA может предоставить attributes и связать устройство с узлом, однако NVLink, NUMA, NIC locality или ComputeDomain должны поддерживаться конкретным стеком. Неверная локальность заметна не как crash, а как просадка token throughput и tail latency: Kubernetes покажет Running, пользователь увидит медленный сервис.

Consumable capacity развивается в upstream, но в NVIDIA DRA v0.5.0 ConsumableShares отмечен alpha. DynamicMIG и MPSSupport тоже alpha и имеют взаимные ограничения. Не включайте всё «для гибкости». Возьмите один сценарий, сформулируйте isolation и метрики, затем выполните нагрузочный тест. На shared GPU соседний Pod — источник noisy-neighbor с высокой ценой ошибки.

Multi-tenant безопасность и RBAC для ResourceClaim

DRA добавляет объекты, контроллеры и операции обновления status, расширяя поверхность авторизации. Пользователь, который создаёт произвольные ResourceClaim с admin access, потенциально получает доступ к занятому устройству или дополнительным привилегиям драйвера. В multi-tenant кластере это административная операция.

Kubernetes 1.36 использует более гранулярную авторизацию обновлений ResourceClaim status через synthetic subresources и node-aware verbs. Настройку берите из официального DRA Hardening Guide и ограничивайте service accounts scheduler, controllers и driver components. Широкое правило со звёздочками экономит минуты при установке и создаёт годы неясного trust boundary.

Разделите роли. Platform team управляет DeviceClass, driver deployment и feature gates. Namespace owner создаёт claims разрешённых классов. Application service account не нуждается в праве менять claim status. Admission policy может запретить admin access, неизвестные DeviceClass и alpha-конфигурацию вне canary namespaces.

Пример: команда debugging создаёт privileged claim, чтобы проверить нестабильную карту, и забывает удалить его. Обычные Pods ждут, хотя utilization низкий. Audit должен отслеживать возраст claims, finalizers, reservedFor, namespace и владельца. Бесхозный claim похож на выключенный сервер, продолжающий занимать стойку.

Наблюдаемость и диагностика Pending, prepare и unhealthy

Разделяйте путь на четыре этапа: публикация inventory, allocation scheduler-ом, reservation для Pod и prepare устройства на узле. Pending само по себе ничего не говорит. Если нет подходящего ResourceSlice — проблема до scheduler. Если allocation заполнен, но Pod не назначен — смотрите node constraints. Если Pod назначен, а контейнер не стартует — проверяйте kubelet plugin, CDI и runtime.

kubectl describe pod -n ai-inference llm-smoke
kubectl get resourceclaim -n ai-inference -o yaml
kubectl get resourceslices -o yaml
kubectl get events -n ai-inference --sort-by=.lastTimestamp
kubectl logs -n gpu-operator -l app=nvidia-dra-driver-kubelet-plugin --tail=200
kubectl get pod -n ai-inference llm-smoke -o jsonpath='{.status.containerStatuses}'

Собирайте два слоя метрик. DRA отвечает за inventory и lifecycle: доступные и allocated devices, возраст pending claims, ошибки prepare/unprepare, рестарты driver pods. DCGM и host telemetry отвечают за Xid, ECC, temperature, power, throttling и utilization. Running claim не доказывает здоровье GPU, а нулевая загрузка не доказывает, что устройство свободно.

Device health reporting развивается: upstream ResourceHealthStatus в 1.36 имеет beta-статус, а NVIDIA указывает ограничения health-функций DRA driver. Incident response не должен зависеть от единственного поля Pod status. При Xid сопоставляйте UUID устройства, node, claim и Pod; процедура разобрана в статье про диагностику NVIDIA Xid.

Опасны зависшие finalizers после удаления plugin: claim остаётся allocated, а оператор не может выполнить unprepare. Не снимайте finalizer первым движением. Сначала восстановите kubelet plugin и дайте ему завершить lifecycle; ручное удаление допустимо только в recovery, когда workload точно не использует устройство.

План rollout без простоя AI-сервисов

Хороший rollout DRA — миграция контракта, а не обновление daemonset. Сначала зафиксируйте baseline на Device Plugin: время Pending, успешность старта Pod, число allocatable GPU, p95/p99 latency inference и ошибки CUDA. Затем поднимите canary-пул с DRA и повторите workload profiles. Сравнивайте рабочие SLO и поведение при отказе.

Начните со stateless batch или тестовой реплики inference. Не берите первым распределённое обучение на десятках GPU: scheduler, network fabric, storage и collective libraries создадут слишком много переменных. Один Pod, один полный GPU, без alpha gates — информативный шаг. После стабильного create, run, delete и unprepare переходите к Deployment, существующим MIG devices и потом к sharing.

Определите stop conditions заранее: несовпадение inventory, orphan claim, ручной restart runtime, неизвестное device health или рост времени старта возвращает rollout назад. Rollback должен восстановить operator и capacity для nvidia.com/gpu. Проверьте это отдельным Pod после отката.

Для выделенных GPU-серверов удобно держать canary на отдельной группе узлов: меньше blast radius, проще kernel/driver maintenance и понятнее учёт. Но аппаратная изоляция не заменяет Kubernetes-дисциплину. Запишите владельца DeviceClass, совместимые версии, процедуру обновления, dashboard и escalation path.

Production-checklist перед расширением пула

Перед добавлением следующего GPU-узла проведите формальный gate review. Control plane и kubelet должны быть в поддерживаемом диапазоне, CDI включён, host driver совместим с GPU Operator, DRA driver публикует ожидаемую версию, а DeviceClass имеет владельца. Зафиксируйте manifests и chart values в системе изменений; ручной флаг на одном узле не считается конфигурацией кластера.

Проверьте lifecycle минимум десятью последовательными циклами создания и удаления тестового Pod. После каждого цикла ResourceClaim должен переходить в ожидаемые состояния и исчезать без orphan finalizers, а GPU возвращаться в pool. Отдельно перезапустите kubelet plugin во время idle и во время подготовленного тестового устройства. Цель не сломать сервис, а увидеть, как стек восстанавливается.

Добавьте alerts на отсутствие ResourceSlice от GPU-узла, рост pending claims, повторяющиеся prepare/unprepare errors, рестарты DRA operands и claims старше допустимого TTL. Свяжите их с DCGM alerts, но не объединяйте в один безымянный «GPU problem»: allocation failure и Xid требуют разных владельцев и runbook.

Наконец, подтвердите rollback фактом, а не схемой. Верните canary к Device Plugin, запустите workload с обычным nvidia.com/gpu, проверьте CUDA и удалите Pod. Затем снова включите DRA по документированной процедуре. Если этот круг выполняется без ручного удаления finalizers и неизвестных команд, расширяйте пул на небольшую долю capacity. Если нет — canary уже окупился, потому что проблема осталась за границей production.

Вывод: внедряйте DRA как управляемый контракт

Kubernetes DRA даёт AI-платформе выразительный способ просить GPU: DeviceClass описывает класс, ResourceClaim фиксирует запрос и allocation, ResourceSlice публикует inventory, а драйвер готовит устройство. Это шаг вперёд по сравнению с безликим числом GPU в неоднородных кластерах. Но стабильный core API и зрелость vendor-возможностей — разные вещи.

Практический маршрут: проверьте версии и CDI, сравните physical inventory с ResourceSlice, изолируйте canary, запустите один full-GPU workload на stable API, отрепетируйте delete/unprepare и rollback, затем добавьте observability и RBAC. Alpha sharing, DynamicMIG и дополнительные gates оставьте отдельными изменениями с собственными тестами.

Возьмите аудит-команды и прогоните на одном GPU-узле до maintenance window. Если устройства, claims и UUID совпадают, у вас есть отправная точка. Следующий шаг — собрать canary-профиль под вашу модель и проверить жизненный цикл без влияния на production; при необходимости команда King Servers поможет подобрать выделенные GPU-узлы и изолировать тестовый пул.