Kubernetes s’est imposé comme la plateforme de référence pour orchestrer des applications containerisées, un point que nous avions détaillé auparavant ici : Qu’est ce que Kubernetes ? Il gère très bien les ressources classiques comme le CPU, la mémoire ou le stockage, mais ses mécanismes montrent leurs limites dès qu’un workload dépend de matériel spécialisé comme les GPU, les FPGA ou les cartes réseau avancées.
Pour répondre à ce besoin, Kubernetes introduit la Dynamic Resource Allocation (DRA), un système qui permet d’allouer ce type de matériel de manière dynamique et déclarative. Avec la montée des workloads liés à l’IA, cette évolution devient particulièrement utile.
Historique et évolution de la Dynamic Resource Allocation
La Dynamic Resource Allocation a connu une progression rapide au sein de l’écosystème Kubernetes. Introduite pour la première fois en version Alpha dans Kubernetes v1.26 en décembre 2022, elle n’était alors disponible qu’en mode expérimental et nécessitait l’activation d’un feature gate. Après une refonte majeure, la fonctionnalité franchit une étape importante en accédant au statut Beta dans Kubernetes v1.32 fin 2024, devenant plus table et activée par défaut. En définitive, la DRA atteint sa pleine maturité avec son passage en General Availability (GA) dans Kubernetes v1.34 en septembre 2025, marquant son adoption officielle comme fonctionnalité stable et prête pour les environnements de production.
Pourquoi Dynamic Resource Allocation existe
Historiquement, lorsqu’un Pod devait utiliser un GPU ou une carte réseau particulière, on devait combiner plusieurs techniques : labels, nodeSelector, taints, affinities, ou même des scripts maison. En clair, on demandait au Pod non seulement ce dont il avait besoin, mais aussi où aller le chercher. Cela introduisait plusieurs contraintes :
- Il fallait connaître la topologie exacte du cluster (qui possède quoi).
- Les fichiers YAML devenaient peu portables et difficiles à maintenir.
- Une simple modification de nœud pouvait casser le scheduling.
- Impossible d’exprimer des contraintes matérielles fines.
- Le partage ou l’isolation du matériel devenait compliqué.
À mesure que les workloads IA, data science et HPC se sont généralisés, ce système a commencé à montrer ses limites. DRA apporte une solution plus propre, plus structurée et plus simple à maintenir, qui s’inscrit dans la logique déclarative de Kubernetes.
Comment fonctionne Dynamic Resource Allocation
DRA repose sur trois objets principaux qui permettent à Kubernetes de décrire, inventorier et allouer des ressources matérielles.
1. DeviceClass : la définition du type de matériel
Une DeviceClass sert à décrire une catégorie de devices : GPU, FPGA, cartes réseau avancées, etc. On peut y ajouter des critères comme la mémoire minimale, la génération ou d’autres attributs. Cela permet de décrire un besoin sans faire référence à un nœud précis.
Exemple : une DeviceClass pour des NVIDIA A100 possédant plus de 40 Go de mémoire.
apiVersion: resource.k8s.io/v1alpha2
kind: DeviceClass
metadata:
name: nvidia-a100
spec:
selectors:
- cel:
expression: device.memory > 400002. ResourceSlice : l’inventaire réel du matériel
Chaque nœud publie un inventaire du matériel dont il dispose via des ResourceSlices. Cette étape est assurée par les drivers compatibles DRA. Le cluster obtient ainsi une vision claire de toutes les ressources matérielles disponibles, à jour et sans intervention manuelle.
3. ResourceClaim : la demande d’allocation du Pod
Lorsqu’un Pod a besoin d’un device, il ne pointe plus un nœud ou un label. Il demande une ressource via un ResourceClaim. Cela suffit pour que Kubernetes identifie un nœud compatible et y déploie le Pod.
Exemple de ResourceClaim réclamant un GPU conforme à notre DeviceClass :
apiVersion: resource.k8s.io/v1alpha2
kind: ResourceClaim
metadata:
name: claim-gpu-a100
spec:
devices:
requests:
- deviceClassName: nvidia-a1004. Exemple concret : un Pod qui utilise DRA
Voici un exemple complet intégrant un ResourceClaim :
apiVersion: v1
kind: Pod
metadata:
name: training-job
spec:
resourceClaims:
- name: gpu
source:
resourceClaimName: claim-gpu-a100
containers:
- name: trainer
image: my-ml-image:latest
command: ["python", "train.py"]Le Pod ne sait pas où se trouve le GPU. Il demande simplement un matériel répondant à une DeviceClass, et Kubernetes sélectionne le bon nœud.
Vous souhaitez aller plus loin sur les DRA et développez vos compétences ? Notre formation Kubernetes vous accompagne dans la maîtrise des mécanismes avancés, de la gestion des ressources aux fonctionnalités récentes comme la Dynamic Resource Allocation, afin de structurer et optimiser durablement vos environnements.
L’équipe Ambient IT
Ce que Dynamic Resource Allocation simplifie réellement dans un cluster
Une utilisation plus efficace du matériel
Les GPUs et autres accélérateurs coûtent cher et sont souvent sous-utilisés. Sans DRA, on réserve souvent des nœuds de manière arbitraire. Avec DRA, les Pods sont positionnés selon les capacités réellement disponibles, ce qui améliore l’utilisation du matériel.
Une gestion plus propre et moins dépendante des labels
Les labels et affinities fonctionnent, mais vieillissent mal. Avec DRA, tout repose sur des objets dédiés :
DeviceClasses, ResourceSlices, ResourceClaims.
C’est plus clair, plus propre et plus durable.
Une granularité beaucoup plus fine
Les DeviceClasses permettent d’exprimer des contraintes matérielles qu’on ne pouvait pas représenter auparavant : type de carte, quantité de mémoire, génération, capacités spécifiques…
Un meilleur support des clusters multi-équipes
Dans un cluster partagé, chaque équipe demande simplement le matériel dont elle a besoin, sans connaissance préalable de la topologie. Cela évite les conflits et les réservations permanentes de nœuds.
Quand Dynamic Resource Allocation devient intéressant à mettre en oeuvre
DRA apporte une vraie valeur dans les environnements suivants :
- Workloads IA / Machine Learning nécessitant des GPU ou accélérateurs.
- Pipelines de calcul scientifique s’appuyant sur du FPGA ou matériel spécialisé.
- Plateformes multi-équipes, où l’allocation doit être dynamique et équitable.
- Clusters où le matériel évolue souvent.
- Environnements hétérogènes mêlant CPU, GPU, FPGA, NIC avancées, etc.
Plus les workloads sont variés et “matériels dépendants”, plus DRA facilite la gestion globale.
Ce qu’il faut préparer avant d’activer Dynamic Resource Allocation
- Un cluster compatible avec la fonctionnalité (selon la version).
- Des drivers compatibles DRA installés sur les nœuds.
- Des DeviceClasses définies selon le matériel du cluster.
- Une adaptation possible de certaines configurations basées sur des labels.
- La vérification de la compatibilité des devices selon les fournisseurs.
Une évolution logique dans l’écosystème Kubernetes
La Dynamic Resource Allocation représente une évolution cohérente de Kubernetes, portée par la généralisation des workloads qui reposent sur du matériel spécialisé. Sans chercher à remplacer les mécanismes existants, DRA propose une manière plus structurée de gérer les GPU, FPGA, cartes réseau avancées ou autres composants spécifiques. En déplaçant la logique d’allocation vers des objets dédiés, et en s’appuyant sur une description précise des capacités matérielles, elle permet de réduire la dépendance à la topologie du cluster et d’éviter de multiples ajustements manuels.
Au-delà de la facilité d’usage, DRA apporte une meilleure visibilité sur les ressources disponibles et une allocation plus fine, ce qui est particulièrement utile dans les environnements multi-équipes ou dans les infrastructures où le matériel évolue régulièrement. Cela permet de maintenir un cluster plus propre, plus lisible, et surtout plus adaptable aux besoins réels des workloads.
En intégrant cette fonctionnalité, Kubernetes continue de progresser sans perdre de vue sa philosophie déclarative : des déploiements standardisés et indépendants du support sous-jacent. Pour les organisations qui doivent gérer du matériel spécialisé à grande échelle, DRA devient donc une option sérieuse à considérer, tant pour simplifier les pratiques que pour mieux tirer parti des ressources disponibles.
