Kubernetes 1.35 : le Dynamic Resource Allocation passe en beta pour les GPU

Docker Compose vers Kubernetes 1.35 "Timbernetes" marque un tournant stratégique dans l'écosystème cloud-native : le Dynamic Resource Allocation (DRA) pour les cluster Mac Studio pour IA passe en beta, consolidant la position de Kubernetes comme plateforme de référence pour les workloads d'intelligence artificielle à grande échelle. Avec l'explosion des "AI factories" et des pipelines de machine learning distribués, la gestion fine des accélérateurs matériels devient critique.

Alors que les device plugins traditionnels montrent leurs limites en termes de flexibilité et de granularité, le DRA propose une approche déclarative et extensible pour orchestrer non seulement les GPU NVIDIA, mais aussi les TPU, FPGA et autres accélérateurs spécialisés. Cette évolution technique répond à un besoin opérationnel majeur : comment partager efficacement des ressources matérielles coûteuses entre des dizaines de pods d'entraînement et d'inférence tout en garantissant isolation et performance ?

Kubernetes et l'ère de l'IA : pourquoi le DRA change la donne

Depuis Kubernetes 1.8, les device plugins permettaient de gérer les GPU comme des ressources countables. Le problème : cette approche reste rigide. Un pod demande "1 GPU" ou "2 GPU", sans pouvoir spécifier des contraintes topologiques complexes comme "deux GPU partageant la même NVLink" ou "un GPU avec au moins 40 GB de VRAM sur un nœud avec InfiniBand".

Le Dynamic Resource Allocation résout ce problème en déplaçant la logique de gestion des ressources hors du core de Kubernetes vers des drivers externes. Au lieu d'une simple quantité, le DRA utilise des structured parameters qui permettent d'exprimer des requêtes sophistiquées. Kubernetes 1.34 a fait passer le DRA en GA (General Availability) pour les API de base, et la version 1.35 ajoute des features critiques :

• BindingConditions (beta) : gestion des GPU qui nécessitent un temps de setup (connexion fabric, initialisation firmware)
• Prioritised alternatives (beta) : définir plusieurs configurations GPU acceptables par ordre de préférence
• Device Taints and Tolerations (alpha) : marquer certains GPU comme réservés ou dégradés
• Partitionable Devices (alpha) : découper un GPU en slices (MIG sur NVIDIA A100/H100)
• Consumable Capacity (alpha) : tracking de ressources consommables comme la bande passante PCIe

Ces fonctionnalités transforment Kubernetes en orchestrateur capable de gérer des clusters d'IA de milliers de GPU avec une granularité digne d'un HPC scheduler classique, tout en conservant la philosophie cloud-native. Pour comprendre l'impact sur vos pipelines, consultez notre guide Kubernetes en production.

Qu'est-ce que le Dynamic Resource Allocation exactement ?

Le DRA introduit trois nouvelles ressources Kubernetes natives :

1. DeviceClass : définit un type de ressource matérielle (ex: "GPU NVIDIA H100 80GB") avec ses paramètres et son driver associé
2. ResourceClaim : demande d'allocation d'une ressource, similaire à un PersistentVolumeClaim pour le stockage
3. ResourceClaimTemplate : template pour créer automatiquement des claims par pod dans un Deployment ou StatefulSet

Contrairement aux device plugins où le kubelet gère tout localement, le DRA fonctionne via un modèle driver-based :

┌─────────────────────┐
│   Pod avec claim    │
│  resourceClaims:    │
│   - name: my-gpu    │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│  ResourceClaim      │
│  deviceClassName:   │
│   gpu.nvidia.com    │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│   DRA Controller    │
│  (nvidia-dra-driver)│
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│  Kubelet Plugin     │
│  (setup GPU sur     │
│   le nœud)          │
└─────────────────────┘

Le scheduler Kubernetes traite les claims comme des contraintes de placement. Si un pod requiert un claim qui nécessite un GPU H100, le scheduler ne placera ce pod que sur des nœuds équipés de ce matériel. Une fois le pod schedulé, le DRA controller communique avec le kubelet pour configurer l'accès au GPU (device mapping, cgroups, permissions).

Nouveautés Kubernetes 1.35 : beta features pour les GPU

BindingConditions : gérer l'asynchronisme matériel

Certains GPU enterprise nécessitent une phase d'initialisation après allocation : établissement de connexions NVLink entre GPU, configuration de GPU fabric managers, ou warm-up de firmware. Avant Kubernetes 1.35, le kubelet démarrait le pod immédiatement après l'allocation, ce qui causait des crashs si le GPU n'était pas prêt.

Les BindingConditions permettent au driver DRA de signaler "allocation réussie, mais GPU pas encore prêt". Le kubelet attend alors que la condition passe à Ready avant de lancer les containers. Cela améliore drastiquement la fiabilité sur des workloads IA avec des GPU haut de gamme (NVIDIA H100, AMD MI300) qui peuvent nécessiter 10-30 secondes de setup.

Prioritised alternatives : fallback automatique

Imaginez un pod d'entraînement qui préfère 8x H100 avec NVLink, mais peut fonctionner avec 8x A100 ou même 16x V100. Avec le DRA en beta, vous pouvez exprimer cette préférence :

deviceRequests:
  - name: training-gpus
    allocationMode: ExactCount
    count: 8
    alternatives:
      - selector: gpu.nvidia.com/model=H100
        priority: 100
      - selector: gpu.nvidia.com/model=A100
        priority: 50
      - selector: gpu.nvidia.com/model=V100
        count: 16  # Fallback avec plus de GPU
        priority: 10

Le scheduler tente d'abord l'option priorité 100. Si aucun nœud ne satisfait cette contrainte, il essaie priorité 50, et ainsi de suite. Cela optimise l'utilisation du cluster en évitant que des pods restent en Pending alors que des GPU alternatifs sont disponibles.

Device Taints and Tolerations

Emprunté au mécanisme node taints/tolerations, cette feature permet de marquer des GPU individuels. Cas d'usage :

• GPU en dégradation détecté par monitoring (température élevée, erreurs ECC) → taint "degraded=true:NoSchedule"
• Réservation de GPU pour une équipe spécifique → taint "team=ml-research:NoSchedule"
• GPU avec firmware spécifique requis pour certains workloads

Les pods doivent alors inclure une toleration explicite pour utiliser ces GPU taintés, offrant un contrôle fin au niveau device, pas seulement au niveau nœud.

Partitionable Devices : MIG et GPU virtuels

NVIDIA Multi-Instance GPU (MIG) permet de découper un A100 ou H100 en jusqu'à 7 instances isolées. Le DRA alpha dans Kubernetes 1.35 expose cette capacité nativement. Une DeviceClass peut définir des "partitions" :

apiVersion: resource.k8s.io/v1alpha3
kind: DeviceClass
metadata:
  name: nvidia-h100-mig-3g.40gb
spec:
  selectors:
    - cel:
        expression: device.driver == "gpu.nvidia.com"
  config:
    opaque:
      driver: gpu.nvidia.com
      parameters:
        apiVersion: gpu.nvidia.com/v1alpha1
        kind: MIGDeviceClaimParameters
        profile: 3g.40gb  # Profil MIG : 3 GPU slices, 40 GB VRAM
        sharing:
          strategy: TimeSlicing  # Ou MPS pour partage fin

Cela permet de faire tourner 7 pods d'inférence sur un seul H100 physique, chacun avec sa slice MIG isolée. Idéal pour maximiser l'utilisation GPU sur des workloads d'inférence légers. Pour le contexte de déploiement, voir notre article sur Docker en production.

Configuration DRA pour GPU : exemple pratique

Déployons un cluster Kubernetes 1.35 avec NVIDIA DRA driver pour gérer des GPU H100 en mode DRA complet.

1. Prérequis infrastructure

# Nœuds avec GPU NVIDIA + drivers installés
# Container runtime compatible (containerd 1.7+, cri-o 1.28+)
# Kubernetes 1.35+ avec feature gate DynamicResourceAllocation=true

# Vérifier support DRA
kubectl api-resources | grep "resource.k8s.io"
# Doit afficher : deviceclasses, resourceclaims, resourceclaimtemplates

2. Installation du NVIDIA DRA driver

# Installer l'opérateur NVIDIA GPU
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/gpu-operator/v24.9.0/deployments/gpu-operator.yaml

# Déployer le DRA driver (remplace nvidia-device-plugin)
helm repo add nvidia https://nvidia.github.io/k8s-dra-driver
helm repo update
helm install nvidia-dra-driver nvidia/k8s-dra-driver \
  --namespace nvidia-dra-system \
  --create-namespace \
  --set enableDRA=true \
  --set enableDevicePlugin=false  # Désactive l'ancien mode

3. Créer une DeviceClass pour H100

apiVersion: resource.k8s.io/v1beta2
kind: DeviceClass
metadata:
  name: nvidia-h100-80gb
spec:
  selectors:
    - cel:
        expression: 'device.driver == "gpu.nvidia.com" && device.attributes["gpu.nvidia.com/model"] == "H100"'
  config:
    opaque:
      driver: gpu.nvidia.com
      parameters:
        apiVersion: gpu.nvidia.com/v1alpha1
        kind: GpuClaimParameters
        sharing:
          strategy: None  # GPU exclusif, pas de partage
        memory: "80Gi"  # VRAM minimum
        topology:
          nvlink: "required"  # Exige NVLink entre GPU si count > 1

4. ResourceClaimTemplate pour un Deployment ML

apiVersion: resource.k8s.io/v1beta2
kind: ResourceClaimTemplate
metadata:
  name: training-gpu-claim
  namespace: ml-team
spec:
  spec:
    deviceClassName: nvidia-h100-80gb
    allocationMode: ExactCount
    count: 2  # 2 GPU par pod
    constraints:
      - matchAttribute: "gpu.nvidia.com/nvlink-domain"
        # Les 2 GPU doivent être dans le même domaine NVLink
        operator: Equal

5. Utiliser le claim dans un Pod PyTorch

apiVersion: v1
kind: Pod
metadata:
  name: pytorch-distributed-training
  namespace: ml-team
spec:
  resourceClaims:
    - name: gpus
      resourceClaimTemplateName: training-gpu-claim

  containers:
    - name: trainer
      image: pytorch/pytorch:2.5.0-cuda12.4-cudnn9-runtime
      command: ["python", "train.py"]
      env:
        - name: NVIDIA_VISIBLE_DEVICES
          value: "DRA"  # Signale au runtime d'utiliser DRA

      resources:
        claims:
          - name: gpus  # Référence au resourceClaim
        limits:
          memory: "64Gi"
          cpu: "16"

  restartPolicy: OnFailure

Une fois déployé, vérifiez l'allocation :

# Status du claim
kubectl get resourceclaim -n ml-team
kubectl describe resourceclaim training-gpu-claim-pytorch-distributed-training-xxxxx

# Logs du DRA controller
kubectl logs -n nvidia-dra-system deploy/nvidia-dra-controller

# Devices alloués visibles dans le pod
kubectl exec -it pytorch-distributed-training -- nvidia-smi

Le scheduler a automatiquement placé le pod sur un nœud avec 2x H100 connectés en NVLink, conformément aux contraintes du claim. Pour gérer le déploiement en production, référez-vous à notre guide Terraform pour Kubernetes.

Impact sur les pipelines ML : du développement à la production

Isolation et multi-tenancy renforcés

Avec le DRA, chaque équipe ML peut avoir ses propres DeviceClasses avec quotas et contraintes. Un namespace "ml-research" peut autoriser des claims de 8 GPU max, tandis que "ml-production" peut aller jusqu'à 64 GPU pour l'entraînement de LLM. Les ResourceQuotas Kubernetes s'appliquent aux claims :

apiVersion: v1
kind: ResourceQuota
metadata:
  name: ml-research-quota
  namespace: ml-research
spec:
  hard:
    count/resourceclaims: "10"  # Max 10 claims actifs
    nvidia-h100-80gb.resource.k8s.io/count: "16"  # Max 16 GPU H100 total

Scheduling intelligent pour workloads hétérogènes

Un cluster typique d'IA mixe plusieurs types de workloads :

• Entraînement de modèles : 8-64 GPU, haute bande passante NVLink, durée 12-72h
• Fine-tuning : 1-4 GPU, moins exigeant en inter-GPU, durée 2-8h
• Inférence batch : 1-2 GPU, peut tolérer MIG ou GPU partagés
• Inférence temps réel : 1 GPU MIG slice, latence critique

Le DRA permet de définir des DeviceClasses adaptées à chaque cas d'usage. Le scheduler peut bin-pack efficacement : des pods d'inférence MIG sur des nœuds partiellement utilisés, et réserver des nœuds entiers pour du training distribué. Cela améliore significativement le taux d'utilisation GPU par rapport aux device plugins classiques, selon les benchmarks NVIDIA.

Gestion du cycle de vie : draining et maintenance

Drainer un nœud GPU en production devient plus propre. Avec les device plugins, un kubectl drain évictait brutalement les pods. Avec le DRA, le controller peut :

1. Marquer les GPU du nœud avec un taint "maintenance=true:NoSchedule"
2. Attendre que les pods d'entraînement en cours checkpointent (via PreStop hooks)
3. Libérer progressivement les claims
4. Signaler au nœud qu'il peut être mis hors ligne

Cette approche réduit les pertes de travail sur des entraînements de plusieurs jours. Pour les stratégies de mise à jour, voir nos optimisations Nginx en production qui partagent des patterns similaires.

Monitoring GPU avec Prometheus : métriques DRA-aware

Le DRA expose de nouvelles métriques via le standard OpenTelemetry et Prometheus. NVIDIA DCGM (Data Center GPU Manager) s'intègre nativement avec le DRA driver.

Déploiement du stack de monitoring

# Installer DCGM exporter avec support DRA
helm repo add nvidia https://nvidia.github.io/dcgm-exporter/helm-charts
helm install dcgm-exporter nvidia/dcgm-exporter \
  --namespace monitoring \
  --set serviceMonitor.enabled=true \
  --set arguments=["--dra-enabled", "--collect-interval=5000"]

# Prometheus découvre automatiquement les exporters via ServiceMonitor
# Vérifier les targets
kubectl port-forward -n monitoring svc/prometheus 9090:9090
# http://localhost:9090/targets → dcgm-exporter endpoints

Métriques clés DRA

Les métriques exposées incluent :

# Utilisation GPU par claim
DCGM_FI_DEV_GPU_UTIL{resourceclaim="training-gpu-claim-xxxxx", namespace="ml-team", pod="pytorch-training-0", gpu="0"}

# VRAM utilisée vs allouée par claim
DCGM_FI_DEV_FB_USED{resourceclaim="...", gpu="0"}
DCGM_FI_DEV_FB_RESERVED{resourceclaim="...", gpu="0"}

# Throughput NVLink entre GPU d'un même claim
DCGM_FI_PROF_NVLINK_TX_BYTES{resourceclaim="...", gpu_pair="0-1"}

# Violations de contraintes DRA (ex: température GPU > seuil)
dra_constraint_violations_total{deviceclass="nvidia-h100-80gb", constraint="temperature"}

# Temps d'allocation DRA (BindingConditions)
dra_allocation_duration_seconds{deviceclass="nvidia-h100-80gb", phase="binding"}

Dashboard Grafana pour DRA

Créez un dashboard centré sur les claims plutôt que les nœuds :

# Panel : GPU utilization par ResourceClaim
avg by (resourceclaim, namespace) (DCGM_FI_DEV_GPU_UTIL)

# Panel : Efficacité d'allocation (GPU utilisés / GPU alloués dans le cluster)
sum(DCGM_FI_DEV_GPU_UTIL > 10) / sum(kube_node_status_allocatable{resource="nvidia_com_gpu"}) * 100

# Panel : Durée moyenne d'allocation DRA
histogram_quantile(0.95, sum(rate(dra_allocation_duration_seconds_bucket[5m])) by (le, deviceclass))

# Alert : Claim en pending trop longtemps
ALERT DRAClaimPendingTooLong
  IF kube_resourceclaim_status_allocation_state{state="pending"} > 300
  FOR 5m
  ANNOTATIONS {
    summary = "ResourceClaim {{ $labels.resourceclaim }} pending > 5min",
    description = "Possible manque de GPU {{ $labels.deviceclass }} dans le cluster"
  }

Pour une configuration complète de monitoring Kubernetes, consultez notre guide Prometheus et Grafana en production et l'article sur les métriques Linux en production.

Observabilité des workloads IA

Couplé avec des outils comme MLflow ou Weights & Biases, le monitoring DRA permet de corréler performance ML et utilisation GPU :

# Exemple : tracer GPU util vs training loss
# Dans le code PyTorch, logger les métriques DRA
import prometheus_client as prom

gpu_util_gauge = prom.Gauge('training_gpu_util', 'GPU utilization during training', ['epoch', 'claim'])

for epoch in range(num_epochs):
    # ... training loop ...

    # Récupérer les métriques GPU du claim
    gpu_util = get_claim_gpu_metrics()  # Via Prometheus API ou DCGM
    gpu_util_gauge.labels(epoch=epoch, claim=os.getenv('CLAIM_NAME')).set(gpu_util)

    # Logger training loss
    wandb.log({'loss': loss, 'gpu_util': gpu_util, 'epoch': epoch})

Cela révèle des insights précieux : si GPU util tombe à 30% pendant certaines étapes du training, cela indique un bottleneck I/O ou CPU qui gaspille du temps GPU coûteux.

Migration depuis les device plugins : stratégie progressive

Migrer un cluster GPU de production vers le DRA nécessite une approche progressive pour éviter les interruptions.

Phase 1 : Dual-stack (semaines 1-2)

# Garder nvidia-device-plugin actif
kubectl get daemonset -n kube-system nvidia-device-plugin-daemonset

# Installer le DRA driver en parallèle
helm install nvidia-dra-driver nvidia/k8s-dra-driver \
  --set coexistWithDevicePlugin=true

# Les pods existants continuent d'utiliser resources.limits.nvidia.com/gpu
# Nouveaux workloads testent le DRA sur une DeviceClass dédiée
kubectl apply -f deviceclass-test.yaml

Phase 2 : Migration par namespace (semaines 3-6)

Migrez namespace par namespace, en commençant par dev/staging :

# Namespace ml-dev : interdire l'ancien mode
kubectl label namespace ml-dev gpu-mode=dra-only

# AdmissionWebhook rejette les pods avec resources.limits.nvidia.com/gpu dans ce namespace
# Force l'utilisation de resourceClaims

# Mettre à jour les Deployments/StatefulSets
# Avant :
resources:
  limits:
    nvidia.com/gpu: 2

# Après :
resourceClaims:
  - name: gpus
    resourceClaimTemplateName: ml-dev-gpu-claim
resources:
  claims:
    - name: gpus

Phase 3 : Désactivation du device plugin (semaine 7+)

Une fois tous les namespaces migrés :

# Vérifier qu'aucun pod n'utilise l'ancien mode
kubectl get pods --all-namespaces -o json | \
  jq '.items[] | select(.spec.containers[].resources.limits["nvidia.com/gpu"] != null) | .metadata.name'

# Si vide, désactiver le device plugin
kubectl delete daemonset -n kube-system nvidia-device-plugin-daemonset

# Retirer la feature gate legacy
# Dans kube-apiserver et kubelet flags :
--feature-gates=DevicePlugins=false

Rollback plan

Gardez un plan B en cas de régression critique :

1. Snapshot etcd avant chaque phase
2. Conserver les manifests device plugin dans Git
3. Script de rollback automatique si taux d'erreur pod > seuil
4. Canary deployments : 10% des pods en DRA, monitorer 48h avant scale-up

Limitations et roadmap DRA

Bien que Kubernetes 1.35 apporte des avancées majeures, certaines limites persistent :

• Pas de live migration : un pod ne peut pas migrer son claim vers un autre nœud sans redémarrage
• Snapshots GPU non supportés : impossible de checkpoint l'état VRAM d'un GPU pour migration
• Quota dynamique limité : les quotas restent statiques, pas d'auto-scaling de quotas GPU
• Multi-cluster DRA inexistant : pas de fédération de claims entre clusters Kubernetes

La roadmap Kubernetes 1.36-1.37 prévoit :

• DRA pour d'autres ressources : réseau (SmartNIC, RDMA), stockage (NVMe-oF), mémoire (CXL)
• Intégration avec Cluster Autoscaler : provisionner automatiquement des nœuds GPU selon les claims pending
• Cost-aware scheduling : choisir le GPU le moins cher satisfaisant les contraintes (cloud multi-provider)
• GPU time-slicing natif : partage temporel fin sans MIG, pour GPU consumer

Pour suivre le développement, consultez le KEP 4381 et le SIG Node.

Conclusion : Kubernetes, infrastructure des AI factories

Kubernetes 1.35 confirme la transformation de K8s d'orchestrateur de containers généraliste vers la plateforme de référence pour l'IA distribuée. Le passage du DRA GPU en beta supprime une friction majeure pour les équipes ML : gérer manuellement l'allocation de GPU via des scripts custom ou des systèmes HPC legacy comme SLURM.

L'approche déclarative du DRA s'aligne parfaitement avec la philosophie GitOps : toute la configuration GPU (DeviceClasses, quotas, constraints) est versionnée en YAML, auditable, et reproductible. Couplé à des outils comme ArgoCD ou Flux, vous pouvez déployer des environnements ML complets en quelques minutes.

Pour les organisations opérant des clusters GPU à grande échelle (100+ GPU), les gains sont tangibles :

• Amélioration significative de l'utilisation GPU grâce au scheduling intelligent et MIG
• Réduction du temps de debugging d'allocation avec l'observabilité DRA
• Réduction des coûts cloud par optimisation du bin-packing GPU
• Accélération du time-to-production pour les nouveaux projets ML

Si vous démarrez un nouveau cluster GPU, adoptez directement le DRA. Si vous avez un cluster existant avec device plugins, planifiez la migration sur Q2 2026 pour profiter des features beta stabilisées. Kubernetes 1.36 (prévu avril 2026, sortie le 22 avril) devrait voir plusieurs de ces features passer en stable.

L'ère des "AI factories" ne fait que commencer, et Kubernetes s'impose comme le système d'exploitation de cette révolution. Pour approfondir la containerisation, explorez nos ressources sur Docker et nos retours d'expérience en production.

FAQ : Dynamic Resource Allocation et GPU dans Kubernetes