Créer un cluster GKE personnalisé optimisé pour l'IA qui utilise A4X

Cette page vous explique comment créer un cluster Google Kubernetes Engine (GKE) optimisé pour l'IA qui utilise des machines virtuelles (VM) A4X pour prendre en charge vos charges de travail d'IA et de ML. Pour en savoir plus sur les VM A4X, consultez la section Série A4X.

La série de machines A4X est conçue 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 varié de charges de travail pour vos organisations, ce qui réduit la charge opérationnelle liée à la gestion de plusieurs plates-formes. Vous pouvez exécuter des charges de travail telles que 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 associés.

Sur cette page, vous allez apprendre à créer un cluster GKE avec Google Cloud CLI pour configurer votre cluster de manière aussi flexible que possible en fonction des besoins de votre charge de travail. Vous pouvez également choisir d'utiliser Cluster Toolkit pour déployer rapidement votre cluster avec des paramètres par défaut qui reflètent les bonnes pratiques pour de nombreux cas d'utilisation.

Pour en savoir plus, consultez Créer un cluster GKE optimisé pour l'IA avec la configuration par défaut.
Pour créer un cluster qui utilise A4 ou A3 Ultra, consultez Créer un cluster GKE personnalisé optimisé pour l'IA qui utilise A4 ou A3 Ultra.

Options de configuration de cluster avec GPUDirect RDMA

Pour créer votre cluster avec Google Cloud CLI, vous pouvez choisir l'une des options de configuration de cluster suivantes :

Si vous prévoyez d'exécuter des charges de travail d'IA distribuées : créez un cluster GKE avec GPUDirect RDMA en suivant les instructions de cette page.
Si vous ne prévoyez pas d'exécuter de charges de travail d'IA distribuées : créez un cluster GKE sans utiliser GPUDirect RDMA. Pour en savoir plus, consultez Créer un cluster sans GPUDirect-RDMA.

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 et 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.
Remarque : Pour les installations de la gcloud CLI existantes, veillez à définir la propriété compute/region. Si vous utilisez principalement des clusters zonaux, définissez plutôt compute/zone. En définissant un emplacement par défaut, vous pouvez éviter les erreurs gcloud CLI de ce type : One of [--zone, --region] must be supplied: Please specify location. Vous devrez peut-être spécifier l'emplacement dans certaines commandes si celui de votre cluster diffère de l'emplacement par défaut que vous avez défini.

Rôles requis

Pour obtenir les autorisations nécessaires pour créer et gérer un cluster GKE, demandez à votre administrateur de vous accorder les rôles IAM suivants sur le projet :

Administrateur de Kubernetes Engine (roles/container.admin)
Éditeur Cloud Build (roles/cloudbuild.builds.editor)
Administrateur de Compute (roles/compute.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 de l'espace de stockage (roles/storage.admin)

Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises avec des rôles personnalisés ou d'autres rôles prédéfinis.

Obtenir de la capacité

Vous pouvez obtenir de la capacité pour les VM A4X en créant une réservation future. Pour en savoir plus sur les réservations futures, consultez la colonne Réservations futures dans AI Hypercomputer du tableau Choisir une option de consommation.

Pour obtenir de la capacité avec une réservation future, consultez la ligne Réservations futures dans AI Hypercomputer du tableau Obtenir de la capacité.

Conditions requises

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

Pour A4X, assurez-vous d'utiliser la version 1.33.4-gke.1036000 ou ultérieure de GKE pour la version 1.33 ou ultérieure. Pour la version 1.32, utilisez GKE version 1.32.8-gke.1108000 ou ultérieure. Ces versions garantissent qu'A4X utilise les éléments suivants :
- R580, la version minimale du pilote GPU pour A4X.
- Coherent Driver-based Memory Management (CDMM), qui est activé par défaut. NVIDIA recommande aux clusters Kubernetes d'activer ce mode pour résoudre les problèmes de surdéclaration de mémoire. CDMM permet de gérer la mémoire GPU via le pilote au lieu du système d'exploitation. Cette approche vous aide à é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 CDMM est activé. Pour en savoir plus sur CDMM, consultez Assistance matérielle et logicielle.
- GPUDirect RDMA, qui est recommandé pour permettre aux pools de nœuds A4X d'utiliser les fonctionnalités réseau d'A4X.
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.
Votre charge de travail GKE doit utiliser tous les GPU disponibles, et votre pod doit utiliser toutes les cartes d'interface réseau secondaires disponibles sur un seul nœud GKE. Plusieurs pods ne peuvent pas partager RDMA sur un même nœud GKE.
Cette configuration exécute un test NCCL. Pour exécuter ce test NCCL, vous devez disposer d'un quota de VM d'au moins 2 (quatre GPU chacune lorsque vous utilisez a4x-highgpu-4g ou a4x-highgpu-4g-nolssd).
Vous devez utiliser le modèle de provisionnement lié à la réservation pour créer des clusters avec A4X. Les autres modèles de provisionnement ne sont pas acceptés.
GPUDirect RDMA n'est pas compatible avec NCCL Fast Socket ni avec GPUDirect-TCPX/TCPXO. N'activez pas NCCL Fast Socket et n'installez pas le plug-in TCPX/TCPXO sur les clusters qui utilisent GPUDirect RDMA.

Éléments à prendre en compte pour créer un cluster

Lorsque vous créez un cluster, tenez compte des informations suivantes :

Choisissez l'emplacement d'un cluster :
- Vérifiez que vous utilisez un emplacement où le type de machine que vous choisissez est disponible. Pour en savoir plus, consultez Emplacements des GPU.
- Pour les réservations denses, vous pouvez créer un cluster zonal. Dans ce cas, remplacez l'indicateur --region par l'indicateur --zone=COMPUTE_ZONE, où COMPUTE_ZONE correspond à la zone de votre plan de contrôle.
- Lorsque vous créez des pools de nœuds dans un cluster régional, vous pouvez utiliser l'option --node-locations pour spécifier les zones de vos nœuds GKE.
Choisissez une version du pilote :
- La version du pilote peut être l'une des valeurs suivantes :
  - default : installe la version de pilote par défaut pour la version de nœud GKE. Pour en savoir plus sur les exigences concernant les versions de pilote par défaut, consultez la section Exigences.
  - latest : installe la dernière version de pilote disponible pour votre version de GKE. Cette option n'est disponible que pour les nœuds qui utilisent Container-Optimized OS.
  - disabled : ignorer l'installation automatique du pilote. Vous devez installer manuellement un pilote après avoir créé le pool de nœuds.
- Pour en savoir plus sur les versions de pilote de GPU par défaut et les plus récentes pour les versions de nœud GKE, consultez le tableau de la section Installer manuellement des pilotes de GPU NVIDIA.
Choisir une affinité de réservation :
- Vous pouvez trouver des informations sur votre réservation, comme son nom ou celui d'un bloc spécifique. Pour trouver ces valeurs, consultez Afficher les demandes de réservations futures.
- L'indicateur --reservation-affinity peut prendre les valeurs specific ou any. Toutefois, pour les charges de travail d'IA distribuées à hautes performances, nous vous recommandons d'utiliser une réservation spécifique.
- Lorsque vous utilisez une réservation spécifique, y compris les réservations partagées, spécifiez la valeur de l'indicateur --reservation au format suivant :
```
projects/PROJECT_ID/reservations/RESERVATION_NAME/reservationBlocks/BLOCK_NAME
```
  Remplacez les valeurs suivantes :
  - PROJECT_ID : ID de votre projet Google Cloud .
  - RESERVATION_NAME : nom de votre réservation.
  - BLOCK_NAME : nom d'un bloc spécifique dans la réservation.
  Pour utiliser une réservation ciblée par sous-bloc afin que les VM soient placées sur un seul sous-bloc dans BLOCK_NAME, ajoutez ce qui suit à la fin du chemin d'accès :
```
/reservationSubBlocks/SUB_BLOCK_NAME
```
  Remplacez SUB_BLOCK_NAME par le nom du sous-bloc.
Remarque : Si la réservation se trouve dans le projet actuel, vous pouvez omettre projects/PROJECT_ID/reservations/de la valeur de réservation.

Créer un cluster GKE optimisé pour l'IA qui utilise A4X et GPUDirect RDMA

Pour les charges de travail d'IA distribuées, plusieurs nœuds GPU sont souvent associés pour fonctionner comme un seul ordinateur. A4X est une plate-forme exaflopique basée sur l'architecture rack NVIDIA GB200 NVL72. Ce type de machine permet de faire évoluer et de collaborer sur plusieurs GPU en offrant une expérience cloud hautes performances pour les charges de travail d'IA. Pour en savoir plus sur l'architecture réseau d'A4X, y compris sur la bande passante réseau et la configuration des cartes d'interface réseau, consultez Types de machines A4X.

Pour créer vos clusters GKE Standard avec A4X et GPUDirect RDMA, procédez comme suit (ces étapes sont décrites dans les sections suivantes) :

Créer des VPC et des sous-réseaux
Créer le cluster GKE avec le multiréseau
Créer les objets réseau GKE
Créer une règle de charge de travail
Créer un pool de nœuds avec A4X
Installer le binaire RDMA et configurer NCCL
Installer le pilote CRD et DRA du domaine de calcul NVIDIA

Créer des VPC et des sous-réseaux

Les VM A4X présentent la configuration suivante :

Quatre GPU NVIDIA B200 par machine virtuelle connectés avec NVLink
Deux processeurs NVIDIA Grace basés sur Arm
Quatre cartes d'interface réseau (NIC) CX-7 de 400 Gbit/s pour la mise en réseau GPU à GPU
Deux cartes d'interface réseau (NIC) Google Titanium de 200 Gbit/s pour les services externes

Les charges de travail d'IA et de ML, telles que l'entraînement distribué, nécessitent une accélération puissante pour optimiser les performances en réduisant les délais d'exécution des tâches. Pour les charges de travail nécessitant des performances, un débit et une latence élevés, GPUDirect RDMA réduit le nombre de sauts réseau nécessaires pour transférer des charges utiles vers et depuis les GPU. Cette approche utilise plus efficacement la bande passante réseau disponible.

L'une des cartes d'interface réseau Google Titanium associées au processeur utilise le réseau par défaut dans GKE. Vous n'avez donc pas besoin de créer un VPC pour cette carte d'interface réseau, à condition d'avoir suffisamment de plages d'adresses IP pour le réseau par défaut.

Vous pouvez créer un VPC pour la deuxième carte réseau Titanium (gVNIC) et un autre VPC pour les quatre cartes réseau CX-7 RDMA à l'aide des commandes suivantes.

Pour maximiser la bande passante du réseau, la commande permettant de créer un VPC pour les ensembles GVNIC supplémentaires définit l'unité de transmission maximale (MTU) sur 8 896. Le VPC RDMA est défini par défaut sur le paramètre recommandé de 8896. Pour en savoir plus, consultez Paramètres MTU et types de machines avec GPU.

Définissez les variables d'environnement pour qu'elles correspondent à votre déploiement :
```
export REGION="COMPUTE_REGION"
export ZONE="COMPUTE_ZONE"
export PROJECT="PROJECT_ID"
export GVNIC_NETWORK_PREFIX="GVNIC_NETWORK_PREFIX"
export RDMA_NETWORK_PREFIX="RDMA_NETWORK_PREFIX"
```
Remplacez les variables suivantes :
- COMPUTE_REGION : région de votre cluster.
- COMPUTE_ZONE : zone de votre pool de nœuds.
- PROJECT_ID : ID de votre projet Google Cloud .
- GVNIC_NETWORK_PREFIX : préfixe réseau GVNIC (par exemple, a4x-gvnic).
- RDMA_NETWORK_PREFIX : préfixe du réseau RDMA (par exemple, a4x-rdma).

Créez deux réseaux VPC :

# Create a VPC for the additional GVNIC
gcloud compute --project=${PROJECT} \
  networks create \
  GVNIC_NETWORK_PREFIX-net \
  --subnet-mode=custom \
  --mtu=8896

gcloud compute --project=${PROJECT} \
  networks subnets create \
  GVNIC_NETWORK_PREFIX-sub \
  --network=GVNIC_NETWORK_PREFIX-net \
  --region=${REGION} \
  --range=192.168.0.0/24

gcloud compute --project=${PROJECT} \
  firewall-rules create \
  GVNIC_NETWORK_PREFIX-internal \
  --network=GVNIC_NETWORK_PREFIX-net \
  --action=ALLOW \
  --rules=tcp:0-65535,udp:0-65535,icmp \
  --source-ranges=192.168.0.0/16

# Create HPC VPC for the RDMA NICs with 4 subnets.
gcloud compute --project=${PROJECT} \
  networks create RDMA_NETWORK_PREFIX-net \
  --network-profile=${ZONE}-vpc-roce \
  --subnet-mode=custom

# Create subnets for the HPC VPC.
for N in $(seq 0 3); do
  gcloud compute --project=${PROJECT} \
    networks subnets create \
    RDMA_NETWORK_PREFIX-sub-$N \
    --network=RDMA_NETWORK_PREFIX-net \
    --region=${REGION} \
    --range=192.168.$((N+1)).0/24 &  # offset to avoid overlap with gvnics
done

Créer le cluster GKE avec le multiréseau

Créez un cluster GKE Standard avec le multiréseau :
```
gcloud container clusters create CLUSTER_NAME \
    --enable-dataplane-v2 --enable-ip-alias --location=COMPUTE_REGION \
    --enable-multi-networking --cluster-version=CLUSTER_VERSION \
    --enable-kubernetes-unstable-apis=resource.k8s.io/v1beta1/deviceclasses,resource.k8s.io/v1beta1/resourceclaims,resource.k8s.io/v1beta1/resourceclaimtemplates,resource.k8s.io/v1beta1/resourceslices \
    [--services-ipv4-cidr=SERVICE_CIDR \
    --cluster-ipv4-cidr=POD_CIDR]
```
Lorsque vous préparez cette commande, procédez comme suit :
- Supprimez l'indicateur --enable-kubernetes-unstable-apis, qui permet d'activer DRA, lorsque vous créez un cluster exécutant GKE version 1.34 ou ultérieure. Cette option n'est nécessaire que lorsque vous créez un cluster exécutant la version 1.32 ou 1.33. Lorsque vous activez une API bêta, vous devez finir par migrer depuis l'API bêta lorsqu'elle est abandonnée et supprimée dans les versions mineures ultérieures de Kubernetes. Pour en savoir plus, consultez la section Abandons d'API bêta.
- Remplacez les éléments suivants :
  - CLUSTER_NAME : nom du cluster
  - CLUSTER_VERSION : version de votre nouveau cluster. Pour savoir quelle version de GKE est compatible avec votre configuration, consultez la section Conditions requises de ce document.
  - COMPUTE_REGION : nom de la région de calcul.
- Vous pouvez éventuellement fournir explicitement les plages CIDR secondaires pour les services et les pods. Si vous utilisez ces options facultatives, remplacez les variables suivantes :
  - SERVICE_CIDR : plage CIDR secondaire pour les services.
  - POD_CIDR : plage CIDR secondaire des pods.
  Lorsque vous utilisez ces indicateurs, vous devez vérifier que les plages CIDR ne chevauchent pas les plages de sous-réseaux pour les réseaux de nœuds supplémentaires. Par exemple, prenons SERVICE_CIDR=10.65.0.0/19 et POD_CIDR=10.64.0.0/19. Pour en savoir plus, consultez Ajouter des plages d'adresses IPv4 de pods.

Créer les objets réseau GKE

Vous devez configurer les réseaux VPC créés dans la section précédente à l'aide des ensembles de paramètres réseau GKE. Plus précisément, la deuxième carte d'interface réseau Titanium (gVNIC) du processeur doit être configurée en mode NetDevice, et chacune des quatre cartes d'interface réseau RDMA CX-7 doit être configurée en mode RDMA.

Cette commande utilise les noms suivants :

Le réseau VPC de l'interface réseau Titanium (gVNIC) du processeur est nommé GVNIC_NETWORK_PREFIX-net et le sous-réseau est nommé GVNIC_NETWORK_PREFIX-sub.
Le VPC des cartes d'interface réseau RDMA CX-7 est nommé RDMA_NETWORK_PREFIX-net, et les sous-réseaux sont nommés RDMA_NETWORK_PREFIX-sub-[0…3].

Créez les objets réseau GKE en exécutant la commande suivante :

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: gvnic-1
spec:
  vpc: GVNIC_NETWORK_PREFIX-net
  vpcSubnet: GVNIC_NETWORK_PREFIX-sub
  deviceMode: NetDevice
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: gvnic-1
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: gvnic-1
---
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: rdma-0
spec:
  vpc: RDMA_NETWORK_PREFIX-net
  vpcSubnet: RDMA_NETWORK_PREFIX-sub-0
  deviceMode: RDMA
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: rdma-0
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: rdma-0
---
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: rdma-1
spec:
  vpc: RDMA_NETWORK_PREFIX-net
  vpcSubnet: RDMA_NETWORK_PREFIX-sub-1
  deviceMode: RDMA
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: rdma-1
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: rdma-1
---
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: rdma-2
spec:
  vpc: RDMA_NETWORK_PREFIX-net
  vpcSubnet: RDMA_NETWORK_PREFIX-sub-2
  deviceMode: RDMA
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: rdma-2
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: rdma-2
---
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: rdma-3
spec:
  vpc: RDMA_NETWORK_PREFIX-net
  vpcSubnet: RDMA_NETWORK_PREFIX-sub-3
  deviceMode: RDMA
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: rdma-3
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: rdma-3
EOF

Créer une règle de charge de travail

Vous devez disposer d'une règle de charge de travail pour créer une partition. Pour en savoir plus, consultez la Règle de charge de travail pour les MIG.

Créez une règle de charge de travail HIGH_THROUGHPUT avec le champ accelerator_topology défini sur 1x72.

gcloud beta compute resource-policies create workload-policy WORKLOAD_POLICY_NAME \
    --type HIGH_THROUGHPUT \
    --accelerator-topology 1x72 \
    --project PROJECT \
    --region COMPUTE_REGION

Remplacez les éléments suivants :

WORKLOAD_POLICY_NAME : nom de votre règle de charge de travail.
PROJECT : nom de votre projet.
COMPUTE_REGION : nom de la région de calcul.

Créer un pool de nœuds avec A4X

Nous vous recommandons de créer un pool de nœuds qui utilise le plug-in de périphérique GPU GKE. Ce plug-in permet la gestion des ressources GPU gérées par GKE. Cette approche présente les avantages suivants :

Facilité de déploiement et de mise à niveau
Installation automatique des pilotes
Fonctionnalités des GPU gérées par GKE, telles que les métriques et les GPU partitionnés
Corrections de failles de sécurité essentielles

Vous pouvez également utiliser l'opérateur GPU NVIDIA, si votre cas d'utilisation l'exige. Pour en savoir plus, consultez Pourquoi utiliser l'opérateur GPU NVIDIA ?.

Créer un pool de nœuds A4X avec le plug-in de périphérique GPU GKE

Créez un pool de nœuds A4X qui utilise le plug-in d'appareil GPU GKE :

gcloud container node-pools create NODE_POOL_NAME \
    --location COMPUTE_REGION \
    --node-locations COMPUTE_ZONE \
    --cluster CLUSTER_NAME \
    --num-nodes=NODE_COUNT \
    --machine-type MACHINE_TYPE \
    --accelerator type=nvidia-gb200,count=4,gpu-driver-version=DRIVER_VERSION \
    --additional-node-network network=GVNIC_NETWORK_PREFIX-net,subnetwork=GVNIC_NETWORK_PREFIX-sub \
    --additional-node-network network=RDMA_NETWORK_PREFIX-net,subnetwork=RDMA_NETWORK_PREFIX-sub-0 \
    --additional-node-network network=RDMA_NETWORK_PREFIX-net,subnetwork=RDMA_NETWORK_PREFIX-sub-1 \
    --additional-node-network network=RDMA_NETWORK_PREFIX-net,subnetwork=RDMA_NETWORK_PREFIX-sub-2 \
    --additional-node-network network=RDMA_NETWORK_PREFIX-net,subnetwork=RDMA_NETWORK_PREFIX-sub-3 \
    --scopes "https://www.googleapis.com/auth/cloud-platform" \
    --reservation-affinity=specific \
    --reservation=RESERVATION_NAME/reservationBlocks/BLOCK_NAME \
    --placement-policy=WORKLOAD_POLICY_NAME

Remplacez les éléments suivants :

NODE_POOL_NAME : nom du pool de nœuds.
COMPUTE_REGION : région de votre cluster.
COMPUTE_ZONE : zone de votre pool de nœuds.
CLUSTER_NAME : nom du cluster
NODE_COUNT : nombre de nœuds pour le pool de nœuds, qui doit être inférieur ou égal à 18. 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.
MACHINE_TYPE : a4x-highgpu-4g ou a4x-highgpu-4g-nolssd, selon que vous souhaitez ou non utiliser des disques SSD locaux.
DRIVER_VERSION : version du pilote NVIDIA à installer. Elle peut être l'une des valeurs suivantes : default, latest ou disabled.
RESERVATION_NAME : nom de votre réservation. Pour trouver cette valeur, consultez Afficher les demandes de réservations futures.
BLOCK_NAME : nom d'un bloc spécifique dans la réservation. Pour trouver cette valeur, consultez Afficher les demandes de réservations futures.
WORKLOAD_POLICY_NAME : nom de la règle de charge de travail que vous avez créée précédemment.

Créer un pool de nœuds A4X avec l'opérateur GPU NVIDIA

Vous pouvez également utiliser l'opérateur GPU NVIDIA en procédant comme suit :

Exécutez la commande gcloud container node-pools create de la section précédente en apportant les modifications suivantes :
- Remplacez gpu-driver-version=latest par gpu-driver-version=disabled. Cette modification ignore l'installation automatique des pilotes de GPU, car ceux-ci ne sont pas compatibles avec l'opérateur GPU NVIDIA.
- Définissez --node-labels="gke-no-default-nvidia-gpu-device-plugin=true" pour désactiver le DaemonSet ciblant le plug-in des appareils GPU gérés par GKE.
Appliquez le fichier manifeste du DaemonSet du programme d'installation des pilotes de GPU GKE. Ce fichier manifeste déploie un pod d'installation de pilote GPU sur chaque nœud A4X :
```
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/refs/heads/master/nvidia-driver-installer/cos/daemonset-preloaded.yaml
```

Gérer la pile de GPU avec l'opérateur GPU NVIDIA sur Google Kubernetes Engine (GKE) :

Dans la section Créer et configurer le pool de nœuds GPU, suivez les instructions à partir de l'étape permettant d'obtenir les identifiants d'authentification.

Installez l'opérateur GPU NVIDIA. Suivez toutes les étapes, mais remplacez la commande de la section référencée qui installe l'opérateur GPU NVIDIA à l'aide de Helm. Utilisez plutôt la commande suivante :

helm install --wait --generate-name \
  -n gpu-operator \
  nvidia/gpu-operator \
  --version="25.3.0" \
  -f <(cat <<EOF
hostPaths:
  driverInstallDir: /home/kubernetes/bin/nvidia
toolkit:
  installDir: /home/kubernetes/bin/nvidia
cdi:
  enabled: true
  default: true
driver:
  enabled: false

daemonsets:
  tolerations:
    - key: nvidia.com/gpu
      operator: Equal
      value: present
      effect: NoSchedule
    - key: kubernetes.io/arch
      operator: Equal
      value: arm64
      effect: NoSchedule

node-feature-discovery:
  worker:
    tolerations:
      - key: kubernetes.io/arch
        operator: Equal
        value: arm64
        effect: NoSchedule
      - key: "node-role.kubernetes.io/master"
        operator: "Equal"
        value: ""
        effect: "NoSchedule"
      - key: "node-role.kubernetes.io/control-plane"
        operator: "Equal"
        value: ""
        effect: "NoSchedule"
      - key: nvidia.com/gpu
        operator: Exists
        effect: NoSchedule
EOF
)

Installer le binaire RDMA et configurer NCCL

Appliquez le DaemonSet suivant pour installer les binaires RDMA et la bibliothèque NCCL sur chaque nœud. Sur chaque VM sous-jacente, les binaires RDMA sont installés dans le répertoire /home/kubernetes/bin/gib et la bibliothèque NCCL est installée dans le répertoire /home/kubernetes/bin/nvidia/lib64.

  kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/gpudirect-rdma/nccl-rdma-installer-a4x.yaml

Installer le CRD du domaine de calcul NVIDIA et le pilote DRA

Installez le pilote CRD et DRA du domaine de calcul NVIDIA. Pour en savoir plus, consultez Pilote NVIDIA DRA pour les GPU.

Vérifiez que Helm est installé dans votre environnement de développement. Helm est préinstallé sur Cloud Shell.

Bien qu'aucune version Helm spécifique ne soit requise, vous pouvez utiliser la commande suivante pour vérifier que Helm est bien installé.
```
helm version
```
Si le résultat renvoie Command helm not found, vous pouvez installer la CLI Helm en exécutant la commande suivante :
```
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 \
  && chmod 700 get_helm.sh \
  && ./get_helm.sh
```

Ajoutez le dépôt Helm NVIDIA :

helm repo add nvidia https://helm.ngc.nvidia.com/nvidia \
  && helm repo update

Créez un ResourceQuota pour le pilote DRA :

export POD_QUOTA=POD_QUOTA

kubectl create ns nvidia-dra-driver-gpu

kubectl apply -n nvidia-dra-driver-gpu -f - << EOF
apiVersion: v1
kind: ResourceQuota
metadata:
  name: nvidia-dra-driver-gpu-quota
spec:
  hard:
    pods: ${POD_QUOTA}
  scopeSelector:
    matchExpressions:
    - operator: In
      scopeName: PriorityClass
      values:
        - system-node-critical
        - system-cluster-critical
EOF

Remplacez POD_QUOTA par un nombre au moins deux fois supérieur au nombre de nœuds A4X du cluster, plus 1. Par exemple, vous devez définir la variable sur au moins 37 si votre cluster comporte 18 nœuds A4X.

Installez le pilote DRA :

helm install nvidia-dra-driver-gpu nvidia/nvidia-dra-driver-gpu \
    --version="DRA_DRIVER_VERSION" \
    --create-namespace \
    --namespace nvidia-dra-driver-gpu \
    -f <(cat <<EOF
nvidiaDriverRoot: /home/kubernetes/bin/nvidia
resources:
  gpus:
    enabled: false

controller:
  affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: "nvidia.com/gpu"
              operator: "DoesNotExist"

kubeletPlugin:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: cloud.google.com/gke-accelerator
                operator: In
                values:
                  - nvidia-gb200
              - key: kubernetes.io/arch
                operator: In
                values:
                  - arm64

  tolerations:
    - key: nvidia.com/gpu
      operator: Equal
      value: present
      effect: NoSchedule
    - key: kubernetes.io/arch
      operator: Equal
      value: arm64
      effect: NoSchedule
EOF
)

Remplacez DRA_DRIVER_VERSION par la version 25.3.1 ou ultérieure. Vous pouvez trouver la liste des versions de pilote NVIDIA DRA disponibles en exécutant la commande helm search repo nvidia/nvidia-dra-driver-gpu --versions. Vous pouvez également trouver une version disponible en consultant les notes de version GitHub.

Configurer le fichier manifeste de votre charge de travail pour le multiréseau, RDMA et le domaine IMEX

Ajoutez les annotations suivantes aux métadonnées du pod :

metadata:
  annotations:
    networking.gke.io/default-interface: 'eth0'
    networking.gke.io/interfaces: |
      [
        {"interfaceName":"eth0","network":"default"},
        {"interfaceName":"eth2","network":"rdma-0"},
        {"interfaceName":"eth3","network":"rdma-1"},
        {"interfaceName":"eth4","network":"rdma-2"},
        {"interfaceName":"eth5","network":"rdma-3"}
      ]

Ajoutez une règle d'affinité de nœuds pour planifier sur les nœuds Arm :

spec:
affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/arch
          operator: In
          values:
          - arm64

Pour en savoir plus, consultez Planifier la charge de travail sur une seule architecture.

Ajoutez les volumes suivants à la spécification de pod :

spec:
volumes:
  - name: library-dir-host
    hostPath:
      path: /home/kubernetes/bin/nvidia
  - name: gib
    hostPath:
      path: /home/kubernetes/bin/gib

Ajoutez les installations de volume, la variable d'environnement et la ressource suivantes au conteneur qui demande des GPU. Le conteneur de votre charge de travail doit demander les quatre GPU :

containers:
- name: my-container
  volumeMounts:
    - name: library-dir-host
      mountPath: /usr/local/nvidia
    - name: gib
   mountPath: /usr/local/gib
  env:
    - name: LD_LIBRARY_PATH
      value: /usr/local/nvidia/lib64
  resources:
    limits:
      nvidia.com/gpu: 4

Créez la ressource ComputeDomain pour la charge de travail :

apiVersion: resource.nvidia.com/v1beta1
kind: ComputeDomain
metadata:
  name: a4x-compute-domain
spec:
  numNodes: NUM_NODES
  channel:
    resourceClaimTemplate:
      name: a4x-compute-domain-channel

Remplacez NUM_NODES par le nombre de nœuds requis par la charge de travail.

Spécifiez le resourceClaimTemplate que le pod utilisera :

spec:
  ...
  volumes:
    ...
  containers:
    - name: my-container
      ...
      resources:
        limits:
          nvidia.com/gpu: 4
  claims:
          - name: compute-domain-channel
        ...
resourceClaims:
  - name: compute-domain-channel
    resourceClaimTemplateName: a4x-compute-domain-channel

Définissez toutes les variables d'environnement requises pour configurer NCCL. Utilisez le script shell suivant à partir du conteneur de charge de travail :
```
source /usr/local/gib/scripts/set_nccl_env.sh
```

Une spécification de pod terminée ressemble à ce qui suit :

apiVersion: resource.nvidia.com/v1beta1
kind: ComputeDomain
metadata:
  name: a4x-compute-domain
spec:
  numNodes: NUM_NODES
  channel:
    resourceClaimTemplate:
      name: a4x-compute-domain-channel
---
apiVersion: apps/v1
kind: Pod
metadata:
  name: my-pod
  labels:
    k8s-app: my-pod
  annotations:
    networking.gke.io/default-interface: 'eth0'
    networking.gke.io/interfaces: |
      [
        {"interfaceName":"eth0","network":"default"},
        {"interfaceName":"eth2","network":"rdma-0"},
        {"interfaceName":"eth3","network":"rdma-1"},
        {"interfaceName":"eth4","network":"rdma-2"},
        {"interfaceName":"eth5","network":"rdma-3"},
      ]
spec:
  ...
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/arch
            operator: In
            values:
            - arm64
  volumes:
    - name: library-dir-host
      hostPath:
        path: /home/kubernetes/bin/nvidia
    - name: gib
      hostPath:
        path: /home/kubernetes/bin/gib
  containers:
    - name: my-container
      volumeMounts:
        - name: library-dir-host
          mountPath: /usr/local/nvidia
        - name: gib
       mountPath: /usr/local/gib
      env:
        - name: LD_LIBRARY_PATH
          value: /usr/local/nvidia/lib64
      resources:
        limits:
          nvidia.com/gpu: 4
        claims:
          - name: compute-domain-channel
        ...
resourceClaims:
  - name: compute-domain-channel
    resourceClaimTemplateName: a4x-compute-domain-channel

Tester les performances du réseau

Nous vous recommandons de valider le fonctionnement des clusters provisionnés. Pour ce faire, utilisez les tests NCCL/gIB, qui sont des tests NVIDIA Collective Communications Library (NCCL) optimisés pour l'environnement Google.

Étapes suivantes

Pour savoir comment planifier des charges de travail sur vos clusters GKE à l'aide de TAS et Kueue, consultez Planifier des charges de travail GKE avec la planification sensible à la topologie.
Pour savoir comment gérer les événements courants liés aux clusters GKE et aux charges de travail d'IA, consultez Gérer les clusters GKE optimisés pour l'IA.