Sommaire:
À l’ère des avancées technologiques exponentielles, la demande pour une infrastructure cloud capable de supporter des charges de travail toujours plus massives est devenue incontournable. Chez Google Cloud, nous repoussons constamment les limites de Google Kubernetes Engine (GKE) en matière de scalabilité et de performance pour répondre à ces impératifs, notamment dans le domaine de l’Intelligence Artificielle. Lors d’une démonstration à KubeCon, nous avons dévoilé un exploit remarquable : la gestion d’un cluster GKE expérimental de 130 000 nœuds, soit le double du nombre officiel de nœuds jusqu’alors supporté. Cette percée n’est pas seulement une question d’augmentation numérique ; elle englobe également une innovation architecturale profonde pour optimiser la création de pods et le dimensionnement des performances.
Défis et tendances de la scalabilité des clusters GKE
Alors que les plus grands clients de Google Cloud poussent les limites de notre infrastructure avec des charges de travail IA ambitieuses, le besoin de clusters gigantesques devient évident. À titre d’exemple, un client notable a récemment exprimé son intérêt pour une infrastructure comportant 100 000 nœuds, poussant ainsi notre engagement à innover sans relâche.
Ce mouvement est motivé non seulement par la croissance continue et effrénée des besoins en capacités de calcul, mais également par une transition critique du monde numérique, passant d’un univers limité par les puces à un univers contraint par l’énergie électrique. Considérez qu’un seul GPU NVIDIA GB200 consomme 2700W — un chiffre astronomique quand multiplié par des milliers. Cela rend non seulement la gestion de l’énergie une priorité, mais nécessite également des solutions multiclasses robustes, comme MultiKueue, pour orchestrer des apprentissages distribués entre plusieurs clusters et centres de données.
En parallèle, ces améliorations ne sont pas uniquement bénéfiques pour les utilisateurs à grande échelle. Elles rendant tous les clusters, mêmes plus modestes, plus résilients, optimisent la tolérance face aux erreurs des utilisateurs, et améliorent les performances des contrôleurs, assurant une expérience utilisateur harmonieuse.
- Augmentation de la résilience des clusters
- Optimisation des contrôleurs Kubernetes
- Expérience utilisateur intuitive et en libre-service
- Réduction du coût énergétique cumulatif
| Aspects | Avantages |
|---|---|
| Gestion de l’énergie | Réduction des dépenses en électricité grâce à une optimisation de la puissance GPU |
| Architecture distribuée | Capacité à gérer des workloads distribués au-delà d’un seul cluster |
| Scalabilité | Support expérimental pour 130 000 nœuds |
Innovations architecturales pour le cluster géant
Pour atteindre une telle échelle avec GKE, des innovations substantielles dans tout l’écosystème Kubernetes étaient nécessaires, notamment au niveau du plan de contrôle, de la planification personnalisée et du stockage. Une
Une des innovations majeures était la capacité de mettre à l’échelle la lecture des données. Avec 130 000 nœuds, la quantité massive de requêtes de lecture adressées au serveur API peut devenir un goulot d’étranglement. Pour surmonter ce défi, plusieurs fonctionnalités ont été intégrées.
Tout d’abord, la fonctionnalité Consistent Reads from Cache permet au serveur API de fournir des données directement à partir de son cache mémoire, ce qui réduit considérablement la charge sur la base de données de stockage d’objets. Ensuite, la fonctionnalité Snapshottable API Server Cache optimise encore davantage les performances en permettant au serveur API de répondre aux demandes de LIST pour les états antérieurs, directement à partir de ce cache cohérent.
Ces améliorations ont permis de garantir que le serveur API reste rapide et réactif, servant les lectures filtrées et les demandes de liste efficacement.
- Optimisation du cache de lecture pour le serveur API
- Réduction de la latence
- Amélioration de la réactivité du cluster
- Soutien d’un nombre croissant d’objets Kubernetes
| Fonctionnalité | Impact |
|---|---|
| Consistent Reads from Cache | Diminution drastique de la charge du serveur d’objets |
| Snapshottable API Server Cache | Amélioration des performances pour les demandes LIST |
Pouvoir de traitement augmenté avec l’architecture distribuée
À ces améliorations s’ajoute l’implémentation d’un back-end de stockage distribué optimisé grâce à un magasin clé-valeur basé sur la base de données distribuée Spanner de Google. Avec 130 000 nœuds, nous pouvions maintenir 13 000 QPS pour la mise à jour des objets de location, assurant que les opérations critiques du cluster telles que les vérifications de santé des nœuds ne deviennent pas des goulots d’étranglement.
En outre, le contrôleur de mise en file d’attente des travaux Kueue a joué un rôle crucial. Conçu pour les environnements complexes d’IA et de ML, Kueue organise les tâches non pas seulement au niveau des pods, mais suivant une approche centrée sur les charges de travail.
- Système de stockage distribué résilient
- Système de mise en file d’attente Kueue
- Réduction significative du goulot d’étranglement dans l’infrastructure AI/ML
- Planification centrée sur les workloads
| Composant | Avantage |
|---|---|
| Spanner Storage | Stabilité du cluster renforcée |
| Kueue | Gestion des travaux à l’échelle |
Benchmark GKE pour les workloads AI dynamiques
Pour valider les performances de GKE face aux workloads AI/ML à grande échelle, un benchmark en quatre phases a été mis en place, simulant un environnement dynamique avec des défis complexes de gestion des ressources, de priorisation et de planification. Ce benchmark a examiné les capacités du cluster à maintenir une charge sous des demands fluctuantes.
Lors de la première phase, un ensemble de tâches massif figure parmi les tests de base, partageant les ressources du cluster pour répondre aux exigences d’un environnement réaliste.
Les résultats de ces tests ont révélé que GKE peut gérer efficacement ces pressions de scale extrême, offrant flexibilité et puissance de gestion des charges de travail.
- Validation de la performance GKE
- Gestion de la variable dynamique des demandes de ressources
- Benchmarking rigoureux sur quatre phases
- Réactivité optimisée du cluster
| Phase | Objectif |
|---|---|
| Phase 1 | Établissement d’une base de performance |
| Phase 2 | Simulation d’un environnement de workloads mixtes |
| Phase 3 | Priorisation d’un service d’inférence sensible à la latence |
| Phase 4 | Validation de l’élasticité du cluster |
Vers l’avenir des clusters GKE à échelle massive
Cet exploit montre clairement que GKE peut soutenir des workloads AI et ML à une échelle dépassant largement les limites publiques actuelles. Les enseignements tirés de ce projet pionnier guident hébdomadairement le développement futur de GKE, notamment en matière d’amélioration de l’architecture cloud et de l’infrastructure distribuée.
Même si nous ne supportons pas encore officiellement 130K nœuds, les perspectives qu’offre cet exploit sont des plus prometteuses. Nous invitons n’importe quelle entreprise ou individu intéressé par une scalabilité cloud de cette ampleur à nous contacter pour discuter des besoins spécifiques de workloads surdimensionnés.
Pour les dernières avancées en matière de gestion native du cloud avec Google Kubernetes Engine, n’hésitez pas à explorer nos ressources en ligne et nos discussions enrichissantes avec des experts à KubeCon.
- Capacités MO de GKE
- Nouveautés technologiques de Kubernetes
- Réduction des goulots d’étranglement
- Avenir de la gestion des clusters