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

Autopilot Standard

Google Kubernetes Engine (GKE) DRANET 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 présente le concept de GKE DRANET et vous explique comment allouer des ressources réseau aux charges de travail de 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 leur organisation. Pour obtenir une présentation de l'ensemble de la documentation GKE, consultez Explorer la documentation GKE. Pour en savoir plus sur les rôles et les tâches courants référencé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 DRANET géré par GKE

Le DRANET géré par GKE est implémenté via un DaemonSet networking-dra-driver. Ce DaemonSet s'exécute sur des nœuds dotés de GPU, de TPU ou de VM optimisées pour le stockage sur lesquelles GKE DRANET est activé.

Il fonctionne comme un agent au niveau du nœud pour rendre les interfaces réseau détectables et allouables aux pods via les API d'allocation dynamique des ressources (DRA) Kubernetes.

Dans GKE 1.34.1-gke.1829001 et versions ultérieures, GKE installe automatiquement les ressources DeviceClass pour la mise en réseau. Ces classes définissent les types d'appareils réseau que vous pouvez demander. Par exemple, GKE crée la classe mrdma.google.com pour les VM GPU, la classe netdev.google.com pour les TPU et les autres appareils réseau, et la classe irdma.google.com pour les VM optimisées pour le stockage (comme Z4M).

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

Pour demander des périphériques réseau pour une charge de travail, définissez un ResourceClaimTemplate. Ce modèle spécifie le DeviceClass et le mode d'allocation, par exemple en demandant tous les appareils disponibles sur un nœud. Dans votre spécification de 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 DRANET géré par GKE

GKE DRANET fournit un moyen standardisé de gérer les ressources réseau qui tiennent compte de la topologie et des dépendances. Cette standardisation en fait une solution adaptée à l'IA et au ML, aux grands systèmes de fichiers parallèles et à d'autres charges de travail de stockage gourmandes en données qui nécessitent une mise en réseau hautes performances.

Voici quelques cas d'utilisation courants de la demande d'interfaces réseau pour un pod :

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

Points clés à prendre en compte lors de l'utilisation de 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. Cette approche permet de s'assurer que le pod dispose d'un accès exclusif à l'intégralité de la bande passante et des ressources de cette interface, ce qui est un avantage clé pour les charges de travail sensibles aux performances.

• Utiliser le pilote DRANET géré par GKE indépendamment

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

• Utiliser d'autres pilotes DRA GKE

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

• Éviter les configurations contradictoires

  Le pilote GKE DRANET gère les interfaces RDMA et les gVNIC pour lesquelles aucune plage d'adresses IP secondaire n'est configurée. N'utilisez pas à la fois le pilote DRANET GKE et l'API GKE multi-réseau avec une ressource Network de type Device dans le même cluster. L'utilisation conjointe du pilote et de l'API n'est pas possible, 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.

• Cycle de vie géré du pilote DRANET

  Dans GKE version 1.34 et ultérieure, GKE crée automatiquement l'espace de noms géré gke-managed-networking-dra-driver dans votre cluster. Comme plusieurs autres charges de travail système GKE, les pods du pilote DRANET ne s'exécutent que sur les nœuds où ils sont pertinents (par exemple, les nœuds avec des GPU, des TPU et d'autres matériels spécialisés). Sur les nœuds où le pilote n'est pas pertinent, aucun pod de ce pilote ne s'exécute. Ne modifiez pas manuellement le DaemonSet networking-dra-driver. Les modifications manuelles, telles que la mise à jour du champ nodeAffinity, peuvent interférer avec la gestion de la fonctionnalité DRANET par GKE et entraîner la planification des pods du daemon DRANET sur des nœuds non compatibles.

Conditions requises

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

• Standard : 1.34.1-gke.1829001 ou version ultérieure (1.36.3-gke.1767000 ou version ultérieure pour les VM Z4M).
• Autopilot : 1.35.2-gke.1842000 ou version ultérieure (1.37.0-gke.4713000 ou version ultérieure pour les VM Z4M).
• GKE Dataplane V2 est activé sur le cluster.

Vous devez également utiliser l'un des types de machines optimisés pour les accélérateurs ou pour le stockage suivants :

Série de machines	Type de machine	Modèle d'accélérateur	Technologie de mise en réseau	DeviceClass
A3 Ultra	a3-ultragpu-8g	GPU NVIDIA H200	RDMA	mrdma.google.com
A4	a4-highgpu-8g	GPU NVIDIA B200	RDMA	mrdma.google.com
A4X	a4x-highgpu-4g	GPU NVIDIA GB200	RDMA	mrdma.google.com
A4X Max	a4x-maxgpu-4g-metal	GPU NVIDIA B300	RDMA	mrdma.google.com
TPU v7	tpu7x-standard-4t	TPU v7	NetDevice	netdev.google.com
TPU v6e	ct6e-standard-8t	TPU Trillium	NetDevice	netdev.google.com
TPU v6e	ct6e-standard-4t	TPU Trillium	NetDevice	netdev.google.com
TPU v6e	ct6e-standard-1t	TPU Trillium	NetDevice	netdev.google.com
Z4M	Tout type de machine Z4M compatible avec IRDMA	Non applicable (optimisé pour le stockage)	RDMA	irdma.google.com

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 ou des cartes d'interface réseau virtuelles (telles que veth).
• Certains types d'instances, en particulier les nœuds Bare Metal tels que a4x-max, ne sont pas compatibles avec l'autoscaling et les clusters Autopilot.

Remarques spécifiques aux machines

Selon l'architecture matérielle sous-jacente de vos nœuds, certaines séries de machines nécessitent des options de pool de nœuds, des packages d'images de conteneurs ou des DaemonSets système supplémentaires pour configurer les interfaces RDMA avec GKE DRANET.

A4X Max bare metal

• Déployer asapd-lite : lorsque vous utilisez des nœuds GPU bare metal, tels que A4X Max, vous devez déployer le DaemonSet asapd-lite sur votre cluster. Le DaemonSet asapd-lite configure les cartes d'interface réseau (NIC) RDMA. Sans cela, les interfaces enfants ne sont pas créées et le pilote dranet filtre les cartes d'interface réseau RDMA, ce qui empêche la fonctionnalité RDMA dans vos pods. Pour obtenir des instructions de configuration complètes, consultez Configurer les cartes d'interface réseau MRDMA avec asapd-lite.

VM Z4M optimisées pour le stockage

• Exigences concernant l'image de conteneur : pour utiliser RDMA sur des instances Z4M, vous devez utiliser une image de conteneur Rocky Linux 8 configurée avec les packages RDMA d'espace utilisateur requis. Les autres distributions, telles qu'Ubuntu ou Debian, ne sont pas compatibles. Les packages en amont standards pour ces distributions ne disposent pas des extensions ABI personnalisées requises par le pilote IRDMA. Sans ces extensions, les packages échouent au moment de l'exécution avec une erreur -ENOSPC. Pour obtenir des instructions de configuration, consultez Utiliser des interfaces RDMA dans un pool de nœuds optimisé pour le stockage.

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.
  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 :
  • VM Z4M : 1.36.3-gke.1767000 ou version ultérieure
  • Toutes les autres VM ou instances bare metal compatibles : 1.34.1-gke.1829001 ou version ultérieure

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

Les sections suivantes expliquent comment configurer un pool de nœuds GPU et une charge de travail 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 l'étiquette 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 : région Google Cloud 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 du 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 réseau d'accélérateur pour configurer automatiquement des réseaux et des sous-réseaux VPC pour vos VM d'accélérateurs. Vous pouvez également spécifier explicitement votre réseau VPC et vos sous-réseaux.

Déployer des ressources RDMA de charge de travail

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

1. Créez un ResourceClaimTemplate pour définir comment 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 le 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 montre les interfaces eth0 et lo par défaut, ainsi que les interfaces RDMA allouées, telles que gpu0rdma0. Le nombre et le nom 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 expliquent 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 de mise en 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 de TPU

Pour activer le pilote GKE DRANET lors de la création d'un pool de nœuds de tranche TPU, ajoutez l'étiquette 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 : zones Google Cloud 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 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 référence le DeviceClass netdev.google.com. 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 le ResourceClaimTemplate. Le fichier manifeste suivant déploie un pod qui utilise le modèle all-netdev pour lui accorder 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 résultat suivant montre les interfaces eth0 et lo par défaut, ainsi que les périphériques réseau alloués, qui portent 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
   

Utiliser des interfaces RDMA dans un pool de nœuds optimisé pour le stockage

Les sections suivantes expliquent comment configurer un pool de nœuds et une charge de travail optimisés pour le stockage afin d'utiliser des interfaces réseau RDMA avec GKE DRANET, en prenant l'exemple d'une VM Z4M (z4m-highmem-192).

Créer un pool de nœuds optimisé pour le stockage

Créez un pool de nœuds optimisé pour le stockage avec l'option --accelerator-network-profile=auto afin que GKE provisionne et associe automatiquement les réseaux VPC Falcon, les sous-réseaux et les interfaces réseau secondaires sous-jacents. Sur les pools de nœuds Z4M, GKE active DRANET par défaut. Vous n'avez donc pas besoin de spécifier l'étiquette de nœud cloud.google.com/gke-networking-dra-driver=true lorsque vous créez le pool de nœuds. Cet exemple utilise le type de machine z4m-highmem-192, qui dispose de deux cartes d'interface réseau Titanium physiques et fournit deux interfaces RDMA. Pour obtenir la liste des types de machines compatibles, consultez Exigences.

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --project=PROJECT_ID \
    --zone=ZONE \
    --machine-type=z4m-highmem-192 \
    --num-nodes=NUM_NODES \
    --accelerator-network-profile=auto

Remplacez les éléments suivants :

• NODE_POOL_NAME : nom de votre nouveau pool de nœuds.
• CLUSTER_NAME : nom du cluster
• PROJECT_ID : ID de votre projet Google Cloud .
• ZONE : la zone Google Cloud de votre pool de nœuds.
• NUM_NODES : nombre de nœuds dans le pool de nœuds. Pour tester le trafic RDMA entre les nœuds avec les exemples de pods rdma-server et rdma-client, spécifiez au moins 2.

Préparer l'image de conteneur de la charge de travail optimisée pour le stockage

Les charges de travail qui utilisent Cloud RDMA sur des nœuds optimisés pour le stockage nécessitent une image de conteneur Rocky Linux 8 avec les bibliothèques RDMA d'espace utilisateur personnalisées (rdma-core) pour Cloud RDMA installées. N'utilisez pas les packages en amont par défaut. Ils ne disposent pas des extensions ABI personnalisées requises par le pilote IRDMA hôte et échouent lors de l'exécution avec des erreurs -ENOSPC. Pour vérifier les attributions d'adresses IP et tester la connectivité RDMA, installez également iproute, libibverbs-utils, librdmacm-utils, infiniband-diags et perftest.

Pour obtenir un exemple de Dockerfile qui configure le dépôt de packages requis, consultez Préparer votre image Docker. Dans la commande dnf install, incluez iproute afin de pouvoir inspecter les attributions d'adresses IP avec la commande ip. Pour en savoir plus sur les packages requis, consultez RPM Cloud RDMA.

Déployer une charge de travail avec des ressources RDMA

Pour allouer des interfaces RDMA à un pod sur un nœud optimisé pour le stockage, créez un ResourceClaimTemplate qui demande le DeviceClass irdma.google.com :

1. Créez un fichier manifeste ResourceClaimTemplate et enregistrez-le sous le nom irdma-template.yaml :

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

   Dans le fichier manifeste :

   • deviceClassName: irdma.google.com : demande des interfaces réseau IRDMA gérées par GKE DRANET sur des nœuds optimisés pour le stockage.
   • allocationMode: ExactCount et count: 2 : demande les deux interfaces IRDMA disponibles sur un nœud z4m-highmem-192. Si votre charge de travail ne nécessite qu'une seule interface RDMA ou si vous utilisez un type de machine Z4M qui fournit une interface IRDMA, spécifiez 1.

2. Appliquez le fichier manifeste :

   kubectl apply -f irdma-template.yaml
   

3. Créez un fichier manifeste qui définit deux pods, rdma-server et rdma-client, afin de pouvoir tester le trafic RDMA entre les nœuds. Chaque pod ajoute la fonctionnalité IPC_LOCK et fait référence au ResourceClaimTemplate irdma-template. Enregistrez le fichier manifeste sous le nom irdma-pods.yaml :

   apiVersion: v1
   kind: Pod
   metadata:
     name: rdma-server
     labels:
       app: perftest
       role: server
   spec:
     restartPolicy: Never
     affinity:
       podAntiAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
         - labelSelector:
             matchExpressions:
             - key: app
               operator: In
               values: ["perftest"]
           topologyKey: "kubernetes.io/hostname"
     containers:
     - name: perftest
       image: IMAGE_URI
       command: ["sleep", "infinity"]
       securityContext:
         capabilities:
           add: ["IPC_LOCK"]
       resources:
         claims:
         - name: irdma
     resourceClaims:
     - name: irdma
       resourceClaimTemplateName: irdma-template
   ---
   apiVersion: v1
   kind: Pod
   metadata:
     name: rdma-client
     labels:
       app: perftest
       role: client
   spec:
     restartPolicy: Never
     affinity:
       podAntiAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
         - labelSelector:
             matchExpressions:
             - key: app
               operator: In
               values: ["perftest"]
           topologyKey: "kubernetes.io/hostname"
     containers:
     - name: perftest
       image: IMAGE_URI
       command: ["sleep", "infinity"]
       securityContext:
         capabilities:
           add: ["IPC_LOCK"]
       resources:
         claims:
         - name: irdma
     resourceClaims:
     - name: irdma
       resourceClaimTemplateName: irdma-template
   

   Remplacez les deux instances de IMAGE_URI par l'URI de votre image de conteneur Rocky Linux 8 RDMA.

   Dans le fichier manifeste :

   • metadata.labels : attribue à chaque pod les libellés app: perftest et role. Les deux pods partagent l'étiquette app: perftest afin que la règle d'anti-affinité s'applique à eux. Le libellé role distingue le pod rdma-server (role: server) du pod rdma-client (role: client) afin que vous puissiez tester la connectivité RDMA de pod à pod entre les nœuds.
   • affinity.podAntiAffinity : empêche Kubernetes de planifier des pods partageant l'étiquette app: perftest sur le même nœud. Comme les deux pods ont ce libellé, ils s'exécutent sur des hôtes physiques distincts pour les tests RDMA entre nœuds, même lorsque votre ResourceClaimTemplate ne demande qu'une seule interface (count: 1). Votre pool de nœuds doit comporter au moins deux nœuds pour planifier les deux pods.
   • securityContext.capabilities.add: ["IPC_LOCK"] : permet au conteneur de verrouiller les pages de mémoire, ce qui est nécessaire pour que les bibliothèques d'espace utilisateur RDMA enregistrent les régions de mémoire pour l'accès direct à la mémoire.
   • spec.resourceClaims : génère un ResourceClaim spécifique au pod (nommé irdma) à partir du ResourceClaimTemplate irdma-template.
   • containers.resources.claims : accorde au conteneur perftest l'accès aux interfaces allouées par la revendication irdma.

4. Appliquez le fichier manifeste :

   kubectl apply -f irdma-pods.yaml
   

5. Vérifiez que les interfaces RDMA allouées (rdma0 et rdma1) sont visibles dans le pod du serveur :

   kubectl exec rdma-server -- ip -br addr show
   

   Le résultat ressemble à ce qui suit :

   lo               UNKNOWN        127.0.0.1/8
   rdma1            UP             10.5.0.3/32
   rdma0            UP             10.31.0.3/32
   eth0@if18        UP             10.120.2.6/32
   

Pour vérifier le trafic RDMA entre les deux pods, exécutez rping entre rdma-server et rdma-client :

1. Démarrez le serveur rping sur le pod du serveur :

   kubectl exec -it rdma-server -- rping -s -a RDMA_IP -v -d
   

   Remplacez RDMA_IP par l'adresse IP rdma0 ou rdma1 du pod du serveur, par exemple 10.31.0.3.

2. Dans un deuxième terminal, exécutez le client rping sur le pod client :

   kubectl exec -it rdma-client -- rping -c -a RDMA_IP -C 5 -v -d
   

   Dans la sortie du client, vérifiez les indicateurs suivants d'une connexion RDMA réussie :

   • RDMA_CM_EVENT_ADDR_RESOLVED et RDMA_CM_EVENT_ROUTE_RESOLVED : confirme que le gestionnaire de communication RDMA a résolu l'adresse IP et la route RDMA cibles.
   • ESTABLISHED et rdma_connect successful : confirme que le client a créé la paire de files d'attente (qp), la file d'attente d'achèvement (cq) et le domaine de protection (pd), et qu'il a établi la connexion RDMA.
   • Cinq entrées send completion, recv completion et ping data: rdma-ping- : confirme que cinq itérations d'aller-retour de lecture et d'écriture RDMA ont été effectuées sur l'interface RDMA avant la fermeture de la connexion (destroy cm_id).

Activer DRANET avec une ComputeClass personnalisée

Pour utiliser DRANET géré par GKE dans des clusters Autopilot ou avec le provisionnement automatique des nœuds dans des clusters standards, vous devez utiliser une ressource ComputeClass personnalisée pour activer la fonctionnalité.

1. Créez un fichier manifeste ComputeClass qui active le pilote DRANET et définit le profil réseau de l'accélérateur sur auto :

   apiVersion: cloud.google.com/v1
   kind: ComputeClass
   metadata:
     name: dranet-compute-class
   spec:
     nodePoolAutoCreation:
       enabled: true
     nodePoolConfig:
       dra:
         networking:
           enabled: true
     priorities:
     - machineType: MACHINE_TYPE
       # Omit the gpu section for storage-optimized VMs (such as Z4M).
       gpu:
         count: GPU_COUNT
         type: GPU_TYPE
       acceleratorNetworkProfile: auto
   

   Remplacez les éléments suivants :

   • MACHINE_TYPE : type de machine du pool de nœuds, tel que a3-ultragpu-8g ou z4m-highmem-192.
   • GPU_COUNT : nombre de GPU pour le type de machine.
   • GPU_TYPE : type de GPU, tel que nvidia-h200.

2. Appliquez le fichier manifeste :

   kubectl apply -f COMPUTE_CLASS_FILENAME.yaml
   

3. Dans la spécification de votre pod, référencez la ComputeClass à l'aide du sélecteur de nœud cloud.google.com/compute-class :

   apiVersion: v1
   kind: Pod
   metadata:
     name: dranet-pod
   spec:
     nodeSelector:
       cloud.google.com/compute-class: "dranet-compute-class"
     ...
   

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

Les exemples de GPU et de TPU précédents montrent comment demander tous les périphériques réseau disponibles d'un certain type en définissant allocationMode sur All. Pour demander un nombre spécifique d'appareils, définissez allocationMode sur ExactCount dans votre ResourceClaimTemplate, comme indiqué dans Déployer une charge de travail avec des ressources RDMA.

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érateurs