Concevoir pour l'obtention de ressources sur GKE avec Gemini

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 tirant parti de Gemini dans Google Cloud et Compute Advisor (aperçu), 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, aux administrateurs de plate-forme et aux opérateurs qui gèrent l'infrastructure GKE et souhaitent optimiser la planification et la programmation de la capacité.

Présentation de la disponibilité des ressources sur GKE

La planification Kubernetes repose sur des demandes de ressources déclarées. Lors de la planification d'accélérateurs à grande échelle, tels que des GPU ou des TPU, des demandes de ressources strictes peuvent entraîner l'échec du scaling à la hausse des clusters si du matériel spécifique n'est pas disponible. Vous pouvez optimiser la disponibilité de la capacité sur GKE à l'aide des fonctionnalités suivantes :

  • Création automatique de pools de nœuds : création dynamique de pools de nœuds multifamiliaux.
  • Remplacements au niveau de la charge de travail : tolérances et sélecteurs de nœuds configurés pour accepter du matériel alternatif.
  • Planification 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 disponibilité des ressources sur GKE

Cette section fournit des recommandations pour augmenter la disponibilité de votre capacité lors de la planification de 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 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 la section Utiliser Compute Advisor.

Options de flexibilité matérielle

Pour optimiser la disponibilité de la capacité, vous pouvez demander à GKE d'éviter de lier les charges de travail à une seule famille de machines ou à un seul type d'accélérateur statique. Voici quelques 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 processeurs à 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 des pods avec une affinité de nœuds ou des tolérances qui permettent la planification sur plusieurs libellés de familles de machines, par exemple cloud.google.com/machine-family dans ["n2", "n2d", "c2d"]. Cette configuration permet à GKE de provisionner le pool qui dispose de la capacité disponible.

  • Pools de nœuds GPU :

    • Exemple principal : série A2 (GPU NVIDIA A100).
    • Exemples d'alternatives : L4 (IA/ML universelle) ou T4 (inférence).
    • Modèle d'implémentation : configurez des pools de nœuds ou des ComputeClasses distincts pour différents niveaux de GPU. Pour les charges de travail qui peuvent 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 de 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 compatibles avec des topologies de tranches 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 sélections principales et les 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 GPU A2 (A100) L4, T4 Cible de manière flexible les pools de nœuds GPU à moindre coût ou à plus 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.

Mettre en œuvre 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 ComputeClasses. Voici quelques bonnes pratiques :

  • Définir des ComputeClasses : créez des ressources ComputeClass qui spécifient une liste priorisée de familles de machines, de types de GPU ou de modèles de provisionnement. GKE tente de provisionner des nœuds à l'aide de la configuration la plus prioritaire disponible dans la classe. Une liste de remplacement priorisé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 la section Contrôler les attributs de nœud avec autoscaling à l'aide de ComputeClasses personnalisées.

  • Faire référence aux ComputeClasses dans les spécifications des pods : dans les spécifications des pods de votre charge de travail, utilisez le libellé cloud.google.com/compute-class pour cibler votre ComputeClass personnalisée au lieu d'une famille de machines ou d'un type de GPU spécifique. Pour en savoir plus, consultez la section Demander une ComputeClass dans une charge de travail.

  • Définir plusieurs tolérances : si vous n'utilisez pas de ComputeClasses, utilisez des règles d'affinité de nœuds dans les spécifications de vos pods qui autorisent une plage de familles de machines (par exemple, cloud.google.com/machine-family dans ["n2", "n2d"]). Pour en savoir plus, consultez la section Configurer la création automatique de pools de nœuds.

Flexibilité géographique et multirégionale sur GKE

Pour augmenter la disponibilité de la capacité, 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 un scaling automatique sur toutes les zones disponibles d'une région.

  • Fédération de clusters multirégionaux : pour les tâches asynchrones volumineuses (telles que l'inférence par lot hors connexion ou l'entraînement distribué), déployez un orchestrateur multicluster (tel que 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 exécutés 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 distribuer la capacité excédentaire dans différentes zones.

Autres bonnes pratiques pour la disponibilité de GKE

Au-delà de la diversification matérielle, intégrez ces bonnes pratiques GKE pour optimiser la réussite du scaling des clusters :

  • Mettre en œuvre le surprovisionnement des 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 la section À propos des tampons de capacité.
  • Utiliser le démarrage flexible avec provisionnement en file d'attente : pour les tâches d'entraînement de modèles d'IA et par lot volumineuses, utilisez le démarrage flexible avec 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 de nœuds atomique tout ou rien, ce qui évite les échecs partiels de scaling à la hausse des clusters. Pour en savoir plus, consultez la section Exécuter une charge de travail à grande échelle avec le démarrage flexible et le provisionnement en file d'attente.
  • Activer le streaming d'images et le préchargement d'images de conteneurs : pour les grandes images de conteneurs d'IA (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éparation 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 les sections Utiliser le streaming d'images pour extraire des images de conteneurs et Utiliser des disques de démarrage secondaires pour précharger des données ou des images de conteneurs.
  • Définir la stratégie de localisation de l'autoscaler de cluster sur ANY: configurez les pools de nœuds (en particulier pour les VM Spot ou le démarrage flexible) avec la ANY stratégie de localisation. Ce paramètre demande à 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.
  • Optimiser 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 dans les pools de nœuds. Pour en savoir plus, consultez la section À 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 Google Cloud console, alimentée par Gemini, qui vous aide à concevoir des architectures résilientes pour GKE. Compute Advisor fournit des conseils sur la disponibilité des VM à démarrage flexible et des VM Spot en temps quasi réel, tout en vérifiant les règles de votre organisation et les quotas de ressources 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 Google Cloud console, procédez comme suit :

  1. Dans la Google Cloud console, accédez à la page Présentation.

    Accéder à la page "Présentation"

  2. Dans la section Concevoir votre infrastructure avec Compute Advisor, envoyez un prompt. Gemini commence à générer une réponse.

  3. Pour générer des recommandations architecturales, exécutez l'un des exemples de prompts suivants dans Compute Advisor. Lorsque vous cliquez sur les boutons Exécuter le prompt dans Compute Advisor, le chargement de la Google Cloud console peut prendre plus de 15 secondes :

    • Stratégie générale d'accélérateur :

      Cas d'utilisation : utilisez ce prompt 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 remplacement lors de la conception de configurations de clusters.

      Configure a GKE cluster to improve chances of obtaining scarce GPU or TPU capacity.

      Exécuter le prompt dans Compute Advisor

    • Flexibilité géographique et remplacements:

      Cas d'utilisation : utilisez ce prompt lorsque vous concevez des architectures multiclusters ou des systèmes de mise en file d'attente de tâches globales (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.

      Exécuter le prompt dans Compute Advisor

    • Consommation de réservations prioritaires :

      Cas d'utilisation : utilisez ce prompt pour générer des modèles de configuration YAML pour l'affinité des pods et des règles 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.

      Exécuter le prompt dans Compute Advisor

    • ComputeClasses pour la priorisation des remplacements:

      Cas d'utilisation : utilisez ce prompt pour générer le fichier manifeste YAML d'une ComputeClass CustomResourceDefinition qui donne la priorité aux GPU hautes performances, mais inclut des remplacements de niveau inférieur pour garantir 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.

      Exécuter le prompt dans Compute Advisor

    • Création automatique de pools de nœuds pour la diversification :

      Cas d'utilisation : utilisez ce prompt pour écrire le fichier manifeste YAML pour les limites de ressources de l'autoscaler de cluster GKE et les règles d'affinité de pods qui permettent à NAP de provisionner automatiquement des nœuds GPU ou de processeur alternatifs.

      Configure GKE node pool auto-creation to diversify machine families and prevent pending pods when regional accelerator capacity is constrained.

      Exécuter le prompt dans Compute Advisor

Étape suivante