Глоссарий

Запрос GPU

capacity request — измеримые величины, которые может запросить claim, в отличие от простого «одно устройство». Модуль публикует две оси: gpu.deckhouse.io/memory (величина вида 1Gi) и sharePercent.

CEL selector — язык выражений, с помощью которого DeviceClass выбирает устройства; вычисляется по атрибутам устройства. Важнее всего одно правило: необязательные атрибуты нужно оборачивать в has(...), поскольку обращение к отсутствующему атрибуту приводит к ошибке всего выражения, а не к значению false.

DeviceClass — именованный набор устройств, из которого claim может выбирать; задаётся CEL-селекторами. Его либо пишут вручную, либо генерирует GPUClass. Документация Kubernetes.

DRA (Dynamic Resource Allocation) — механизм Kubernetes, на котором построен модуль. Рабочие нагрузки запрашивают устройства на уровне пода, описывая свои потребности, вместо того чтобы за них решала конфигурация уровня узла. Документация Kubernetes.

extended resource — короткий путь к GPU: gpu.deckhouse.io/<имя-device-class>. При таком запросе модуль создаёт ResourceClaim за вас, поэтому не нужно писать ни spec.resourceClaims, ни resources.claims. Для эксклюзивных классов запрашивают 1, для классов -percent — от 1 до 100. Не применяется в неймспейсах kube-system и d8-*. Подробнее — в разделе «Использование».

GPUClass — именованный пул объектов PhysicalGPU, задаваемый администратором; контроллер генерирует по одному DeviceClass на каждую разрешённую комбинацию партиции и разделения, каждый со своим именем extended-ресурса. Достоверный список созданного — в .status.deviceClassNames. Подробнее — в разделе «Классы GPU».

opaque config — специфичные для модуля параметры устройства внутри claim, в группе API resource.gpu.deckhouse.io/v1alpha1. Виды opaque config: GpuConfig (целая карта), MigDeviceConfig (MIG-партиция) и VfioDeviceConfig (проброс). Именно так явно запрашивают MPS или VFIO.

ResourceClaim — запрос одного или нескольких устройств, который удовлетворяет планировщик и который подготавливается на узле до запуска пода. Документация Kubernetes.

ResourceClaimTemplate — создаёт отдельный ResourceClaim для каждого пода, который на него ссылается. Обычно ссылаются именно на шаблон, а не на отдельный ResourceClaim. Документация Kubernetes.

Оборудование GPU и разделение

DCGM — демон телеметрии NVIDIA, источник метрик DCGM_FI_*. Зависит от вендора: разворачивается вместе с адаптером NVIDIA, другие вендоры поставляли бы свой экспортер. Подробнее — в разделе «Мониторинг».

MIG

Multi-Instance GPU — аппаратное разделение одной карты NVIDIA на независимые экземпляры, у каждого свои вычислительные ресурсы и память. Изоляцию обеспечивает железо. В этом модуле MIG-партиции эфемерны: создаются при подготовке claim и удаляются при его освобождении, поэтому постоянной раскладки, которой нужно управлять, нет. Подробнее — в разделе «Использование».

Поддерживаемые карты и профили: NVIDIA MIG User Guide.

MPS

Multi-Process Service — механизм NVIDIA для одновременной работы нескольких процессов на одном GPU. На карту приходится один control-демон: он запускается по требованию и переиспользуется всеми нагрузками, разделяющими это устройство. Аппаратной изоляции нет: нагрузки на одной карте влияют друг на друга.

Требуется compute capability 7.0 и выше. MPS существует и на более старых картах, но раздельные адресные пространства клиентов и независимое планирование появились с Volta — именно это делает его пригодным для разделения без изоляции. Подробнее — Multi-Process Service.

NFD/GFD — Node Feature Discovery и GPU Feature Discovery, добавляемые на узлы лейблы с обнаруженными аппаратными возможностями. Только для режима Device Plugin, в DRA-стек они не входят.

NVML — библиотека управления NVIDIA, через которую адаптер вендора NVIDIA читает возможности карты. Если она недоступна, карта не переходит в Ready и ни одно её устройство не публикуется. У других вендоров свои библиотеки: ROCm SMI у AMD, sysfs у Intel.

partition profile — форма MIG-партиции, например 1g.5gb. Существуют два написания, и они не взаимозаменяемы: аппаратное имя с точками (1g.5gb) — используется в CEL-селекторах и возможностях PhysicalGPU; форма DNS-метки (1g5gb) — используется в GPUClass.spec.partitionFilter, поскольку становится частью имени генерируемого объекта.

sharePercent — ось ёмкости для разделяемых устройств, от 1 до 100. Её публикуют только разделяемые варианты, поэтому запроса sharePercent достаточно, чтобы попасть на разделяемое устройство без указания стратегии.

sharingStrategy — атрибут устройства со значением mps или ts. У эксклюзивных устройств он отсутствует, поэтому !has(...sharingStrategy) — это способ сказать в селекторе «дай целиком».

sGPU

Механизм разделения у MetaX: вместо нарезки карты на фиксированные места он раздаёт квоту — долю вычислительных ресурсов в процентах и объём памяти шагом 128 MiB. Он ничего не партиционирует, поэтому является стратегией разделения, а не технологией партиционирования.

SPX, DPX, CPX

Режимы разделения вычислителя у ускорителей AMD Instinct, работающие в паре с режимами разделения памяти NPS. Это аналог MIG у AMD. Подробнее — в документации AMD GPU Partitioning.

slice — единица, из которой собираются MIG-профили. Карта публикует общие счётчики по своим слайсам, и каждое устройство объявляет, какие из них потребляет; поэтому две конфликтующие раскладки не могут быть выделены одновременно. Подробнее — в разделе «Причины конфликта MIG-раскладок».

Time-slicing

Разделение GPU за счёт поочерёдной выдачи карты каждой нагрузке на квант времени, а не разделения оборудования. Особой поддержки со стороны железа не требует и изоляции не даёт. В sharingStrategy обозначается как ts.

Объекты модуля

vendor adapter — DaemonSet под конкретного вендора, превращающий обнаруженную карту в выделяемое устройство. Объединяет общий dra-plugin с контейнером вендора, реализующим контракт Backend, и планируется на узлы с лейблом gpu.deckhouse.io/vendor. Адаптеры поставляются для NVIDIA и MetaX. Подробнее — в разделе «Адаптеры вендоров».

capacity units — лейбл gpu.deckhouse.io/capacity-units на сгенерированном DeviceClass: 1 для эксклюзивных классов, 100 для классов -percent. Подсказывает, какое число указывать в запросе extended-ресурса.

device name — кодирует тип устройства: gpu-<pci> — целая карта, part-gpu-<pci>-p<профиль>-s<начало>-n<размер> — MIG-партиция, а суффикс -mps или -ts обозначает разделяемый вариант. Подробнее — в разделе «Получение информации о выделенном GPU».

driver binding — отражается в PhysicalGPU.status.driverBinding тремя полями: driver (имя драйвера из sysfs, достоверный источник), mode (Compute, Passthrough, Unbound, Unknown) и managementState (Managed, Excluded, Orphaned, Unclaimed, Unknown). Команда d8 k get physicalgpus выводит это в колонке Management, а также в колонках KernelDriver и Mode расширенного вывода -o wide. Подробнее — в Справочнике.

management state — кто управляет устройством и держит ли его кто-нибудь: модуль, оператор, сознательно исключивший устройство, никто, непреднамеренный orphan на passthrough-привязке — либо установленного ответа нет. Только это значение управляет допуском к reclaim, а причину несёт условие Managed. Свободная исправная карта показывает Unclaimed и действий не требует; Unknown — fail-safe для всех случаев без установленного ответа. Бесхозная passthrough-привязка должна продержаться две минуты, прежде чем будет классифицирована как Orphaned; привязка в режиме Compute без claim’а не становится Orphaned никогда, сколько бы ни оставалась свободной. Подробнее — в разделе «Состояние управления устройством».

reclaim — инициированные администратором сброс и повторное обнаружение устройства по аннотации gpu.deckhouse.io/reclaim; ход выполнения отражается в условии Reclaim. Гейтится он раньше всего остального на колонке Management: допуск открывает только карта в состоянии Orphaned, поэтому при любом другом значении запрос отклоняется, и отказ называет именно это значение, а не то, что за ним стоит. Исключение — Unknown с причиной OrphanPending: такой запрос не отклоняется, а удерживается до конца периода ожидания. За этим гейтом контроллер ещё раз проверяет занятость и остаётся fail-closed, поэтому отказ получит и Orphaned-карта, если выделенный ResourceClaim всё-таки нашёлся или занятость установить не удалось.

PhysicalGPU — определяется этим модулем. Один кластерный объект на каждую обнаруженную карту с PCI-идентификацией, условиями готовности и возможностями. Это только инвентарь: spec намеренно пустой. Фазы: Pending, Initializing, Ready, Reconfiguring, Passthrough, Failed и Lost. Подробнее — в Справочнике.

placementID — стабильный идентификатор места устройства: карты или конкретного слота партиции на ней.

ResourceSlice — то, что узел публикует, объявляя устройства, которые действительно может выделить. Создаётся только пока PhysicalGPU находится в Ready, поэтому карта с проблемой драйвера не попадает ни в один slice. Документация Kubernetes.

Узлы и runtime

CDI (Container Device Interface) — стандартный механизм, которым выделенное устройство пробрасывается в контейнер. Его стоит понимать, потому что он объясняет самое неожиданное поведение модуля: устройства попадают в контейнер только через claim, поэтому NVIDIA_VISIBLE_DEVICES не действует, а под без claim не видит ни одного /dev/nvidia*. Такая изоляция сделана намеренно.

feature gate — флаг функциональности Kubernetes. Режиму DRA требуются шесть таких флагов; их включает платформа, а модуль только проверяет их состояние — он никогда не включает их сам и не изменяет аргументы control-plane и kubelet. Подробнее — в разделе «Готовность feature gates для DRA».

finalizer — причина, по которой удаление модуля не мгновенно: gpu-controller должен освободить каждый PhysicalGPU до удаления CRD, поэтому хук pre-delete удаляет их и ждёт.

IOMMU — аппаратный блок изоляции адресов, от которого зависит VFIO-проброс. Должен быть включён и в BIOS, и в командной строке ядра; параметр ядра модуль может добавить сам, но его применение перезагружает узел.

node labels — модуль и выставляет, и читает лейблы, определяющие, где работают компоненты GPU и какие карты находятся под управлением. Полная таблица с указанием, какой компонент что выставляет, — в разделе «Лейблы узла, влияющие на планирование».

NodeGroupConfiguration — механизм Deckhouse, которым модуль подготавливает узлы: проверки драйвера, runtime handler для containerd, параметры ядра и настройка VFIO. Скрипты и порядок их выполнения перечислены в разделе Подготовка узла.

render gate — три внутренних условия, определяющих, что именно разворачивается: dra.enabled, migrationReady и draFeatureGatesReady. Наборы шаблонов у них разные, а не один общий. Первые два включают подготовку узла; дополнительно включённые feature gates нужны рабочему стеку. Необратимые шаги подготовки узла — правка командной строки ядра с перезагрузкой и привязка к vfio-pci — придерживаются отдельно, пока gates подтверждённо отсутствуют и рабочий стек ни разу не разворачивался. Подробнее — в разделе «Условия для включения режима».

RuntimeClass nvidia — поставляется модулем, но используется только DaemonSet’ами DCGM. Обычные DRA-нагрузки работают в стандартном runtime и указывать его не должны.

VFIO / vfio-pci — механизм ядра для передачи «сырого» PCI-устройства потребителю в пространстве пользователя, например виртуальной машине. Карта, привязанная к vfio-pci, не является CUDA-устройством: внутри контейнера нет nvidia-smi, только device-node’ы VFIO. Подробнее — в разделе «VFIO-проброс».