Configurer la mise en réseau automatisée pour les VM d'accélérateur

Ce document explique comment utiliser la mise en réseau automatisée pour les VM d'accélérateur, telles que les GPU et les TPU, afin de simplifier la configuration réseau pour les charges de travail d'accélérateur Google Kubernetes Engine (GKE). C'est essentiel pour exécuter l'intelligence artificielle (IA), le machine learning (ML) et le calcul hautes performances (HPC) sur des machines optimisées pour les accélérateurs.

Ce document part du principe que vous maîtrisez les concepts fondamentaux de GKE, les charges de travail GPU et TPU, ainsi que la mise en réseau VPC. Plus précisément, vous devez maîtriser les éléments suivants :

Cette page s'adresse aux architectes cloud et aux spécialistes de la mise en réseau qui conçoivent et implémentent le réseau de leur organisation. Pour obtenir une présentation de tous les ensembles de documentation GKE, consultez Explorer la documentation GKE. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenuGoogle Cloud , consultez Rôles utilisateur et tâches courantes de GKE.

GKE simplifie l'exécution de l'IA et du ML hautes performances sur des accélérateurs spécialisés. Avec la mise en réseau automatisée pour les VM d'accélérateur, vous pouvez activer la connectivité multiréseau à haut débit, essentielle pour les protocoles tels que RDMA, avec un seul indicateur de configuration. Cette automatisation élimine le processus manuel et complexe de configuration de plusieurs réseaux VPC, de gestion des plages d'adresses IP et de configuration des interfaces réseau pour chaque pool de nœuds et chaque pod. En utilisant un seul paramètre lors de la création d'un pool de nœuds, GKE fournit toutes les ressources réseau cloud et Kubernetes nécessaires.

Terminologie

Les termes suivants sont essentiels pour comprendre l'architecture réseau des VM avec accélérateur.

  • Cloud privé virtuel (VPC) : un VPC est une version virtuelle d'un réseau physique, implémentée au sein du réseau de production de Google. Il fournit une connectivité à vos instances de machines virtuelles (VM) Compute Engine, à vos clusters GKE et à d'autres ressources.
  • Carte d'interface réseau Titanium : carte d'interface réseau intelligente qui décharge les tâches de traitement réseau du processeur, ce qui permet à ce dernier de se concentrer sur vos charges de travail. Sur les machines GPU, ils gèrent tout le trafic qui n'est pas une communication directe GPU à GPU. Sur les machines TPU, toutes les cartes d'interface réseau sont des cartes Titanium.
  • Sous-réseau : un sous-réseau est une partie segmentée d'un VPC plus grand. Chaque sous-réseau est associé à une région et possède une plage d'adresses IP définie.
  • Contrôleur d'interface réseau (NIC) : une NIC est une interface réseau virtuelle qui connecte une instance de VM à un réseau. Chaque carte d'interface réseau est associée à un VPC et un sous-réseau spécifiques.
  • Réseau hôte : réseau principal utilisé par les principales interfaces réseau (NIC) du nœud pour la communication générale du cluster, comme le trafic du plan de contrôle et la mise en réseau régulière des pods.
  • Réseau de données : réseau dédié au transfert de données hautes performances entre les VM d'accélérateur. Pour les GPU, il s'agit souvent d'un VPC GPUDirect avec RDMA. Pour les TPU, il peut s'agir d'un deuxième réseau hôte.
  • Accès direct à la mémoire à distance(RDMA) : RDMA est une technologie qui permet aux périphériques réseau d'échanger des données directement avec la mémoire principale d'un ordinateur sans impliquer le système d'exploitation ni le processeur. Cela réduit considérablement la latence et améliore le débit, ce qui est essentiel pour les charges de travail HPC et de ML.
  • NVLink : NVLink est une technologie d'interconnexion à haut débit développée par NVIDIA pour connecter plusieurs GPU au sein d'un même nœud, ce qui leur permet de partager de la mémoire et de travailler ensemble sur de grands ensembles de données.
  • Allocation dynamique des ressources (DRA) Kubernetes : la DRA est une fonctionnalité Kubernetes qui permet aux pods de demander et de consommer des ressources de manière plus flexible, comme des GPU et d'autres matériels spécialisés. Il permet un contrôle précis de l'allocation des ressources.

Fonctionnement de la mise en réseau automatisée

Les machines optimisées pour les accélérateurs disposent d'une architecture réseau spécialisée pour prendre en charge la communication à haut débit et à faible latence entre les GPU et les TPU. Chaque machine physique contient plusieurs GPU ou TPU, souvent connectés par des interconnexions haut débit comme NVLink. Les machines disposent également d'une ou plusieurs cartes d'interface réseau pour la mise en réseau générale et de plusieurs cartes d'interface réseau GPU pour les interconnexions à haut débit.

Lorsque vous créez un nœud GKE qui utilise un type de machine optimisé pour les accélérateurs, GKE configure plusieurs cartes d'interface réseau sur la VM sous-jacente. Les cartes d'interface réseau de l'hôte se connectent aux réseaux VPC de l'hôte pour la communication et la gestion générales du cluster afin de communiquer avec le plan de contrôle. Les cartes d'interface réseau GPU se connectent à un réseau VPC dédié et hautes performances, souvent avec RDMA activé et un paramètre MTU élevé (8896), pour faciliter la communication GPUDirect.

Lorsqu'un pod demande des GPU ou des TPU, vous pouvez le configurer pour qu'il accède aux interfaces réseau hautes performances du nœud. Vous pouvez demander toutes les cartes d'interface réseau disponibles ou un sous-ensemble spécifique. Chaque interface réseau revendiquée est dédiée à un seul pod et n'est pas partagée. Cette configuration réseau garantit que le pod a un accès exclusif à la bande passante et aux ressources complètes de cette interface, ce qui constitue un avantage clé pour les charges de travail sensibles aux performances.

Limites

  • La mise en réseau automatisée pour les VM d'accélérateur n'est pas compatible avec les clusters Autopilot.
  • La mise en réseau automatisée nécessite que le cluster utilise GKE Dataplane V2.
  • Types de machines compatibles : la mise en réseau automatisée est compatible avec les familles de machines optimisées pour les accélérateurs A3, A4 et TPU Trillium (v6e).
  • Pools de nœuds à zone unique requis : vous devez utiliser un pool de nœuds avec une seule zone.
  • Lorsque vous utilisez DRANET géré par GKE pour configurer des charges de travail, consultez les points clés à prendre en compte et les limites pour DRANET géré par GKE.
  • Vous ne pouvez pas utiliser à la fois l'API multiréseau et DRANET dans le même pool de nœuds. Vous devez choisir une méthode d'association au réseau pour vos pods.

Configurations réseau des machines optimisées pour les accélérateurs

Les configurations réseau des machines optimisées pour les accélérateurs varient selon leur type. Le tableau suivant récapitule les spécifications réseau pour différents types de machines.

VM avec accélérateur GPU

Type de machine Number of GPUs Nombre de cartes réseau Titanium Nombre de cartes réseau GPU Technologie GPUDirect VPC supplémentaires
A3 8 (H100) 1 4 TCPX 4 pour les cartes d'interface réseau GPU
A3 Mega 8 (H100) 1 8 TCPXO 8 pour les cartes d'interface réseau GPU
A3 Ultra 8 (H200) 2 8 RDMA 2 (1 pour la deuxième carte d'interface réseau, 1 pour les cartes d'interface réseau GPU)
A4 8 (B200) 2 8 RDMA 2 (1 pour la deuxième carte d'interface réseau, 1 pour les cartes d'interface réseau GPU)
A4X 4 (GB200) 1 4 RDMA 2 (1 pour la deuxième carte d'interface réseau, 1 pour les cartes d'interface réseau GPU)

VM d'accélérateur TPU

Type de machine Nombre de puces TPU Nombre de cartes d'interface réseau VPC supplémentaires
TPU Trillium (v6e) (ct6e-standard-4t) 4 2 2 (1 pour la deuxième carte réseau, 1 pour la carte réseau virtuelle supplémentaire sur la première carte réseau)

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 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.

  • Assurez-vous que votre cluster utilise GKE version 1.34.1-gke.1829001 ou ultérieure.

  • Assurez-vous que votre cluster dispose de GKE Dataplane V2. Vous pouvez activer cette fonctionnalité lorsque vous créez un cluster ou que vous en mettez à jour un existant.

    • Créez un cluster :

      gcloud container clusters create CLUSTER_NAME \
  --cluster-version=CLUSTER_VERSION \
  --enable-dataplane-v2

      Remplacez les éléments suivants :

      • CLUSTER_NAME : nom de votre nouveau cluster
      • CLUSTER_VERSION : version de votre cluster, qui doit être 1.34.1-gke.1829001 ou ultérieure.

    • Mettez à jour un cluster existant :

      gcloud container clusters update CLUSTER_NAME \
    --enable-dataplane-v2

      Remplacez CLUSTER_NAME par le nom de votre cluster.

  • Si vous prévoyez de déployer des charges de travail GPU qui utilisent RDMA, vérifiez l'existence des ressources DeviceClass :

    kubectl get deviceclass mrdma.google.com

Créer un pool de nœuds avec un profil réseau par défaut

Pour créer automatiquement un réseau qui connecte toutes les machines GPU ou TPU d'une même zone, créez un pool de nœuds avec le profil réseau d'accélérateur auto.

gcloud

Pour créer un pool de nœuds avec un profil réseau configuré automatiquement, exécutez la commande suivante :

gcloud beta container node-pools create NODE_POOL_NAME \
    --accelerator-network-profile=auto \
    --node-locations=ZONE \
    --machine-type=MACHINE_TYPE

Pour en savoir plus sur la création de pools de nœuds avec des accélérateurs, consultez Exécuter des GPU dans des pools de nœuds Autopilot et Déployer des charges de travail TPU dans Autopilot. Lorsque vous suivez les instructions de ces documents, ajoutez l'indicateur --accelerator-network-profile=auto à la commande gcloud container node-pools create.

Pour les pools de nœuds de tranche TPU multi-hôtes, vous devez également ajouter l'indicateur --tpu-topology.

Remplacez les éléments suivants :

  • NODE_POOL_NAME : nom de votre nouveau pool de nœuds.
  • ZONE : zone du pool de nœuds.
  • MACHINE_TYPE : type de machine pour les nœuds, par exemple a3-ultragpu-8g.

REST

Dans une requête à la méthode nodePools.create, spécifiez le champ accelerator_network_profile :

{
  "nodePool": {
    "name": "NODE_POOL_NAME",
    "machineType": "MACHINE_TYPE",
    ...
    "accelerator_network_profile": "auto"
  }
}

Remplacez les éléments suivants :

  • NODE_POOL_NAME : nom de votre nouveau pool de nœuds.
  • MACHINE_TYPE : type de machine pour les nœuds, par exemple a3-ultragpu-8g.

Planifier une charge de travail qui utilise des GPU

Les sections suivantes vous expliquent comment configurer un pool de nœuds et une charge de travail GPU pour utiliser des interfaces réseau RDMA avec DRANET géré par GKE. Pour en savoir plus, consultez Allouer des ressources réseau à l'aide de DRANET géré par GKE.

Activer le pilote DRANET géré par GKE sur un pool de nœuds GPU

Pour activer le pilote GKE DRANET sur un pool de nœuds GPU compatible avec RDMA, ajoutez le libellé cloud.google.com/gke-networking-dra-driver=true lorsque vous créez le pool de nœuds.

gcloud beta container node-pools create NODE_POOL_NAME \
  --region=REGION \
  --cluster=CLUSTER_NAME \
  --node-locations=NODE_LOCATIONS \
  --accelerator type=ACCELERATOR_TYPE,count=ACCELERATOR_COUNT,gpu-driver-version=DRIVER_VERSION \
  --machine-type=MACHINE_TYPE \
  --num-nodes=NUM_NODES \
  --reservation-affinity=specific \
  --reservation=projects/RESERVATION_PROJECT/reservations/RESERVATION_NAME/reservationBlocks/RESERVATION_BLOCK \
  --accelerator-network-profile=auto \
  --node-labels=cloud.google.com/gke-networking-dra-driver=true

Remplacez les éléments suivants :

  • NODE_POOL_NAME : nom de votre nouveau pool de nœuds.
  • REGION : Google Cloud région de votre cluster.
  • CLUSTER_NAME : nom du cluster

  • ACCELERATOR_TYPE : type d'accélérateur GPU :

    Exemple :

    • VM A4 : saisissez nvidia-b200.
    • VM A3 Ultra : saisissez nvidia-h200-141gb.

  • ACCELERATOR_COUNT : nombre de GPU à associer aux nœuds du pool de nœuds. Par exemple, pour les VM a4-highgpu-8g et a3-ultragpu-8g, le nombre de GPU est de 8.

  • DRIVER_VERSION : version du pilote de GPU à utiliser. Par exemple, default ou latest.

  • MACHINE_TYPE : type de machine du pool de nœuds, par exemple a3-ultragpu-8g.

  • NUM_NODES : nombre de nœuds pour le pool de nœuds. Pour le démarrage flexible, cette valeur doit être définie sur 0.

  • RESERVATION_PROJECT : ID du projet de la réservation.

  • RESERVATION_NAME : nom de votre réservation. Pour trouver cette valeur, consultez Afficher les demandes de réservations futures.

  • RESERVATION_BLOCK : nom d'un bloc spécifique dans la réservation. Pour trouver cette valeur, consultez Afficher les demandes de réservations futures.

Cette commande utilise des profils de réseau d'accélérateur pour configurer automatiquement les réseaux et sous-réseaux VPC pour vos VM d'accélérateur. Vous pouvez également spécifier explicitement votre réseau VPC et vos sous-réseaux.

Déployer des ressources RDMA pour une charge de travail

Pour allouer des ressources RDMA à un pod, spécifiez un ResourceClaimTemplate.

  1. Créez un ResourceClaimTemplate pour définir la façon d'allouer les appareils RDMA. Le fichier manifeste suivant demande tous les appareils mrdma disponibles sur le nœud. Enregistrez le fichier manifeste sous le nom all-mrdma-template.yaml :

    apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: all-mrdma
spec:
  spec:
    devices:
      requests:
      - name: req-mrdma
        exactly:
          deviceClassName: mrdma.google.com
          allocationMode: All

  2. Appliquez le fichier manifeste :

    kubectl apply -f all-mrdma-template.yaml

  3. Déployez votre charge de travail et référencez ResourceClaimTemplate. Le fichier manifeste suivant déploie un pod qui fait référence au modèle all-mrdma, ce qui lui permet d'accéder aux interfaces RDMA sur le nœud. Enregistrez le fichier manifeste sous le nom agnhost-rdma-pod.yaml.

    apiVersion: v1
kind: Pod
metadata:
  name: agnhost-rdma
  namespace: default
  labels:
    app: agnhost
spec:
  containers:
  - name: agnhost
    image: registry.k8s.io/e2e-test-images/agnhost:2.39
    args: ["netexec", "--http-port", "80"]
    ports:
    - name: agnhost-port
      containerPort: 80
    resources:
      claims:
      - name: rdma
      limits:
        nvidia.com/gpu: 1
  resourceClaims:
  - name: rdma
    resourceClaimTemplateName: all-mrdma

  4. Appliquez le fichier manifeste :

    kubectl apply -f agnhost-rdma-pod.yaml

  5. Vérifiez que les interfaces réseau supplémentaires allouées sont visibles dans le pod.

    kubectl exec agnhost-rdma -- ls /sys/class/net

    L'exemple de résultat suivant affiche les interfaces eth0 et lo par défaut, ainsi que les interfaces RDMA allouées, telles que gpu0rdma0. Le nombre et les noms des cartes d'interface réseau (NIC) varient en fonction du type de machine du nœud GKE.

    eth0
gpu0rdma0
gpu1rdma0
gpu2rdma0
gpu3rdma0
lo

Planifier une charge de travail qui utilise des TPU

Les sections suivantes vous expliquent comment configurer un pool de nœuds TPU et une charge de travail pour utiliser des interfaces réseau non RDMA avec DRANET géré par GKE. Pour en savoir plus, consultez Allouer des ressources réseau à l'aide de DRANET géré par GKE.

Vérifier les DeviceClasses réseau

Vérifiez que les ressources DeviceClass pour la mise en réseau existent dans votre cluster.

kubectl get deviceclass netdev.google.com

Le résultat ressemble à ce qui suit :

NAME                AGE
netdev.google.com   2d22h

Activer le pilote DRANET géré par GKE sur un pool de nœuds de tranche TPU

Pour activer le pilote GKE DRANET lorsque vous créez un pool de nœuds de tranche TPU, ajoutez le libellé cloud.google.com/gke-networking-dra-driver=true.

gcloud beta container node-pools create NODE_POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --node-locations=NODE_LOCATIONS \
    --machine-type=MACHINE_TYPE \
    --tpu-topology=TPU_TOPOLOGY \
    --num-nodes=NUM_NODES \
    --accelerator-network-profile=auto \
    --node-labels=cloud.google.com/gke-networking-dra-driver=true

Remplacez les éléments suivants :

  • NODE_POOL_NAME : nom de votre nouveau pool de nœuds.
  • LOCATION : région ou zone Google Cloud de votre cluster.
  • CLUSTER_NAME : le nom du cluster
  • NODE_LOCATIONS : Google Cloud zones pour les nœuds du pool de nœuds.
  • MACHINE_TYPE : type de machine à utiliser pour les nœuds. Pour en savoir plus sur les types de machines compatibles avec les TPU, consultez Choisir la version de TPU.
  • TPU_TOPOLOGY : topologie TPU, par exemple 2x4x4. Le format de la topologie dépend de la version du TPU. Pour en savoir plus sur les topologies de TPU, consultez Choisir une topologie.
  • NUM_NODES : Nombre de nœuds dans le pool de nœuds.

Pour en savoir plus, consultez Créer un pool de nœuds de tranche TPU à hôte unique.

Déployer une charge de travail revendiquant tous les périphériques réseau

Pour allouer des périphériques réseau non RDMA à un pod, spécifiez un ResourceClaimTemplate.

  1. Créez un ResourceClaimTemplate qui fait référence à netdev.google.com DeviceClass. Le fichier manifeste suivant demande tous les périphériques réseau non RDMA disponibles sur le nœud.

    Enregistrez le fichier manifeste sous le nom all-netdev-template.yaml :

    apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: all-netdev
spec:
  spec:
    devices:
      requests:
      - name: req-netdev
        exactly:
          deviceClassName: netdev.google.com
          allocationMode: All

  2. Appliquez le fichier manifeste :

    kubectl apply -f all-netdev-template.yaml

  3. Déployez votre charge de travail et référencez ResourceClaimTemplate. Le fichier manifeste suivant déploie un pod qui utilise le modèle all-netdev pour accorder au pod l'accès à tous les périphériques réseau non RDMA du nœud. Enregistrez le fichier manifeste sous le nom netdev-pod.yaml :

    apiVersion: v1
kind: Pod
metadata:
  name: agnhost-netdev
  namespace: default
  labels:
    app: agnhost
spec:
  containers:
  - name: agnhost
    image: registry.k8s.io/e2e-test-images/agnhost:2.39
    args: ["netexec", "--http-port", "80"]
    ports:
    - name: agnhost-port
      containerPort: 80
    resources:
      claims:
      - name: netdev
      limits:
        google.com/tpu: 4
  nodeSelector:
    cloud.google.com/gke-tpu-accelerator: TPU_ACCELERATOR
    cloud.google.com/gke-tpu-topology: TPU_TOPOLOGY
  resourceClaims:
  - name: netdev
    resourceClaimTemplateName: all-netdev

    Remplacez les éléments suivants :

    • TPU_ACCELERATOR : type d'accélérateur TPU, par exemple tpu-v5p-slice.
    • TPU_TOPOLOGY : topologie TPU, par exemple 2x4x4.

  4. Appliquez le fichier manifeste :

    kubectl apply -f netdev-pod.yaml

  5. Vérifiez que les interfaces réseau supplémentaires allouées sont visibles dans le pod.

    kubectl exec agnhost-netdev -- ls /sys/class/net

    L'exemple de sortie suivant montre les interfaces eth0 et lo par défaut, ainsi que les périphériques réseau alloués, qui ont des noms tels que eth1 et eth2. Le nombre de cartes d'interface réseau et leurs noms varient en fonction du type de machine du nœud GKE.

    eth0
eth1
eth2
lo

Résoudre les problèmes

Pour vérifier la configuration réseau d'un pool de nœuds, exécutez la commande suivante :

gcloud beta container node-pools describe NODE_POOL_NAME \
    --zone=ZONE \
    --cluster=CLUSTER_NAME

Remplacez les éléments suivants :

  • NODE_POOL_NAME : nom de votre pool de nœuds.
  • ZONE : zone du pool de nœuds.
  • CLUSTER_NAME : nom du cluster

Le résultat affiche les réseaux et sous-réseaux supplémentaires associés au pool de nœuds.

Étapes suivantes