Kubernetes pour l'orchestration GPU : Gestion de clusters multi-milliers de GPU

Mis à jour le 8 décembre 2025

Mise à jour de décembre 2025 : L'allocation dynamique de ressources (DRA) de Kubernetes 1.31+ est maintenant en disponibilité générale, permettant le partitionnement fin des GPU et le time-slicing. NVIDIA GPU Operator 24.6+ ajoute le support Blackwell et une gestion MIG améliorée. Kueue (système de files d'attente natif Kubernetes) atteint la maturité en production pour les charges de travail AI. Run:ai et CoreWeave démontrent des clusters de 50 000+ GPU sur Kubernetes. Les outils de fédération multi-clusters (Liqo, Admiralty) permettent l'orchestration GPU cross-cloud. Le support vGPU s'améliore pour les déploiements d'inférence multi-tenants.

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 toutes les 2,5 heures en moyenne.¹ L'équipe infrastructure de l'entreprise a découvert que Kubernetes vanilla s'effondre vers 5 000 nœuds sans modifications extensives, les forçant à implémenter une fédération de clusters hiérarchique, des algorithmes de planification personnalisés, et un autoscaling conscient 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—une panne GPU pendant l'entraînement distribué peut gaspiller des millions en temps de calcul, tandis qu'une mauvaise planification qui sépare les GPU connectés via NVLink cause 8x de dégradation des performances. Les organisations orchestrant avec succès des milliers de GPU sur Kubernetes rapportent 35% de meilleure utilisation, 60% de temps de déploiement plus rapides, et 90% de réduction des frais généraux opérationnels comparé à la gestion bare-metal.²

Kubernetes domine l'orchestration de conteneurs avec 88% de parts de marché, mais le support GPU est arrivé tard et reste difficile à grande échelle.³ Le NVIDIA GPU Operator, lancé en 2019, a finalement apporté la 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 AI sur Kubernetes doivent naviguer les configurations de device plugins, les règles d'affinité de nœuds, la planification topology-aware, et les quotas de ressources qui empêchent les équipes individuelles de monopoliser les ressources GPU. Pourtant, ceux qui maîtrisent Kubernetes pour l'orchestration GPU gagnent 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 planificateurs HPC traditionnels.

Architecture des device plugins GPU

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

NVIDIA GPU Device Plugin sert d'interface primaire entre Kubernetes et les GPU NVIDIA.⁴ Le plugin s'exécute comme un DaemonSet sur chaque nœud GPU, enregistrant les GPU comme ressources planifiables avec le kubelet. Pendant l'initialisation, le plugin interroge NVIDIA Management Library (NVML) pour découvrir les GPU disponibles, leur capacité mémoire, capacité de calcul, et topologie d'interconnexion. Le plugin annonce les GPU au planificateur Kubernetes en utilisant le nom de ressource nvidia.com/gpu, permettant aux pods de demander des GPU à travers les 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 avec kubelet via socket Unix à /var/lib/kubelet/device-plugins/ 3. Annonce les GPU disponibles avec des ID de périphérique uniques 4. Implémente l'RPC Allocate() pour l'attribution GPU de conteneur 5. Surveille la santé GPU et rapporte les pannes au kubelet 6. Gère le nettoyage GPU pendant la terminaison de pod

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é à Kubernetes, permettant l'allocation fine de ressources. Le device plugin gère les profils MIG, gérant la création, suppression, et attribution d'instances. Les organisations atteignent 7x de meilleure utilisation GPU en partitionnant les GPU sous-utilisés pour des charges de travail plus petites. La configuration MIG nécessite une planification soigneuse car les modes de partitionnement ne peuvent pas changer sans vider les nœuds.

Device Plugins Alternatifs offrent la diversité des fournisseurs : - AMD Device Plugin supporte les GPU compatibles ROCm comme MI250X - Intel Device Plugin gère les GPU Intel et 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 assure que les jobs d'entraînement distribué reçoivent tous les GPU demandés simultanément. Sans gang scheduling, l'allocation partielle de ressources cause un interblocage—les jobs attendent indéfiniment les GPU restants qui ne deviennent jamais disponibles. Les plugins de planificateur Kubernetes comme Volcano et Apache YuniKorn implémentent le gang scheduling à travers les PodGroups.⁶ Les jobs spécifient les exigences GPU minimales, et le planificateur alloue soit toutes les ressources soit met en file d'attente le job entier. Le gang scheduling réduit l'utilisation du cluster de 10-15% mais empêche la famine des jobs d'entraînement.

Planification Topology-Aware optimise le placement GPU basé sur les interconnexions matérielles. Les GPU connectés via NVLink atteignent 600GB/s de bande passante versus 32GB/s sur PCIe.⁷ Le planificateur 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 les règles d'affinité. Les mauvaises décisions de topologie causent 3-8x de dégradation des performances pour les charges de travail à forte communication. La conscience de 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 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 basées sur 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 planificateur préempte les pods de priorité inférieure quand les ressources deviennent rares. Une configuration de priorité soigneuse empêche les jobs de recherche de bloquer l'inférence de production. Le checkpointing de préemption assure que le progrès d'entraînement n'est pas perdu. Les classes de priorité vont de système-critique (1000000) à développement (100).

Partage Équitable et Quotas : Les quotas de ressources empêchent les é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 de 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 rafale future. Les systèmes de files d'attente comme Kueue fournissent la mise en file d'attente de jobs avec un contrôle d'admission sophistiqué.

Considérations de mise à l'échelle

Mise à l'échelle de Kubernetes à des milliers de GPU nécessite des modifications architecturales :

Limitations de Taille de Cluster : Les clusters Kubernetes uniques supportent 5 000 nœuds maximum avant que les performances etcd se dégradent.⁸ La charge du serveur API augmente quadratiquement avec le nombre de nœuds à cause 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 cross-cluster. Les outils GitOps comme Flux ou ArgoCD synchronisent les configurations à travers les clusters. Les technologies service mesh fournissent le réseau cross-cluster. La fédération ajoute de la complexité mais permet la mise à l'échelle horizontale au-delà des limites de cluster unique.

Gestion de Ressources Hiérarchique : 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'explosion des pannes. La séparation claire des préoccupations simplifie le dépannage.

Définitions de Ressources Personnalisées (CRDs) pour les charges de travail AI : - TrainingJob : Définit les spécifications d'entraînement distribué - InferenceService : Gère les déploiements de service de modèle - GPUPool : Représente les groupements GPU logiques - Checkpoint : Gère la persistance d'état d'entraînement - ModelVersion : Suit les itérations de modèle et la lignée

Optimisations de performance pour l'échelle : - Désactiver les webhooks d'admission inutilisés réduisant la latence API - Implémenter les contraintes de répartition de topologie de pod pour une distribution uniforme - Utiliser SSD local pour les images de conteneur évitant le goulot d'étranglement réseau - Activer le gestionnaire CPU pour l'allocation CPU garantie - Configurer les pages énormes pour les exigences mémoire de grands modèles

Surveillance et observabilité

Une surveillance complète empêche des millions de dollars de temps d'inactivité GPU :

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

Métriques GPU Clés pour la surveillance Kubernetes : - Utilisation GPU : Pourcentage de SMs actifs (cible >90%) - Utilisation Mémoire : Mémoire GPU allouée versus disponible - Consommation Énergétique : Actuelle versus TDP indiquant l'étranglement - Température : Températures GPU et mémoire - Bande Passante PCIe : Taux de transfert de données vers/depuis GPU - Trafic NVLink : Bande passante de communication inter-GPU - Métriques d'Entraînement : Courbes de perte, normes de gradient, taux d'apprentissage - Métriques d'Inférence : Requêtes par seconde, latence P99, tailles de lots

Traçage Distribué suit les requêtes à travers plusieurs GPU et nœuds. L'instrumentation OpenTelemetry capture les temps d'étape d'entraînement, la latence de chargement de données, et les durées de checkpoint. Jaeger ou Tempo fournissent le stockage et l'analyse de traces distribuées. La corrélation entre traces et métriques identifie les goulots d'étranglement de performance. La visibilité bout-à-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 conteneur 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'erreur indiquant des problèmes systémiques.

Introl déploie et gère les clusters Kubernetes pour l'orchestration GPU à travers notre zone de couverture globale, avec une expertise de mise à l'échelle vers 10 000+ déploiements GPU.¹⁰ Nos équipes d'ingénierie de 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 planificateur central - Stockage : Système de fichiers Lustre distribué pour données d'entraînement - Réseau : Fabric RoCE v2 avec 200Gbps par nœud - Planification : Gang scheduler personnalisé avec conscience de topologie - Surveillance : DCGM + Prometheus avec intervalles de scraping de 15 secondes - Résultat : 94% d'utilisation GPU, 50% de réduction du temps d'entraînement

Plateforme d'Inférence chez Uber : - Charge de travail : 500 millions de prédictions quotidiennement - Infrastructure : 2 000 GPU T4 à travers 20 régions - Orchestration : Kubernetes avec Knative pour serverless - Autoscaling : Mise à l'échelle prédictive basée sur les patterns de trafic - Équilibrage de Charge : Proxy Envoy avec routage de latence minimale - Optimisation : La mise en cache de modèle réduit le démarrage à froid à 2 secondes - Résultat : 65% de réduction des coûts versus architecture précédente

Entraînement-Inférence Hybride chez Spotify : - GPU : Flotte mixte de 3 000 V100/A100/T4 - Planification : Partage time-sliced pour développement - Isolation : Conteneurs Kata pour sécurité multi-tenant - Cos