Pourquoi l'autoscaling Kubernetes échoue pour les charges de travail IA et comment DRA y remédie

Kubernetes s'est longtemps appuyé sur une séparation nette entre son ordonnanceur, qui place les pods sur des nœuds existants, et son autoscaler, qui ajoute de nouveaux nœuds lorsque la capacité vient à manquer. Cette division du travail fonctionnait bien pour le calcul standard, mais elle se heurte désormais au poids des charges de travail IA qui nécessitent des topologies d'accélérateurs spécifiques. En octobre 2026, la communauté retravaille activement ces composants pour garantir qu'ils parlent le même langage concernant les contraintes matérielles.

Ce qui s'est passé

Pendant une décennie, l'hypothèse selon laquelle les ressources de calcul étaient largement interchangeables a permis à l'ordonnanceur et à l'autoscaler de fonctionner indépendamment. Cependant, les accélérateurs IA comme les GPU ne sont pas génériques ; leurs performances dépendent fortement de leur connexion aux CPU, à la mémoire et aux autres GPU. Un mode de défaillance courant voit désormais des pods rester en attente même lorsque le cluster semble avoir de la capacité. L'autoscaler ajoute un nœud, mais l'ordonnanceur le rejette car la topologie matérielle ne correspond pas aux exigences strictes de localité de la charge de travail.

Le problème central est que l'autoscaler répond à la question de savoir s'il faut ajouter un nœud, alors que la vraie question est de savoir si le nœud ajouté a la bonne forme pour le travail. Si l'autoscaler provisionne un nœud sans comprendre le câblage complexe des accélérateurs, l'ordonnanceur ne peut pas placer le pod. Ce déséquilibre laisse une capacité d'accélération coûteuse inutilisée et retarde les jobs critiques d'inférence ou d'entraînement. La Cloud Native Computing Foundation (CNCF) souligne qu'il ne s'agit pas seulement d'un problème spécifique à un fournisseur, mais d'un défi architectural fondamental dans Kubernetes upstream.

Pour y remédier, la communauté évolue vers un vocabulaire partagé pour la description du matériel. Historiquement, Kubernetes traitait les accélérateurs comme de simples comptes entiers. Désormais, avec l'introduction de l'Allocation Dynamique des Ressources (DRA), les charges de travail peuvent déposer des demandes structurées décrivant non seulement combien de périphériques elles nécessitent, mais aussi comment ces périphériques doivent être liés entre eux et aux interfaces réseau. Cela permet à la fois à l'ordonnanceur et aux autoscalers conscients de la DRA d'évaluer la capacité en utilisant les mêmes critères détaillés.

Comment cela fonctionne

L'Allocation Dynamique des Ressources modifie le modèle de ressources, passant d'un simple comptage brut à une demande structurée. Au lieu de demander quatre GPU, une charge de travail spécifie qu'elle a besoin de quatre GPU situés dans le même domaine NUMA et connectés via des liens à haut débit. L'ordonnanceur lit directement ces demandes pour prendre des décisions de placement. Crucialement, les autoscalers conscients de la DRA commencent à utiliser cette même information lors de la simulation d'ajouts potentiels de capacité. Cela garantit que, lorsque l'autoscaler décide de monter en charge, il sélectionne des types de nœuds qui satisfont réellement les contraintes de topologie définies par la charge de travail.

Au-delà de la topologie, la DRA permet également un partage plus fin des accélérateurs. Les appareils modernes sont suffisamment puissants pour qu'attribuer un GPU entier à une petite tâche soit gaspilleur. La DRA prend en charge les périphériques partitionnables, permettant à un seul accélérateur physique d'être divisé en instances isolées ou en parts consommables. Plusieurs charges de travail peuvent tirer simultanément des portions mesurées d'un périphérique. L'ordonnanceur suit ces allocations fractionnées, et les autoscalers peuvent peser les nœuds prospectifs en fonction des tranches disponibles plutôt que simplement des périphériques entiers. Cela réduit le gaspillage tout-ou-rien qui affectait auparavant l'utilisation des GPU.

Malgré ces progrès, un fossé subsiste pour la planification en gang, où un groupe de pods doit être planifié ensemble ou pas du tout. Les API actuelles de planification consciente de la charge de travail permettent à l'ordonnanceur de retenir les pods jusqu'à ce qu'un groupe complet puisse être placé, mais l'autoscaler raisonne encore pod par pod. Il peut provisionner une capacité partielle pour quelques membres d'un gang, gaspillant des ressources tandis que le job attend le reste. Un mécanisme provisoire appelé demande de provisionnement tente de combler ce fossé en permettant aux charges de travail de demander une capacité de groupe de manière atomique, mais il reste une solution ajoutée plutôt qu'une fonctionnalité profondément intégrée.

Détails clés

• La topologie compte : Les performances des accélérateurs dépendent de la localité, incluant les domaines NUMA CPU, les chemins PCIe et les liens inter-GPU, et non seulement du nombre de périphériques.
• Allocation Dynamique des Ressources (DRA) : Remplace les demandes de ressources basées sur des entiers par des demandes structurées décrivant les relations entre périphériques et les interfaces réseau.
• Vocabulaire partagé : La DRA permet à la fois à l'ordonnanceur et à l'autoscaler de comprendre les contraintes matérielles de manière identique, réduisant les déséquilibres de provisionnement.
• Partage fractionné : La DRA prend en charge les périphériques partitionnables et la capacité consommable, permettant à plusieurs charges de travail de partager efficacement un seul accélérateur.
• Fossé de la planification en gang : Bien que l'ordonnanceur prenne en charge le placement atomique de groupes, l'autoscaler monte toujours en charge pod par pod, entraînant un gaspillage potentiel pour les grands jobs distribués.
• Intégration future : SIG-Autoscaling et SIG-Scheduling conçoivent des API permettant à l'ordonnanceur de voir la capacité provisionnable et de la demander explicitement.

Pourquoi c'est important

Pour les équipes d'ingénierie gérant l'infrastructure IA, ce déséquilibre se traduit directement par un budget gaspillé et des cycles d'itération plus lents. Les heures de GPU sont coûteuses, et les laisser inactives en raison d'un désaccord entre planification et provisionnement représente un coût opérationnel significatif. Comprendre qu'un pod en attente pourrait ne pas indiquer un manque de capacité régionale, mais plutôt un déséquilibre de topologie, change la façon dont les équipes déboguent et optimisent leurs clusters. Cela déplace l'attention de la simple addition de nœuds vers la garantie que les nœuds ajoutés sont compatibles avec les besoins structurels de la charge de travail.

De plus, le mouvement vers une conception intégrée signifie que les futures fonctionnalités Kubernetes considéreront les implications d'autoscaling dès le départ. Plutôt que de rétrofitter le support d'autoscaling après la sortie d'une nouvelle primitive de planification, la communauté construit des interfaces permettant aux deux boucles de contrôle de coordonner proactivement. Cette évolution est critique pour soutenir les inférences irrégulières et les charges de travail agentiques qui ne peuvent pas tolérer la latence des démarrages à froid ou des nœuds mal provisionnés. Les équipes exécutant des accélérateurs ont désormais un intérêt dans ces discussions upstream, car les normes résultantes définiront l'efficacité de leur infrastructure pour les années à venir.

Ce que vous pouvez faire

• Auditer les pods en attente : Vérifiez si les pods GPU en attente sont dus à des déséquilibres de topologie plutôt qu'à une véritable épuisement de la capacité.
• Adopter la DRA : Migrez les charges de travail pour utiliser les demandes d'Allocation Dynamique des Ressources afin d'exprimer explicitement les exigences de topologie et de partage.
• Activer la planification consciente de la charge de travail : Testez les API Workload et PodGroup en version bêta pour améliorer le comportement de la planification en gang, notant qu'elles sont désactivées par défaut.
• Évaluer la compatibilité de l'autoscaler : Vérifiez si votre implémentation actuelle de l'autoscaler est consciente de la DRA et peut simuler les contraintes de topologie lors de la montée en charge.
• Surveiller la fragmentation : Suivez les métriques d'utilisation GPU pour identifier le gaspillage dû aux attributions tout-ou-rien et envisagez d'activer le partage fractionné.
• S'engager avec les SIG : Participez aux discussions SIG-Autoscaling et SIG-Scheduling pour influencer la conception des futures API d'intégration.