Créer un cluster GKE optimisé pour l'IA avec Cluster Toolkit

Ce document explique comment créer un cluster Google Kubernetes Engine (GKE) optimisé pour l'IA qui utilise des instances Compute Engine A4X, A4, A3 Ultra, A3 Mega et A3 High (8 GPU) pour prendre en charge vos charges de travail d'IA et de ML.

Les séries de machines A4X, A4, A3 Ultra, A3 Mega et A3 High (8 GPU) sont conçues pour vous permettre d'exécuter des clusters d'IA/de ML à grande échelle avec des fonctionnalités telles que le placement ciblé des charges de travail, des contrôles avancés de maintenance des clusters et la planification tenant compte de la topologie. Pour en savoir plus, consultez la présentation de la gestion des clusters.

GKE fournit une plate-forme unique pour exécuter un ensemble diversifié de charges de travail répondant aux besoins de votre organisation. Ces charges de travail incluent le pré-entraînement distribué hautes performances, l'affinage de modèles, l'inférence de modèles, la diffusion d'applications et les services d'assistance. GKE réduit la charge opérationnelle liée à la gestion de plusieurs plates-formes.

Choisir comment créer un cluster GKE optimisé pour l'IA

Les options de création de cluster suivantes offrent chacune différents niveaux de facilité et de flexibilité pour la configuration du cluster et la planification des charges de travail :

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
    • Activer l'API Google Kubernetes Engine
  • Si vous souhaitez utiliser la Google Cloud CLI pour cette tâche, installez puis initialisez la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la commande gcloud components update. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.
  • Vérifiez que vous disposez des autorisations requises pour créer et gérer le cluster GKE et les comptes de service associés :
    • Administrateur Kubernetes Engine (roles/container.admin)
    • Administrateur de Compute (roles/compute.admin)
    • Administrateur de l'espace de stockage (roles/storage.admin)
    • Administrateur de projet IAM (roles/resourcemanager.projectIamAdmin)
    • Administrateur de compte de service (roles/iam.serviceAccountAdmin)
    • Utilisateur du compte de service (roles/iam.serviceAccountUser)
    • Consommateur Service Usage (roles/serviceusage.serviceUsageConsumer)
    • Administrateur des rôles (roles/iam.roleAdmin)
    • Gestionnaire des versions de secrets Secret Manager (roles/secretmanager.secretVersionManager)
    • Pour utiliser une réservation monoprojet : Administrateur d'instances Compute (v1) (roles/compute.instanceAdmin.v1) sur le projet
    • Pour utiliser une réservation partagée : Administrateur d'instances Compute (v1) (roles/compute.instanceAdmin.v1) sur le projet propriétaire et sur tout projet client dans lequel vous souhaitez utiliser la réservation

Choisir une option de consommation et obtenir de la capacité

Pour obtenir de la capacité, procédez comme suit :

  1. Choisissez une option de consommation : faites votre choix en fonction de la manière dont vous souhaitez obtenir et utiliser les ressources GPU. Pour en savoir plus, consultez Choisir une option de consommation.

    Pour GKE, tenez compte des informations supplémentaires suivantes lorsque vous choisissez une option d'utilisation :

  2. Obtenir de la capacité : le processus d'obtention de la capacité diffère pour chaque option de consommation. Pour en savoir plus sur le processus de l'option de consommation que vous avez choisie, consultez Présentation de la capacité.

Conditions requises

Les exigences suivantes s'appliquent à un cluster GKE optimisé pour l'IA :

  • Pour A4X Max, vous devez utiliser l'une des versions suivantes :

    • Pour la version 1.35 ou ultérieure, utilisez GKE version 1.35.0-gke.2745000 ou ultérieure.
    • Pour la version 1.34, utilisez GKE version 1.34.3-gke.1318000 ou ultérieure.

    Ces versions permettent de s'assurer qu'A4X Max utilise les éléments suivants :

    • R580.95.05, la version minimale du pilote de GPU pour A4X Max, qui est activée par défaut.
    • Gestion de la mémoire basée sur un pilote cohérent (CDMM), qui est activée par défaut. NVIDIA recommande aux clusters Kubernetes d'activer ce mode pour résoudre les problèmes de sur-reporting de la mémoire. CDMM permet de gérer la mémoire du GPU via le pilote plutôt que via le système d'exploitation (OS). Cette approche vous permet d'éviter la mise en ligne de la mémoire GPU par l'OS et expose la mémoire GPU en tant que nœud NUMA (Non-Uniform Memory Access) à l'OS. Les GPU multi-instances ne sont pas compatibles lorsque le CDMM est activé. Pour en savoir plus sur CDMM, consultez Compatibilité matérielle et logicielle.
    • GPUDirect RDMA et MNNVL, qui sont recommandés pour permettre aux pools de nœuds A4X Max d'utiliser les fonctionnalités réseau d'A4X Max.

  • Pour A4X, vous devez utiliser l'une des versions suivantes :

    • Pour la version 1.33 ou ultérieure, utilisez GKE version 1.33.4-gke.1036000 ou ultérieure.
    • Pour la version 1.32, utilisez GKE version 1.32.8-gke.1108000 ou ultérieure.

    Ces versions permettent de s'assurer qu'A4X utilise les éléments suivants :

    • R580, la version minimale du pilote de GPU pour A4X, qui est activée par défaut.
    • Gestion de la mémoire basée sur un pilote cohérent (CDMM), qui est activée par défaut. NVIDIA recommande aux clusters Kubernetes d'activer ce mode pour résoudre les problèmes de sur-reporting de la mémoire. CDMM permet de gérer la mémoire du GPU via le pilote plutôt que via le système d'exploitation (OS). Cette approche vous permet d'éviter la mise en ligne de la mémoire GPU par l'OS et expose la mémoire GPU en tant que nœud NUMA (Non-Uniform Memory Access) à l'OS. Les GPU multi-instances ne sont pas compatibles lorsque le CDMM est activé. Pour en savoir plus sur CDMM, consultez Compatibilité matérielle et logicielle.
    • GPUDirect RDMA et MNNVL, qui sont recommandés pour permettre aux pools de nœuds A4X d'utiliser les fonctionnalités de mise en réseau d'A4X.

  • Assurez-vous d'utiliser la version minimale du pilote de GPU, en fonction du type de machine :

    • A4X Max : les GPU GB300 des instances Bare Metal A4X Max nécessitent au moins la version R580.95.05 du pilote GPU. Consultez les exigences de version mentionnées précédemment.
    • A4X : les GPU GB200 des instances A4X nécessitent au minimum la version R580 du pilote de GPU. Consultez les exigences de version mentionnées précédemment.
    • A4 : les GPU B200 des instances A4 nécessitent au moins la version R570 du pilote GPU. Par défaut, GKE installe automatiquement cette version du pilote sur tous les nœuds A4 exécutant la version minimale requise pour A4, à savoir 1.32.1-gke.1729000 ou une version ultérieure.
    • A3 Ultra : les GPU H200 des instances A3 Ultra nécessitent au minimum la version de pilote GPU R550, qui est disponible dans GKE 1.31 en tant que version de pilote latest. Pour A3 Ultra, vous devez définir gpu-driver-version=latest avec GKE 1.31. Pour GKE 1.31.5-gke.1169000 ou version ultérieure, GKE installe automatiquement par défaut les versions de pilote de GPU R550 sur les nœuds A3 Ultra.
    • A3 Mega et A3 High : les GPU H100 des instances A3 High et A3 Mega sont compatibles avec la version du pilote de GPU par défaut dans toutes les versions de GKE compatibles. Vous pouvez également définir gpu-driver-version=latest pour accéder aux pilotes de production plus récents disponibles sur les versions de GKE compatibles.

  • Pour les pools de nœuds A3 Ultra, vous devez définir le type de disque sur hyperdisk-balanced.

  • Pour utiliser GPUDirect RDMA, utilisez les versions minimales suivantes en fonction du type de machine :

    • A4X Max : consultez les exigences de version mentionnées précédemment.
    • A4X : consultez les exigences de version mentionnées précédemment.
    • A4 : utilisez la version 1.32.2-gke.1475000 ou une version ultérieure.
    • A3 Ultra : utilisez la version 1.31.4-gke.1183000 ou une version ultérieure.

  • Pour utiliser GPUDirect-TCPXO (pour A3 Mega) et GPUDirect-TCPX (pour A3 High), utilisez les versions de GKE suivantes :

    • A3 High : utilisez n'importe quelle version de GKE disponible antérieure à la version 1.34.
    • A3 Mega : utilisez n'importe quelle version de GKE disponible.

  • Pour utiliser GPUDirect RDMA, les nœuds GKE doivent utiliser une image de nœud Container-Optimized OS. Les images de nœuds Ubuntu et Windows ne sont pas acceptées.

  • Vous devez utiliser le modèle de provisionnement lié à la réservation pour créer des clusters avec A4X Max et A4X. Les autres modèles de provisionnement ne sont pas acceptés.

Créer un cluster avec Cluster Toolkit

Suivez les instructions ci-dessous pour créer un cluster à l'aide de Cluster Toolkit. Cette section vous guide tout au long du processus de création de cluster, en veillant à ce que votre projet suive les bonnes pratiques et réponde aux exigences d'un cluster GKE optimisé pour l'IA. Cette section vous explique également comment utiliser Terraform pour provisionner et gérer l'infrastructure de votre déploiement.

A4X Max

  1. Lancez Cloud Shell. Vous pouvez utiliser un autre environnement. Toutefois, nous vous recommandons Cloud Shell, car les dépendances sont déjà préinstallées pour Cluster Toolkit. Si vous ne souhaitez pas utiliser Cloud Shell, suivez les instructions pour installer les dépendances afin de préparer un autre environnement.

  2. Installez Cluster Toolkit.

  3. Créez un bucket Cloud Storage avec la gestion des versions activée pour stocker l'état de votre déploiement Terraform :

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    Remplacez les variables suivantes :

    • BUCKET_NAME : nom du nouveau bucket Cloud Storage, qui doit respecter les exigences de dénomination des buckets.
    • PROJECT_ID : ID de votre projet Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE : région de calcul dans laquelle vous souhaitez stocker l'état du déploiement Terraform.

  4. Dans le plan examples/gke-a4x-max-bm/gke-a4x-max-bm-deployment.yaml du dépôt GitHub, renseignez les paramètres suivants dans les sections terraform_backend_defaults et vars pour qu'ils correspondent aux valeurs spécifiques de votre déploiement :

    • BUCKET : nom du bucket Cloud Storage que vous avez créé à l'étape précédente.
    • PROJECT_ID : ID de votre projet Google Cloud .
    • DEPLOYMENT_NAME : nom unique du déploiement, qui doit comporter entre 6 et 30 caractères. Si le nom du déploiement n'est pas unique dans un projet, la création du cluster échoue. La valeur par défaut est gke-a4x-max-bm.
    • REGION : région de calcul du cluster.
    • ZONE : zone de calcul du pool de nœuds des machines A4X Max. Cette zone doit correspondre à celle où les machines sont disponibles dans votre réservation.
    • STATIC_NODE_COUNT : nombre de nœuds A4X Max dans le pool de nœuds de votre cluster, qui doit être inférieur ou égal à 18 nœuds. Nous vous recommandons d'utiliser 18 nœuds pour obtenir la topologie GPU de 1x72 dans un sous-bloc à l'aide d'un domaine NVLink.
    • AUTHORIZED_CIDR : plage d'adresses IP que vous souhaitez autoriser à se connecter au cluster. Ce bloc CIDR doit inclure l'adresse IP de la machine qui appelle Terraform. Pour en savoir plus, consultez Fonctionnement des réseaux autorisés.

    • Pour le champ reservation, utilisez l'une des options suivantes, selon que vous souhaitez cibler des blocs spécifiques dans une réservation lorsque vous provisionnez le pool de nœuds :

    • Pour placer le pool de nœuds n'importe où dans la réservation, indiquez le nom de votre réservation (RESERVATION_NAME).

    • Pour cibler un bloc spécifique dans votre réservation, utilisez les noms de la réservation et du bloc au format suivant :

      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Si vous ne savez pas quels blocs sont disponibles dans votre réservation, consultez Afficher la topologie d'une réservation.

    • RESERVATION_PROJECT_ID : ID du projet Google Cloudcontenant la réservation. Votre réservation peut exister dans un projet différent de PROJECT_ID.

    • NUM_NODE_POOLS : nombre de pools de nœuds à activer dans votre cluster. Si vous souhaitez un cluster de plus de 18 nœuds, vous pouvez spécifier plusieurs pools de nœuds. La valeur par défaut est 1.

    Pour modifier les paramètres avancés, modifiez le fichier examples/gke-a4x-max-bm/gke-a4x-max-bm.yaml.

  5. Facultatif : Configurez Google Cloud Managed Lustre pour un stockage partagé hautes performances. Le plan GKE A4X Max active le pilote CSI Managed Lustre par défaut. Pour provisionner une instance Managed Lustre et un volume persistant avec votre cluster, procédez comme suit :

    1. Ouvrez le fichier examples/gke-a4x-max-bm/gke-a4x-max-bm.yaml.
    2. Dans la section vars, annulez la mise en commentaire sur les variables lustre_instance_id, lustre_size_gib et per_unit_storage_throughput.
    3. Dans la section # --- MANAGED LUSTRE ADDITIONS ---, annulez la mise en commentaire des modules private_service_access, lustre_firewall_rule, managed-lustre et lustre-pv.

  6. Générez des identifiants par défaut de l'application (ADC) pour fournir un accès à Terraform. Si vous utilisez Cloud Shell, exécutez la commande gcloud auth application-default login :

    gcloud auth application-default login

  7. Utilisez la commande gcluster deploy pour déployer le plan et provisionner l'infrastructure GKE à l'aide des types de machines A4X Max :

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a4x-max-bm/gke-a4x-max-bm-deployment.yaml \
    examples/gke-a4x-max-bm/gke-a4x-max-bm.yaml

  8. Lorsque vous y êtes invité, sélectionnez (A)pply pour déployer le plan.

    • Le plan crée des réseaux VPC, un réseau VPC GPU RDMA, des comptes de service, un cluster et un pool de nœuds.
    • Pour prendre en charge le modèle de job fio-bench-job-template dans le plan, des buckets, un espace de stockage réseau et des ressources de volume persistantGoogle Cloud sont créés.

A4X

  1. Lancez Cloud Shell. Vous pouvez utiliser un autre environnement. Toutefois, nous vous recommandons Cloud Shell, car les dépendances sont déjà préinstallées pour Cluster Toolkit. Si vous ne souhaitez pas utiliser Cloud Shell, suivez les instructions pour installer les dépendances afin de préparer un autre environnement.

  2. Installez Cluster Toolkit.

  3. Créez un bucket Cloud Storage avec la gestion des versions activée pour stocker l'état de votre déploiement Terraform :

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    Remplacez les variables suivantes :

    • BUCKET_NAME : nom du nouveau bucket Cloud Storage, qui doit respecter les exigences de dénomination des buckets.
    • PROJECT_ID : ID de votre projet Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE : région de calcul dans laquelle vous souhaitez stocker l'état du déploiement Terraform.

  4. Dans le plan examples/gke-a4x/gke-a4x-deployment.yaml du dépôt GitHub, renseignez les paramètres suivants dans les sections terraform_backend_defaults et vars pour qu'ils correspondent aux valeurs spécifiques de votre déploiement :

    • BUCKET : nom du bucket Cloud Storage que vous avez créé à l'étape précédente.
    • PROJECT_ID : ID de votre projet Google Cloud .
    • DEPLOYMENT_NAME : nom unique du déploiement, qui doit comporter entre 6 et 30 caractères. Si le nom du déploiement n'est pas unique dans un projet, la création du cluster échoue. La valeur par défaut est gke-a4x.
    • REGION : région de calcul du cluster.
    • ZONE : zone de calcul du pool de nœuds de machines A4X. Cette zone doit correspondre à la zone où les machines sont disponibles dans votre réservation.
    • STATIC_NODE_COUNT : nombre de nœuds A4X dans le pool de nœuds de votre cluster, qui doit être de 18 nœuds ou moins. Nous vous recommandons d'utiliser 18 nœuds pour obtenir la topologie GPU de 1x72 dans un sous-bloc à l'aide d'un domaine NVLink.
    • AUTHORIZED_CIDR : plage d'adresses IP que vous souhaitez autoriser à se connecter au cluster. Ce bloc CIDR doit inclure l'adresse IP de la machine qui appelle Terraform. Pour en savoir plus, consultez Fonctionnement des réseaux autorisés.

    • Pour le champ reservation, utilisez l'une des options suivantes, selon que vous souhaitez cibler des blocs spécifiques dans une réservation lorsque vous provisionnez le pool de nœuds :

    • Pour placer le pool de nœuds n'importe où dans la réservation, indiquez le nom de votre réservation (RESERVATION_NAME).

    • Pour cibler un bloc spécifique dans votre réservation, utilisez les noms de la réservation et du bloc au format suivant :

      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Si vous ne savez pas quels blocs sont disponibles dans votre réservation, consultez Afficher la topologie d'une réservation.

    • RESERVATION_PROJECT_ID : ID du projet Google Cloudcontenant la réservation. Votre réservation peut exister dans un projet différent de PROJECT_ID.

    • NUM_NODE_POOLS : nombre de pools de nœuds à activer dans votre cluster. Si vous souhaitez un cluster de plus de 18 nœuds, vous pouvez spécifier plusieurs pools de nœuds. La valeur par défaut est 1.

    Pour modifier les paramètres avancés, modifiez le fichier examples/gke-a4x/gke-a4x.yaml.

  5. Facultatif : Configurez Managed Lustre pour un stockage partagé hautes performances. Le plan GKE A4X active le pilote CSI Managed Lustre par défaut. Pour provisionner une instance Managed Lustre et un volume persistant avec votre cluster, procédez comme suit :

    1. Ouvrez le fichier examples/gke-a4x/gke-a4x.yaml.
    2. Dans la section vars, annulez la mise en commentaire sur les variables lustre_instance_id, lustre_size_gib et per_unit_storage_throughput.
    3. Dans la section # --- MANAGED LUSTRE ADDITIONS ---, annulez la mise en commentaire des modules private_service_access, lustre_firewall_rule, managed-lustre et lustre-pv.

  6. Générez des identifiants par défaut de l'application (ADC) pour fournir un accès à Terraform. Si vous utilisez Cloud Shell, exécutez la commande gcloud auth application-default login :

    gcloud auth application-default login

  7. Exécutez la commande gcluster deploy pour déployer le plan et provisionner l'infrastructure GKE à l'aide de types de machines A4X :

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a4x/gke-a4x-deployment.yaml \
    examples/gke-a4x/gke-a4x.yaml

  8. Lorsque vous y êtes invité, sélectionnez (A)pply pour déployer le plan.

    • Le plan crée des réseaux VPC, un réseau VPC GPU RDMA, des comptes de service, un cluster et un pool de nœuds.
    • Pour prendre en charge le modèle de job fio-bench-job-template dans le plan, des buckets, un espace de stockage réseau et des ressources de volume persistantGoogle Cloud sont créés.

A4

  1. Lancez Cloud Shell. Bien qu'il soit possible d'utiliser un autre environnement, nous vous recommandons d'utiliser Cloud Shell, car les dépendances sont déjà préinstallées pour Cluster Toolkit. Si vous ne souhaitez pas utiliser Cloud Shell, suivez les instructions pour installer les dépendances afin de préparer un autre environnement.

  2. Installez Cluster Toolkit.

  3. Créez un bucket Cloud Storage avec la gestion des versions activée pour stocker l'état de votre déploiement Terraform :

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    Remplacez les variables suivantes :

    • BUCKET_NAME : nom du nouveau bucket Cloud Storage, qui doit respecter les exigences de dénomination des buckets.
    • PROJECT_ID : ID de votre projet Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE : région de calcul dans laquelle vous souhaitez stocker l'état du déploiement Terraform.

  4. Choisissez une option de consommation pour votre déploiement GKE :

    Par défaut, le fichier de déploiement est configuré pour utiliser des réservations spécifiques. Pour utiliser un autre modèle de consommation (comme les VM Spot ou le mode de provisionnement à démarrage flexible), mettez à jour votre fichier YAML de déploiement. Pour en savoir plus, consultez Options de consommation GKE.

  5. Dans le plan examples/gke-a4/gke-a4-deployment.yaml du dépôt GitHub, renseignez les paramètres suivants dans les sections terraform_backend_defaults et vars pour qu'ils correspondent aux valeurs spécifiques de votre déploiement :

    • BUCKET : nom du bucket Cloud Storage que vous avez créé à l'étape précédente.
    • PROJECT_ID : ID de votre projet Google Cloud .
    • DEPLOYMENT_NAME : nom unique du déploiement, qui doit comporter entre 6 et 30 caractères. Si le nom du déploiement n'est pas unique dans un projet, la création du cluster échoue. La valeur par défaut est gke-a4.
    • REGION : région de calcul du cluster.
    • ZONE : zone de calcul du pool de nœuds de machines A4. Cette zone doit correspondre à la zone où les machines sont disponibles dans votre réservation.
    • AUTHORIZED_CIDR : plage d'adresses IP que vous souhaitez autoriser à se connecter au cluster. Ce bloc CIDR doit inclure l'adresse IP de la machine qui appelle Terraform. Pour en savoir plus, consultez Fonctionnement des réseaux autorisés.
    • Dans la section de réservation spécifique, configurez les paramètres suivants :

    • Dans le bloc reservation_affinity, dans la liste specific_reservations, spécifiez le champ name de la réservation :

      • Pour placer le pool de nœuds n'importe où dans la réservation, indiquez le nom de votre réservation (RESERVATION_NAME).
      • Pour cibler un bloc spécifique dans votre réservation, utilisez les noms de la réservation et du bloc au format suivant :
      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Si vous ne savez pas quels blocs sont disponibles dans votre réservation, consultez Afficher la topologie d'une réservation.

      Pour modifier les paramètres avancés, modifiez examples/gke-a4/gke-a4.yaml.

    Démarrage flexible

    1. Dans le plan examples/gke-a4/gke-a4-deployment.yaml du dépôt GitHub, renseignez les paramètres suivants dans les sections terraform_backend_defaults et vars pour qu'ils correspondent aux valeurs spécifiques de votre déploiement :

      • BUCKET : nom du bucket Cloud Storage que vous avez créé à l'étape précédente.
      • PROJECT_ID : ID de votre projet Google Cloud .
      • DEPLOYMENT_NAME : nom unique du déploiement, qui doit comporter entre 6 et 30 caractères. Si le nom du déploiement n'est pas unique dans un projet, la création du cluster échoue. La valeur par défaut est gke-a4.
      • REGION : région de calcul du cluster.
      • ZONE : zone de calcul du pool de nœuds de machines A4.
      • AUTHORIZED_CIDR : plage d'adresses IP que vous souhaitez autoriser à se connecter au cluster. Ce bloc CIDR doit inclure l'adresse IP de la machine que vous souhaitez utiliser pour appeler Terraform. Pour en savoir plus, consultez Fonctionnement des réseaux autorisés.
      • Supprimez le champ reservation et remplacez-le par enable_flex_start: true. Ajoutez enable_queued_provisioning: true sur la ligne suivante si vous souhaitez également utiliser le provisionnement en file d'attente. Pour en savoir plus, consultez Utiliser des pools de nœuds avec démarrage flexible et provisionnement en file d'attente.
      • Supprimez static_node_count.

    2. Dans le plan examples/gke-a4/gke-a4.yaml du dépôt GitHub, apportez les modifications suivantes :

      • Dans le bloc vars, supprimez static_node_count.
      • Dans le bloc vars, assurez-vous que le numéro version_prefix est "1.32." ou supérieur. Pour utiliser le démarrage flexible dans GKE, votre cluster doit utiliser la version 1.32.2-gke.1652000 ou une version ultérieure.
      • Dans le bloc vars, remplacez l'intégralité du bloc reservation (y compris la ligne reservation elle-même) par enable_flex_start: true et, éventuellement, enable_queued_provisioning: true.
      • Dans le bloc vars, si vous n'avez pas besoin du provisionnement en file d'attente, supprimez la ligne suivante : kueue_configuration_path: $(ghpc_stage("./kueue-configuration.yaml.tftpl")).
      • Sous id: a4-pool, supprimez la ligne suivante : static_node_count: $(vars.static_node_count).

      • Sous id: a4-pool, supprimez le bloc reservation_affinity. Remplacez ce bloc par les lignes suivantes :

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • Pour le provisionnement en file d'attente, si vous souhaitez l'activer, ajoutez les lignes supplémentaires suivantes :
          • enable_queued_provisioning: $(vars.enable_queued_provisioning)
          • autoscaling_total_min_nodes: 0

      • Sous id: workload-manager-install, supprimez le bloc suivant :

         kueue:
    install: true
    config_path: $(vars.kueue_configuration_path)
    config_template_vars:
       num_gpus: $(a3-ultragpu-pool.static_gpu_count)
       accelerator_type: $(vars.accelerator_type)

        • Pour le démarrage flexible avec provisionnement en file d'attente, procédez comme suit :

          1. Ajoutez gpu_nominal_quota: NOMINAL_QUOTA au bloc vars. La valeur gpu_nominal_quota est utilisée pour définir la valeur nominalQuota des GPU dans la spécification ClusterQueue (voir l'étape de définition de ClusterQueue ci-dessous). Dans cet exemple, ClusterQueue n'admet les charges de travail que si la somme des requêtes GPU est inférieure ou égale à la valeur NOMINAL_QUOTA. Pour en savoir plus sur ClusterQueue, consultez le document Kueue sur ClusterQueue.

          2. Mettez à jour le bloc kueue comme suit :

            kueue:
   install: true
   config_path: $(vars.kueue_configuration_path)
   config_template_vars:
      num_gpus: $(vars.gpu_nominal_quota)

          3. Remplacez le contenu du fichier kueue-configuration.yaml.tftpl par le code suivant :

            apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
   name: "default-flavor"
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: AdmissionCheck
metadata:
   name: dws-prov
spec:
   controllerName: kueue.x-k8s.io/provisioning-request
   parameters:
      apiGroup: kueue.x-k8s.io
      kind: ProvisioningRequestConfig
      name: dws-config
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ProvisioningRequestConfig
metadata:
   name: dws-config
spec:
   provisioningClassName: queued-provisioning.gke.io
   managedResources:
   - nvidia.com/gpu
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
   name: "dws-cluster-queue"
spec:
   namespaceSelector: {}
   resourceGroups:
   - coveredResources: ["nvidia.com/gpu"]
      flavors:
      - name: "default-flavor"
      resources:
      - name: "nvidia.com/gpu"
         nominalQuota: ${num_gpus}
   admissionChecks:
   - dws-prov
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
   namespace: "default"
   name: "dws-local-queue"
spec:
   clusterQueue: "dws-cluster-queue"
---

      • Sous id: job-template, remplacez la variable node_count par 2.

    Spot

    1. Dans le plan examples/gke-a4/gke-a4-deployment.yaml du dépôt GitHub, renseignez les paramètres suivants dans les sections terraform_backend_defaults et vars pour qu'ils correspondent aux valeurs spécifiques de votre déploiement :

      • BUCKET : nom du bucket Cloud Storage que vous avez créé à l'étape précédente.
      • PROJECT_ID : ID de votre projet Google Cloud .
      • DEPLOYMENT_NAME : nom unique du déploiement, qui doit comporter entre 6 et 30 caractères. Si le nom du déploiement n'est pas unique dans un projet, la création du cluster échoue. La valeur par défaut est gke-a4.
      • REGION : région de calcul du cluster.
      • ZONE : zone de calcul du pool de nœuds de machines A4.
      • STATIC_NODE_COUNT : nombre de nœuds A4 dans votre cluster.
      • AUTHORIZED_CIDR : plage d'adresses IP que vous souhaitez autoriser à se connecter au cluster. Ce bloc CIDR doit inclure l'adresse IP de la machine que vous souhaitez utiliser pour appeler Terraform. Pour en savoir plus, consultez Fonctionnement des réseaux autorisés.
      • Remplacez l'intégralité du bloc reservation (y compris la ligne reservation elle-même) par spot: true.

    2. Dans le plan examples/gke-a4/gke-a4.yaml du dépôt GitHub, apportez les modifications suivantes :

      • Dans le bloc vars, remplacez l'intégralité du bloc reservation (y compris la ligne reservation elle-même) par spot: true.

      • Sous id: a4-pool, supprimez le bloc reservation_affinity. Remplacez ce bloc par la ligne suivante :

        • spot: $(vars.spot)

  6. Facultatif : Configurez Managed Lustre pour un stockage partagé hautes performances. Le plan GKE A4 active le pilote CSI Managed Lustre par défaut. Pour provisionner une instance Managed Lustre et un volume persistant avec votre cluster, procédez comme suit :

    1. Ouvrez le fichier examples/gke-a4/gke-a4.yaml.
    2. Dans la section vars, annulez la mise en commentaire sur les variables lustre_instance_id, lustre_size_gib et per_unit_storage_throughput.
    3. Dans la section # --- MANAGED LUSTRE ADDITIONS ---, annulez la mise en commentaire des modules private_service_access, lustre_firewall_rule, managed-lustre et lustre-pv.

  7. Générez des identifiants par défaut de l'application (ADC) pour fournir un accès à Terraform. Si vous utilisez Cloud Shell, exécutez la commande gcloud auth application-default login :

    gcloud auth application-default login

  8. Exécutez la commande gcluster deploy pour déployer le plan et provisionner l'infrastructure GKE à l'aide de types de machines A4 :

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a4/gke-a4-deployment.yaml \
    examples/gke-a4/gke-a4.yaml

  9. Lorsque vous y êtes invité, sélectionnez (A)pply pour déployer le plan.

    • Le plan crée des réseaux VPC, un réseau VPC GPU RDMA, des comptes de service, un cluster et un pool de nœuds.
    • Pour prendre en charge le modèle de job fio-bench-job-template dans le plan, des buckets, un espace de stockage réseau et des ressources de volume persistantGoogle Cloud sont créés.

A3 Ultra

  1. Lancez Cloud Shell. Bien qu'il soit possible d'utiliser un autre environnement, nous vous recommandons d'utiliser Cloud Shell, car les dépendances sont déjà préinstallées pour Cluster Toolkit. Si vous ne souhaitez pas utiliser Cloud Shell, suivez les instructions pour installer les dépendances afin de préparer un autre environnement.

  2. Installez Cluster Toolkit.

  3. Créez un bucket Cloud Storage avec la gestion des versions activée pour stocker l'état de votre déploiement Terraform :

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    Remplacez les variables suivantes :

    • BUCKET_NAME : nom du nouveau bucket Cloud Storage, qui doit respecter les exigences de dénomination des buckets.
    • PROJECT_ID : ID de votre projet Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE : région de calcul dans laquelle vous souhaitez stocker l'état du déploiement Terraform.

  4. Choisissez une option de consommation pour votre déploiement GKE :

    Par défaut, le fichier de déploiement est configuré pour utiliser des réservations spécifiques. Pour utiliser un autre modèle de consommation (comme les VM Spot ou le mode de provisionnement à démarrage flexible), mettez à jour votre fichier YAML de déploiement. Pour en savoir plus, consultez Options de consommation GKE.

  5. Dans le plan examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml du dépôt GitHub, renseignez les paramètres suivants dans les sections terraform_backend_defaults et vars pour qu'ils correspondent aux valeurs spécifiques de votre déploiement :

    • BUCKET : nom du bucket Cloud Storage que vous avez créé à l'étape précédente.
    • PROJECT_ID : ID de votre projet Google Cloud .
    • DEPLOYMENT_NAME : nom unique du déploiement, qui doit comporter entre 6 et 30 caractères. Si le nom du déploiement n'est pas unique dans un projet, la création du cluster échoue. La valeur par défaut est gke-a3-ultragpu.
    • REGION : région de calcul du cluster.
    • ZONE : zone de calcul du pool de nœuds des machines A3 Ultra. Cette zone doit correspondre à la zone où les machines sont disponibles dans votre réservation.
    • AUTHORIZED_CIDR : plage d'adresses IP que vous souhaitez autoriser à se connecter au cluster. Ce bloc CIDR doit inclure l'adresse IP de la machine qui appelle Terraform. Pour en savoir plus, consultez Fonctionnement des réseaux autorisés.
    • Dans la section de réservation spécifique, configurez les paramètres suivants :

    • Dans le bloc reservation_affinity, dans la liste specific_reservations, spécifiez le champ name de la réservation :

      • Pour placer le pool de nœuds n'importe où dans la réservation, indiquez le nom de votre réservation (RESERVATION_NAME).
      • Pour cibler un bloc spécifique dans votre réservation, utilisez les noms de la réservation et du bloc au format suivant :
      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Si vous ne savez pas quels blocs sont disponibles dans votre réservation, consultez Afficher la topologie d'une réservation.

    • STATIC_NODE_COUNT : nombre de nœuds A3 Ultra dans votre cluster.

      Pour modifier les paramètres avancés, modifiez examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml.

    Démarrage flexible

    1. Dans le plan examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml du dépôt GitHub, remplacez les variables suivantes dans les sections terraform_backend_defaults et vars par les valeurs spécifiques à votre déploiement :

      • BUCKET_NAME : nom du bucket Cloud Storage que vous avez créé à l'étape précédente.
      • DEPLOYMENT_NAME : nom unique du déploiement, qui doit comporter entre 6 et 30 caractères. Si le nom du déploiement n'est pas unique dans un projet, la création du cluster échoue.
      • PROJECT_ID : ID de votre projet Google Cloud .
      • COMPUTE_REGION : région de calcul du cluster.
      • COMPUTE_ZONE : zone de calcul du pool de nœuds des machines A3 Ultra.
      • IP_ADDRESS/SUFFIX : plage d'adresses IP que vous souhaitez autoriser à se connecter au cluster. Ce bloc CIDR doit inclure l'adresse IP de la machine que vous souhaitez utiliser pour appeler Terraform. Pour en savoir plus, consultez Fonctionnement des réseaux autorisés.
      • Supprimez le champ reservation et remplacez-le par enable_flex_start: true. Ajoutez enable_queued_provisioning: true sur la ligne suivante si vous souhaitez également utiliser le provisionnement en file d'attente. Pour en savoir plus, consultez Utiliser des pools de nœuds avec démarrage flexible et provisionnement en file d'attente.
      • Supprimez static_node_count.

    2. Dans le plan examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml du dépôt GitHub, apportez les modifications suivantes :

      • Dans le bloc vars, supprimez static_node_count.
      • Dans le bloc vars, remplacez le numéro version_prefix par "1.32." ou une version ultérieure. Pour utiliser le démarrage flexible dans GKE, votre cluster doit utiliser la version 1.32.2-gke.1652000 ou une version ultérieure.
      • Dans le bloc vars, remplacez l'intégralité du bloc reservation (y compris la ligne reservation elle-même) par enable_flex_start: true et, éventuellement, enable_queued_provisioning: true.
      • Dans le bloc vars, supprimez la ligne suivante : kueue_configuration_path: $(ghpc_stage("./kueue-configuration.yaml.tftpl")).
      • Sous id: a3-ultragpu-pool, supprimez la ligne suivante : static_node_count: $(vars.static_node_count).

      • Sous id: a3-ultragpu-pool, supprimez le bloc reservation_affinity. Remplacez ce bloc par les lignes suivantes :

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • Pour le provisionnement en file d'attente, si vous souhaitez l'activer, ajoutez les lignes supplémentaires suivantes :
          • enable_queued_provisioning: $(vars.enable_queued_provisioning)
          • autoscaling_total_min_nodes: 0

      • Sous id: workload-manager-install, supprimez le bloc suivant :

        config_path: $(vars.kueue_configuration_path)
config_template_vars:
  num_gpus: $(a4-pool.static_gpu_count)
  accelerator_type: $(vars.accelerator_type)

        • Pour le démarrage flexible avec provisionnement en file d'attente, suivez ces trois étapes :

          1. Ajoutez gpu_nominal_quota: NOMINAL_QUOTA au bloc vars. La valeur gpu_nominal_quota est utilisée pour définir le nominalQuota de GPU dans la spécification ClusterQueue. Dans cet exemple, le ClusterQueue n'admet les charges de travail que si la somme des requêtes GPU est inférieure ou égale à la valeur NOMINAL_QUOTA. Pour en savoir plus sur ClusterQueue, consultez le document Kueue sur ClusterQueue.

          2. Mettez à jour le bloc kueue comme suit :

            kueue:
   install: true
   config_path: $(vars.kueue_configuration_path)
   config_template_vars:
      num_gpus: $(vars.gpu_nominal_quota)

          3. Remplacez le contenu du fichier kueue-configuration.yaml.tftpl par le code suivant :

            apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
   name: "default-flavor"
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: AdmissionCheck
metadata:
   name: dws-prov
spec:
   controllerName: kueue.x-k8s.io/provisioning-request
   parameters:
      apiGroup: kueue.x-k8s.io
      kind: ProvisioningRequestConfig
      name: dws-config
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ProvisioningRequestConfig
metadata:
   name: dws-config
spec:
   provisioningClassName: queued-provisioning.gke.io
   managedResources:
   - nvidia.com/gpu
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
   name: "dws-cluster-queue"
spec:
   namespaceSelector: {}
   resourceGroups:
   - coveredResources: ["nvidia.com/gpu"]
      flavors:
      - name: "default-flavor"
      resources:
      - name: "nvidia.com/gpu"
         nominalQuota: ${num_gpus}
   admissionChecks:
   - dws-prov
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
   namespace: "default"
   name: "dws-local-queue"
spec:
   clusterQueue: "dws-cluster-queue"
---

        • Dans le champ id: job-template, remplacez la variable node_count par 2.

    Spot

    1. Dans le plan examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml du dépôt GitHub, renseignez les paramètres suivants dans les sections terraform_backend_defaults et vars pour qu'ils correspondent aux valeurs spécifiques de votre déploiement :

      • BUCKET_NAME : nom du bucket Cloud Storage que vous avez créé à l'étape précédente.
      • DEPLOYMENT_NAME : nom unique du déploiement, qui doit comporter entre 6 et 30 caractères. Si le nom du déploiement n'est pas unique dans un projet, la création du cluster échoue.
      • PROJECT_ID : ID de votre projet Google Cloud .
      • COMPUTE_REGION : région de calcul du cluster.
      • COMPUTE_ZONE : zone de calcul du pool de nœuds des machines A3 Ultra.
      • IP_ADDRESS/SUFFIX : plage d'adresses IP que vous souhaitez autoriser à se connecter au cluster. Ce bloc CIDR doit inclure l'adresse IP de la machine que vous souhaitez utiliser pour appeler Terraform. Pour en savoir plus, consultez Fonctionnement des réseaux autorisés.
      • Remplacez l'intégralité du bloc reservation (y compris la ligne reservation elle-même) par spot: true.
      • NODE_COUNT : nombre de nœuds A3 Ultra dans votre cluster.

    2. Dans le plan examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml du dépôt GitHub, apportez les modifications suivantes :

      • Dans le bloc vars, remplacez l'intégralité de la variable reservation par spot: true.

      • Dans la section id: a3-ultragpu-pool, supprimez le bloc reservation_affinity. Remplacez ce bloc par la ligne suivante :

        • spot: $(vars.spot)

  6. Facultatif : Configurez Managed Lustre pour un stockage partagé hautes performances. Le plan GKE A3 Ultra active le pilote CSI Managed Lustre par défaut. Pour provisionner une instance Managed Lustre et un volume persistant avec votre cluster, procédez comme suit :

    1. Ouvrez le fichier examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml.
    2. Dans la section vars, annulez la mise en commentaire sur les variables lustre_instance_id, lustre_size_gib et per_unit_storage_throughput.
    3. Dans la section # --- MANAGED LUSTRE ADDITIONS ---, annulez la mise en commentaire des modules private_service_access, lustre_firewall_rule, managed-lustre et lustre-pv.

  7. Générez des identifiants par défaut de l'application (ADC) pour fournir l'accès à Terraform. Si vous utilisez Cloud Shell, exécutez la commande gcloud auth application-default login :

    gcloud auth application-default login

  8. Utilisez la commande gcluster deploy pour déployer le plan et provisionner l'infrastructure GKE à l'aide de types de machines A3 Ultra :

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml \
    examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml

  9. Lorsque vous y êtes invité, sélectionnez (A)pply pour déployer le plan.

    • Le plan crée des réseaux VPC, un réseau VPC GPU RDMA, des comptes de service, un cluster et un pool de nœuds.
    • Pour prendre en charge le modèle de job fio-bench-job-template dans le plan, des buckets, un espace de stockage réseau et des ressources de volume persistantGoogle Cloud sont créés.

A3 Mega

  1. Lancez Cloud Shell. Bien qu'il soit possible d'utiliser un autre environnement, nous vous recommandons d'utiliser Cloud Shell, car les dépendances sont déjà préinstallées pour Cluster Toolkit. Si vous ne souhaitez pas utiliser Cloud Shell, préparez un autre environnement en suivant les instructions pour installer les dépendances.

  2. Installez Cluster Toolkit.

  3. Créez un bucket Cloud Storage avec la gestion des versions activée pour stocker l'état de votre déploiement Terraform :

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    Remplacez les variables suivantes :

    • BUCKET_NAME : nom du nouveau bucket Cloud Storage, qui doit respecter les exigences de dénomination des buckets.
    • PROJECT_ID : ID de votre projet Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE : région de calcul dans laquelle vous souhaitez stocker l'état du déploiement Terraform.

  4. Dans le plan examples/gke-a3-megagpu/gke-a3-megagpu-deployment.yaml du dépôt GitHub, remplacez les variables suivantes dans les sections terraform_backend_defaults et vars par les valeurs spécifiques à votre déploiement :

    • BUCKET : nom du bucket Cloud Storage que vous avez créé à l'étape précédente.
    • DEPLOYMENT_NAME : nom unique du déploiement, qui doit comporter entre 6 et 30 caractères. Si le nom du déploiement n'est pas unique dans un projet, la création du cluster échoue.
    • PROJECT_ID : ID de votre projet Google Cloud .
    • REGION : région de calcul du cluster.
    • ZONE : zone de calcul du pool de nœuds de machines A3 Mega. Cette zone doit correspondre à la zone où les machines sont disponibles dans votre réservation.
    • AUTHORIZED_CIDR : plage d'adresses IP que vous souhaitez autoriser à se connecter au cluster. Ce bloc CIDR doit inclure l'adresse IP de la machine qui appelle Terraform. Pour en savoir plus, consultez Fonctionnement des réseaux autorisés. Pour obtenir l'adresse IP de votre machine hôte, exécutez la commande curl -s https://ifconfig.me.

  5. Choisissez une option de consommation pour votre déploiement GKE :

    Par défaut, le fichier de déploiement est configuré pour utiliser des réservations standards ou futures. Pour utiliser un autre modèle de consommation (tel que la capacité à la demande, les VM Spot ou le mode de provisionnement à démarrage flexible), mettez à jour votre fichier YAML de déploiement. Pour en savoir plus, consultez Options de consommation GKE.

    Pour configurer une réservation, définissez les valeurs suivantes dans la section de réservation spécifique :

    • Dans le bloc reservation_affinity, dans la liste specific_reservations, spécifiez le champ name de la réservation :
    • Pour placer le pool de nœuds n'importe où dans la réservation, indiquez le nom de votre réservation (RESERVATION_NAME).

    • Pour cibler un bloc spécifique dans votre réservation, utilisez les noms de la réservation et du bloc au format suivant :

      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Si vous ne savez pas quels blocs sont disponibles dans votre réservation, consultez Afficher la topologie d'une réservation.

    • STATIC_NODE_COUNT : nombre de nœuds A3 Mega dans votre cluster.

    Pour modifier les paramètres avancés, modifiez le plan examples/gke-a3-megagpu/gke-a3-megagpu.yaml à partir du dépôt GitHub.

  6. Générez des identifiants par défaut de l'application (ADC) pour fournir un accès à Terraform. Si vous utilisez Cloud Shell, exécutez la commande gcloud auth application-default login :

    gcloud auth application-default login

  7. Utilisez la commande gcluster deploy pour déployer le plan et provisionner l'infrastructure GKE à l'aide des types de machines A3 Mega :

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a3-megagpu/gke-a3-megagpu-deployment.yaml \
    examples/gke-a3-megagpu/gke-a3-megagpu.yaml

  8. Lorsque vous y êtes invité, sélectionnez (A)pply pour déployer le plan. Le plan crée des réseaux VPC, des comptes de service, un cluster et un pool de nœuds.

A3 High

  1. Lancez Cloud Shell. Bien qu'il soit possible d'utiliser un autre environnement, nous vous recommandons d'utiliser Cloud Shell, car les dépendances sont déjà préinstallées pour Cluster Toolkit. Si vous ne souhaitez pas utiliser Cloud Shell, préparez un autre environnement en suivant les instructions pour installer les dépendances.

  2. Installez Cluster Toolkit.

  3. Créez un bucket Cloud Storage avec la gestion des versions activée pour stocker l'état de votre déploiement Terraform :

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    Remplacez les variables suivantes :

    • BUCKET_NAME : nom du nouveau bucket Cloud Storage, qui doit respecter les exigences de dénomination des buckets.
    • PROJECT_ID : ID de votre projet Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE : région de calcul dans laquelle vous souhaitez stocker l'état du déploiement Terraform.

  4. Dans le plan examples/gke-a3-highgpu/gke-a3-highgpu-deployment.yaml du dépôt GitHub, remplacez les variables suivantes dans les sections terraform_backend_defaults et vars par les valeurs spécifiques à votre déploiement :

    • BUCKET : nom du bucket Cloud Storage que vous avez créé à l'étape précédente.
    • DEPLOYMENT_NAME : nom unique du déploiement, qui doit comporter entre 6 et 30 caractères. Si le nom du déploiement n'est pas unique dans un projet, la création du cluster échoue.
    • PROJECT_ID : ID de votre projet Google Cloud .
    • REGION : région de calcul du cluster.
    • ZONE : zone de calcul du pool de nœuds de machines A3 High. Cette zone doit correspondre à la zone où les machines sont disponibles dans votre réservation.
    • AUTHORIZED_CIDR : plage d'adresses IP que vous souhaitez autoriser à se connecter au cluster. Ce bloc CIDR doit inclure l'adresse IP de la machine qui appelle Terraform. Pour en savoir plus, consultez Fonctionnement des réseaux autorisés. Pour obtenir l'adresse IP de votre machine hôte, exécutez la commande curl -s https://ifconfig.me.

  5. Choisissez une option de consommation pour votre déploiement GKE :

    Par défaut, le fichier de déploiement est configuré pour utiliser des réservations standards ou futures. Pour utiliser un autre modèle de consommation (tel que la capacité à la demande, les VM Spot ou le mode de provisionnement à démarrage flexible), mettez à jour votre fichier YAML de déploiement. Pour en savoir plus, consultez Options de consommation GKE.

    Pour configurer une réservation, définissez les valeurs suivantes dans la section de réservation spécifique :

    • Dans le bloc reservation_affinity, dans la liste specific_reservations, spécifiez le champ name de la réservation :
    • Pour placer le pool de nœuds n'importe où dans la réservation, indiquez le nom de votre réservation (RESERVATION_NAME).

    • Pour cibler un bloc spécifique dans votre réservation, utilisez les noms de la réservation et du bloc au format suivant :

      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Si vous ne savez pas quels blocs sont disponibles dans votre réservation, consultez Afficher la topologie d'une réservation.

    • STATIC_NODE_COUNT : nombre de nœuds A3 High dans votre cluster.

    Pour modifier les paramètres avancés, modifiez le plan examples/gke-a3-highgpu/gke-a3-highgpu.yaml à partir du dépôt GitHub.

  6. Générez des identifiants par défaut de l'application (ADC) pour fournir un accès à Terraform. Si vous utilisez Cloud Shell, exécutez la commande gcloud auth application-default login :

    gcloud auth application-default login

  7. Utilisez la commande gcluster deploy pour déployer le plan et provisionner l'infrastructure GKE à l'aide de types de machines A3 High :

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a3-highgpu/gke-a3-highgpu-deployment.yaml \
    examples/gke-a3-highgpu/gke-a3-highgpu.yaml

  8. Lorsque vous y êtes invité, sélectionnez (A)pply pour déployer le plan. Le plan crée des réseaux VPC, des comptes de service, un cluster et un pool de nœuds.

Exécuter des exemples de jobs Dynamic Workload Scheduler

Si vous avez provisionné votre cluster à l'aide de Dynamic Workload Scheduler (provisionnement à démarrage flexible ou provisionnement en file d'attente), vous pouvez valider la planification de la charge de travail en envoyant des exemples de jobs Kubernetes.

Pour en savoir plus sur les modes de provisionnement de Dynamic Workload Scheduler, consultez Démarrage flexible de Dynamic Workload Scheduler avec provisionnement en file d'attente.

Envoyer un exemple de job

Sélectionnez l'onglet correspondant à votre option de consommation :

Démarrage flexible

Cette tâche est facultative et ne s'applique que si vous avez provisionné votre cluster avec le démarrage flexible. Les charges de travail configurées pour le démarrage flexible nécessitent le sélecteur de nœud cloud.google.com/gke-flex-start: "true" dans leur spécification de pod.

  1. Envoyez l'exemple de job à démarrage flexible :

    kubectl apply -f examples/dws-sample-workloads/sample-job-flex.yaml

  2. Surveillez l'état de votre job et de vos pods :

    kubectl get jobs
kubectl describe job JOB_NAME
kubectl get pods
kubectl describe pod POD_NAME

    Remplacez les éléments suivants :

    • JOB_NAME : nom de votre job.
    • POD_NAME : nom de votre pod.

  3. Une fois le job terminé, supprimez les ressources du job :

    kubectl delete -f examples/dws-sample-workloads/sample-job-flex.yaml

Provisionnement en file d'attente

Cette tâche est facultative et ne s'applique que si vous avez provisionné votre cluster avec le provisionnement en file d'attente. Les charges de travail configurées pour le provisionnement en file d'attente nécessitent l'étiquette et l'annotation suivantes dans leur spécification de pod :

  • Libellé : kueue.x-k8s.io/queue-name: dws-local-queue
  • Annotation : provreq.kueue.x-k8s.io/maxRunDurationSeconds: "MAX_RUN_DURATION"

Pour en savoir plus, consultez Exigences concernant le fichier manifeste de charge de travail pour le provisionnement en file d'attente.

  1. Envoyez l'exemple de job de provisionnement en file d'attente :

    kubectl apply -f examples/dws-sample-workloads/sample-job-flex-queue.yaml

  2. Surveillez l'état de votre job et de vos pods :

    kubectl get jobs
kubectl describe job JOB_NAME
kubectl get pods
kubectl describe pod POD_NAME

    Remplacez les éléments suivants :

    • JOB_NAME : nom de votre job.
    • POD_NAME : nom de votre pod.

  3. Une fois le job terminé, supprimez les ressources du job :

    kubectl delete -f examples/dws-sample-workloads/sample-job-flex-queue.yaml

Tester les performances du réseau

Nous vous recommandons de valider la fonctionnalité des clusters provisionnés. Pour ce faire, utilisez les tests NCCL, qui sont des tests de la bibliothèque NVIDIA Collective Communications Library (NCCL) optimisés pour l'environnement Google.

Exécuter des benchmarks reproductibles

Après avoir créé un cluster à l'aide de Cluster Toolkit, vous pouvez reproduire des benchmarks de pré-entraînement pour de grands modèles de machine learning ouverts sur la série de machines de votre choix en suivant les recettes fournies sur GitHub.

Chaque recette vous fournit les instructions nécessaires pour effectuer les tâches suivantes :

  • Préparez votre environnement.
  • Exécutez le benchmark.
  • Analysez les résultats du benchmark. Cet examen inclut les résultats du benchmark et des journaux détaillés pour une analyse plus approfondie.

Pour afficher toutes les recettes disponibles pour l'entraînement et d'autres types de charges de travail, consultez le dépôt GitHub Recettes de GPU.

Nettoyer les ressources créées par Cluster Toolkit

Pour éviter que les ressources utilisées sur cette page ne soient facturées de manière récurrente, utilisez la commande gcluster destroy pour nettoyer les ressources provisionnées par Cluster Toolkit, y compris les réseaux VPC et le cluster GKE :

   cd ~/cluster-toolkit
   ./gcluster destroy CLUSTER_NAME/

Remplacez CLUSTER_NAME par le nom de votre cluster. Pour les clusters créés avec Cluster Toolkit, le nom du cluster est basé sur le nom DEPLOYMENT_NAME.

Étapes suivantes