Documentation navigation
π₯οΈ Managing NVIDIA GPUs
βοΈ GPU Operator
The GPU operator is a Kubernetes operator that automates the management of NVIDIA GPUs in a cluster. It handles driver installation, monitoring, and enabling features like MIG mode.
π MIG Mode
MIG (Multi-Instance GPU) mode partitions a single physical GPU into multiple isolated instances, each with dedicated resources. This improves resource utilization when running multiple workloads on the same GPU.
π Supported GPU Models and MIG Profiles
Custom MIG configurations can also be added. See more in the Custom MIG configurations on Scaleway section below.
π Enabling MIG Mode
Prerequisites
Before enabling MIG mode, deploy the Node-feature-discovery (NFD) helm chart to the cluster. NFD is a Kubernetes add-on that detects hardware features and system configuration. See the upstream repository.
βοΈ AKS GPU Nodes
Deploy the GPU operator helm chart to the cluster.
GPU model-specific configuration may be required:
H100
No extra configuration needed β H100 GPUs support enabling MIG without a reboot.
A100
A100 GPUs require a reboot to enable MIG mode. Configure the GPU operator to allow rebooting the node:
gpu-operator:
migManager:
env:
- name: WITH_REBOOT
value: "true"
Reboot is only triggered as a fallback if MIG configuration fails.
Since the node will reboot, take the following steps beforehand to prevent scheduling issues:
-
Add a taint to prevent new workloads from being scheduled:
"nvidia.com/gpu:NoSchedule" -
Add the corresponding toleration to both the GPU operator and NFD charts, so they can still run on the tainted node:
- key: nvidia.com/gpu operator: Exists effect: NoSchedule
The GPU operator will remove the taint automatically once MIG is enabled and configured.
π§ Talos GPU Nodes
NVIDIA drivers
In Talos nodes, GPU drivers are pre-installed using the following system extensions (use -production for latest driver versions):
ghcr.io/siderolabs/nvidia-container-toolkit-production:<version>ghcr.io/siderolabs/nvidia-open-gpu-kernel-modules-production:<version>
See the Talos Linux Image Factory to find the correct extension versions for a specific Talos version.
As for all Talos nodes, our custom extensions are also needed:
ghcr.io/kommodity-io/kommodity-attestation-extension:v1.1.1(see releases)ghcr.io/kommodity-io/kommodity-autobootstrap-extension:v1.6.0(see releases)
Build the Talos image with the required extensions using this pipeline.
vLLM hosted models
The vLLM runtime needs to be configured with the correct CUDA driver version and library paths to work with the pre-installed NVIDIA drivers on Talos nodes.
As a rule of thumb, use latest driver versions with latest vLLM runtime version.
# Scaleway/Talos GPU cluster overrides
runtime:
# Required for CUDA 13.x / driver 595.58.03 on Scaleway H100 nodes
version: "v0.20.1"
env:
# Host glibc path must come first to load host CUDA driver
# before container compat libs to avoid driver mismatch errors
# There is a known discrepancy of driver locations between nodes on AKS and how we configure them on Talos
- name: LD_LIBRARY_PATH
value: "/usr/local/glibc/usr/lib:/usr/local/nvidia/lib64:/usr/local/cuda/lib64:/usr/lib/x86_64-linux-gnu"
GPU Operator and MIG
In Talos, GPU drivers are pre-installed at a non-standard path, so the GPU operator cannot manage MIG on these nodes.
Talos 1.13 now supports configuring NVIDIA GPUs via the gpu-operator. However, after some testing, it seems like the GPU operator is not able to manage MIG (see this issue).
Instead, deploy the following helm charts:
| Chart | Purpose |
|---|---|
| nvidia-dcgm-exporter | DaemonSet that collects GPU metrics and exposes them to Prometheus |
| nvidia-device-plugin | DaemonSets that manage GPU resources and expose them to Kubernetes; includes mig-manager |
The mig-manager DaemonSet is disabled by default in the nvidia-device-plugin chart. Enable it with:
deviceplugin:
migManager:
enabled: true
Limitation: MIG with reboot is not yet supported by mig-manager. Only H100 GPUs (which don't require a reboot) can be configured with this method.
π οΈ Configuring MIG on a GPU node
Apply the nvidia.com/mig.config label to a node to select a MIG configuration. The GPU operator or mig-manager will detect the label and apply it automatically.
# Creates 7 partitions of 1g.10gb each
nvidia.com/mig.config: 1g.10gb
Custom MIG configurations on Scaleway
On Scaleway we use a custom mig-manager (see mig-daemonset.yaml) that supports MIG configurations not natively available on the GPU nodes.
To add a custom MIG configuration:
- Add the configuration to
customConfigsin thenvidia-device-pluginvalues file:
customConfigs: |-
# Splits into 2 partitions: one 3g.40gb and one 4g.40gb
3g.40gb-4g.40gb:
devices:
- 3g.40gb: 1
- 4g.40gb: 1
Devices listed in customConfigs must be supported MIG profiles, otherwise mig-manager will fail to apply the configuration.
- Label the GPU node. For asymmetric configurations (unequal partition sizes), also add
nvidia.com/device-plugin.config: mig-mixed:
labels:
nvidia.com/mig.config: 3g.40gb-4g.40gb
nvidia.com/device-plugin.config: mig-mixed
ποΈ Scheduling GPU Workloads
Use a combination of taints/tolerations and labels/node selectors (or node affinity) to control GPU workload scheduling:
- Taints + tolerations β restrict non-GPU workloads from landing on GPU nodes.
- Labels + node selectors/affinity β force GPU workloads to land on GPU nodes.
Both are needed: tolerations alone permit scheduling on GPU nodes but don't guarantee it.
Naming conventions
Taints and labels encode the GPU model and MIG configuration using the following templates:
| Template | |
|---|---|
| Taint | workload=gpu-<gpu-model>[-mig-<mig-config>]:NoSchedule |
| Label (workload) | workload=gpu-<gpu-model>[-mig-<mig-config>] |
| Label (gpu-type) | gpu-type=<gpu-model>[mig<mig-config>] |
Examples:
| Scenario | Taint | workload label |
gpu-type label |
|---|---|---|---|
| H100, no MIG | workload=gpu-h100:NoSchedule |
workload=gpu-h100 |
gpu-type=h100 |
| H100, 7Γ1g partitions | workload=gpu-h100-mig-all-1:NoSchedule |
workload=gpu-h100-mig-all-1 |
gpu-type=h100migall1 |
| H100, 3g+4g partitions | workload=gpu-h100-mig-3-4:NoSchedule |
workload=gpu-h100-mig-3-4 |
gpu-type=h100mig34 |
π Taints and Tolerations
Taint the GPU node:
workload=gpu-h100-mig:NoSchedule
Add the corresponding toleration to the workload:
tolerations:
- key: "workload"
operator: "Equal"
value: "gpu-h100-mig"
effect: "NoSchedule"
π·οΈ Labels and Node Selectors
Label the GPU node:
workload: "gpu-h100-mig"
gpu-type: "h100mig"
Add the corresponding nodeSelector to the workload:
nodeSelector:
workload: "gpu-h100-mig"
gpu-type: "h100mig"
Don't use nodeSelector with labels added to nodes after creation (e.g. nvidia.com/gpu.product) β this would prevent the cluster autoscaler from scaling up the node pool. Use nodeAffinity instead (see below).
π― Node Affinity
Node affinity is more flexible than node selectors and is required for dynamically-applied labels like nvidia.com/gpu.product, which encodes the GPU model and MIG state:
# H100 with MIG disabled
nvidia.com/gpu.product: NVIDIA-H100-PCIe
# H100 with MIG enabled, 7 partitions of 1g.10gb
nvidia.com/gpu.product: NVIDIA-H100-PCIe-MIG-1g.10gb
Example node affinity targeting a specific GPU product:
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: nvidia.com/gpu.product
operator: In
values:
- NVIDIA-H100-PCIe