Si tu gères des nœuds GPU sur un cluster Kubernetes, tu connais sûrement la mécanique historique : déclarer nvidia.com/gpu comme ressource étendue, poser des labels et des taints sur les nœuds, et croiser les doigts pour que le scheduler place correctement les pods. Ça fonctionne, mais ça reste rigide — impossible d’exprimer finement « je veux un GPU avec au moins 20 Gio de VRAM » ou « je préfère telle référence, mais telle autre fera l’affaire ». C’est précisément ce que corrige la Dynamic Resource Allocation (DRA), passée en disponibilité générale avec Kubernetes 1.35. Voici ce qu’elle change concrètement pour toi.
Le problème avec l’ancien modèle
Le mécanisme des ressources étendues (resources.requests/resources.limits avec nvidia.com/gpu: 1) traite un GPU comme un simple compteur, sans notion de caractéristiques du matériel. Résultat : pour cibler un type de GPU précis, tu dois passer par des nodeSelector ou des règles d’affinité, ce qui t’oblige à colocaliser des types de matériel spécifiques sur des nœuds dédiés et à maintenir ce mapping à la main. Dès que ton parc GPU devient hétérogène (T4, A100, H100 mélangés), ça devient vite ingérable.
Dynamic Resource Allocation, en résumé
Introduite en alpha dès Kubernetes 1.30, la Dynamic Resource Allocation a atteint la disponibilité générale avec Kubernetes 1.35 : le feature gate DynamicResourceAllocation est désormais verrouillé et ne peut plus être désactivé, ce qui en fait un mécanisme désormais considéré comme stable et recommandé pour piloter du matériel spécialisé (GPU, TPU, FPGA…).
ResourceClaim et ResourceClaimTemplate
Un ResourceClaim représente une demande de ressource matérielle faite par un pod — l’équivalent d’un PersistentVolumeClaim, mais pour du matériel plutôt que du stockage. Un ResourceClaimTemplate permet de générer ces claims automatiquement à partir d’un modèle, exactement comme un PodTemplate génère des pods.
DeviceClass et ResourceSlice
Une DeviceClass définit les caractéristiques et sélecteurs d’une famille de matériels (par exemple, « tous les GPU NVIDIA de la classe compute 8.0+ »). Une ResourceSlice, elle, est publiée par le driver de ressource pour annoncer l’inventaire disponible sur chaque nœud — le scheduler s’appuie dessus pour prendre ses décisions de placement.
# Exemple simplifié : une DeviceClass ciblant des GPU avec au moins 20 Gio de VRAM
apiVersion: resource.k8s.io/v1
kind: DeviceClass
metadata:
name: gpu-20gb-minimum
spec:
selectors:
- cel:
expression: "device.attributes['gpu.nvidia.com'].memory.compareTo(quantity('20Gi')) >= 0"
---
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
name: gpu-claim-template
spec:
spec:
devices:
requests:
- name: gpu
deviceClassName: gpu-20gb-minimum
Ce que ça change concrètement pour toi
Une sélection fine, exprimée en CEL
Plutôt que de jongler avec des labels de nœuds, tu exprimes tes contraintes matérielles directement via des expressions CEL (Common Expression Language) qui examinent les attributs et la capacité des devices. Tu peux aussi exprimer des préférences classées (firstAvailable) : privilégier un GPU A5000, et accepter un T4 si aucun A5000 n’est disponible — sans avoir à écrire deux DeploymentSpec différents.
Le partage de GPU devient natif
DRA supporte plusieurs pods (ou plusieurs conteneurs d’un même pod) partageant un même GPU via ResourceClaim, ainsi que du time slicing pour faire tourner plusieurs charges sur une seule carte — utile pour des environnements de développement ou de test où monopoliser un GPU entier par pod serait du gaspillage.
Et sur AKS ?
À ce jour, les stratégies de partitionnement GPU documentées pour AKS reposent encore principalement sur le modèle historique : ressources étendues nvidia.com/gpu, combinées à du MIG (partitionnement matériel), du time-slicing ou du MPS via le NVIDIA GPU Operator. DRA étant un mécanisme du cœur de Kubernetes, sa disponibilité effective sur AKS dépend de la version de Kubernetes du cluster et du support du driver NVIDIA associé — vérifie les notes de version AKS avant de migrer une charge de production, et commence par un nodepool de test si tu veux évaluer DRA dès maintenant.
FAQ
DRA remplace-t-il complètement le device plugin NVIDIA ?
Pas immédiatement : les deux modèles peuvent coexister le temps de la transition. Mais DRA est désormais la direction recommandée par le projet Kubernetes pour tout nouveau déploiement ciblant du matériel spécialisé.
Ai-je besoin d’un driver de ressource spécifique pour utiliser DRA avec NVIDIA ?
Oui, le driver DRA NVIDIA (distribué avec le GPU Operator) doit être installé sur ton cluster pour que les ResourceSlice soient correctement publiées et que le scheduler puisse allouer les GPU dynamiquement.
DRA fonctionne-t-il aussi pour du matériel non-GPU ?
Oui, le mécanisme est générique : il s’applique à toute ressource matérielle nécessitant une allocation fine — FPGA, cartes réseau spécialisées (SmartNIC), ou futurs types d’accélérateurs.
En résumé
Si tu pilotes un cluster GPU hétérogène pour des charges IA, la Dynamic Resource Allocation vaut clairement le détour : elle remplace des contournements fragiles par un modèle d’allocation pensé pour ça, avec la maturité de la GA depuis Kubernetes 1.35. Pour aller plus loin sur la gestion de ton cluster, notre article sur les nouveautés de Kubernetes 1.37 et notre guide pour sécuriser un cluster Kubernetes en 2026 complètent bien ce sujet, tout comme notre article sur la migration vers la Gateway API si tu prépares une mise à niveau plus large de ton cluster.
Laisser un commentaire