How to Enable MIG on Kubernetes: A Step-by-Step Guide

This walks through enabling NVIDIA MIG on a Kubernetes cluster using the NVIDIA GPU Operator — the standard path most teams take, regardless of which cloud or bare-metal provider you're running on. It assumes you're on MIG-capable hardware (A100, H100, or H200) and already have a working Kubernetes cluster.

If you'd rather not run this yourself, this is exactly the kind of setup we handle as a managed service — but the steps below are the real thing if you want to do it yourself.

Before you start: check compatibility

Not every GPU supports MIG. Confirm your hardware first:

• Supported: A100, H100, H200, and newer Blackwell/Hopper-generation datacenter GPUs.
• Not supported: RTX 4090, L40S, T4, V100, and most consumer/prosumer cards. If you're on one of these, use time-slicing instead.

Step 1: Install the NVIDIA GPU Operator with a MIG strategy

The GPU Operator installs drivers, the device plugin, and the mig-manager component in one pass. You choose a MIG strategy at install time:

• single — every MIG-capable GPU on a node uses the same partition geometry.
• mixed — use this if MIG mode isn't enabled on all GPUs on a node, or you want different partition shapes per GPU.

helm install --wait --generate-name \
  -n gpu-operator --create-namespace \
  nvidia/gpu-operator \
  --set mig.strategy=single

Cloud provider note: on CSP-managed Kubernetes (GKE, EKS, AKS, and similar), you typically also need to force a node reboot for the MIG mode change to apply cleanly:

--set migManager.env[0].name=WITH_REBOOT \
--set-string migManager.env[0].value=true

Skipping this is one of the most common reasons MIG "doesn't seem to enable" on managed Kubernetes — the mode change silently fails to take effect without the reboot flag.

Step 2: Label the node with your desired MIG configuration

By default, nodes come labeled nvidia.com/mig.config: all-disabled. You need to explicitly apply a configuration:

kubectl label node <node-name> nvidia.com/mig.config=all-1g.5gb --overwrite

The mig-manager watches for this label, cordons the node, terminates any running GPU pods, and applies the geometry. No user workloads can be running on the GPU while this happens — plan this as a maintenance-window operation, not a live change.

Step 3: Verify the partition applied

Once the node comes back, check the GPU Operator pods are healthy:

kubectl get pods -n gpu-operator

Then exec into the driver container and confirm the partitions exist:

nvidia-smi -L

You should see output like:

GPU 0: A100-SXM4-40GB (UUID: GPU-5c89852c-...)
  MIG 1g.5gb Device 0: (UUID: MIG-GPU-5c89852c-.../7/0)
  MIG 1g.5gb Device 1: (UUID: MIG-GPU-5c89852c-.../8/0)
  ...

Seven 1g.5gb slices on an A100, in this example — one physical GPU now scheduling as seven independent devices.

Step 4: Schedule workloads against MIG devices

Once partitions exist, Kubernetes schedules pods against them like any other resource request:

resources:
  limits:
    nvidia.com/mig-1g.5gb: 1

The gotcha almost every team hits: MIG doesn't persist across reboots

This is the detail most tutorials leave out, and it's the one that causes production incidents. MIG partitions are not retained if the GPU or node resets. If a node reboots — for maintenance, an autoscaler event, or a crash — you need to recreate the MIG geometry from scratch. It doesn't come back on its own.

The fix is to automate this rather than do it manually every time:

• Use the mig-parted tool's systemd service integration to reapply the configuration automatically at node startup.
• Or, if you're using the GPU Operator's mig-manager, make sure the node label persists (it usually does, since labels are stored in the Kubernetes API, not on the node) so mig-manager reapplies it automatically when the node rejoins the cluster.

Either way — test a node reboot in staging before you rely on MIG in production. This is the single most common cause of "MIG was working yesterday" tickets.

Monitoring your MIG instances

Once MIG is running, you want per-instance visibility — utilization, memory, and errors *per partition*, not just per physical GPU. NVIDIA recommends DCGM (v2.0.13+) for this, since standard nvidia-smi polling doesn't give you the per-instance attribution you need to know which workload is actually using which slice.

See our GPU Observability guide for how to set this up.

Enabling MIG correctly — including the reboot handling and persistence automation — is exactly the kind of operational detail that's easy to get 80% right and then get paged for at 2am when it's the 20% that matters. Talk to us if you'd rather have this managed, or run your config through our cost calculator to see what managed MIG costs on top of your existing provider.