GPUs in Kubernetes: what the GPU Operator installs, and four ways to share a card

What the GPU Operator installs

NVIDIA’s GPU Operator uses the Kubernetes operator framework “to automate the management of all NVIDIA software components needed to provision GPU”. This guide follows release v26.7.0, the current one in NVIDIA’s release notes on 21 September 2026. On GPU nodes the Operator deploys these components, each as a container.

NVIDIA GPU Operator documentation: release notes, installation options and platform support, updated 21 September 2026; NVIDIA DCGM Exporter documentation, May 2026.

Node Feature Discovery and validator pods complete the set, and toolkit.enabled=false keeps a container runtime that is already configured for NVIDIA. Our monitoring guide covers what to watch in the DCGM metrics. Check NVIDIA’s support list for the Operator first: it names data-centre cards such as the H200 NVL, L40S and L4 and, among the Blackwell PCIe cards, the RTX PRO 6000 and RTX PRO 4500 Server Editions. We found no entry for the RTX PRO 6000 Workstation or Max-Q editions or for the RTX PRO 5000. For the RTX PRO 6000 Server Edition the list requires driver 575.57.08 or later and notes that MIG is not supported on the 575.57.08 driver release itself.

Four ways to hand out a GPU

A pod asks for a whole number of GPU resources; the device plugin decides what one unit is: a physical card, a MIG instance or a replica of a shared card. The four methods differ most in one respect, which is what one pod can do to its neighbours.

NVIDIA MIG user guide (11 September 2026), GPU Operator documentation (21 September 2026), NVIDIA k8s-device-plugin README and CUDA MPS documentation, read September 2026.

Whole GPUs: the default

Without further configuration the device plugin advertises each physical card as one nvidia.com/gpu, and a pod asks for it in its resource limits, for example nvidia.com/gpu: 1. The card then belongs to that container until the pod ends. It is the right unit for training, for models that need most of a card’s memory and for services that keep a GPU busy. The device plugin’s README, which assumes the NVIDIA runtime is the node’s default runtime, adds a warning: if a pod does not request GPUs, the plugin “exposes all the GPUs on the machine inside your container”. Since v25.10.0 the Operator injects GPUs through CDI by default and no longer makes the nvidia runtime class the default handler, so check which set-up your nodes run.

MIG: partitions in hardware

MIG divides a card into GPU instances with their own streaming multiprocessors, memory and memory paths. In NVIDIA’s words, “the on-chip crossbar ports, L2 cache banks, memory controllers, and DRAM address busses are all assigned uniquely to an individual instance”, which gives each instance a defined quality of service “with fault isolation”. Of the cards we supply, NVIDIA’s MIG guide of 11 September 2026 lists the RTX PRO 6000 Workstation Edition and Max-Q with up to four instances of 24 GB, the RTX PRO 5000 with two, the RTX PRO 4500 with two of 16 GB and the H200 NVL with seven, whose smallest profile is 1g.18gb. For the RTX PRO 4500 the guide names no edition and gives profiles but no prerequisites: NVIDIA documents driver 575.51.03 or later, a minimum vBIOS and the display-mode switch only for the RTX PRO 6000 and 5000, and the workstation card’s datasheet and product page do not mention MIG, so have MIG support for that card confirmed in writing. The guide covers the 48 GB RTX PRO 5000, split into two of 24 GB; for the 72 GB card NVIDIA’s datasheet gives two of 36 GB. The RTX PRO 5500 is announced with two instances of up to 42 GB and is not in the guide yet. The L4, L40S, RTX PRO 4000 and RTX PRO 2000 are not on NVIDIA’s MIG list. Our MIG and vGPU comparison covers the virtual machine side.

The device plugin exposes MIG through one of two strategies, set by the Operator’s mig.strategy value, which defaults to single. With single, MIG instances are advertised under the usual nvidia.com/gpu name, and the resource now stands for the MIG devices on the node instead of the full GPUs. With mixed, every profile becomes its own resource type. Following NVIDIA’s naming pattern, a quarter of an RTX PRO 6000 then appears as nvidia.com/mig-1g.24gb and the smallest H200 NVL instance as nvidia.com/mig-1g.18gb. NVIDIA’s rules for choosing are short: single is for nodes on which MIG is enabled on all GPUs, mixed for nodes on which it is not, or whose layout uses more than one profile. A node that keeps a second NVIDIA GPU out of MIG, such as a display card, therefore needs mixed. Device plugin v0.20.0, the version in Operator v26.7.0, fixed its profile matching so that variants with suffixes such as -me, +me.all and +gfx are exposed as separate Kubernetes resources.

MIG Manager applies the layout. A node label, nvidia.com/mig.config, names it, for example all-disabled or a layout with one profile throughout such as NVIDIA’s example all-1g.10gb; since Operator v26.3.0, MIG Manager generates the available layouts for each node from the GPUs it finds, and reports progress in nvidia.com/mig.config.state. Changing the layout is disruptive: NVIDIA states that MIG Manager requires that no user workloads run on the GPUs being configured, and that the node might need to be cordoned and, on some platforms, rebooted. MIG does not build a bigger GPU either, because NCCL is not supported with MIG, as our Nutanix cluster article explains for distributed training.

Three of the workstation cards need one more step that the Operator does not take. On the RTX PRO 6000 Workstation and Max-Q editions and on the RTX PRO 5000, MIG can be enabled only after the display mode has been switched from graphics to compute with NVIDIA’s DisplayModeSelector tool, which turns the display outputs off; NVIDIA supplies the RTX PRO 6000 Server Edition from the factory in display-off mode. We found nothing about this switch in the GPU Operator documentation, so on these cards it is a manual step for each card, described in our MIG runbook for RTX PRO Blackwell.

Time-slicing: more pods, no isolation

Time-slicing lets several pods take turns on one GPU. It is set in a ConfigMap for the device plugin: under sharing.timeSlicing, a resource such as nvidia.com/gpu gets a replicas value, “the number of shared accesses that will be granted for a GPU”, and the ClusterPolicy points to the ConfigMap through devicePlugin.config.name. The field devicePlugin.config.default names the entry for all nodes, and the label nvidia.com/device-plugin.config selects another for a single node; without a default, NVIDIA notes, the configuration does not reach all nodes automatically. With four replicas, each card is advertised as four GPUs. renameByDefault advertises the replicas as nvidia.com/gpu.shared; left at false, the resource name stays the same and the node’s product label gets the suffix -SHARED instead. failRequestsGreaterThanOne rejects any request for more than one replica with an UnexpectedAdmissionError. The Operator does not watch the ConfigMap, so a change applies only after you restart the device plugin pods; running workloads continue, and NVIDIA recommends doing it in a maintenance period.

The trade-off is isolation. NVIDIA’s Operator documentation says that, unlike MIG, “there is no memory or fault-isolation between replicas”, and the device plugin README is blunter: each workload “has access to the GPU memory and runs in the same fault-domain as of all the others (meaning if one workload crashes, they all do)”. A pod that requests two replicas is not guaranteed twice the compute either. Time-slicing suits development, notebooks and light jobs that tolerate a noisy neighbour. It can also be combined with MIG, to let several pods share each instance.

MPS: fixed shares, one fault domain

CUDA’s Multi-Process Service runs work from several processes on a GPU at the same time through a control daemon. The device plugin supports it with a sharing.mps section that takes replicas like time-slicing, but with limits: the memory each client may use is “limited to an equal fraction of the total device memory”, and the control daemon also caps each client’s share of compute. The README states the constraints plainly: “As of v0.15.0 of the device plugin, MPS support is considered experimental”, sharing with MPS is not supported on devices with MIG enabled, and only nvidia.com/gpu resources on full GPUs can be shared this way.

NVIDIA’s MPS documentation fills in the fault picture. MPS client processes “have fully isolated GPU address spaces”, but a fatal GPU fault “will be reported to all the clients running on the subset of GPUs in which the fatal fault is contained”, so one faulting process interrupts every pod on that card. NVIDIA describes MPS as useful when “each application process does not generate enough work to saturate the GPU”, which fits many small inference services.

Virtual machines and DRA

The Operator can also give GPUs to KubeVirt virtual machines, as whole cards by passthrough or as vGPUs, chosen node by node with the label nvidia.com/gpu.workload.config; that is a separate set-up from the container sharing described here. The larger change is Dynamic Resource Allocation. Release v26.7.0 can manage NVIDIA’s DRA driver v0.5.0, which needs Kubernetes v1.34.2 or later. Allocation of full GPUs and of existing MIG devices is generally available; creating MIG devices on demand, MPS and custom time-slicing settings are alpha features. Under the Operator, a cluster has either a GPUCluster resource for the DRA driver or a ClusterPolicy for the device plugin, not both.

Choosing a method

Whole GPUs for training and for any service that keeps a card busy on its own.

MIG when several services or teams share a card and each needs guaranteed memory and protection from the others: four instances of 24 GB on an RTX PRO 6000, up to seven on an H200 NVL. Of the cards named here, the H200 NVL and the RTX PRO 6000 Server Edition are on both NVIDIA’s MIG list and the Operator’s support list; the RTX PRO 6000 Workstation and Max-Q editions and the RTX PRO 5000 are on the MIG list only, and need the manual display-mode step.

Time-slicing for development and light jobs, where a crash that takes the neighbours down is acceptable.

MPS for many small inference processes on one full GPU, with the fault caveat above and not on MIG-enabled cards.

What we supply

Eurokommerz supplies the MIG-capable RTX PRO 6000 Workstation Edition and Max-Q, RTX PRO 5000 and H200 NVL, and the L40S and L4 for whole-GPU and time-sliced use, EU-wide with manufacturer warranty; we also supply the RTX PRO 4500, but NVIDIA does not document what MIG requires on it. We build AI servers to order with the cards a cluster needs; tell us the Kubernetes set-up and the workloads, and we will match the card to the sharing method.

FAQ