Kubernetes DRA passe en GA : l'allocation matérielle pilotée par attributs

Pendant des années, les infrastructures d'IA et de machine learning d'entreprise exécutées sur Kubernetes reposaient sur des plugins de périphériques rigides et basés sur des entiers (comme nvidia.com/gpu: 1). Si ce modèle primitif a répondu aux premiers besoins des workloads GPU, il a contraint les équipes plateforme à surdimensionner un matériel d'accélération coûteux, masqué la topologie NUMA entre composants et empêché le partage fin des ressources matérielles. Avec la disponibilité générale (General Availability ou GA) du Dynamic Resource Allocation (DRA) via l'API resource.k8s.io/v1 dans Kubernetes v1.34 et Red Hat OpenShift 4.21, cette ère de planification à grain grossier touche à sa fin.

Le DRA introduit un modèle d'allocation matérielle piloté par les attributs, qui découple l'ordonnancement des workloads du décompte fixe de périphériques. En déplaçant la gestion du matériel vers des primitives déclaratives, Kubernetes peut désormais inspecter les capacités des composants, évaluer les topologies d'interconnexion à haut débit (telles que les hiérarchies NVLink et PCIe) et partitionner dynamiquement les ressources de calcul. Pour les CTO, directeurs d'infrastructure et SRE seniors gérant des clusters d'entraînement et d'inférence IA pesant plusieurs millions d'euros, le DRA fournit les fondations de control plane nécessaires pour maximiser l'utilisation des GPU et réduire le CapEx.

Impact métier et opérationnel

Les plugins de périphériques historiques imposaient aux organisations un modèle d'affectation matérielle binaire : un GPU physique entier était soit dédié à un seul pod, soit sous-utilisé. Le DRA modifie fondamentalement cette équation économique. En autorisant les allocations fractionnaires, le partage dynamique des cartes et la sélection basée sur les capacités, les entreprises peuvent consolider leurs microservices d'inférence et leurs tâches d'entraînement légères sur du matériel partagé, ce qui augmente considérablement la densité des clusters et réduit le coût total de possession (TCO).

Sur le plan opérationnel, le DRA atténue la fragmentation matérielle et réduit la complexité de configuration sur les clusters hétérogènes. Les ingénieurs plateforme n'ont plus besoin de maintenir des labels de nœuds sur mesure ou des daemonsets complexes pour exposer des attributs matériels propres à chaque fournisseur. De plus, grâce à une prise en compte fine de la topologie, les workloads nécessitant une bande passante inter-GPU élevée sont automatiquement ordonnancés sur les domaines NUMA et les arbres NVLink optimaux. Cela évite les goulots d'étranglement inter-sockets, élimine la dégradation silencieuse des traitements et garantit des performances d'entraînement prévisibles à l'échelle de l'entreprise.

Architecture et conception ingénierie

Le DRA s'appuie sur trois abstractions de ressources personnalisées (CRD) principales au sein du groupe d'API resource.k8s.io/v1 : DeviceClass, ResourceSlice et ResourceClaim. Les fabricants de matériel fournissent un pilote DRA qui publie les capacités et attributs des composants via des objets ResourceSlice dans l'API server Kubernetes.

Les architectes plateforme définissent des manifestes DeviceClass pour catégoriser les pools matériels et appliquer des règles de sélection à l'aide du langage CEL (Common Expression Language). Lorsque les workloads demandent des ressources de calcul, une ResourceClaim (ou un modèle ResourceClaimTemplate en ligne) spécifie les exigences matérielles précises — telles que la VRAM minimale, les versions de pilotes ou la topologie d'interconnexion.

Voici un manifeste prêt pour la production montrant comment demander des GPU à haute mémoire connectés via NVLink à l'aide d'un filtrage CEL :

apiVersion: resource.k8s.io/v1
kind: DeviceClass
metadata:
  name: high-bandwidth-gpu
spec:
  selectors:
  - cel:
      expression: "device.driver == 'nvidia.com/gpu' && device.attributes['memory'].quantity >= quantity('40Gi') && device.attributes['nvlink'].boolean == true"
---
apiVersion: v1
kind: Pod
metadata:
  name: deep-learning-inference
spec:
  containers:
  - name: model-server
    image: vllm/vllm-openai:latest
    resources:
      claims:
      - name: gpu-claim
  resourceClaims:
  - name: gpu-claim
    resourceClaimTemplateName: h100-nvlink-template

Lorsque l'ordonnanceur Kubernetes évalue ce pod, il dialogue directement avec le plugin du pilote DRA pour réserver les tranches (slices) disponibles répondant aux contraintes CEL. Cela garantit que le matériel correspondant exactement aux critères opérationnels est réservé avant le placement du pod.

Les changements concrets en pratique

• Passage d'un ordonnancement par entiers à un ordonnancement par attributs : remplacez les annotations statiques du type nvidia.com/gpu: 2 par des expressions CEL explicites ciblant la VRAM, l'architecture constructeur, les capacités de calcul et la vitesse d'interconnexion.
• Découpage matériel dynamique (Hardware Slicing) : permettez à plusieurs pods de réclamer des tranches structurées d'accélérateurs de grande capacité sans recourir à des hacks d'opérateurs sur mesure ou à des middlewares propriétaires.
• Colocalisation sensible à la topologie : placez automatiquement les pods d'entraînement distribué sur des nœuds physiques où les GPU partagent une topologie directe NVLink ou des switches PCIe afin d'éviter la dégradation de latence inter-NUMA.
• Maintenance simplifiée des clusters : standardisez l'allocation matérielle sur l'ensemble du cluster via resource.k8s.io/v1, en éliminant les labels de nœuds fragiles et les plugins d'ordonnancement propriétaires.

L'approche d'Ali Run AIOps

Chez Ali Run AIOps, nous concevons des infrastructures cloud automatisées et résilientes, optimisées pour les workloads d'entreprise à forte intensité de calcul. Nous accompagnons les directions techniques dans la transition de leurs clusters GPU Kubernetes patrimoniaux vers les architectures DRA modernes — en mesurant le débit matériel, en rédigeant des définitions de règles CEL précises et en déployant des workflows GitOps pour l'infrastructure plateforme sous-jacente.

Notre équipe fait la jonction entre les abstractions matérielles Linux de bas niveau, l'intégration des pilotes d'accélérateurs et l'orchestration Kubernetes. Que vous développiez des fermes d'inférence LLM ou optimisiez des pipelines d'entraînement distribué, Ali Run AIOps fournit une infrastructure pilotée par la télémétrie qui maximise l'efficacité de calcul, applique des limites de sécurité Zero Trust et réduit la charge opérationnelle.

Sources

• Kubernetes v1.34: Dynamic Resource Allocation (DRA) Reaches GA
• Dynamic Resource Allocation Goes GA in Red Hat OpenShift 4.21