Release notes

v1.3.0 — 2026-09-04

Summary: The release moves DRA mode to preview status and makes it the recommended way to work with GPUs. Support for MetaX cards is added. The module’s Kubernetes requirement is lowered to 1.33. Node setup for GPU work is improved. The security model is streamlined. For DRA mode the module does not change cluster settings, it only checks their state. GPU configuration problems no longer block node preparation. The module makes no irreversible changes on nodes where DRA will not be able to work. The isolation of shared GPUs between namespaces is reworked. Working with GPUs no longer requires SuperAdmin.

Highlights

• For DRA mode the module does not change cluster settings, it only checks their state. It reports when the required feature gates are not enabled. DRA mode needs Kubernetes 1.34. On Kubernetes 1.33 the module installs as well and runs in device plugin mode.
• GPU configuration problems no longer block node preparation. The node converges, and the fault is visible in node labels, a metric and an alert. The module makes no irreversible changes on nodes where DRA will not be able to work.
• The isolation of shared GPUs between namespaces is reworked. Parts of a shared card can be used only by workloads from one namespace. A conflict is rejected before the Pod is placed, and the scheduler takes another device. Previously the conflict appeared after placement and the Pod stayed in ContainerCreating.
• MetaX GPUs are supported. They can be used through DRA alongside NVIDIA ones. The module deploys the adapter only on nodes with such cards.
• Working with GPUs no longer requires SuperAdmin. Access is granted with the standard DKP roles, without hand-written ClusterRoles.

New features

• A readiness check of DRA feature gates before deployment
  With dra.enabled=true the stack is deployed only with every required gate enabled. Readiness is derived from the runtime state of kube-apiserver, not from the Kubernetes version. When gates are missing, the module raises the FeatureGatesReady condition, the gpu_dra_feature_gate_missing metric and an alert.
• Detection of a broken GPU host stack on a node in DRA mode
  The check covers the kernel module load and the version match between kernel module and driver. It also covers the health of the container toolkit. The result is published in the node.deckhouse.io/gpu-host-stack-error and node.deckhouse.io/gpu-host-stack-vendor node labels. It also appears in the gpu_node_host_stack_unhealthy{node,vendor,reason} metric and the D8GpuNodeHostStackUnhealthy alert.
• GPU access is granted with the standard DKP roles
  Module resources previously belonged to no platform role. Below SuperAdmin a user could not even list the GPU classes. A developer with a namespace role creates ResourceClaim and ResourceClaimTemplate. A view-level role reads module resources and DRA objects, including ResourceSlice. An administrator manages GPUClass and DeviceClass, and services cards through the gpu.deckhouse.io/reclaim and gpu.deckhouse.io/unmanaged annotations. Roles ship for both DKP role models. The current model gets six cumulative d8:user-authz:gpu:<level> ClusterRoles. The experimental one gets infrastructure administrator roles and namespace user roles. Two more roles ship separately: d8:gpu:viewer and d8:gpu:deviceclass-editor. An administrator grants them with a ClusterRoleBinding. They give access to cluster-scoped GPU objects, which a namespace user role cannot grant.
• An unambiguous state for a card in VFIO passthrough
  A card handed to a virtual machine no longer stays in the Initializing phase. The driverBinding field is added to PhysicalGPU.status, and the card itself moves to the Passthrough phase. A card on vfio-pci without a claim is marked Orphaned and raises the D8GPUPhysicalGPUOrphaned alert. The gpu.deckhouse.io/reclaim and gpu.deckhouse.io/unmanaged annotations return a card to its compute driver or hide it from the module.
• The MetaX adapter as part of the DRA stack
  Support for using MetaX GPUs in workloads is added. Vendor-specific request validation rules are supported.
• The GPU module namespace is prepared for the restricted Pod Security Standards policy
  Every component that needs an exception got its own SecurityPolicyException. A blanket relaxation of the security policy for the whole namespace is no longer needed.

Improvements

• The irreversible part of node preparation is confined
  It is the kernel command line for IOMMU and the vfio-pci bind. On a first enablement with gates confirmed disabled they are not applied. The kernel command line is edited only on a node with a GPU of a supported vendor. Previously the parameters were edited and a reboot was requested on every bare-metal node of the group, GPU or not. The reversible steps are applied unchanged: containerd, sysctl, labels.
• Node checks are split per GPU vendor
  Only the checks of the vendors found on the PCI bus are run. The list of supported vendors is the single data source for the gpu-supported-vendors ConfigMap and for the node check script.
• DRA feature gate readiness works as a monotonic latch
  It constrains only the first rollout of the stack. A stack that is already deployed is not removed. Transient gate unavailability does not stop running workloads. It happens during a control-plane rolling upgrade or a read from another apiserver replica. Only an alert is raised.

Fixes

• DRA mode: the resourceclaimnamespace.gpu.deckhouse.io mutating webhook is removed
  It appended a CEL selector to the spec of ResourceClaim and ResourceClaimTemplate objects. That spec is immutable. The rendered manifest could diverge from the stored object. Re-applying it was rejected with spec: field is immutable. This affected a Helm release, a GitOps controller and the module applier.
• DRA mode: fixed the settings.dra.allowCrossNamespaceSharing parameter
  The parameter had no effect on placement. The value was delivered only to gpu-controller. There it affected nothing but the registration of that webhook. The component that enforces the policy never received it. The DaemonSet templates read the setting from an undocumented path. The node always got the default value.
• The module’s Kubernetes requirement is lowered from 1.34 to 1.33
  The 1.34 floor belongs to DRA mode. In device plugin mode the module installs on a 1.33 cluster.
• The GPU node check no longer aborts node configuration
  The step runs early, before kubelet is configured. With the driver or the container toolkit missing it exited non-zero, and bashible stopped configuring the node altogether. The step now always exits successfully, and the result is visible in the node labels.
• Fixed a false D8GPUControlPlaneControllerTargetAbsent alert
  The DRA stack rules and dashboards are not applied on device plugin clusters. Previously the alert fired where no DRA controller was meant to run, and dashboards were duplicated.
• Fixed the permissions of DRA stack components
  The controller got access to the events API it writes to. ConfigMap access is narrowed to the required objects.

Security updates

• Fixed known vulnerabilities (CVE). The module components and the images of both stacks are updated.

Breaking changes

• The module no longer enables DRA feature gates
  The hook and the NodeGroupConfiguration that did so are removed. Without the required gates the DRA stack is not deployed with dra.enabled=true. The module reports what is missing through a condition, a metric and an alert.

Upgrade notes

• Before updating with dra.enabled=true, check the required DRA feature gates
  Without them the DRA stack is not deployed after the update. The list of gates and the Kubernetes 1.34 floor are in the “Prerequisites for DRA mode” section. An already deployed stack is not removed by the update.
• The isolation of shared GPUs is checked on the node, not in admission
  The rejection arrives before the Pod is placed. It appears as the BindingFailed=True condition with the NamespaceConflict reason in ResourceClaim.status.devices. The scheduler then picks another device. Previously the conflict appeared at NodePrepareResources, after placement. It looked like a prolonged ContainerCreating state. The restriction applies at placement level. Different MIG partitions of one card remain available to different namespaces. Look for the rejection in ResourceClaim.status.devices, not in the admission logs.
• ResourceClaimTemplate objects created earlier with the appended selector have to be recreated
  Removing the webhook does not correct them, their spec is immutable. Recreate such objects by their owner. For a Helm release: delete the object and run helm upgrade. Otherwise the ManifestsApplyFailed state persists.
• On nodes with a broken GPU host stack, D8GpuNodeHostStackUnhealthy alerts appear
  It happens with mismatched nvidia-container* versions. It also happens with a DKMS module not built for the current kernel. This is detection of pre-existing faults. Convergence of such nodes is not blocked. The node.deckhouse.io/gpu-setup-complete readiness marker is removed from them. GPU stack components are not placed on such nodes.
• Before disabling the module, return any card in VFIO passthrough to its compute driver
  Use the gpu.deckhouse.io/reclaim annotation. Disabling the module does not release the driver binding. A card left on vfio-pci keeps that binding after the module is removed. Returning it requires a node reboot.

Known issues

• MetaX: whole cards only
  The MetaX adapter allocates a whole card. Partitioning and sharing are available for NVIDIA. A claim asking for a share of a MetaX card is rejected at prepare.
• The GPU host stack verdict is not recomputed continuously
  The check runs at node bootstrap, on a configuration change and on reboot. A fault that appears between those moments reaches the labels and the alert only on the next run.

Docs

• The module documentation is reworked
  The overview, settings, architecture, FAQ, usage and glossary sections are consistent with each other. DRA and device plugin are described as mutually exclusive modes. DRA is described as the recommended one. It is in Preview and has to be enabled explicitly. Without extra configuration the module runs in device plugin mode. Pages added: a glossary, a GPUClass description, a manifest set, a tutorial and a usage section. The examples page is removed and its content moved into the new sections. The “Prerequisites for DRA mode” section documents both Kubernetes floors and the six required feature gates. The FAQ now covers “GPU workloads do not work with the driver and toolkit installed”.
• The resource reference is aligned with the schema
  A Russian description of GPUClass is added. The PhysicalGPU description is updated to the current schema.

Dependencies

• Platform requirements: Deckhouse >= 1.75, Kubernetes >= 1.33. The previous Kubernetes floor was 1.34. DRA mode still requires Kubernetes >= 1.34. This is verified at runtime.

v1.2.8 — 2026-08-31

Summary: Maintenance release of the 1.2.x line with security metadata and dependency updates. The deployed GPU stack behaviour does not change.

Highlights

• Security reporting for module images became more accurate. Images can carry VEX metadata. It covers vulnerabilities known not to affect the shipped binaries.

Security updates

• Fixed known vulnerabilities (CVE).
• Added VEX metadata for vulnerabilities not reachable in shipped module binaries. It reduces false positive findings for the affected images.

v1.2.7 — 2026-08-31

Summary: Fixed the root type declaration in the module configuration OpenAPI schema. Deckhouse validates the gpu module values against the schema.

Highlights

• Validation of the gpu module configuration values works correctly. The root of the OpenAPI schema is declared as an object. That is what Deckhouse requires.

Fixes

• Fixed the root type declaration in the module configuration OpenAPI schema. The root is declared as an object. Deckhouse validates the gpu module values against the schema. Previously it treated the schema root as an unknown field.

v1.2.6 — 2026-08-30

Summary: Technical release of the 1.2.x line. The update changes only image build mechanics and does not affect deployed GPU stack behaviour.

Highlights

• Technical release: the deployed manifests, image set and component versions do not change, so no operator action is required.

v1.2.5 — 2026-08-29

Summary: Maintenance release of the 1.2.x line with security updates. The release does not change GPU workload behaviour and requires no operator action.

Highlights

• Known vulnerabilities in the module images were fixed without changing the deployed GPU stacks or their configuration contract.

Security updates

• Fixed known vulnerabilities (CVE).

v1.2.4 — 2026-07-17

Summary: Technical release of the 1.2.x line.

Highlights

• Technical release: nothing changes for operations. The update is safe and requires no action.

v1.2.3 — 2026-07-17

Summary: Security update of the 1.2.x line.

Highlights

• Known vulnerabilities in the shipped images have been fixed.

Security updates

• Fixed known vulnerabilities (CVE).

v1.2.2 — 2026-07-17

Summary: Technical release of the 1.2.x line.

Highlights

• Technical release: nothing changes for operations. The update is safe and requires no action.

v1.2.1 — 2026-07-15

Summary: Fixes for VFIO passthrough, GPUClass handling and the GPU utilisation metric.

Highlights

• VFIO passthrough works correctly: the device is bound to the workload.
• The GPU utilisation metric is published — monitoring panels show card load.

Fixes

• Fixed device binding for VFIO passthrough.
• Fixed handling of the GPUClass resource.
• Fixed the GPU utilisation metric.

v1.2.0 — 2026-07-01

Summary: The GPUClass resource is introduced — a declarative description of GPU classes for the DRA stack.

Highlights

• The GPUClass resource (gpuclasses.gpu.deckhouse.io) is added. GPU classes are described declaratively. A workload requests a class rather than a specific card.
• Device selection for a DRA claim became predictable: incomplete placement candidates no longer take part in the choice.

New features

• The GPUClass resource (gpuclasses.gpu.deckhouse.io). It is a declarative description of GPU classes for the DRA stack.

Fixes

• Resolved DRA claim placement conflicts: synthetic (incomplete) placement candidates are no longer considered when selecting a device.
• Fixed ownership of PhysicalGPU resources — the objects no longer end up orphaned.

v1.1.2 — 2026-06-11

Summary: DRA workloads are isolated from the node’s unallocated devices, and monitoring dashboard names are fixed.

Highlights

• GPUs requested through DRA no longer overlap with the node’s unallocated devices. A workload cannot touch a card that was not handed to it.

Fixes

• DRA workload isolation: GPUs requested through DRA no longer overlap with unallocated devices on the node.
• Fixed monitoring dashboard names — the dashboards are found in Grafana under the expected titles.

v1.1.1 — 2026-06-10

Summary: GPU sharing in DRA mode (MPS and Time-Slicing), automatic MIG reconfiguration with a node reboot, and VFIO passthrough support.

Highlights

• DRA mode now supports GPU sharing. MPS and Time-Slicing are switched on by a partial resource request. No manual node configuration is needed.
• MIG reconfiguration that needs a node reboot is orchestrated automatically and consistently. The operator no longer drains workloads and stops driver access by hand.
• VFIO passthrough is supported: a GPU can be handed to a virtual machine as a whole.
• A workload no longer sees the node’s other GPUs inside its container. This matters on nodes with several cards.

New features

• GPU sharing for DRA workloads in MPS and Time-Slicing modes. A partial resource request (sharePercent) automatically enables sharing of the physical card.
• Automatic orchestration of MIG reconfiguration with a node reboot. The node is drained in a coordinated way. GPU driver and DCGM access is paused for the repartition. No operator intervention is required.
• VFIO passthrough support for GPUs.

Fixes

• GPU visibility inside a container is limited to the allocated devices only. This matters on nodes with several GPUs. A workload previously saw every card there.
• Correct CDI identifiers are returned for every allocation. This is important for multi-device workloads and for sharing and partitioning scenarios.
• Device preparation recovers after failures. Stale completed claims are cleaned up and binding errors are typed. A retry proceeds correctly.
• Added the metrics that were missing from the GPU dashboard.

Docs

• Added the basic GPU usage scenarios — from exclusive allocation to sharing and MIG.

v1.1.0 — 2026-05-22

Summary: The DRA (Dynamic Resource Allocation) stack is introduced as an alternative to the device plugin stack. The module’s minimum Kubernetes version is raised to 1.34.

Highlights

• The DRA stack (Dynamic Resource Allocation) is available. It is enabled with dra.enabled=true. GPUs are allocated through ResourceClaim objects rather than through extended node resources.
• Default behaviour is unchanged. With dra.enabled=false the device plugin stack is deployed, exactly as in 1.0.x.
• The module’s minimum Kubernetes version is raised from 1.32 to 1.34. The module cannot be installed or updated on older clusters.

New features

• DRA mode is enabled with dra.enabled=true. Instead of the NVIDIA GPU Operator based stack, the module deploys gpu-controller, gpu-node-agent, dra-plugin and nvidia-adapter. Node GPUs are described by the PhysicalGPU resource.

Fixes

• Improved the MIG configuration logic (mig-parted) and added support for operating systems with an older glibc.
• Fixed the retry interval of MIG configuration. A card that is temporarily not ready no longer leaves the configuration abandoned.
• Reverted the automount configuration that granted stack pods excessive permissions.

Security updates

• Fixed known vulnerabilities (CVE).

Breaking changes

• The module’s minimum Kubernetes version is 1.34, it was 1.32. On 1.32 and 1.33 clusters installing and updating the module is rejected by the requirements check.

Upgrade notes

• Before updating, make sure the cluster runs Kubernetes 1.34 or newer. If it does not, stay on the 1.0.x line. It keeps receiving fixes and security updates.
• Enable DRA mode deliberately. Do it on new installations or after validating it on a test cluster. dra.enabled=true replaces the whole node GPU stack rather than complementing it.

Dependencies

• Platform requirements: Deckhouse >= 1.75, Kubernetes >= 1.34 (was >= 1.32).

v1.0.4 — 2026-06-10

Summary: Technical release of the 1.0.x maintenance line.

Highlights

• Technical release: nothing changes for operations. The update is safe and requires no action.

v1.0.3 — 2026-06-02

Summary: Security update of the 1.0.x maintenance line.

Highlights

• Known vulnerabilities in the shipped images have been fixed.

Security updates

• Fixed known vulnerabilities (CVE).

v1.0.2 — 2026-05-14

Summary: MIG configuration fixes, including on operating systems with an older glibc, and known vulnerabilities fixed.

Highlights

• MIG configuration is applied correctly on operating systems with an older glibc — previously partitioning never completed on such nodes.
• Known vulnerabilities in the shipped images have been fixed.

Fixes

• Improved the MIG configuration logic (mig-parted) and added support for operating systems with an older glibc.
• Fixed the nvidia-mig-manager script that could leave card partitioning unapplied.

Security updates

• Fixed known vulnerabilities (CVE).

v1.0.1 — 2026-04-17

Summary: Technical release of the 1.0.x maintenance line.

Highlights

• Technical release: nothing changes for operations. The update is safe and requires no action.

v1.0.0 — 2026-04-01

Summary: First release of the gpu module. It runs and operates NVIDIA GPU workloads in Deckhouse Kubernetes Platform on the device plugin stack.

Highlights

• The gpu module is ready for use. GPU nodes are enabled through the spec.gpu section of the target NodeGroup. The module then deploys the NVIDIA GPU Operator based device plugin stack on them.
• Three GPU allocation modes are supported: exclusive, Time-Slicing and MIG (Multi-Instance GPU).
• GPU monitoring through DCGM with ready-made Grafana dashboards works out of the box.

New features

• MIG (Multi-Instance GPU) support. A physical card is split into isolated partitions. Each partition is handed to a workload as a separate device.
• GPU monitoring through DCGM and DCGM-exporter. Utilisation, temperature and memory metrics are available in Prometheus and on Grafana dashboards.
• Automatic discovery of GPU nodes through Node Feature Discovery. Manual node labelling is not required.

Dependencies

• Platform requirements: Deckhouse >= 1.75, Kubernetes >= 1.32.
• Device plugin stack components shipped. 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.