Kubernetes pour l'orchestration GPU : Gérer des clusters de plusieurs milliers de GPU

Mis à jour le 8 décembre 2025

Mise à jour décembre 2025 : L'allocation dynamique des ressources (DRA) de Kubernetes 1.31+ est désormais en disponibilité générale, permettant un partitionnement GPU fin et le time-slicing. NVIDIA GPU Operator 24.6+ ajoute le support Blackwell et une gestion MIG améliorée. Kueue (mise en file d'attente native Kubernetes) atteint sa maturité pour les charges de travail IA. Run:ai et CoreWeave démontrent des clusters de plus de 50 000 GPU sur Kubernetes. Les outils de fédération multi-cluster (Liqo, Admiralty) permettent l'orchestration GPU inter-cloud. Le support vGPU s'améliore pour les déploiements d'inférence multi-locataires.

OpenAI orchestre 25 000 GPU à travers plusieurs clusters Kubernetes pour entraîner les modèles GPT, utilisant des opérateurs personnalisés qui gèrent automatiquement les pannes GPU, rééquilibrent les charges de travail en temps réel et maintiennent 97 % d'utilisation malgré des pannes matérielles survenant en moyenne toutes les 2,5 heures.¹ L'équipe infrastructure de l'entreprise a découvert que Kubernetes standard s'effondre autour de 5 000 nœuds sans modifications extensives, les obligeant à implémenter une fédération hiérarchique de clusters, des algorithmes de planification personnalisés et un autoscaling tenant compte des GPU qui traite chaque H100 à 30 000 $ comme une ressource précieuse nécessitant un suivi individuel. La gestion des GPU à grande échelle diffère fondamentalement de l'orchestration CPU — un GPU défaillant pendant un entraînement distribué peut gaspiller des millions en temps de calcul, tandis qu'une mauvaise planification séparant des GPU connectés via NVLink cause une dégradation de performance de 8x. Les organisations qui orchestrent avec succès des milliers de GPU sur Kubernetes rapportent une utilisation 35 % meilleure, des temps de déploiement 60 % plus rapides et une réduction de 90 % de la charge opérationnelle par rapport à la gestion bare-metal.²

Kubernetes domine l'orchestration de conteneurs avec 88 % de parts de marché, mais le support GPU est arrivé tardivement et reste difficile à grande échelle.³ Le NVIDIA GPU Operator, lancé en 2019, a finalement apporté une gestion GPU de niveau entreprise à Kubernetes, permettant des fonctionnalités comme l'installation dynamique de pilotes, le déploiement automatique de device plugins et la surveillance de santé GPU. Les organisations exécutant des charges de travail IA sur Kubernetes doivent naviguer entre les configurations de device plugins, les règles d'affinité de nœuds, la planification tenant compte de la topologie et les quotas de ressources qui empêchent des équipes individuelles de monopoliser les ressources GPU. Pourtant, ceux qui maîtrisent Kubernetes pour l'orchestration GPU acquièrent la capacité de traiter des milliers de GPU comme un pool de ressources programmable unique, atteignant des taux d'utilisation et une efficacité opérationnelle impossibles avec les ordonnanceurs HPC traditionnels.

Architecture du device plugin GPU

Le framework device plugin de Kubernetes permet la découverte, l'allocation et la surveillance de santé des GPU à travers les clusters :

NVIDIA GPU Device Plugin sert d'interface principale entre Kubernetes et les GPU NVIDIA.⁴ Le plugin s'exécute en tant que DaemonSet sur chaque nœud GPU, enregistrant les GPU comme ressources planifiables auprès du kubelet. Lors de l'initialisation, le plugin interroge NVIDIA Management Library (NVML) pour découvrir les GPU disponibles, leur capacité mémoire, leur capacité de calcul et leur topologie d'interconnexion. Le plugin annonce les GPU au scheduler Kubernetes en utilisant le nom de ressource nvidia.com/gpu, permettant aux pods de demander des GPU via des spécifications de ressources standard.

Flux d'enregistrement du Device Plugin : 1. Le plugin démarre et découvre les GPU locaux via NVML 2. S'enregistre auprès du kubelet via un socket Unix à /var/lib/kubelet/device-plugins/ 3. Annonce les GPU disponibles avec des identifiants de périphérique uniques 4. Implémente le RPC Allocate() pour l'attribution GPU aux conteneurs 5. Surveille la santé des GPU et signale les pannes au kubelet 6. Gère le nettoyage GPU lors de la terminaison des pods

Support Multi-Instance GPU (MIG) permet de partitionner les GPU A100 et H100 en instances isolées.⁵ Chaque instance MIG apparaît comme un GPU séparé pour Kubernetes, permettant une allocation fine des ressources. Le device plugin gère les profils MIG, gérant la création, la suppression et l'attribution des instances. Les organisations obtiennent une utilisation GPU 7x meilleure en partitionnant les GPU sous-utilisés pour des charges de travail plus légères. La configuration MIG nécessite une planification soigneuse car les modes de partitionnement ne peuvent pas changer sans drainer les nœuds.

Device Plugins alternatifs offrent une diversité de fournisseurs : - AMD Device Plugin supporte les GPU compatibles ROCm comme le MI250X - Intel Device Plugin gère les GPU Intel et les accélérateurs Gaudi - Xilinx FPGA Device Plugin orchestre les ressources FPGA - Google TPU Device Plugin pour les clusters GKE

Stratégies de planification pour les charges de travail GPU

Une planification GPU efficace maximise l'utilisation tout en maintenant les performances :

Gang Scheduling garantit que les jobs d'entraînement distribué reçoivent tous les GPU demandés simultanément. Sans gang scheduling, l'allocation partielle des ressources cause un deadlock — les jobs attendent indéfiniment les GPU restants qui ne deviennent jamais disponibles. Les plugins de scheduler Kubernetes comme Volcano et Apache YuniKorn implémentent le gang scheduling via les PodGroups.⁶ Les jobs spécifient leurs besoins minimum en GPU, et le scheduler alloue soit toutes les ressources soit met le job entier en file d'attente. Le gang scheduling réduit l'utilisation du cluster de 10-15 % mais prévient la famine des jobs d'entraînement.

Planification tenant compte de la topologie optimise le placement GPU basé sur les interconnexions matérielles. Les GPU connectés via NVLink atteignent 600 Go/s de bande passante contre 32 Go/s sur PCIe.⁷ Le scheduler examine la topologie des nœuds pour placer les pods liés sur des GPU avec des interconnexions rapides. NVIDIA GPU Feature Discovery étiquette les nœuds avec des informations de topologie permettant des règles d'affinité. De mauvaises décisions de topologie causent une dégradation de performance de 3-8x pour les charges de travail intensives en communication. La prise en compte de la topologie devient critique au-delà de 8 GPU par job.

Bin Packing vs Spreading : Le bin packing consolide les charges de travail sur moins de nœuds, améliorant la localité du cache et réduisant le trafic réseau. Le spreading distribue le travail à travers les nœuds pour une meilleure tolérance aux pannes et gestion thermique. La stratégie optimale dépend des caractéristiques de la charge de travail — les jobs d'entraînement bénéficient du bin packing tandis que l'inférence favorise le spreading. Les stratégies dynamiques s'ajustent selon l'utilisation du cluster et le mix de charges de travail.

Priorité et Préemption : Les charges de travail de production reçoivent une priorité plus élevée que les jobs de développement. Le scheduler préempte les pods de priorité inférieure quand les ressources deviennent rares. Une configuration soigneuse des priorités empêche les jobs de recherche de bloquer l'inférence de production. Le checkpointing de préemption garantit que la progression de l'entraînement n'est pas perdue. Les classes de priorité vont de system-critical (1000000) à development (100).

Partage équitable et Quotas : Les quotas de ressources empêchent des équipes individuelles de monopoliser les GPU. Les quotas hiérarchiques permettent des limites à l'échelle de l'organisation avec des sous-quotas spécifiques aux équipes. La planification en partage équitable assure une distribution équitable des ressources dans le temps. Les utilisateurs qui consomment moins de ressources accumulent des crédits pour une capacité de burst future. Les systèmes de files d'attente comme Kueue fournissent une mise en file d'attente de jobs avec un contrôle d'admission sophistiqué.

Considérations de mise à l'échelle

La mise à l'échelle de Kubernetes vers des milliers de GPU nécessite des modifications architecturales :

Limitations de taille de cluster : Les clusters Kubernetes uniques supportent maximum 5 000 nœuds avant que les performances d'etcd ne se dégradent.⁸ La charge du serveur API augmente quadratiquement avec le nombre de nœuds en raison des mécanismes de watch. Les boucles de réconciliation du controller manager ralentissent au-delà de 1 000 nœuds. Les politiques réseau deviennent ingérables à grande échelle. La plupart des organisations limitent les clusters à 500-1 000 nœuds GPU pour la stabilité opérationnelle.

Fédération multi-cluster : Les grands déploiements utilisent plusieurs clusters Kubernetes gérés via la fédération. Admiralty ou Virtual Kubelet permettent la planification inter-cluster. Les outils GitOps comme Flux ou ArgoCD synchronisent les configurations à travers les clusters. Les technologies de service mesh fournissent le réseau inter-cluster. La fédération ajoute de la complexité mais permet une mise à l'échelle horizontale au-delà des limites d'un cluster unique.

Gestion hiérarchique des ressources : Organisez les clusters hiérarchiquement avec des clusters de gestion contrôlant les clusters de charge de travail. Les clusters de gestion exécutent les composants du plan de contrôle et la logique de planification. Les clusters de charge de travail hébergent les pods GPU sans contrôleurs complexes. La conception hiérarchique réduit le rayon d'impact des pannes. Une séparation claire des responsabilités simplifie le dépannage.

Custom Resource Definitions (CRDs) pour les charges de travail IA : - TrainingJob : Définit les spécifications d'entraînement distribué - InferenceService : Gère les déploiements de serving de modèles - GPUPool : Représente des groupements logiques de GPU - Checkpoint : Gère la persistance de l'état d'entraînement - ModelVersion : Suit les itérations et la lignée des modèles

Optimisations de performance pour la mise à l'échelle : - Désactiver les webhooks d'admission inutilisés pour réduire la latence API - Implémenter des contraintes de répartition topologique des pods pour une distribution uniforme - Utiliser des SSD locaux pour les images de conteneurs évitant le goulot d'étranglement réseau - Activer le gestionnaire CPU pour une allocation CPU garantie - Configurer les huge pages pour les besoins mémoire des grands modèles

Surveillance et observabilité

Une surveillance complète prévient des millions de dollars de temps GPU inactif :

NVIDIA Data Center GPU Manager (DCGM) fournit des métriques spécifiques aux GPU indisponibles via la surveillance Kubernetes standard.⁹ DCGM exporte plus de 100 métriques incluant l'utilisation des SM, la bande passante mémoire, la température, la consommation électrique et les erreurs ECC. L'intégration Prometheus permet le stockage de métriques à long terme et les alertes. Les tableaux de bord Grafana visualisent les performances GPU à travers toute la flotte. Les alertes personnalisées détectent les GPU sous-utilisés, le throttling thermique et la dégradation matérielle avant que les pannes ne surviennent.

Métriques GPU clés pour la surveillance Kubernetes : - Utilisation GPU : Pourcentage de SM actifs (cible >90 %) - Utilisation mémoire : Mémoire GPU allouée versus disponible - Consommation électrique : Réelle versus TDP indiquant le throttling - Température : Températures GPU et mémoire - Bande passante PCIe : Taux de transfert de données vers/depuis le GPU - Trafic NVLink : Bande passante de communication inter-GPU - Métriques d'entraînement : Courbes de loss, normes de gradient, taux d'apprentissage - Métriques d'inférence : Requêtes par seconde, latence P99, tailles de batch

Traçage distribué suit les requêtes à travers plusieurs GPU et nœuds. L'instrumentation OpenTelemetry capture les temps des étapes d'entraînement, la latence de chargement des données et les durées de checkpoint. Jaeger ou Tempo fournissent le stockage et l'analyse des traces distribuées. La corrélation entre les traces et les métriques identifie les goulots d'étranglement de performance. La visibilité de bout en bout réduit le temps moyen de résolution de 70 %.

Agrégation de logs centralise les logs de milliers de pods GPU. Fluentd ou Fluent Bit collectent les logs de conteneurs avec un overhead minimal. Elasticsearch stocke les logs avec indexation automatique et politiques de rétention. Kibana permet la recherche et l'analyse de logs à travers tout le cluster. La journalisation structurée avec des formats cohérents simplifie le dépannage. Alerter sur les patterns d'erreurs indiquant des problèmes systémiques.

Introl déploie et gère des clusters Kubernetes pour l'orchestration GPU à travers notre zone de couverture mondiale, avec une expertise pour des déploiements de plus de 10 000 GPU.¹⁰ Nos équipes d'ingénierie plateforme ont implémenté des opérateurs personnalisés et des améliorations de planification pour une utilisation GPU optimale.

Patterns de déploiement en production

Architecture de cluster d'entraînement chez Anthropic : - Échelle : 4 000 GPU à travers 8 clusters Kubernetes - Topologie : Fédération hiérarchique avec scheduler central - Stockage : Système de fichiers Lustre distribué pour les données d'entraînement - Réseau : Fabric RoCE v2 avec 200 Gbps par nœud - Planification : Gang scheduler personnalisé avec prise en compte de la topologie - Surveillance : DCGM + Prometheus avec intervalles de scrape de 15 secondes - Résultat : 94 % d'utilisation GPU, réduction de 50 % du temps d'entraînement

Plateforme d'inférence chez Uber : - Charge de travail : 500 millions de prédictions quotidiennes - Infrastructure : 2 000 GPU T4 à travers 20 régions - Orchestration : Kubernetes avec Knative pour le serverless - Autoscaling : Scaling prédictif basé sur les patterns de trafic - Load Balancing : Proxy Envoy avec routage à moindre latence - Optimisation : Le caching de modèles réduit le cold start à 2 secondes - Résultat : Réduction des coûts de 65 % versus l'architecture précédente

Entraînement-Inférence hybride chez Spotify : - GPU : 3 000 flotte mixte V100/A100/T4 - Planification : Partage en time-slicing pour le développement - Isolation : Conteneurs Kata pour la sécurité multi-locataire - Cos

[Contenu tronqué pour la traduction]