Module gpu

The gpu module adds GPU management and GPU workload support to Deckhouse Kubernetes Platform: node preparation, hardware discovery, exposing GPUs to the scheduler, and shipping data for monitoring.

The module is built around a vendor-agnostic core and per-vendor adapters. Discovery, scheduling, and the PhysicalGPU inventory work the same for any GPU brand. Access to vendor hardware goes through a contract implemented by a vendor adapter. Adapters ship for NVIDIA and MetaX.

The module operates in two mutually exclusive modes. DRA mode is the recommended one: workloads request GPUs through Kubernetes Dynamic Resource Allocation (DRA), and a Pod states what it actually needs — a whole card, a MIG partition, or a percentage of a shared GPU — and gets exactly that. The mode is in Preview and has to be enabled explicitly. Without extra configuration the module runs in Device Plugin mode: the GPU sharing mode is configured per node group and a Pod asks for nvidia.com/gpu: 1.

Module capabilities

• Allocate whole GPUs — one per Pod.
• Partition GPUs with MIG on A100 and H100. Partitions are created on demand from the workload’s request. You do not need to run nvidia-smi -mig by hand.
• Share one GPU between workloads with MPS or time-slicing, down to the requested percentage.
• Pass a GPU straight through to a virtual machine with VFIO — for QEMU/KVM and similar consumers.
• Publish GPU pools by name. An administrator defines a GPUClass; users then request gpu.deckhouse.io/<class> in one line, and the module builds the claim for them.
• Observe the hardware — DCGM metrics with ready-made Grafana dashboards, plus GPU inventory and per-workload allocation views.
• Prepare nodes automatically. containerd, the GPU runtime, kernel parameters, and VFIO/IOMMU setup are handled by NodeGroupConfiguration. Manual node tuning is not required.
• Add a GPU vendor without changing the core. A new vendor is a container implementing the adapter contract plus a PCI vendor ID in a ConfigMap. No core or custom resource changes are required when adding a new vendor.

Cluster requirements for using the module

To use the module in a DKP cluster, the cluster must meet the following requirements:

• Deckhouse Kubernetes Platform 1.75 or newer, edition EE.
• Kubernetes 1.33 or newer for Device Plugin mode, which is the default.
• Kubernetes 1.34 or newer for DRA mode: three of the six feature gates the module needs do not exist in 1.33. See DRA feature gates readiness.
• A GPU vendor with a shipped adapter — NVIDIA or MetaX. See Vendor adapters.
• The vendor driver installed on GPU nodes — for NVIDIA, the driver and the NVIDIA Container Toolkit. The module configures containerd itself, but does not install the driver. See How do I install the NVIDIA driver on GPU nodes?.
• The DRA feature gates enabled by the platform. The module verifies this and refuses to deploy the DRA stack otherwise; it never changes control-plane or kubelet arguments itself. See DRA feature gates readiness.

Module components

The module creates a set of components in the d8-nvidia-gpu namespace. The component lists for the supported modes are in the Architecture section:

• module components in DRA mode,
• module components in Device Plugin mode.

Module operating modes

The module can run in one of the following modes:

• DRA;
• Device Plugin.

DRA and Device Plugin modes are mutually exclusive and differ in where the decision is made: Device Plugin mode fixes a sharing mode per node group, while DRA lets each workload state what it needs. Switching between them requires no manual cleanup — the module removes one stack and deploys the other into the same namespace. See How do I migrate from Device Plugin mode to DRA?.

For more about the modes, see Architecture.

Prerequisites for DRA mode

The module never enables feature gates itself and never modifies control-plane or kubelet arguments.