Релизы

v1.3.3 — 2026-10-14

Кратко: Патч-релиз DRA-режима. Исправлены остановка nvidia-persistenced, зависание карт в passthrough и выделение второй MIG-партиции. Изменились колонки kubectl get и правило подтверждения перезагрузки узла. Перед обновлением выполните шаги из раздела «Что учесть при обновлении».

Ключевые изменения

• DRA-режим: перевод карты в VFIO-passthrough и смена режима MIG сейчас не останавливают nvidia-persistenced.
• DRA-режим: неудачный возврат карты из passthrough повторяется в фоне. Перезагрузка узла нужна, только если карта так и не вернулась.
• DRA-режим: причина состояния PhysicalGPU видна в колонке STATUS. Исправный свободный PhysicalGPU в режиме Compute получает Unclaimed вместо Unknown.
• DRA-режим: перезагрузку узла ради перенастройки карты разрешает только аннотация update.node.deckhouse.io/disruption-approved. Такое подтверждение нужно и для других обновлений Deckhouse с disruption.

Улучшения

• DRA-режим: значение Unclaimed у состояния управления PhysicalGPU
  Значение Unclaimed получает исправный PhysicalGPU в режиме Compute, который не занимает ни один ResourceClaim. Раньше такой PhysicalGPU отмечался как Unknown и выглядел как сбой. Значение Unclaimed не требует действий от администратора.
• DRA-режим: поле PhysicalGPU.status.message
  Поле содержит пояснение к фазе PhysicalGPU, например почему он не готов. Текст может меняться между версиями. Для автоматизации используйте phase, conditions и driverBinding.managementState.
• DRA-режим: новый набор колонок в kubectl get
  По умолчанию PhysicalGPU показывает узел, модель, фазу, состояние управления и причину состояния. GPUClass показывает состояние класса и число PhysicalGPU. Технические атрибуты выводятся с -o wide. Все колонки описаны в справочнике ресурсов.
• DRA-режим: возврат карты из VFIO-passthrough повторяется до запроса перезагрузки узла
  Раньше адаптер запрашивал перезагрузку узла при первой ошибке возврата карты к драйверу nvidia. Это перезапускало все нагрузки узла. Такая ошибка бывает, например, после перезагрузки гостевой ВМ. Сейчас заявка освобождается сразу, а возврат карты повторяется в фоне в течение 5 минут. Ход восстановления виден в условии Reconfiguring и событиях VFIORestore*. Перезагрузка узла остаётся запасным вариантом.
• DRA-режим: зависший gpu-controller перезапускается сам
  Раньше контроллер мог перестать обрабатывать изменения ресурсов, а его Pod продолжал работать. На обработку пропущенного изменения ресурса уходило до 10 часов. Сейчас такой контроллер перезапускается сам, а пропущенное изменение обрабатывается не позже чем через 10 минут. Admission webhooks на время перезапуска остаются доступны. Состояние контроллера видно в метриках gpu_controller_heartbeat_timestamp_seconds и gpu_controller_last_reconcile_timestamp_seconds.
• DRA-режим: метрики и события освобождения карты от nvidia-persistenced
  Результат каждой операции виден в метрике gpu_persistence_release_total{outcome} и в событиях Persistence* у PhysicalGPU. Метрика gpu_persistence_restore_pending показывает число карт, ожидающих восстановления persistence.
• DRA-режим: MIG-vGPU внутри гостевой ВМ
  Раньше в кластере внутри ВМ с MIG-vGPU не запускались Pod’ы с GPU. Попытка адаптера выключить MIG завершалась ошибкой mig instances still present. Сейчас Pod’ы получают MIG-устройство гостевой ВМ, а разметка MIG не меняется.

Исправления

• DRA-режим: nvidia-persistenced сейчас не останавливается при работе с картами
  Раньше при переводе карты в passthrough или смене режима MIG адаптер останавливал nvidia-persistenced. Сервис оставался в состоянии failed, а сокет /run/nvidia-persistenced/socket пропадал. Новые GPU-контейнеры на всём узле не запускались. Сейчас persistence выключается только у нужной карты и после операции включается обратно. Если сервис уже остановлен прежней версией, адаптер запустит его сам. Запуск ждёт, пока все карты узла вернутся из ВМ. Сервис, остановленный или замаскированный вручную, адаптер не трогает.
• DRA-режим: пропавший сокет на узле больше не мешает запуску контейнеров
  Раньше без сокета nvidia-persistenced, nvidia-fabricmanager или MPS на узле GPU-контейнер не запускался с ошибкой no such file or directory. При этом PrepareResources проходил успешно. Сейчас сокет монтируется в контейнер, только если он есть на узле. Изменения монтирования видны в метрике gpu_cdi_ipc_mount_changes_total. Узел, уже попавший в это состояние, восстанавливается после обновления сам.
• DRA-режим: MPS и time-slicing включаются так, как запрошено
  Раньше заявка на долю GPU без явной настройки режима могла получить не тот режим. Это касалось и ResourceClaim, и запроса через extended resource. Целая карта при запросе time-slicing получала MPS. На MIG-партиции при запросе MPS он не включался. Сейчас режим берётся из атрибута gpu.deckhouse.io/sharingStrategy устройства, которое выбрал планировщик.
• DRA-режим: карта больше не застревает в passthrough после удаления ВМ
  Раньше после удаления ВМ карта могла остаться на vfio-pci. Вернуть её удавалось только перезагрузкой узла. Reclaim через аннотацию gpu.deckhouse.io/reclaim тоже отклонялся.
• DRA-режим: вторая MIG-партиция на карте больше не отклоняется
  Раньше после выделения одной партиции карта считалась занятой при свободных слайсах. Следующие заявки висели в Pending с сообщением cannot allocate all claims.
• DRA-режим: отказ в reclaim снимается при смене состояния управления PhysicalGPU
  Раньше отказ Reclaim=Refused оставался у PhysicalGPU и после смены его состояния. Отказ и его снятие видны в событиях ReclaimRefused и ReclaimRefusalCleared.
• DRA-режим: отменённая перезагрузка узла больше не выводит карту из работы
  Аннотацию update.node.deckhouse.io/reboot могут снять до перезагрузки. Раньше карта после этого ждала следующей перезагрузки узла. Сейчас она повторно запрашивает disruption, и создаётся событие NodeRebootWithdrawn.

Что учесть при обновлении

• DRA-режим: из вывода kubectl get удалены и переименованы колонки
  У PhysicalGPU удалена колонка DEVICE. PCI device ID входит в имя объекта. Полный адрес выводится колонкой PCI с -o wide. Колонки VENDOR, MODE и HEALTHY выводятся только с -o wide. У GPUClass колонка READY заменена на STATE. Колонка DEVICES переименована в GPUS. Поля ресурсов не изменились. Скрипты, разбирающие вывод по именам колонок, нужно поправить.
• DRA-режим: перезагрузку узла разрешает только disruption-approved
  Раньше перезагрузку разрешала любая из аннотаций disruption-approved, draining и drained с префиксом update.node.deckhouse.io/. Узел мог перезагрузиться после обычного drain без явного подтверждения. Сейчас нужна аннотация update.node.deckhouse.io/disruption-approved. Такое подтверждение нужно и для других обновлений Deckhouse с disruption. Чтобы отменить перезагрузку, снимите update.node.deckhouse.io/reboot и update.node.deckhouse.io/disruption-approved.
• DRA-режим: перед обновлением проверьте узлы, на которых карты переводились в passthrough
  Шаг 1. Для каждого GPU-узла выполните d8 k -n d8-nvidia-gpu get jobs,pods -l gpu.deckhouse.io/vfio-switch-node=<узел>.
  Шаг 2. Узел нужно перезагрузить, если команда вернула объекты. То же, если карты на узле переводились в passthrough после его последней перезагрузки или это неизвестно. Завершённые Job удаляются через 5 минут, поэтому пустой вывод не гарантирует отсутствия переключений.
  Шаг 3. До обновления переведите такой узел в cordon и уберите с него GPU-нагрузку. После обновления удалите Job переключения этого узла, перезагрузите его и верните в работу. Остальные узлы обновляются как обычно.
• DRA-режим: у свободных PhysicalGPU Unknown меняется на Unclaimed
  Серия gpu_physicalgpu_info{managementState="Unknown"} у свободных PhysicalGPU заменяется на managementState="Unclaimed". На графиках будет однократный разрыв. Поправьте автоматику и фильтры, которые считали Unknown свободным PhysicalGPU.
• DRA-режим: работающие разделяемые карты переходят на новый режим не сразу
  Новая заявка без явной конфигурации использует текущий режим разделения устройства. Так на одной карте не смешиваются MPS и time-slicing. После освобождения устройства всеми заявками режим определяется атрибутом sharingStrategy выбранного устройства.
• DRA-режим: после отката модуля проверьте persistence карт
  Карта могла быть в passthrough или возвращаться из него во время отката. Тогда её persistence останется выключенным. Нагрузки работают, но первая инициализация CUDA занимает больше времени. Проверьте карты командой nvidia-smi --query-gpu=pci.bus_id,persistence_mode --format=csv. Включите persistence командой nvidia-smi -i <pci> -pm 1. После отката перевод карты в passthrough и смена режима MIG останавливают nvidia-persistenced, как в прежней версии. Запустите сервис на узле командой systemctl restart nvidia-persistenced.service.

Известные ограничения

• DRA-режим: MIG-vGPU в гостевой ВМ зависит от определения виртуализации
  Если ВМ ошибочно определена как bare metal, адаптер пытается выключить MIG. Операция завершается ошибкой mig instances still present. Подготовка заявки блокируется, если в гостевой ВМ несколько MIG-устройств или их не удалось определить.
• DRA-режим: alert D8GPUPhysicalGPUOrphaned может прийти позже
  Адаптер может не завершить возврат карты из passthrough. Тогда alert сработает примерно через 30 минут после того, как карта осталась без заявки, а не через 17.

Документация

• Колонки ресурсов описаны в справочнике
  У каждой колонки PhysicalGPU и GPUClass есть описание. Примеры вывода в документации приведены к новому набору колонок. В FAQ разобраны значения состояния управления PhysicalGPU и диагностика отказа в reclaim.

v1.3.2 — 2026-09-23

Кратко: Релиз исправляет запуск воркера node-feature-discovery в стеке device plugin. Режим DRA не затронут.

Ключевые изменения

• Исправлена ошибка CrashLoopBackOff при запуске node-feature-discovery.
• Узлы получают лейблы feature.node.kubernetes.io/pci-*. Без них device plugin и gpu-feature-discovery на узел не планировались.

Исправления

• Воркер node-feature-discovery не запускался
  Контейнер работал от root со снятыми capabilities. Запустить собственный исполняемый файл он при этом не мог. Воркер уходил в CrashLoopBackOff. Узел оставался без лейблов node-feature-discovery. Device plugin и gpu-feature-discovery на такой узел не планировались. Воркер переведён на непривилегированного пользователя модуля.

Что учесть при обновлении

• Воркер собирает только источники local и pci
  Источники cpu, kernel, system и другие отключены. Собственные NodeFeatureRule, опирающиеся на их признаки, на GPU-узлах перестанут срабатывать. Проверьте свои правила перед обновлением. Лейблы feature.node.kubernetes.io/pci-* не изменились.

v1.3.1 — 2026-09-11

Кратко: Релиз закрывает найденные уязвимости. Поведение модуля не меняется.

Ключевые изменения

• Исправлены найденные уязвимости (CVE). Поведение модуля не меняется.

Обновления безопасности

• Исправлены найденные уязвимости (CVE).

v1.3.0 — 2026-09-04

Кратко: Релиз переводит DRA-режим в статус preview и делает его рекомендуемым способом работы с GPU. Добавлена поддержка карт MetaX. Требование модуля к Kubernetes снижено до 1.33. Улучшена работа с настройкой узлов для работы с GPU. Оптимизирована модель безопасности.

Ключевые изменения

• Для DRA-режима модуль не меняет настройки кластера, а только проверяет их состояние. Он сообщает, если нужные feature gates не включены. Для DRA-режима нужен Kubernetes 1.34. На Kubernetes 1.33 модуль тоже ставится и работает в режиме device plugin.
• Проблемы с настройкой GPU больше не блокируют подготовку узла. Узел конвергируется, а неисправность видна в метках узла, метрике и alert. Модуль не делает необратимых изменений на узлах, где DRA работать не сможет.
• Переработан механизм изоляции разделяемых GPU между namespace. Части разделяемой карты могут использовать только нагрузки внутри одного namespace. Конфликт отклоняется до размещения Pod’а, и планировщик берёт другое устройство. Раньше конфликт появлялся после размещения, и Pod оставался в ContainerCreating.
• Поддержаны GPU MetaX. Их можно использовать через DRA наравне с NVIDIA. Модуль устанавливает адаптер только на узлы с такими картами.
• Работать с GPU можно без прав SuperAdmin. Доступ выдаётся штатными ролями DKP, без ручных ClusterRole.

Новый функционал

• Обнаружение неисправного хост-стека GPU на узле в DRA-режиме
  Проверяются загрузка модуля ядра, соответствие версий модуля ядра и драйвера, работоспособность контейнерного toolkit. Результат публикуется в метках узла node.deckhouse.io/gpu-host-stack-error и node.deckhouse.io/gpu-host-stack-vendor. Он же виден в метрике gpu_node_host_stack_unhealthy{node,vendor,reason} и в alert D8GpuNodeHostStackUnhealthy.
• Доступ к GPU выдаётся штатными ролями DKP
  Раньше ресурсы модуля не входили ни в одну роль платформы. Ниже уровня SuperAdmin пользователь не мог даже посмотреть список классов GPU. Разработчик со своей ролью в namespace создаёт ResourceClaim и ResourceClaimTemplate. Роль уровня просмотра читает ресурсы модуля и объекты DRA, включая ResourceSlice. Администратор управляет GPUClass и DeviceClass, а также обслуживает карты аннотациями gpu.deckhouse.io/reclaim и gpu.deckhouse.io/unmanaged. Роли поставляются для обеих ролевых моделей DKP. Для текущей модели это шесть кумулятивных ClusterRole d8:user-authz:gpu:<level>. Для экспериментальной — роли администратора инфраструктуры и роли пользователя namespace. Отдельно поставляются d8:gpu:viewer и d8:gpu:deviceclass-editor. Их выдают через ClusterRoleBinding. Они дают доступ к кластерным объектам GPU, который роль пользователя namespace дать не может.
• Адаптер MetaX в составе DRA-стека
  Добавлена возможность использовать GPU MetaX для рабочих нагрузок. Поддерживаются вендорные правила валидации запросов.
• Пространство имён модуля GPU подготовлено к политике Pod Security Standards restricted
  Каждый компонент, которому необходимо исключение, получил отдельный SecurityPolicyException. Общее ослабление требований к политике безопасности на всё пространство больше не требуется.

Улучшения

• Проверка готовности DRA feature gates перед развёртыванием
  При dra.enabled=true стек разворачивается только со всеми требуемыми gates. Готовность определяется по рантайм-состоянию kube-apiserver, а не по версии Kubernetes. При нехватке gates выставляются condition FeatureGatesReady, метрика gpu_dra_feature_gate_missing и alert. Проверка ограничивает только первое развёртывание стека. Уже развёрнутый стек не удаляется, а транзиентная недоступность gates не останавливает нагрузки. Так бывает при rolling-upgrade control-plane или чтении с другой реплики apiserver. В этом случае выставляется только alert.
• Однозначное состояние карты в режиме VFIO-passthrough
  Карта, отданная виртуальной машине, больше не остаётся в фазе Initializing. В PhysicalGPU.status появилось поле driverBinding, а сама карта переходит в фазу Passthrough. Карту на vfio-pci без заявки модуль помечает как Orphaned и поднимает alert D8GPUPhysicalGPUOrphaned. Вернуть карту вычислительному драйверу или скрыть её от модуля можно аннотациями gpu.deckhouse.io/reclaim и gpu.deckhouse.io/unmanaged.
• Необратимая часть подготовки узла ограничена
  Это правка параметров загрузки ядра для IOMMU и привязка карты к vfio-pci. При первом включении с подтверждённо отключёнными gates они не применяются. Параметры загрузки ядра меняются только на узле с GPU поддерживаемого вендора. Раньше параметры правились и перезагрузка запрашивалась на каждом bare-metal узле группы, даже без GPU. Обратимые шаги применяются без изменений: containerd, sysctl, метки.
• Проверки узла разделены по вендорам GPU
  Выполняются только проверки вендоров, найденных на PCI-шине. Список поддерживаемых вендоров стал единым источником данных для ConfigMap gpu-supported-vendors и скрипта проверки узла.

Исправления

• DRA-режим: удалён mutating webhook resourceclaimnamespace.gpu.deckhouse.io
  Он дописывал CEL-селектор в spec объектов ResourceClaim и ResourceClaimTemplate. Этот spec иммутабелен. Отрендеренный манифест мог разойтись с сохранённым объектом. Повторное применение отвергалось с ошибкой spec: field is immutable. Это касалось Helm-релиза, GitOps-контроллера и module applier.
• DRA-режим: устранена проблема с параметром settings.dra.allowCrossNamespaceSharing
  Параметр не влиял на поведение размещения. Значение доставлялось только в gpu-controller и влияло лишь на регистрацию вебхука. Компонент, применяющий политику, его не получал. Шаблоны DaemonSet читали настройку не по документированному пути. На узел передавалось значение по умолчанию.
• Требование модуля к Kubernetes снижено с 1.34 до 1.33
  Порог 1.34 относится к DRA-режиму. В режиме device plugin модуль ставится на кластер 1.33.
• Проверка GPU-узла больше не прерывает настройку узла
  Шаг выполняется рано, до настройки kubelet. При отсутствии драйвера или контейнерного toolkit он завершался с ошибкой, и bashible прекращал настройку узла целиком. Шаг всегда завершается успешно, а результат виден в метках узла.
• Устранено ложное срабатывание alert D8GPUControlPlaneControllerTargetAbsent
  Правила и дашборды DRA-стека не применяются на кластерах с device plugin. Раньше alert срабатывал там, где DRA-контроллера и не должно быть, а дашборды дублировались.
• Исправлены права компонентов DRA-стека
  Контроллер получил доступ к тому API событий, в который пишет. Доступ к ConfigMap сужен до нужных объектов.

Обновления безопасности

• Исправлены найденные уязвимости (CVE). Обновлены компоненты модуля и образы обоих стеков.

Несовместимые изменения

• Модуль больше не включает DRA feature gates
  Hook и NodeGroupConfiguration, выполнявшие это, удалены. Без требуемых gates при dra.enabled=true DRA-стек не развернётся. Модуль сообщит о нехватке через condition, метрику и alert.

Что учесть при обновлении

• Перед обновлением с dra.enabled=true проверьте требуемые DRA feature gates
  Без них DRA-стек после обновления не развернётся. Список gates и порог Kubernetes 1.34 приведены в разделе «Предварительные требования для DRA-режима». Уже развёрнутый стек обновление не удаляет.
• Изоляция разделяемых GPU проверяется на узле, а не в admission
  Отказ приходит до размещения Pod’а. Он виден как condition BindingFailed=True с reason NamespaceConflict в ResourceClaim.status.devices. Планировщик выбирает другое устройство. Раньше конфликт появлялся на NodePrepareResources, уже после размещения. Выглядело это как длительное состояние ContainerCreating. Ограничение действует на уровне placement. Разные MIG-партиции одной карты остаются доступны разным namespace. Диагностику ищите в ResourceClaim.status.devices, а не в логах admission.
• Ранее созданные ResourceClaimTemplate с дописанным селектором нужно пересоздать
  Удаление вебхука их не исправляет, их spec иммутабелен. Пересоздайте такие объекты их владельцем. Для Helm-релиза: удалите объект и выполните helm upgrade. Иначе состояние ManifestsApplyFailed сохранится.
• На узлах с неисправным хост-стеком GPU появятся alerts D8GpuNodeHostStackUnhealthy
  Так бывает при несовпадении версий nvidia-container*. Так бывает и при модуле DKMS, не собранном под текущее ядро. Это обнаружение уже существующих неисправностей. Конвергенция таких узлов не блокируется. С них снимается признак готовности node.deckhouse.io/gpu-setup-complete. Компоненты GPU-стека на такие узлы не размещаются.
• Перед выключением модуля верните карты из VFIO-passthrough вычислительному драйверу
  Используйте аннотацию gpu.deckhouse.io/reclaim. Выключение модуля не снимает привязку драйвера. Карта на vfio-pci останется на нём и после удаления модуля. Для возврата потребуется перезагрузка узла.

Известные ограничения

• MetaX: только карта целиком
  Адаптер MetaX поддерживает выделение карты целиком. Разделение на партиции и совместное использование доступны для NVIDIA. Заявка с долей карты MetaX отклоняется на этапе подготовки.
• Состояние хост-стека GPU не пересчитывается непрерывно
  Проверка выполняется при bootstrap узла, смене конфигурации и перезагрузке. Неисправность, возникшая между этими моментами, попадёт в метки и alert только на следующем прогоне.

Документация

• Документация модуля переработана
  Обзор, настройки, архитектура, FAQ, использование и глоссарий согласованы между собой. Режимы DRA и device plugin описаны как взаимоисключающие. DRA описан как рекомендуемый режим. Он в статусе Preview и включается явно. Без дополнительной настройки работает режим device plugin. Добавлены страницы: глоссарий, описание GPUClass, набор манифестов, обучающий сценарий и раздел об использовании. Страница с примерами удалена, её содержание перенесено в новые разделы. В разделе «Предварительные требования для DRA-режима» описаны оба порога Kubernetes и шесть требуемых feature gates. В FAQ добавлена диагностика ситуации «GPU-нагрузки не работают при установленных драйвере и toolkit».
• Справочник ресурсов приведён в соответствие со схемой
  Добавлено русское описание GPUClass. Описание PhysicalGPU обновлено по текущей схеме.

Зависимости

• Требования к платформе: Deckhouse >= 1.75, Kubernetes >= 1.33. Прежний порог Kubernetes — 1.34. DRA-режим по-прежнему требует Kubernetes >= 1.34. Это проверяется в рантайме.

v1.2.8 — 2026-08-31

Кратко: Сервисный релиз линии 1.2.x с обновлениями метаданных безопасности и зависимостей. Поведение развёрнутого GPU-стека не меняется.

Ключевые изменения

• Отчётность по безопасности образов модуля стала точнее: образы могут поставлять VEX-метаданные для уязвимостей, которые заведомо не затрагивают поставляемые бинарные файлы.

Обновления безопасности

• Исправлены найденные уязвимости (CVE).
• Добавлены VEX-метаданные для уязвимостей, недостижимых в поставляемых бинарных файлах модуля, чтобы уменьшить ложные срабатывания проверок уязвимостей для затронутых образов.

v1.2.7 — 2026-08-31

Кратко: Исправлено объявление корневого типа в OpenAPI-схеме конфигурации модуля. Deckhouse валидирует значения модуля gpu по схеме.

Ключевые изменения

• Валидация значений конфигурации модуля gpu работает корректно. Корень OpenAPI-схемы объявлен как объект. Этого требует Deckhouse.

Исправления

• Исправлено объявление корневого типа в OpenAPI-схеме конфигурации модуля. Корень объявлен как объект. Deckhouse проверяет значения модуля gpu по схеме. Раньше он считал корень схемы неизвестным полем.

v1.2.6 — 2026-08-30

Кратко: Технический релиз линии 1.2.x. Обновление меняет только механику сборки образов и не влияет на поведение развёрнутого GPU-стека.

Ключевые изменения

• Технический релиз: разворачиваемые манифесты, набор образов и версии компонентов не меняются, поэтому действий от оператора не требуется.

v1.2.5 — 2026-08-29

Кратко: Сервисный релиз линии 1.2.x с обновлениями безопасности. Поведение GPU-нагрузок не меняется, действий от оператора не требуется.

Ключевые изменения

• Исправлены найденные уязвимости в образах модуля без изменения разворачиваемых GPU-стеков и их конфигурационного контракта.

Обновления безопасности

• Исправлены найденные уязвимости (CVE).

v1.2.4 — 2026-07-17

Кратко: Технический релиз линии 1.2.x.

Ключевые изменения

• Технический релиз: изменений, влияющих на эксплуатацию, нет. Обновление безопасно и не требует действий.

v1.2.3 — 2026-07-17

Кратко: Обновление безопасности линии 1.2.x.

Ключевые изменения

• Устранены найденные уязвимости в поставляемых образах.

Обновления безопасности

• Исправлены найденные уязвимости (CVE).

v1.2.2 — 2026-07-17

Кратко: Технический релиз линии 1.2.x.

Ключевые изменения

• Технический релиз: изменений, влияющих на эксплуатацию, нет. Обновление безопасно и не требует действий.

v1.2.1 — 2026-07-15

Кратко: Исправления VFIO-passthrough, работы с GPUClass и метрики утилизации GPU.

Ключевые изменения

• VFIO-passthrough работает корректно: устройство привязывается к нагрузке.
• Метрика утилизации GPU публикуется — панели мониторинга показывают нагрузку на карты.

Исправления

• Исправлена привязка устройств для VFIO-passthrough.
• Исправлена работа с ресурсом GPUClass.
• Исправлена метрика утилизации GPU.

v1.2.0 — 2026-07-01

Кратко: Появился ресурс GPUClass — декларативное описание классов GPU для DRA-стека.

Ключевые изменения

• Добавлен ресурс GPUClass (gpuclasses.gpu.deckhouse.io): классы GPU описываются декларативно, и нагрузка запрашивает класс, а не конкретную карту.
• Выбор устройства для DRA-заявки стал предсказуемым: неполные варианты размещения больше не участвуют в выборе.

Новый функционал

• Ресурс GPUClass (gpuclasses.gpu.deckhouse.io). Это декларативное описание классов GPU для DRA-стека.

Исправления

• Устранены конфликты размещения DRA-заявок: синтетические (неполные) варианты размещения больше не учитываются при выборе устройства.
• Исправлено проставление владельца (ownership) для ресурсов PhysicalGPU. Объекты больше не остаются бесхозными.

v1.1.2 — 2026-06-11

Кратко: Изоляция DRA-нагрузок от невыделенных устройств узла и исправление имён дашбордов.

Ключевые изменения

• Запрошенные через DRA GPU больше не пересекаются с невыделенными устройствами узла. Нагрузка не может задеть карту, которая ей не выдана.

Исправления

• Изоляция DRA-нагрузок: запрошенные через DRA GPU больше не пересекаются с невыделенными устройствами на узле.
• Исправлены имена дашбордов мониторинга — дашборды находятся в Grafana под ожидаемыми названиями.

v1.1.1 — 2026-06-10

Кратко: Совместное использование GPU в DRA-режиме (MPS и Time-Slicing), автоматическая переконфигурация MIG с перезагрузкой узла и поддержка VFIO-passthrough.

Ключевые изменения

• В DRA-режиме появилось совместное использование GPU: режимы MPS и Time-Slicing включаются частичным запросом ресурса, без ручной настройки узла.
• Переконфигурация MIG с перезагрузкой узла выполняется автоматически и согласованно. Оператору не нужно вручную вытеснять нагрузки и останавливать обращения к драйверу.
• Поддержан VFIO-passthrough: GPU можно целиком передать виртуальной машине.
• Нагрузка больше не видит внутри контейнера чужие GPU узла. Исправление важно для узлов с несколькими картами.

Новый функционал

• Совместное использование GPU для DRA-нагрузок в режимах MPS и Time-Slicing. Частичный запрос ресурса (sharePercent) автоматически включает совместное использование физической карты.
• Автоматическая оркестрация переконфигурации MIG с перезагрузкой узла. Узел согласованно выводится из-под нагрузки. Обращения к GPU-драйверу и DCGM ставятся на паузу на время repartition. Вмешательство оператора не требуется.
• Поддержка VFIO-passthrough для GPU.

Исправления

• Видимость GPU внутри контейнера ограничена только выделенными устройствами. Это актуально на узлах с несколькими GPU. Раньше нагрузка видела там все карты.
• Для каждого выделения возвращаются корректные идентификаторы CDI. Это важно для нагрузок с несколькими устройствами и для сценариев sharing и partitioning.
• Восстановление подготовки устройств после сбоев. «Зависшие» завершённые заявки очищаются, ошибки привязки типизированы. Повтор выполняется корректно.
• Добавлены метрики, которых не было на дашборде GPU.

Документация

• Добавлены базовые сценарии использования GPU — от эксклюзивного выделения до совместного использования и MIG.

v1.1.0 — 2026-05-22

Кратко: Добавлен DRA-стек (Dynamic Resource Allocation) как альтернатива стеку device plugin. Минимальная версия Kubernetes для модуля поднята до 1.34.

Ключевые изменения

• Появился DRA-стек (Dynamic Resource Allocation). Он включается опцией dra.enabled=true. GPU выделяются через ResourceClaim, а не через расширенные ресурсы узла.
• Поведение по умолчанию не меняется. При dra.enabled=false разворачивается стек device plugin, как в 1.0.x.
• Минимальная версия Kubernetes для модуля поднята с 1.32 до 1.34. На более старых кластерах модуль установить или обновить нельзя.

Новый функционал

• DRA-режим включается опцией dra.enabled=true. Вместо стека на базе NVIDIA GPU Operator модуль разворачивает компоненты gpu-controller, gpu-node-agent, dra-plugin и nvidia-adapter. GPU узлов описываются ресурсом PhysicalGPU.

Исправления

• Улучшена логика конфигурации MIG (mig-parted), добавлена поддержка ОС со старой версией glibc.
• Исправлен интервал повторных попыток при настройке MIG. При временной неготовности карты настройка больше не забрасывается.
• Откачена конфигурация automount, приводившая к избыточным правам у подов стека.

Обновления безопасности

• Исправлены найденные уязвимости (CVE).

Несовместимые изменения

• Минимальная версия Kubernetes для модуля — 1.34, была 1.32. На кластерах 1.32 и 1.33 установка и обновление модуля будут отклонены проверкой требований.

Что учесть при обновлении

• Перед обновлением убедитесь, что кластер на Kubernetes 1.34 или новее. Если кластер старее, оставайтесь на линии 1.0.x. Она продолжает получать исправления и обновления безопасности.
• Включайте DRA-режим осознанно. Делайте это на новых установках или после проверки на тестовом кластере. Опция dra.enabled=true заменяет весь GPU-стек узла, а не дополняет его.

Зависимости

• Требования к платформе: Deckhouse >= 1.75, Kubernetes >= 1.34 (было >= 1.32).

v1.0.4 — 2026-06-10

Кратко: Технический релиз линии сопровождения 1.0.x.

Ключевые изменения

• Технический релиз: изменений, влияющих на эксплуатацию, нет. Обновление безопасно и не требует действий.

v1.0.3 — 2026-06-02

Кратко: Обновление безопасности линии сопровождения 1.0.x.

Ключевые изменения

• Устранены найденные уязвимости в поставляемых образах.

Обновления безопасности

• Исправлены найденные уязвимости (CVE).

v1.0.2 — 2026-05-14

Кратко: Исправления конфигурации MIG, в том числе на ОС со старой версией glibc, и устранение найденных уязвимостей.

Ключевые изменения

• Конфигурация MIG применяется корректно на ОС со старой версией glibc. Раньше на таких узлах разбиение карты не доводилось до конца.
• Устранены найденные уязвимости в поставляемых образах.

Исправления

• Улучшена логика конфигурации MIG (mig-parted), добавлена поддержка ОС со старой версией glibc.
• Исправлен скрипт nvidia-mig-manager. Из-за него разбиение карты могло не применяться.

Обновления безопасности

• Исправлены найденные уязвимости (CVE).

v1.0.1 — 2026-04-17

Кратко: Технический релиз линии сопровождения 1.0.x.

Ключевые изменения

• Технический релиз: изменений, влияющих на эксплуатацию, нет. Обновление безопасно и не требует действий.

v1.0.0 — 2026-04-01

Кратко: Первый релиз модуля gpu: запуск и эксплуатация нагрузок на NVIDIA GPU в Deckhouse Kubernetes Platform на стеке device plugin.

Ключевые изменения

• Модуль gpu доступен для эксплуатации. GPU-узлы включаются секцией spec.gpu в целевом NodeGroup. После этого модуль разворачивает на них стек device plugin на базе NVIDIA GPU Operator.
• Поддержаны три режима выделения GPU: эксклюзивный, Time-Slicing и MIG (Multi-Instance GPU).
• Мониторинг GPU через DCGM с готовыми дашбордами Grafana работает из коробки.

Новый функционал

• Поддержка MIG (Multi-Instance GPU): физическая карта делится на изолированные партиции, каждая выдаётся нагрузке как отдельное устройство.
• Мониторинг GPU через DCGM и DCGM-exporter: метрики утилизации, температуры и памяти доступны в Prometheus и на дашбордах Grafana.
• Автоматическое обнаружение узлов с GPU через Node Feature Discovery — вручную размечать узлы не требуется.

Зависимости

• Требования к платформе: Deckhouse >= 1.75, Kubernetes >= 1.32.
• Компоненты стека device plugin в поставке. NVIDIA device plugin 0.17.4, Node Feature Discovery 0.17.3, NVIDIA Container Toolkit 1.18.2. DCGM 4.2.3, DCGM-exporter 4.2.3, nvidia-mig-manager 0.12.3.