Ce document explique comment concevoir des clusters Google Kubernetes Engine (GKE) résilients et des stratégies de planification des charges de travail qui vous aident à obtenir des ressources, telles que des GPU, des TPU et des processeurs hautes performances. En utilisant Gemini dansGoogle Cloud et Compute Advisor (Preview), vous pouvez éviter les pods en attente et améliorer la planification fiable des charges de travail d'IA.
Ce document est destiné aux architectes cloud, ainsi qu'aux administrateurs et opérateurs de plate-forme qui gèrent l'infrastructure GKE et souhaitent optimiser la planification et la programmation de la capacité.
Présentation de la flexibilité, de l'efficacité et de la disponibilité de la capacité de calcul sur GKE
La planification Kubernetes repose sur les requêtes de ressources déclarées. Lors de l'ordonnancement d'accélérateurs à grande échelle, tels que les GPU ou les TPU, des requêtes de ressources strictes peuvent entraîner l'échec de l'augmentation de la capacité des clusters si du matériel spécifique n'est pas disponible. Vous pouvez optimiser la disponibilité de la capacité sur GKE en utilisant les fonctionnalités suivantes :
- Création automatique de pools de nœuds : création dynamique de pools de nœuds multifamiliaux.
- Créations de remplacement au niveau de la charge de travail : tolérances et sélecteurs de nœuds configurés pour accepter un matériel alternatif.
- Programmation géographique et régionale : fonctionnalités multizones et multirégionales de GKE.
- Gestion des réservations : utilisation de la capacité préachetée avant de demander des ressources à la demande.
Bonnes pratiques pour la flexibilité, l'efficacité et la disponibilité de la capacité de calcul sur GKE
Cette section fournit des recommandations pour augmenter la disponibilité de votre capacité lorsque vous planifiez des charges de travail sur GKE. Ces bonnes pratiques couvrent des stratégies telles que la conception d'exigences matérielles flexibles, la configuration de la création automatique de pools de nœuds et l'exploitation de la distribution géographique pour s'adapter aux contraintes de ressources. La création automatique de pools de nœuds gère automatiquement les pools de nœuds en fonction des spécifications des pods. Au lieu de prédéfinir des pools de nœuds, spécifiez les exigences en termes de ressources dans vos fichiers manifestes de pods et laissez GKE créer des nœuds de manière dynamique.
Vous pouvez également découvrir et mettre en œuvre les bonnes pratiques suivantes à l'aide de Compute Advisor. Pour en savoir plus, consultez Utiliser Compute Advisor.
Options pour augmenter la disponibilité de la capacité de calcul
Pour optimiser la disponibilité de la capacité, vous pouvez demander à GKE d'éviter d'associer les charges de travail à une seule famille de machines ou à un seul type d'accélérateur statique. Vous trouverez ci-dessous des exemples de configuration de pools de nœuds flexibles et de règles d'affinité de pods pour différentes classes de charges de travail. Les alternatives spécifiques que vous choisissez dépendent des besoins en ressources de votre application :
Pools de nœuds de processeur à usage général :
- Exemple principal : N2 (usage général basé sur Intel).
- Exemples d'alternatives : N2D (AMD EPYC), C2 ou C2D (optimisé pour le calcul), ou E2 (optimisé pour les coûts).
- Modèle d'implémentation : configurez les spécifications de pod avec une affinité de nœud ou des tolérances qui permettent la planification sur plusieurs étiquettes de famille de machines, par exemple
cloud.google.com/machine-familydans["n2", "n2d", "c2d"]. Cette configuration permet à GKE de provisionner le pool qui dispose de capacité disponible.
Pools de nœuds GPU :
- Exemple principal : série A2 (GPU NVIDIA A100).
- Exemples d'alternatives : L4 (IA/ML universel) ou T4 (inférence).
- Schéma d'implémentation : configurez des pools de nœuds ou des ComputeClasses distincts pour différents niveaux de GPU. Pour les charges de travail pouvant s'exécuter sans fonctionnalités spécifiques à A100, autorisez les pods à revenir aux pools L4 ou T4 si le provisionnement A2 est limité.
Pools de nœuds TPU :
- Exemple principal : TPU Ironwood (TPU7x).
- Exemples d'alternatives : TPU v6 (Trillium) ou TPU v5 (v5e ou v5p).
- Modèle d'implémentation : le provisionnement des tranches TPU peut être très limité. Concevez des charges de travail d'entraînement avec une flexibilité au niveau du framework (par exemple, des configurations JAX ou PyTorch prenant en charge des topologies de tranche variables) à déployer sur des tranches v6 ou v5 lorsque la capacité TPU Ironwood (TPU7x) n'est pas disponible.
Le tableau suivant récapitule les principales sélections et alternatives matérielles pour différents types de charges de travail :
| Type de charge de travail | Exemple de sélection principale | Exemples d'alternatives | Considérations relatives à l'architecture |
|---|---|---|---|
| Charges de travail système ou principales | N2 | N2D, C2D, E2 | Couvre les pools de matériel Intel et AMD pour la création automatique de pools de nœuds. |
| Inférence et traitement par GPU | A2 (A100) | L4, T4 | Cible de manière flexible les pools de nœuds GPU à faible coût ou à haute disponibilité. |
| Entraînement de modèles TPU | TPU Ironwood (TPU7x) | TPU v6, TPU v5 (v5e ou v5p) | Utilise des topologies flexibles pour la planification basée sur les tranches. |
Implémenter la création automatique de pools de nœuds et les ComputeClasses
Pour optimiser la disponibilité de la capacité, combinez la création automatique de pools de nœuds avec les ComputeClasses. Voici quelques bonnes pratiques :
Définissez des ComputeClasses : créez des ressources ComputeClass qui spécifient une liste de familles de machines, de types de GPU ou de modèles d'approvisionnement classés par ordre de priorité. GKE tente de provisionner des nœuds en utilisant la configuration la plus prioritaire disponible dans la classe. Une liste de secours hiérarchisée vous aide considérablement à obtenir les ressources dont vos charges de travail ont besoin. Par exemple, pour empêcher GKE de revenir à des machines à usage général lorsqu'un accélérateur spécialisé préféré n'est pas disponible, ajoutez le paramètre
whenUnsatisfiable: DoNotScaleUpà la configuration de votre ComputeClass. Pour en savoir plus, consultez Contrôler les attributs de nœud avec autoscaling à l'aide de ComputeClasses personnalisées.Référencez les ComputeClasses dans les spécifications de pod : dans les spécifications de pod de votre charge de travail, utilisez le libellé
cloud.google.com/compute-classpour cibler votre ComputeClass personnalisée au lieu d'une famille de machines ou d'un type de GPU spécifiques. Pour en savoir plus, consultez Demander une ComputeClass dans une charge de travail.Définissez plusieurs tolérances : si vous n'utilisez pas ComputeClasses, utilisez des règles d'affinité de nœud dans les spécifications de votre pod qui autorisent une gamme de familles de machines (telles que
cloud.google.com/machine-familydans["n2", "n2d"]). Pour en savoir plus, consultez Configurer la création automatique de pools de nœuds.
Flexibilité géographique et multirégionale sur GKE
Pour augmenter la disponibilité des capacités, déployez des clusters GKE qui couvrent plusieurs zones ou exécutez des architectures multiclusters :
Clusters multizones : assurez-vous que les pools de nœuds sont configurés pour effectuer une mise à l'échelle automatique dans toutes les zones disponibles d'une région.
Fédération de clusters multirégionaux : pour les grands jobs asynchrones (tels que l'inférence par lot hors connexion ou l'entraînement distribué), déployez un orchestrateur multicluster (comme Kueue ou Cluster Director) pour mettre en file d'attente les charges de travail à l'échelle mondiale et les envoyer à une région disposant de capacité disponible.
Pods s'exécutant sur des VM Spot : exécutez des charges de travail interruptibles sur des VM Spot en ajoutant des tolérances et en demandant à GKE de répartir la capacité excédentaire dans différentes zones.
Bonnes pratiques supplémentaires pour la flexibilité, l'efficacité et la disponibilité de la capacité de calcul dans GKE
Au-delà de la diversification du matériel, intégrez ces bonnes pratiques GKE pour optimiser le scaling des clusters :
- Implémentez le surprovisionnement de pods (tampons de capacité) : déployez des pods de "pause" de faible priorité qui réservent la capacité des nœuds à l'avance. Lorsque des charges de travail d'IA à priorité élevée sont envoyées et que la capacité régionale est limitée, Kubernetes préempte immédiatement les pods de pause, ce qui permet aux conteneurs de démarrer sans attendre le provisionnement de nouveaux nœuds. Pour en savoir plus, consultez À propos des marges de capacité.
- Utiliser le démarrage flexible avec le provisionnement en file d'attente : pour les grands jobs par lot et d'entraînement de modèles d'IA, utilisez le démarrage flexible avec le provisionnement en file d'attente, qui s'intègre à Kueue et au programmeur de charge de travail dynamique. Le démarrage flexible avec provisionnement en file d'attente permet une allocation atomique des nœuds tout ou rien, ce qui évite les échecs partiels de scaling up du cluster. Pour en savoir plus, consultez Exécuter une charge de travail à grande échelle avec le démarrage flexible et le provisionnement en file d'attente.
- Activez le streaming d'images et le préchargement d'images de conteneurs : pour les images de conteneurs d'IA volumineuses (telles que les images PyTorch ou TensorFlow de plus de 10 Go), activez le streaming d'images GKE ou utilisez des disques de démarrage secondaires pour le préchargement d'images. Cette configuration réduit le temps de préchauffage des nœuds, ce qui permet aux nœuds nouvellement provisionnés de commencer à exécuter des charges de travail en quelques secondes. Pour en savoir plus, consultez Utiliser le streaming d'image pour extraire des images de conteneur et Utiliser des disques de démarrage secondaires pour précharger des données ou des images de conteneurs.
- Définissez la règle d'emplacement de l'autoscaler de cluster sur
ANY: configurez les pools de nœuds (en particulier pour les VM Spot ou à démarrage flexible) avec la règle d'emplacementANY. Ce paramètre indique à l'autoscaler de cluster de rechercher la capacité demandée dans toutes les zones spécifiées. L'autoscaler de cluster trouve la capacité en équilibrant le nombre de nœuds. Pour en savoir plus, consultez la présentation de l'autoscaler de cluster. - Optimisez l'utilisation des accélérateurs avec le partage de GPU : pour les charges de travail qui ne nécessitent pas de GPU dédié, utilisez le partage de temps GPU, les GPU multi-instance (MIG) ou NVIDIA MPS pour permettre à plusieurs conteneurs de partager un seul accélérateur. Cette approche optimise la capacité effective des pools de nœuds. Pour en savoir plus, consultez À propos des stratégies de partage de GPU dans GKE.
Utiliser Compute Advisor
Compute Advisor est une interface optimisée par l'IA dans la consoleGoogle Cloud , optimisée par Gemini, qui vous aide à concevoir des architectures résilientes et économiques pour GKE.
Compute Advisor fournit des conseils de disponibilité en temps quasi réel pour les VM Flex-start et les VM Spot, tout en vérifiant les règles et les quotas de ressources de votre organisation avant le déploiement. Compute Advisor ne fournit pas de conseils sur la disponibilité pour les charges de travail qui nécessitent des ressources à la demande.
Pour accéder à Gemini dans la console Google Cloud , procédez comme suit :
-
Dans la console Google Cloud , accédez à la page Présentation.
-
Dans la section Concevez votre infrastructure avec Compute Advisor, envoyez un prompt. Gemini commence à générer une réponse.
-
Pour générer des recommandations architecturales, exécutez l'un des exemples de requêtes suivants dans Compute Advisor. Lorsque vous cliquez sur les boutons Exécuter l'invite dans Compute Advisor, le chargement de la console Google Cloud peut prendre plus de 15 secondes :
Stratégie générale d'accélérateur :
Cas d'utilisation : utilisez cette requête pour analyser les signaux de capacité régionale et recevoir des recommandations sur les types de machines, les zones et les stratégies de planification de secours lors de la conception des configurations de cluster.
Configure a GKE cluster to improve chances of obtaining scarce GPU or TPU capacity.Flexibilité géographique et solutions de remplacement :
Cas d'utilisation : utilisez ce prompt lorsque vous concevez des architectures multiclusters ou des systèmes de mise en file d'attente de jobs globaux (par exemple, avec Kueue) pour déplacer l'exécution des charges de travail entre les régions en fonction de la disponibilité des ressources.
Configure multi-region fallbacks and geographic scheduling on GKE to increase GPU availability.Consommation des réservations prioritaires :
Cas d'utilisation : utilisez cette requête pour générer des modèles de configuration YAML pour les règles d'affinité de pod et d'autoscaling qui donnent la priorité à la capacité de réservation.
Configure GKE autoscaling rules and Pod specs to prioritize consuming active reservations before scaling into on-demand pools.ComputeClasses pour la priorisation du remplacement :
Cas d'utilisation : utilisez cette requête pour générer le fichier manifeste YAML pour une définition de ressource personnalisée ComputeClass qui donne la priorité aux GPU hautes performances, mais inclut des remplacements de niveau inférieur pour assurer la planification des charges de travail.
Define a ComputeClass manifest for GKE to prioritize A2 GPU nodes with automatic fallbacks to L4 or T4 GPUs.Création automatique de pools de nœuds pour la diversification :
Cas d'utilisation : utilisez cette requête pour rédiger le fichier manifeste YAML pour les limites de ressources de l'autoscaler de cluster GKE et les règles d'affinité de pod qui permettent au NAP de provisionner automatiquement des nœuds GPU ou CPU alternatifs.
Configure GKE node pool auto-creation to diversify machine families and prevent pending pods when regional accelerator capacity is constrained.
Étapes suivantes
- Concevoir et optimiser des clusters GKE avec Compute Advisor
- Configurer la création automatique de pools de nœuds
- Résoudre les problèmes liés à l'autoscaling horizontal des pods