Allocare risorse di rete utilizzando DRANET gestito da GKE

DRANET di Google Kubernetes Engine (GKE) è una funzionalità GKE gestita che si basa sul progetto DRANET open source, che implementa l'API DRA di Kubernetes per le risorse di networking. DRANET ti consente di richiedere e allocare risorse di networking ad alte prestazioni per i tuoi pod, incluse le interfacce di rete che supportano l'accesso diretto alla memoria remota (RDMA). Questo approccio fornisce un'API portatile e allineata con l'upstream per la gestione delle risorse di rete.

Questo documento fornisce una panoramica concettuale di GKE DRANET e mostra come allocare le risorse di rete ai workload nei tuoi cluster GKE.

Questo documento è rivolto ad architetti cloud e specialisti di networking che progettano reti per le loro organizzazioni. Per una panoramica di tutta la documentazione di GKE, consulta Esplora la documentazione di GKE. Per scoprire di più sui ruoli e sulle attività comuni a cui si fa riferimento nei contenuti di Google Cloud , consulta Ruoli e attività comuni degli utenti GKE.

Prima di leggere questo documento, assicurati di avere familiarità con quanto segue:

Come funziona DRANET gestito da GKE

DRANET gestito da GKE viene implementato tramite un DaemonSet networking-dra-driver. Questo DaemonSet viene eseguito su nodi con GPU, TPU o VM ottimizzate per l'archiviazione con GKE DRANET abilitato.

Funziona come un agente a livello di nodo per rendere le interfacce di rete rilevabili e allocabili ai pod tramite le API di allocazione dinamica delle risorse (DRA) di Kubernetes.

In GKE 1.34.1-gke.1829001 e versioni successive, GKE installa automaticamente le risorse DeviceClass per il networking. Queste classi definiscono i tipi di dispositivi di rete che puoi richiedere. Ad esempio, GKE crea la classe mrdma.google.com per le VM GPU, la classe netdev.google.com per le TPU e altri dispositivi di rete e la classe irdma.google.com per le VM ottimizzate per l'archiviazione (come Z4M).

Per utilizzare GKE DRANET, devi prima attivare il driver GKE DRANET su un pool di nodi con GPU, TPU o VM ottimizzate per l'archiviazione.

Per richiedere dispositivi di rete per un workload, definisci un ResourceClaimTemplate. Questo template specifica DeviceClass e la modalità di allocazione, ad esempio la richiesta di tutti i dispositivi disponibili su un nodo. Nella specifica del pod, fai riferimento a questo template in un campo resourceClaims per concedere al pod l'accesso alle interfacce di rete richieste sul nodo.

Quando utilizzare DRANET gestito da GKE

GKE DRANET fornisce un modo standardizzato per gestire le risorse di rete che tengono conto della topologia e delle dipendenze. Questa standardizzazione lo rende una soluzione adatta per AI e ML, file system paralleli di grandi dimensioni e altri workload di archiviazione ad alta intensità di dati che richiedono un networking ad alte prestazioni.

I casi d'uso comuni per la richiesta di interfacce di rete per un pod includono:

  • Richiesta di tutte le interfacce compatibili con RDMA disponibili.
  • Richiedere un numero specifico di interfacce compatibili con RDMA.
  • Richiesta di tutte le interfacce non RDMA disponibili.
  • Richiesta di un numero specifico di interfacce non RDMA.

Considerazioni principali sull'utilizzo di DRANET gestito da GKE per il networking

Tieni presente quanto segue quando utilizzi DRANET di GKE per il networking:

  • Interfacce di rete dedicate

    Quando utilizzi GKE DRANET per richiedere un'interfaccia di rete per un pod, l'interfaccia è dedicata a quel pod. Altri pod sullo stesso nodo non possono condividerlo. Questo approccio contribuisce a garantire che il pod abbia accesso esclusivo alla larghezza di banda e alle risorse complete di quell'interfaccia, il che rappresenta un vantaggio chiave per i carichi di lavoro sensibili alle prestazioni.

  • Utilizza il driver DRANET gestito da GKE in modo indipendente

    Puoi attivare il driver DRA di GKE per gestire le risorse di rete senza attivare altri driver DRANET di GKE. Per farlo, aggiungi l'etichetta cloud.google.com/gke-networking-dra-driver=true a un pool di nodi con GPU, TPU o VM ottimizzate per lo spazio di archiviazione.

  • Utilizza altri driver DRA GKE

    Per ottenere un throughput più elevato nei workload di AI/ML più impegnativi, combina l'API DRA per gli acceleratori (come GPU e TPU) con il networking gestito DRANET di GKE. Questo approccio combinato migliora l'allineamento delle risorse e la consapevolezza della topologia. Per scoprire di più sull'utilizzo di DRA per altre risorse, consulta Prepara l'infrastruttura GKE per i carichi di lavoro DRA.

  • Evita configurazioni in conflitto

    Il driver DRANET di GKE gestisce le interfacce RDMA e le gVNIC che non hanno intervalli di indirizzi IP secondari configurati. Non utilizzare contemporaneamente il driver DRANET di GKE e l'API multi-rete di GKE con una risorsa di rete di tipo Device nello stesso cluster. L'utilizzo combinato del driver e dell'API non è supportato perché entrambe le API tentano di gestire lo stesso insieme di NIC, il che può portare a una configurazione errata e a un comportamento imprevedibile.

  • Ciclo di vita gestito del driver DRANET

    In GKE versione 1.34 e successive, GKE crea automaticamente lo spazio dei nomi gke-managed-networking-dra-driver gestito nel cluster. Analogamente a diversi altri workload di sistema GKE, i pod del driver DRANET vengono eseguiti solo sui nodi in cui sono pertinenti (ad esempio nodi con GPU, TPU e altro hardware specializzato). Sui nodi in cui il driver non è pertinente, non vengono eseguiti pod per questo driver. Non modificare manualmente il DaemonSet networking-dra-driver. Le modifiche manuali, come l'aggiornamento del campo nodeAffinity, possono interferire con la gestione della funzionalità DRANET da parte di GKE e causare la pianificazione dei pod del daemon DRANET su nodi non supportati.

Requisiti

Per utilizzare DRANET gestito da GKE, il tuo ambiente deve soddisfare i seguenti requisiti:

  • Standard: 1.34.1-gke.1829001 o versioni successive (1.36.3-gke.1767000 o versioni successive per le VM Z4M).
  • Autopilot: 1.35.2-gke.1842000 o versioni successive (1.37.0-gke.4713000 o versioni successive per le VM Z4M).
  • GKE Dataplane V2 è abilitato nel cluster.

Devi inoltre utilizzare uno dei seguenti tipi di macchine ottimizzate per l'acceleratore o per l'archiviazione:

Serie di macchine Tipo di macchina Modello di acceleratore Tecnologia di networking 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 Qualsiasi tipo di macchina Z4M che supporta IRDMA Non applicabile (ottimizzato per l'archiviazione) RDMA irdma.google.com

Limitazioni

GKE DRANET presenta le seguenti limitazioni:

  • Non puoi utilizzare GKE DRANET per allocare la scheda di interfaccia di rete (NIC) predefinita o le NIC virtuali (come veth).
  • Alcuni tipi di istanze, in particolare i nodi bare metal come a4x-max, non sono compatibili con i cluster con scalabilità automatica e Autopilot.

Considerazioni specifiche per la macchina

A seconda dell'architettura hardware sottostante dei nodi, alcune serie di macchine richiedono flag aggiuntivi per i pool di nodi, pacchetti di immagini container o DaemonSet di sistema per configurare le interfacce RDMA con GKE DRANET.

A4X Max Bare Metal

  • Esegui il deployment di asapd-lite: quando utilizzi nodi GPU bare metal, come A4X Max, devi eseguire il deployment del DaemonSet asapd-lite nel tuo cluster. Il DaemonSet asapd-lite configura le schede di interfaccia di rete (NIC) RDMA. Senza questo, le interfacce secondarie non vengono create e il driver dranet filtra le NIC RDMA, impedendo la funzionalità RDMA all'interno dei pod. Per istruzioni complete sulla configurazione, consulta Configura le NIC MRDMA con asapd-lite.

VM Z4M ottimizzate per l'archiviazione

  • Requisiti delle immagini container: per utilizzare RDMA sulle istanze Z4M, devi utilizzare un'immagine container Rocky Linux 8 configurata con i pacchetti RDMA dello spazio utente richiesti. Altre distribuzioni, come Ubuntu o Debian, non sono supportate. I pacchetti upstream standard per queste distribuzioni non dispongono delle estensioni ABI personalizzate richieste dal driver IRDMA. Senza queste estensioni, i pacchetti non funzionano in fase di runtime e viene visualizzato un errore -ENOSPC. Per istruzioni sulla configurazione, consulta Utilizza le interfacce RDMA in un pool di nodi ottimizzato per l'archiviazione.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

  • Abilita l'API Google Kubernetes Engine.
    • Abilita l'API Google Kubernetes Engine
  • Per utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per creare node pool e allocare risorse di rete, chiedi all'amministratore di concederti il ruolo IAM Kubernetes Engine Admin (roles/container.admin) nel progetto. Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.

Crea un cluster

Crea un cluster GKE Standard che utilizza GKE Dataplane V2:

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

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del nuovo cluster.
  • CONTROL_PLANE_LOCATION: la regione o la zona del control plane del cluster, ad esempio us-central1 o us-central1-a.
  • PROJECT_ID: il tuo ID progetto Google Cloud .
  • CLUSTER_VERSION: la versione di GKE per il tuo cluster:
    • VM Z4M: 1.36.3-gke.1767000 o versioni successive
    • Tutte le altre VM o istanze bare metal supportate: 1.34.1-gke.1829001 o versioni successive

Utilizza le interfacce RDMA da un pool di nodi GPU

Le sezioni seguenti descrivono come configurare un pool di nodi di GPU e un workload per utilizzare le interfacce di rete RDMA con GKE DRANET.

Abilita il driver DRANET gestito da GKE su un pool di nodi GPU

Per abilitare il driver GKE DRANET su un pool di nodi GPU che supporta RDMA, aggiungi l'etichetta cloud.google.com/gke-networking-dra-driver=true quando crei il pool di nodi.

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

Sostituisci quanto segue:

  • NODE_POOL_NAME: il nome del nuovo pool di nodi.
  • REGION: la regione Google Cloud del tuo cluster.
  • CLUSTER_NAME: il nome del tuo cluster.

  • ACCELERATOR_TYPE: il tipo di acceleratore GPU:

    Ad esempio:

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

  • ACCELERATOR_COUNT: il numero di GPU da collegare ai nodi nel pool di nodi. Ad esempio, per le VM a4-highgpu-8g e a3-ultragpu-8g, la quantità di GPU è 8.

  • DRIVER_VERSION: la versione del driver GPU da utilizzare. Ad esempio: default o latest.

  • MACHINE_TYPE: il tipo di macchina per il pool di nodi, ad esempio a3-ultragpu-8g.

  • NUM_NODES: il numero di nodi per il pool di nodi. Per flex-start, questo valore deve essere impostato su 0.

  • RESERVATION_PROJECT: l'ID progetto della prenotazione.

  • RESERVATION_NAME: il nome della prenotazione. Per trovare questo valore, consulta Visualizza le richieste di prenotazione futura.

  • RESERVATION_BLOCK: il nome di un blocco specifico all'interno della prenotazione. Per trovare questo valore, consulta Visualizza le richieste di prenotazione futura.

Questo comando utilizza i profili di rete dell'acceleratore per configurare automaticamente le reti e le subnet VPC per le VM con acceleratore. In alternativa, puoi specificare esplicitamente la rete VPC e le subnet.

Esegui il deployment di un workload con risorse RDMA

Per allocare risorse RDMA per un pod, specifica un ResourceClaimTemplate.

  1. Crea un ResourceClaimTemplate per definire come allocare i dispositivi RDMA. Il seguente manifest richiede tutti i dispositivi mrdma disponibili sul nodo. Salva il manifest come 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. Applica il manifest:

    kubectl apply -f all-mrdma-template.yaml

  3. Esegui il deployment del workload e fai riferimento a ResourceClaimTemplate. Il seguente manifest esegue il deployment di un pod che fa riferimento al template all-mrdma, che concede al pod l'accesso alle interfacce RDMA sul nodo. Salva il manifest come 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. Applica il manifest:

    kubectl apply -f agnhost-rdma-pod.yaml

  5. Verifica che le interfacce di rete allocate aggiuntive siano visibili all'interno del pod.

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

    L'output di esempio seguente mostra le interfacce predefinite eth0 e lo, nonché le interfacce RDMA allocate, come gpu0rdma0. Il numero e i nomi delle interfacce di rete (NIC) variano in base al tipo di macchina del nodo GKE.

    eth0
gpu0rdma0
gpu1rdma0
gpu2rdma0
gpu3rdma0
lo

Utilizza interfacce di rete non RDMA in un pool di nodi TPU

Le sezioni seguenti descrivono come configurare un pool di nodi TPU e un workload per utilizzare interfacce di rete non RDMA con GKE DRANET.

Verifica le DeviceClass di networking

Verifica che le risorse DeviceClass per il networking esistano nel tuo cluster.

kubectl get deviceclass netdev.google.com

L'output è simile al seguente:

NAME                AGE
netdev.google.com   2d22h

Abilita il driver DRANET gestito da GKE su un pool di nodi di sezioni TPU

Per abilitare il driver DRANET di GKE durante la creazione di un pool di nodi di sezioni TPU, aggiungi l'etichetta 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

Sostituisci quanto segue:

  • NODE_POOL_NAME: il nome del nuovo pool di nodi.
  • LOCATION: la regione o la zona Google Cloud del tuo cluster.
  • CLUSTER_NAME: il nome del tuo cluster.
  • NODE_LOCATIONS: le zone Google Cloud per i nodi nel pool di nodi.
  • MACHINE_TYPE: il tipo di macchina da utilizzare per i nodi. Per saperne di più sui tipi di macchine compatibili con TPU, consulta Scegli la versione della TPU.
  • TPU_TOPOLOGY: la topologia TPU, ad esempio 2x4x4. Il formato della topologia dipende dalla versione della TPU. Per saperne di più sulle topologie TPU, consulta Scegli una topologia.
  • NUM_NODES: il numero di nodi nel pool di nodi.

Per saperne di più, consulta Crea un pool di nodi di sezioni TPU single-host.

Esegui il deployment di un workload che richiede tutti i dispositivi di rete

Per allocare dispositivi di rete non RDMA per un pod, specifica un ResourceClaimTemplate.

  1. Crea un ResourceClaimTemplate che faccia riferimento a netdev.google.com DeviceClass. Il seguente manifest richiede tutti i dispositivi di rete non RDMA disponibili sul nodo.

    Salva il manifest come 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. Applica il manifest:

    kubectl apply -f all-netdev-template.yaml

  3. Esegui il deployment del workload e fai riferimento a ResourceClaimTemplate. Il seguente manifest esegue il deployment di un pod che utilizza il template all-netdev per concedere al pod l'accesso a tutti i dispositivi di rete non RDMA sul nodo. Salva il manifest come 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

    Sostituisci quanto segue:

    • TPU_ACCELERATOR: il tipo di acceleratore TPU, ad esempio tpu-v5p-slice.
    • TPU_TOPOLOGY: la topologia TPU, ad esempio 2x4x4.

  4. Applica il manifest:

    kubectl apply -f netdev-pod.yaml

  5. Verifica che le interfacce di rete allocate aggiuntive siano visibili all'interno del pod.

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

    L'output di esempio seguente mostra le interfacce predefinite eth0 e lo, insieme ai dispositivi di rete allocati, che hanno nomi come eth1 e eth2. Il numero di NIC e i relativi nomi variano in base al tipo di macchina del nodo GKE.

    eth0
eth1
eth2
lo

Utilizza le interfacce RDMA in un pool di nodi ottimizzato per l'archiviazione

Le sezioni seguenti descrivono come configurare un pool di nodi e un workload ottimizzati per l'archiviazione in modo da utilizzare le interfacce di rete RDMA con GKE DRANET, utilizzando come esempio una VM Z4M (z4m-highmem-192).

Crea un pool di nodi ottimizzato per l'archiviazione

Crea un pool di nodi ottimizzato per l'archiviazione con il flag --accelerator-network-profile=auto in modo che GKE esegua automaticamente il provisioning e il collegamento delle reti VPC Falcon, delle subnet e delle interfacce di rete secondarie sottostanti. Sui node pool Z4M, GKE attiva DRANET per impostazione predefinita, quindi non è necessario specificare l'etichetta del nodo cloud.google.com/gke-networking-dra-driver=true quando crei il pool di nodi. Questo esempio utilizza il tipo di macchina z4m-highmem-192, che dispone di NIC Titanium fisiche doppie e fornisce due interfacce RDMA. Per l'elenco dei tipi di macchine supportati, consulta Requisiti.

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

Sostituisci quanto segue:

  • NODE_POOL_NAME: il nome del nuovo pool di nodi.
  • CLUSTER_NAME: il nome del tuo cluster.
  • PROJECT_ID: il tuo ID progetto Google Cloud .
  • ZONE: la zona Google Cloud per il tuo node pool.
  • NUM_NODES: il numero di nodi nel pool di nodi. Per testare il traffico RDMA tra i nodi con i pod di esempio rdma-server e rdma-client, specifica almeno 2.

Prepara l'immagine container del workload ottimizzato per lo spazio di archiviazione

I workload che utilizzano Cloud RDMA su nodi ottimizzati per l'archiviazione richiedono un'immagine container Rocky Linux 8 con le librerie RDMA personalizzate dello spazio utente (rdma-core) installate per Cloud RDMA. Non utilizzare i pacchetti upstream predefiniti, in quanto non dispongono delle estensioni ABI personalizzate richieste dal driver IRDMA host e non funzionano in fase di runtime con errori -ENOSPC. Per verificare le assegnazioni degli indirizzi IP e testare la connettività RDMA, installa anche iproute, libibverbs-utils, librdmacm-utils, infiniband-diags e perftest.

Per un esempio di Dockerfile che configura il Package Repository richiesto, consulta Prepara l'immagine Docker. Nel comando dnf install, includi iproute in modo da poter ispezionare le assegnazioni IP con il comando ip. Per saperne di più sui pacchetti richiesti, consulta RPM Cloud RDMA.

Esegui il deployment di un workload con risorse RDMA

Per allocare interfacce RDMA a un pod su un nodo ottimizzato per l'archiviazione, crea un ResourceClaimTemplate che richiede irdma.google.com DeviceClass:

  1. Crea un manifest ResourceClaimTemplate e salvalo come 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

    In questo manifest:

    • deviceClassName: irdma.google.com: richiede interfacce di rete IRDMA gestite da GKE DRANET su nodi ottimizzati per l'archiviazione.
    • allocationMode: ExactCount e count: 2: richiedono entrambe le interfacce IRDMA disponibili su un nodo z4m-highmem-192. Se il tuo workload richiede una sola interfaccia RDMA o se utilizzi un tipo di macchina Z4M che fornisce un'interfaccia IRDMA, specifica 1.

  2. Applica il manifest:

    kubectl apply -f irdma-template.yaml

  3. Crea un manifest che definisca due pod, rdma-server e rdma-client, in modo da poter testare il traffico RDMA tra i nodi. Ogni pod aggiunge la funzionalità IPC_LOCK e fa riferimento a irdma-template ResourceClaimTemplate. Salva il manifest come 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

    Sostituisci entrambe le istanze di IMAGE_URI con l'URI della tua immagine container RDMA Rocky Linux 8.

    In questo manifest:

    • metadata.labels: etichetta ogni pod con app: perftest e un'etichetta role. Entrambi i pod condividono l'etichetta app: perftest in modo che la regola di anti-affinità venga applicata. L'etichetta role distingue il pod rdma-server (role: server) dal pod rdma-client (role: client) in modo da poter testare la connettività RDMA da pod a pod tra i nodi.
    • affinity.podAntiAffinity: impedisce a Kubernetes di pianificare i pod che condividono l'etichetta app: perftest sullo stesso nodo. Poiché entrambi i pod hanno questa etichetta, vengono eseguiti su host fisici separati per i test RDMA tra nodi, anche quando ResourceClaimTemplate richiede una sola interfaccia (count: 1). Il tuo pool di nodi deve avere almeno due nodi per pianificare entrambi i pod.
    • securityContext.capabilities.add: ["IPC_LOCK"]: consente al container di bloccare le pagine di memoria, operazione necessaria per consentire alle librerie dello spazio utente RDMA di registrare le regioni di memoria per l'accesso diretto alla memoria.
    • spec.resourceClaims: genera un ResourceClaim specifico per il pod (denominato irdma) dal ResourceClaimTemplate irdma-template.
    • containers.resources.claims: concede al container perftest l'accesso alle interfacce allocate dalla richiesta irdma.

  4. Applica il manifest:

    kubectl apply -f irdma-pods.yaml

  5. Verifica che le interfacce RDMA allocate (rdma0 e rdma1) siano visibili all'interno del pod del server:

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

    L'output è simile al seguente:

    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

Per verificare il traffico RDMA tra i due pod, esegui rping tra rdma-server e rdma-client:

  1. Avvia il server rping nel pod del server:

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

    Sostituisci RDMA_IP con l'indirizzo IP rdma0 o rdma1 del pod server, ad esempio 10.31.0.3.

  2. In un secondo terminale, esegui il client rping sul pod client:

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

    Nell'output del client, verifica i seguenti indicatori di una connessione RDMA riuscita:

    • RDMA_CM_EVENT_ADDR_RESOLVED e RDMA_CM_EVENT_ROUTE_RESOLVED: conferma che RDMA Communication Manager ha risolto l'indirizzo IP e la route RDMA di destinazione.
    • ESTABLISHED e rdma_connect successful: conferma che il client ha creato la coppia di code (qp), la coda di completamento (cq) e il dominio di protezione (pd) e ha stabilito la connessione RDMA.
    • Cinque voci send completion, recv completion e ping data: rdma-ping-: confermano che cinque iterazioni di andata e ritorno di lettura e scrittura RDMA sono state completate sull'interfaccia RDMA prima di chiudere la connessione (destroy cm_id).

Abilita DRANET con ComputeClass personalizzata

Per utilizzare DRANET gestito da GKE nei cluster Autopilot o con il provisioning automatico dei nodi nei cluster Standard, devi utilizzare una risorsa ComputeClass personalizzata per attivare la funzionalità.

  1. Crea un manifest ComputeClass che attiva il driver DRANET e imposta il profilo di rete dell'acceleratore su 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

    Sostituisci quanto segue:

    • MACHINE_TYPE: il tipo di macchina per il node pool, ad esempio a3-ultragpu-8g o z4m-highmem-192.
    • GPU_COUNT: il numero di GPU per il tipo di macchina.
    • GPU_TYPE: il tipo di GPU, ad esempio nvidia-h200.

  2. Applica il manifest:

    kubectl apply -f COMPUTE_CLASS_FILENAME.yaml

  3. Nella specifica del pod, fai riferimento alla classe ComputeClass utilizzando il selettore di nodi cloud.google.com/compute-class:

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

Richiedi un numero specifico di dispositivi di rete

Gli esempi di GPU e TPU precedenti mostrano come richiedere tutti i dispositivi di rete disponibili di un determinato tipo impostando allocationMode su All. Per richiedere un numero specifico di dispositivi, imposta allocationMode su ExactCount nel tuo ResourceClaimTemplate, come mostrato in Esegui il deployment di un workload con risorse RDMA.

L'esempio seguente richiede due dispositivi di rete 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

Passaggi successivi