Glossary

Requesting GPUs

capacity request — the measurable amounts a claim can ask for, as opposed to just “one device”. The module publishes two axes: gpu.deckhouse.io/memory (a quantity such as 1Gi) and sharePercent.

CEL selector — the expression language a DeviceClass uses to choose devices, evaluated against device attributes. One rule matters more than the rest: optional attributes must be wrapped in has(...), because referencing a missing attribute makes the whole expression fail rather than evaluate to false.

DeviceClass — the named set of devices a claim may draw from, defined by CEL selectors. It is either written by hand or generated by a GPUClass. Kubernetes documentation.

DRA (Dynamic Resource Allocation) — the Kubernetes mechanism this module is built on. Workloads request devices at the Pod level, describing what they need, instead of a node-level configuration deciding for them. Kubernetes documentation.

extended resource — the short path to a GPU: gpu.deckhouse.io/<device-class-name>. With such a request the module creates the ResourceClaim for you, so you do not need to write spec.resourceClaims or resources.claims. Request 1 for exclusive classes and 1–100 for -percent classes. Not applied in kube-system or d8-* namespaces. See Usage.

GPUClass — a named pool of PhysicalGPU objects defined by an administrator; the controller generates one DeviceClass per allowed partition and sharing combination, each with its own extended resource name. The authoritative list of what was created is in .status.deviceClassNames. See GPU classes.

opaque config — module-specific device parameters inside a claim, in API group resource.gpu.deckhouse.io/v1alpha1. Opaque config kinds: GpuConfig (a whole card), MigDeviceConfig (a MIG partition), and VfioDeviceConfig (passthrough). This is how you explicitly request MPS or VFIO.

ResourceClaim — a request for one or more devices that the scheduler satisfies and that is prepared on the node before the Pod starts. Kubernetes documentation.

ResourceClaimTemplate — creates a separate ResourceClaim for each Pod that references it. You normally reference the template rather than a standalone ResourceClaim. Kubernetes documentation.

GPU hardware and sharing

DCGM — NVIDIA’s telemetry daemon, the source of the DCGM_FI_* metrics. Vendor-specific: it is deployed alongside the NVIDIA adapter; other vendors would ship their own exporter. See Monitoring.

MIG

Multi-Instance GPU — hardware partitioning of one NVIDIA card into independent instances, each with its own compute and memory. Isolation is enforced by the hardware. In this module MIG partitions are ephemeral: created when a claim is prepared and destroyed when it is released, so there is no persistent layout to manage. See Usage.

Supported cards and profiles: NVIDIA MIG User Guide.

MPS

Multi-Process Service — NVIDIA’s mechanism for running several processes concurrently on one GPU. One control daemon per card: it starts on demand and is reused by every workload sharing that device. There is no hardware isolation: workloads on the same card affect each other.

Requires compute capability 7.0 or higher. MPS exists on older cards too, but per-client address spaces and independent scheduling arrived with Volta — that is what makes it usable for isolation-free sharing. See Multi-Process Service.

NFD/GFD — Node Feature Discovery and GPU Feature Discovery, which label nodes with detected hardware features. Device Plugin mode only; they are not part of the DRA stack.

NVML — NVIDIA’s management library, used by the NVIDIA vendor adapter to read a card’s capabilities. If it is unavailable, the card never reaches Ready and none of its devices are published. Other vendors use their own libraries: ROCm SMI on AMD, sysfs on Intel.

partition profile — the shape of a MIG partition, such as 1g.5gb. Two spellings exist and are not interchangeable: the dotted hardware name (1g.5gb) — used in CEL selectors and PhysicalGPU capabilities; the DNS-label form (1g5gb) — used in GPUClass.spec.partitionFilter, because it becomes part of a generated object name.

sharePercent — the capacity axis for shared devices, from 1 to 100. Only shared variants publish it, so requesting sharePercent is enough to land on a shared device without naming a strategy.

sharingStrategy — a device attribute whose value is mps or ts. It is absent on exclusive devices, so !has(...sharingStrategy) is how a selector says “give me the whole thing”.

sGPU

MetaX’s sharing mechanism: instead of cutting the card into fixed seats it hands out quota — a share of compute in percent and an amount of memory in 128 MiB steps. It partitions nothing, so it is a sharing strategy rather than a partition technology.

SPX, DPX, CPX

Compute partitioning modes for AMD Instinct accelerators, paired with the NPS memory partitioning modes. They are AMD’s counterpart to MIG. See AMD GPU Partitioning.

slice — the unit MIG profiles are built from. A card publishes shared counters across its slices, and every device declares which it consumes; that is why two conflicting layouts cannot be allocated at the same time. See Causes of MIG layout conflicts.

Time-slicing

Sharing a GPU by handing the card to each workload in turn for a time quantum, rather than partitioning the hardware. Requires no special hardware support and gives no isolation. Appears as ts in sharingStrategy.

Module objects

vendor adapter — the per-vendor DaemonSet that turns a discovered card into an allocatable device. It pairs the shared dra-plugin with a vendor container implementing the Backend contract, and is scheduled onto nodes labeled gpu.deckhouse.io/vendor. Adapters ship for NVIDIA and MetaX. See Vendor adapters.

capacity units — the gpu.deckhouse.io/capacity-units label on a generated DeviceClass: 1 for exclusive classes, 100 for -percent classes. It tells you what number to put in an extended-resource request.

device name — encodes what a device is: gpu-<pci> is a whole card, part-gpu-<pci>-p<profile>-s<start>-n<size> is a MIG partition, and a -mps or -ts suffix marks a shared variant. See Getting information about the allocated GPU.

driver binding — reported in PhysicalGPU.status.driverBinding as three fields: driver (the sysfs driver name, treated as ground truth), mode (Compute, Passthrough, Unbound, Unknown), and managementState (Managed, Excluded, Orphaned, Unknown). Surfaced as the Mode and Management columns of d8 k get physicalgpus. See Reference.

management state — whether the module owns a device. It is the only value that gates reclaim, and the reason behind it is carried on the Managed condition. A stray passthrough binding must persist for two minutes before it is classified as Orphaned. See Device management state.

reclaim — an administrator-initiated reset and rediscovery of a device via the gpu.deckhouse.io/reclaim annotation; progress is reported on the Reclaim condition. Refused while an active ResourceClaim still references the device.

PhysicalGPU — defined by this module. One cluster-scoped object per discovered card, holding PCI identification, readiness conditions, and capabilities. It is inventory only: spec is intentionally empty. Phases: Pending, Initializing, Ready, Reconfiguring, Passthrough, Failed, and Lost. See Reference.

placementID — a stable identifier for where a device sits: a card or a specific partition slot on it.

ResourceSlice — what a node publishes to advertise the devices it can actually allocate. Produced only while a PhysicalGPU is in Ready, so a card with a driver problem appears in no slice at all. Kubernetes documentation.

Nodes and runtime

CDI (Container Device Interface) — the standard mechanism by which an allocated device is injected into a container. Worth understanding because it explains the module’s most surprising behavior: devices arrive only through a claim, so NVIDIA_VISIBLE_DEVICES has no effect and a Pod without a claim sees no /dev/nvidia* at all. That isolation is deliberate.

feature gate — a Kubernetes feature flag. DRA mode requires six of them; the platform enables them and the module only verifies their state — it never turns them on and never edits control-plane or kubelet arguments. See DRA feature gates readiness.

finalizer — the reason module deletion is not instant: gpu-controller must release each PhysicalGPU before the CRD is removed, so a pre-delete hook deletes them and waits.

IOMMU — the hardware address-isolation unit that VFIO passthrough depends on. It must be enabled both in BIOS and on the kernel command line; the module can add the kernel parameter itself, but applying it reboots the node.

node labels — the module both sets and reads labels that decide where GPU components run and which cards are under management. The full table, including which component sets each one, is in Node labels that gate scheduling.

NodeGroupConfiguration — the Deckhouse mechanism the module uses to prepare nodes: driver checks, the containerd runtime handler, kernel parameters, and VFIO setup. The scripts and their order are listed in Node preparation.

render gate — the three internal conditions that decide what is deployed: dra.enabled, migrationReady, and draFeatureGatesReady. They gate different sets of templates rather than one. The first two enable node preparation; the feature gates on top of them are what the workload stack needs. The irreversible node-preparation steps — the kernel-command-line rewrite with its reboot, and the vfio-pci binding — are withheld separately, while the gates are confirmed absent and the workload stack has never been deployed. See Conditions for enabling the mode.

RuntimeClass nvidia — shipped by the module but used only by the DCGM DaemonSets. Normal DRA workloads run under the default runtime and must not set it.

VFIO / vfio-pci — the kernel framework for handing a raw PCI device to a userspace consumer such as a virtual machine. A card bound to vfio-pci is not a CUDA device: there is no nvidia-smi inside the container, only VFIO device nodes. See VFIO passthrough.