Allouer des ressources réseau à l'aide de DRANET géré par GKE

Standard

Preview

Cette fonctionnalité est soumise(s) aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les fonctionnalités de pré-DG sont disponibles "en l'état" et peuvent avoir une prise en charge limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

La fonctionnalité DRANET de Google Kubernetes Engine (GKE) est une fonctionnalité GKE gérée qui s'appuie sur le projet DRANET Open Source, qui implémente l'API Kubernetes DRA pour les ressources réseau. DRANET vous permet de demander et d'allouer des ressources réseau hautes performances pour vos pods, y compris des interfaces réseau compatibles avec l'accès direct à la mémoire à distance (RDMA). Cette approche fournit une API portable et alignée en amont pour la gestion des ressources réseau.

Ce document fournit un aperçu conceptuel de GKE DRANET et explique comment allouer des ressources réseau aux charges de travail dans vos clusters GKE.

Ce document s'adresse aux architectes cloud et aux spécialistes de la mise en réseau qui conçoivent des réseaux pour leurs organisations. Pour obtenir une présentation de toute la documentation GKE, consultez Explorer la documentation GKE. Pour en savoir plus sur les rôles et les tâches courants mentionnés dans le contenu Google Cloud , consultez Rôles utilisateur et tâches courantes de GKE.

Avant de lire ce document, assurez-vous de connaître les éléments suivants :

• Allocation dynamique des ressources
• À propos de l'allocation dynamique des ressources dans GKE
• Concepts Kubernetes
• Mise en réseau GKE
• Principes de base de la mise en réseau GKE

Fonctionnement de GKE Managed DRANET

DRANET géré par GKE est implémenté via un DaemonSet networking-dra-driver. Ce DaemonSet s'exécute sur les nœuds avec GPU ou TPU sur lesquels GKE DRANET est activé. Il fonctionne comme un agent au niveau du nœud pour rendre les interfaces réseau détectables et attribuables aux pods via les API Kubernetes Dynamic Resource Allocation (DRA).

Dans les versions 1.34.1-gke.1829001 et ultérieures de GKE, GKE installe automatiquement les ressources DeviceClass pour la mise en réseau. Ces classes définissent les types de périphériques réseau que vous pouvez demander. Par exemple, GKE crée la classe mrdma.google.com pour les appareils compatibles RDMA et la classe netdev.google.com pour les autres périphériques réseau.

Pour utiliser GKE DRANET, vous devez d'abord activer le pilote GKE DRANET sur un pool de nœuds avec des GPU ou des TPU.

Pour demander des périphériques réseau pour une charge de travail, définissez un ResourceClaimTemplate. Ce modèle spécifie DeviceClass et le mode d'allocation, par exemple en demandant tous les appareils disponibles sur un nœud. Dans la spécification de votre pod, référencez ce modèle dans un champ resourceClaims pour accorder à votre pod l'accès aux interfaces réseau demandées sur le nœud.

Quand utiliser GKE managed DRANET

GKE DRANET fournit un moyen standardisé de gérer les ressources réseau qui tiennent compte de la topologie et des dépendances. Cette normalisation en fait une solution adaptée aux charges de travail d'IA et de ML qui nécessitent un réseau hautes performances.

Voici quelques cas d'utilisation courants pour demander des interfaces réseau pour un pod :

• Demande de toutes les interfaces compatibles RDMA disponibles.
• Demander un nombre spécifique d'interfaces compatibles avec RDMA.
• Demande de toutes les interfaces non RDMA disponibles.
• Demander un nombre spécifique d'interfaces non RDMA.

Points clés à prendre en compte lorsque vous utilisez le réseau DRANET géré par GKE pour la mise en réseau

Tenez compte des points suivants lorsque vous utilisez GKE DRANET pour la mise en réseau :

• Interfaces réseau dédiées

  Lorsque vous utilisez GKE DRANET pour revendiquer une interface réseau pour un pod, cette interface est dédiée à ce pod. Les autres pods du même nœud ne peuvent pas la partager. Cela 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.

• Utiliser le pilote DRANET géré par GKE de manière indépendante

  Vous pouvez activer le pilote GKE DRA pour gérer les ressources réseau sans activer d'autres pilotes GKE DRANET. Pour ce faire, ajoutez le libellé cloud.google.com/gke-networking-dra-driver=true à un pool de nœuds comportant des GPU et des TPU.

• Utiliser d'autres pilotes GKE DRA

  Pour obtenir un débit plus élevé dans les charges de travail exigeantes d'IA/ML, combinez l'API DRA pour les accélérateurs (comme les GPU et les TPU) avec la mise en réseau gérée DRANET de GKE. Cette approche combinée améliore l'alignement des ressources et la connaissance de la topologie. Pour obtenir des conseils sur l'utilisation de DRA pour d'autres ressources, consultez Préparer l'infrastructure GKE pour les charges de travail DRA.

• Éviter les configurations conflictuelles

  Le pilote GKE DRANET gère les interfaces RDMA et les gVNIC qui n'ont pas de plages d'adresses IP secondaires configurées. N'utilisez pas à la fois le pilote GKE DRANET et l'API GKE multi-réseaux avec une ressource réseau de type Device dans le même cluster. L'utilisation conjointe du pilote et de l'API n'est pas prise en charge, car les deux API tentent de gérer le même ensemble de cartes d'interface réseau, ce qui peut entraîner une configuration incorrecte et un comportement imprévisible.

Conditions requises

Pour utiliser DRANET géré par GKE, votre environnement doit répondre aux exigences suivantes :

• GKE version 1.34.1-gke.1829001 ou ultérieure.
• GKE Dataplane V2 est activé sur le cluster.
• (Preview) GKE DRANET est disponible sur les machines A4X Max.

Limites

GKE DRANET présente les limites suivantes :

• Vous ne pouvez pas utiliser GKE DRANET pour allouer la carte d'interface réseau (NIC) par défaut ni les cartes d'interface réseau virtuelles (telles que veth).
• L'autoscaling de cluster et Autopilot ne sont pas compatibles.
• Vous ne pouvez pas utiliser GKE DRANET avec des interfaces pour lesquelles vous avez configuré un secondaryPodRange.

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.
  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 des pools de nœuds et allouer des ressources réseau, demandez à votre administrateur de vous accorder le rôle IAM Administrateur Kubernetes Engine (roles/container.admin) sur votre projet. 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.

Créer un cluster

Créez un cluster GKE Standard qui utilise GKE Dataplane V2 :

gcloud container clusters create CLUSTER_NAME \
    --enable-dataplane-v2 \
    --region=CONTROL_PLANE_LOCATION \
    --project=PROJECT_ID \
    --cluster-version=CLUSTER_VERSION

Remplacez les éléments suivants :

• CLUSTER_NAME : nom de votre nouveau cluster
• CONTROL_PLANE_LOCATION : région ou zone du plan de contrôle du cluster, par exemple us-central1 ou us-central1-a.
• PROJECT_ID : ID de votre projet Google Cloud .
• CLUSTER_VERSION : version de GKE pour votre cluster. Cette version doit être 1.34.1-gke.1829001 ou ultérieure.

Utiliser des interfaces RDMA à partir d'un pool de nœuds GPU

Les sections suivantes décrivent comment configurer un pool de nœuds et une charge de travail GPU pour utiliser des interfaces réseau RDMA avec GKE DRANET.

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
   

Utiliser des interfaces réseau non RDMA dans un pool de nœuds TPU

Les sections suivantes décrivent comment configurer un pool de nœuds et une charge de travail TPU pour utiliser des interfaces réseau non RDMA avec GKE DRANET.

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
   

Demander un nombre spécifique d'appareils réseau

Les exemples précédents montrent comment demander tous les périphériques réseau disponibles d'un certain type en définissant allocationMode sur All. Si vous devez demander un nombre spécifique d'appareils, vous pouvez définir allocationMode sur ExactCount dans votre ResourceClaimTemplate.

L'exemple suivant demande deux périphériques réseau RDMA :

apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: two-mrdma
spec:
  spec:
    devices:
      requests:
      - name: req-mrdma
        exactly:
          deviceClassName: mrdma.google.com
          allocationMode: ExactCount
          count: 2

Étapes suivantes

• En savoir plus sur l'allocation dynamique des ressources
• En savoir plus sur la configuration de la mise en réseau automatisée pour les VM d'accélérateur