Kubernetes 1.36 passe le GPU en ressource partageable avec DRA en GA

Kubernetes 1.36, livré le 22 avril 2026, marque la fin d’une anomalie. Depuis 2017 et le device plugin NVIDIA, réserver un GPU sur un cluster se résumait à nvidia.com/gpu: 1 — un entier, sans attribut, sans visibilité sur le modèle, la mémoire ou la topologie. La Dynamic Resource Allocation (DRA), introduite en alpha dans la 1.26 et redesignée en 1.31, passe en disponibilité générale. Le GPU devient une ressource comme le CPU : mesurable, qualifiable, partageable.

Pour les équipes qui opèrent des clusters IA/ML et laissent 60 % de leur VRAM inutilisée faute d’outil de partitionnement natif, 1.36 est le signal : le device plugin est mort, DRA prend la main.

Avant DRA : un GPU = une case cochée

Le modèle historique est d’une simplicité brutale. Le device plugin expose les GPU comme un compteur entier par nœud. Un Pod demande nvidia.com/gpu: 1, le scheduler coche une case, et le Pod est placé — sans savoir s’il s’agit d’une A100 40 Go ou d’une H100 80 Go, sans notion de connectivité NVLink, sans capacité à réserver une fraction du GPU.

Les conséquences concrètes en production :

• Pas de topologie. Un job d’entraînement multi-GPU qui a besoin de NVLink entre ses 8 GPU est placé par heuristique, pas par logique planificatrice.
• Pas de partitionnement natif. Servir un modèle 7B sur une H100 80 Go gaspille 70 Go de VRAM. Le MIG (Multi-Instance GPU) existe côté matériel, mais le device plugin traite chaque partition comme un device distinct — configuration manuelle, nœuds spécialisés, cauchemar opérationnel.
• Pas de préemption. Un job batch basse priorité qui monopolise un GPU bloque un workload d’inférence urgent jusqu’à sa fin.
• Pas de gang scheduling. Un job distribué à 8 pods peut voir 7 pods Running et 1 Pending — 7 GPU immobilisés dans le vide.

Le device plugin a tenu dix ans. L’explosion des workloads IA en 2025-2026 l’a rendu structurellement inadapté.

DRA : comment ça marche

DRA introduit trois nouvelles ressources Kubernetes natives. ResourceClaim déclare les ressources dont un Pod a besoin — avec des attributs, pas des entiers. ResourceSlice annonce les ressources disponibles sur un nœud. DeviceClass définit la catégorie de matériel et le driver qui gère l’allocation.

Le scheduler évalue les contraintes en CEL (Common Expression Language) directement sur les attributs publiés par le driver. Plus de nœuds étiquetés à la main.

# ResourceClaim — Demander 2 GPU avec au moins 40 Go de VRAM
apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
  name: gpu-claim
  namespace: ml-training
spec:
  devices:
    requests:
    - name: gpu
      deviceClassName: nvidia-gpu
      count: 2
      selectors:
      - cel:
          expression: "device.attributes['gpu.nvidia.com'].memory.isGreaterThan(quantity('40Gi'))"

# DeviceClass — Définition de la classe GPU NVIDIA avec time-slicing
apiVersion: resource.k8s.io/v1
kind: DeviceClass
metadata:
  name: nvidia-gpu
spec:
  selectors:
  - cel:
      expression: "device.driver == 'gpu.nvidia.com'"
  config:
  - opaque:
      driver: gpu.nvidia.com
      parameters:
        apiVersion: gpu.nvidia.com/v1
        kind: GpuConfig
        sharing:
          strategy: TimeSlicing
          timeSlicingConfig:
            replicas: 4

# Pod d'inférence LLM utilisant DRA
apiVersion: v1
kind: Pod
metadata:
  name: llm-inference
spec:
  containers:
  - name: inference
    image: vllm/vllm-openai:latest
    resources:
      claims:
      - name: gpu
        request: gpu
  resourceClaims:
  - name: gpu
    resourceClaimName: gpu-claim

La différence avec nvidia.com/gpu: 1 est radicale. Le scheduler Kubernetes sait désormais qu’un Pod a besoin d’une H100 avec 80 Go de VRAM et lien NVLink avec les Pods voisins — et il place en conséquence.

GPU sharing : MIG, time-slicing et devices partitionnables

La fonctionnalité la plus attendue est le support natif du partitionnement GPU. La 1.36 passe les Partitionable Devices en beta — le découpage d’un accélérateur physique en instances logiques devient une primitive DRA.

Concrètement, cela couvre trois stratégies :

• MIG natif. Le driver NVIDIA DRA alloue automatiquement une partition MIG au profil demandé (1g.10gb, 2g.20gb, etc.) sans configuration manuelle sur le nœud. Un Pod déclare son besoin en profil ; le driver provisionne.
• Time-slicing. Plusieurs Pods partagent le même GPU par multiplexage temporel, avec une configuration déclarative dans la DeviceClass (replicas: 4 = 4 tranches temporelles).
• Prioritized List. Un Pod peut exprimer une préférence dégressive : « H100 d’abord, A100 en fallback ». Le scheduler évalue dans l’ordre, améliorant le taux d’occupation.

# ResourceClaim avec fallback priorisé
spec:
  devices:
    requests:
    - name: gpu
      deviceClassName: nvidia-gpu
      firstAvailable:
      - count: 2
        selectors:
        - cel:
            expression: "device.attributes['gpu.nvidia.com'].productName.startsWith('H100')"
      - count: 2
        selectors:
        - cel:
            expression: "device.attributes['gpu.nvidia.com'].productName.startsWith('A100')"

Les Device Taints (beta en 1.36) complètent le tableau : un administrateur peut tainter un GPU défaillant pour le retirer du pool d’allocation, ou réserver un sous-ensemble de GPU à une équipe spécifique — exactement comme les taints au niveau nœud.

NVIDIA donne son driver DRA à la CNCF

À KubeCon Europe 2026, NVIDIA a fait un geste structurant : le don du driver DRA GPU à la CNCF. Le driver, déjà open source, passe sous gouvernance neutre — un signal fort pour AMD, Intel et les autres fondeurs.

Le driver assure trois fonctions. Il découvre le matériel GPU sur chaque nœud et publie les attributs structurés (mémoire, compute capability, topologie NVLink, profils MIG) dans l’API Kubernetes. Il traite les ResourceClaim en liant chaque claim à une instance GPU physique. Il configure automatiquement les partitions MIG et le Fabric Manager quand un claim l’exige.

Ce que ça change pour les opérateurs : plus besoin de scripts de labellisation ad-hoc, plus de nœuds spécialisés par modèle de GPU, plus de configuration MIG manuelle. Le scheduler voit le matériel tel qu’il est.

L’impact réel : moins de gaspillage, plus de densité

Le passage de l’allocation binaire à l’allocation attribuée a un effet direct sur les coûts. Un cluster de 32 H100 80 Go qui tourne à 40 % d’occupation VRAM parce que des workloads 7B monopolisent des GPU entiers peut, avec le time-slicing et le MIG natif, doubler sa densité de workloads — sans ajouter un seul GPU.

Le gang scheduling via KAI Scheduler (projet open source NVIDIA complémentaire à DRA) élimine le problème des jobs distribués partiellement ordonnancés : tous les pods d’un job démarrent ensemble ou aucun ne démarre. Les 7 GPU qui attendaient le huitième pod sont rendus au pool.

Les Resource Health Status (beta en 1.36) exposent l’état de santé des devices directement dans le statut du Pod — plus besoin de plonger dans les logs driver pour savoir si un GPU est tombé.

La check-list d’adoption

1. Auditer l’existant. kubectl describe nodes | grep nvidia.com/gpu — tout Pod utilisant encore nvidia.com/gpu est candidat à la migration.
2. Installer le driver DRA. Helm chart NVIDIA nvidia-dra-driver dans le namespace nvidia-dra. Le driver tourne en parallèle du device plugin historique — migration progressive possible.
3. Définir les DeviceClass. Une classe par stratégie de partage (time-slicing, MIG, passthrough). Les Pods choisissent leur classe via le deviceClassName dans le ResourceClaim.
4. Migrer workload par workload. Commencer par les charges d’inférence (bénéfice immédiat du partage), puis les jobs d’entraînement (bénéfice de la topologie).
5. Déployer un scheduler batch si nécessaire. KAI Scheduler pour le gang scheduling et la fair-share queue ; DRA seul suffit pour les clusters à faible contention.

Le verdict

Kubernetes 1.36 n’est pas une release anecdotique — c’est la release qui fait entrer le GPU dans l’ère du cloud-native au même titre que le CPU et la mémoire.

DRA en GA signifie que le scheduler comprend enfin ce qu’est un GPU. Le device plugin NVIDIA a tenu une décennie ; il est temps de le mettre au musée. Si vous gérez des clusters GPU en production, la question n’est pas de savoir si vous devez migrer — mais quand. Chaque mois passé avec nvidia.com/gpu: 1 est un mois de VRAM payée et inutilisée.

Commencez par les workloads d’inférence, déployez le driver DRA en parallèle, et planifiez la migration complète avant 1.38. Le GPU partageable n’est plus une promesse — c’est une primitive Kubernetes.

Références

• Kubernetes v1.36: DRA Updates, Kubernetes Blog, 7 mai 2026.
• Complete Guide to Kubernetes 1.36: DRA GA, DEV Community, avril 2026.
• Kubernetes GPU Orchestration in 2026: DRA, KAI Scheduler, and Grove, Spheron Blog, 2026.
• Dynamic Resource Allocation, documentation Kubernetes.
• NVIDIA DRA Driver for GPU, GitHub.
• KAI Scheduler, GitHub.