Release notes

v1.3.3 — 2026-10-14

Summary: A DRA mode patch release. It fixes stopping of nvidia-persistenced, cards stuck in passthrough and allocation of a second MIG partition. The kubectl get columns and the node reboot approval rule have changed. Before upgrading, follow the steps in the Upgrade notes section.

Highlights

• DRA mode: moving a card to VFIO passthrough and changing the MIG mode no longer stop nvidia-persistenced.
• DRA mode: a failed return of a card from passthrough is retried in the background. A node reboot is needed only if the card still does not come back.
• DRA mode: the reason for a PhysicalGPU state is shown in the STATUS column. A healthy, unallocated PhysicalGPU in Compute mode is marked Unclaimed instead of Unknown.
• DRA mode: only the update.node.deckhouse.io/disruption-approved annotation approves a node reboot for card reconfiguration. Other Deckhouse updates that require disruption use the same approval.

Improvements

• DRA mode: the Unclaimed management state of a PhysicalGPU
  A healthy PhysicalGPU in Compute mode that no ResourceClaim holds gets the Unclaimed value. Previously such a PhysicalGPU was marked Unknown and looked like a failure. Unclaimed needs no action from the administrator.
• DRA mode: the PhysicalGPU.status.message field
  The field explains the PhysicalGPU phase, for example why it is not ready. The text may change between versions. For automation, use phase, conditions and driverBinding.managementState.
• DRA mode: a new set of columns in kubectl get
  By default PhysicalGPU shows the node, model, phase, management state and the reason for the state. GPUClass shows the class state and the number of PhysicalGPUs. Technical attributes are shown with -o wide. All columns are described in the resource reference.
• DRA mode: returning a card from VFIO passthrough is retried before a node reboot is requested
  Previously, the adapter requested a node reboot after the first failure to restore the card to the nvidia driver. This restarted all workloads on the node. Such an error happens, for example, after the guest VM reboots. Now the claim is released at once. Returning the card is retried in the background for 5 minutes. Progress is visible in the Reconfiguring condition and the VFIORestore* events. A node reboot remains the fallback.
• DRA mode: a stuck gpu-controller restarts by itself
  Previously the controller could stop processing resource changes while its Pod kept running. A missed resource change could take up to 10 hours to be handled. Now such a controller restarts itself, and a missed change is handled within 10 minutes. Admission webhooks stay available during the restart. The controller state is visible in the gpu_controller_heartbeat_timestamp_seconds and gpu_controller_last_reconcile_timestamp_seconds metrics.
• DRA mode: metrics and events for releasing a card from nvidia-persistenced
  The result of each operation is visible in the gpu_persistence_release_total{outcome} metric and in the Persistence* events of PhysicalGPU. The gpu_persistence_restore_pending metric counts cards awaiting persistence restoration.
• DRA mode: MIG-backed vGPU inside a guest VM
  Previously Pods with a GPU did not start in a cluster inside a VM with a MIG-backed vGPU. The adapter’s attempt to disable MIG failed with mig instances still present. Now Pods get the guest VM’s MIG device, and the MIG layout stays unchanged.

Fixes

• DRA mode: nvidia-persistenced is no longer stopped during card operations
  Previously, moving a card to passthrough or changing the MIG mode stopped nvidia-persistenced. The service stayed failed, and the /run/nvidia-persistenced/socket socket disappeared. New GPU containers on the whole node did not start. Now persistence is turned off only for the target card and turned back on after the operation. If the previous version already stopped the service, the adapter will start it by itself. The start waits until every card of the node is back from VMs. A service stopped or masked by hand is left alone.
• DRA mode: a missing socket on the node no longer prevents containers from starting
  Previously a GPU container failed to start with no such file or directory. This happened when the nvidia-persistenced, nvidia-fabricmanager or MPS socket was missing on the node. PrepareResources still succeeded. Now a socket is mounted into the container only if it exists on the node. Mount changes are visible in the gpu_cdi_ipc_mount_changes_total metric. A node already in this state recovers by itself after the upgrade.
• DRA mode: MPS and time-slicing are enabled as requested
  Previously a claim for a GPU share without an explicit mode could get the wrong mode. This affected both ResourceClaim and requests through an extended resource. A whole card requested with time-slicing got MPS. On a MIG partition requested with MPS, MPS was not enabled. Now the mode comes from the gpu.deckhouse.io/sharingStrategy attribute of the device chosen by the scheduler.
• DRA mode: a card no longer gets stuck in passthrough after the VM is deleted
  Previously, after the VM was deleted, the card could stay on vfio-pci. Only a node reboot could return it. Reclaim through the gpu.deckhouse.io/reclaim annotation was refused as well.
• DRA mode: a second MIG partition on a card is no longer refused
  Previously, after one partition was allocated, the card looked full while it still had free slices. The next claims stayed Pending with cannot allocate all claims.
• DRA mode: reclaim refusals are cleared when the PhysicalGPU management state changes
  Previously a Reclaim=Refused refusal stayed on the PhysicalGPU after its state changed. The refusal and its clearing are visible in the ReclaimRefused and ReclaimRefusalCleared events.
• DRA mode: a withdrawn node reboot no longer takes the card out of service
  The update.node.deckhouse.io/reboot annotation may be removed before the reboot. Previously the card then waited for the next node reboot. Now it requests disruption once more, and a NodeRebootWithdrawn event is created.

Upgrade notes

• DRA mode: columns removed and renamed in kubectl get output
  The DEVICE column of PhysicalGPU is removed. The PCI device ID is part of the object name. The full address is shown by the PCI column with -o wide. The VENDOR, MODE and HEALTHY columns are shown only with -o wide. For GPUClass the READY column is replaced with STATE. The DEVICES column is renamed to GPUS. Resource fields are unchanged. Scripts that parse the output by column names need an update.
• DRA mode: only disruption-approved approves a node reboot
  Previously a reboot was approved by any of the disruption-approved, draining and drained annotations with the update.node.deckhouse.io/ prefix. A node could reboot after a regular drain without explicit approval. Now the update.node.deckhouse.io/disruption-approved annotation is required. Other Deckhouse updates that require disruption use the same approval. To cancel the reboot, remove update.node.deckhouse.io/reboot and update.node.deckhouse.io/disruption-approved.
• DRA mode: before upgrading, check the nodes where cards were moved to passthrough
  Step 1. For each GPU node, run d8 k -n d8-nvidia-gpu get jobs,pods -l gpu.deckhouse.io/vfio-switch-node=<node>.
  Step 2. The node needs a reboot if the command returned objects. The same applies if cards on the node entered passthrough since its last reboot, or if this is unknown. Completed Jobs are deleted after 5 minutes, so an empty result does not guarantee there were no switches.
  Step 3. Before the upgrade, cordon such a node and move GPU workloads off it. After the upgrade, delete the switch Jobs of this node, reboot it and return it to service. Other nodes are upgraded as usual.
• DRA mode: free PhysicalGPUs change from Unknown to Unclaimed
  For free PhysicalGPUs the gpu_physicalgpu_info{managementState="Unknown"} series is replaced with managementState="Unclaimed". Graphs show a one-time break. Update automation and filters that treated Unknown as a free PhysicalGPU.
• DRA mode: running shared cards switch to the new mode later
  A new claim without explicit configuration uses the device’s current sharing mode. This keeps MPS and time-slicing from mixing on one card. After all claims release the device, its sharing mode is determined by the sharingStrategy attribute of the chosen device.
• DRA mode: after a module rollback, check the persistence of cards
  A card may be in passthrough or returning from it during the rollback. Its persistence then stays off. Workloads remain functional, but the first CUDA initialization takes longer. Check the cards with nvidia-smi --query-gpu=pci.bus_id,persistence_mode --format=csv. Turn persistence on with nvidia-smi -i <pci> -pm 1. After the rollback, moving a card to passthrough and changing the MIG mode stop nvidia-persistenced, as in the previous version. Start the service on the node with systemctl restart nvidia-persistenced.service.

Known issues

• DRA mode: MIG-backed vGPU in a guest VM depends on virtualization detection
  If the VM is misidentified as bare metal, the adapter attempts to disable MIG. The operation fails with mig instances still present. Claim preparation is blocked if the guest VM has multiple MIG devices or device detection fails.
• DRA mode: the D8GPUPhysicalGPUOrphaned alert may fire later
  The adapter may not finish returning a card from passthrough. The alert then fires about 30 minutes after the card was left without a claim, instead of 17.

Docs

• Resource columns are described in the reference
  Every PhysicalGPU and GPUClass column has a description. Output examples in the documentation match the new set of columns. The FAQ covers PhysicalGPU management state values and how to diagnose a reclaim refusal.

v1.3.2 — 2026-09-23

Summary: The release fixes the startup of the node-feature-discovery worker in the device plugin stack. DRA mode is not affected.

Highlights

• Fixed the CrashLoopBackOff on node-feature-discovery startup.
• Nodes get their feature.node.kubernetes.io/pci-* labels. Without them the device plugin and gpu-feature-discovery were not scheduled onto a node.

Fixes

• The node-feature-discovery worker did not start
  The container ran as root with every capability dropped. It could not exec its own binary that way. The worker went into CrashLoopBackOff. The node stayed without its node-feature-discovery labels. The device plugin and gpu-feature-discovery were not scheduled onto such a node. The worker has been moved to the unprivileged module user.

Upgrade notes

• The worker collects the local and pci sources only
  The cpu, kernel, system and other sources are disabled. Custom NodeFeatureRule objects relying on their features stop matching on GPU nodes. Check your own rules before upgrading. The feature.node.kubernetes.io/pci-* labels are unchanged.

v1.3.1 — 2026-09-11

Summary: The release fixes known vulnerabilities. Module behaviour does not change.

Highlights

• Fixed known vulnerabilities (CVE). Module behaviour does not change.

Security updates

• Fixed known vulnerabilities (CVE).

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.

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

• 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.
• 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

• 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. The check constrains only the first rollout of the stack. A stack that is already deployed is not removed, and transient gate unavailability does not stop running workloads. That happens during a control-plane rolling upgrade or a read from another apiserver replica. Only an alert is raised then.
• 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 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.

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.