Модуль gpu

Модуль gpu добавляет в Deckhouse Kubernetes Platform функции управления GPU и работы с ними: подготовка узлов, обнаружение оборудования, предоставление GPU планировщику и поставка данных для мониторинга.

В основе модуля — независимое от вендора ядро и адаптеры под конкретных вендоров. Обнаружение, планирование и инвентарь PhysicalGPU работают одинаково для GPU любой марки. Для обращения к оборудованию вендора используется контракт, который реализует адаптер вендора. Адаптеры поставляются для NVIDIA и MetaX.

Модуль работает в двух взаимоисключающих режимах. Рекомендуемый — режим DRA: рабочие нагрузки запрашивают GPU через механизм Kubernetes Dynamic Resource Allocation (DRA), и под указывает, что ему действительно нужно — целую карту, MIG-партицию или процент разделяемого GPU, — и получает именно это. Режим находится в статусе Preview и включается явно. Без дополнительной настройки работает режим Device Plugin: способ разделения GPU задаётся на уровне группы узлов, а под запрашивает nvidia.com/gpu: 1.

Возможности модуля

• Выдача целых GPU — по одному на под.
• Партиционирование GPU через MIG на A100 и H100. Партиции создаются по требованию из запроса рабочей нагрузки. Выполнять nvidia-smi -mig вручную не нужно.
• Разделение одного GPU между нагрузками через MPS или time-slicing, с точностью до запрошенного процента.
• Проброс GPU напрямую в виртуальную машину через VFIO — для QEMU/KVM и аналогичных потребителей.
• Публикация пулов GPU по имени. Администратор описывает GPUClass, после чего пользователи запрашивают gpu.deckhouse.io/<класс> одной строкой, а модуль сам создаёт заявку (claim).
• Наблюдение за оборудованием — метрики DCGM с готовыми дашбордами Grafana, а также инвентарь GPU и представления по выделениям для каждой нагрузки.
• Автоматическая подготовка узлов. containerd, GPU runtime, параметры ядра и настройка VFIO/IOMMU выполняются через NodeGroupConfiguration. Ручная донастройка узлов не требуется.
• Добавление вендора GPU без изменения ядра. Новый вендор — это контейнер, реализующий контракт адаптера, плюс PCI vendor ID в ConfigMap. Изменения ядра и кастомных ресурсов при добавлении нового вендора не требуются.

Требования к кластеру для использования модуля

Для использования модуля в кластере DKP он должен соответствовать следующим требованиям:

• Deckhouse Kubernetes Platform 1.75 или новее, редакция EE.
• Kubernetes 1.33 или новее — для режима Device Plugin, включённого по умолчанию.
• Kubernetes 1.34 или новее — для DRA-режима: трёх из шести необходимых модулю feature gates в 1.33 не существует. Подробнее — в разделе «Готовность feature gates для DRA».
• Вендор GPU, для которого поставляется адаптер, — NVIDIA или MetaX. Подробнее — в разделе «Адаптеры вендоров».
• Установленный на GPU-узлах драйвер вендора — для NVIDIA это драйвер и NVIDIA Container Toolkit. containerd модуль настраивает сам, но драйвер не устанавливает. Подробнее — в разделе «Как установить драйвер NVIDIA на GPU-узлы?».
• Включённые платформой feature gates для DRA. Модуль проверяет это и без них не разворачивает DRA-стек; аргументы control-plane и kubelet он не изменяет. Подробнее — в разделе «Готовность feature gates для DRA».

Компоненты модуля

Модуль создает в неймспейсе d8-nvidia-gpu ряд компонентов. Перечни компонентов для поддерживаемых режимов представлены в разделе «Архитектура»:

• компоненты модуля в режиме DRA,
• компоненты модуля в режиме Device Plugin.

Режимы работы модуля

Модуль может работать в одном из следующих режимов:

• DRA;
• Device Plugin.

Режимы DRA и Device Plugin взаимоисключающие и различаются тем, где принимается решение: Device Plugin закрепляет способ разделения за группой узлов, а DRA позволяет каждой нагрузке указать, что ей нужно. Переключение между ними не требует ручной очистки — модуль удаляет один стек и разворачивает другой в том же неймспейсе. Подробнее — в разделе «Как мигрировать с режима Device Plugin на DRA».

Подробнее о режимах — в разделе «Архитектура».

Предварительные требования для DRA-режима

Модуль никогда не включает feature gates самостоятельно и не изменяет аргументы control-plane и kubelet.