Configura il networking automatizzato per le VM con acceleratore

Questo documento mostra come utilizzare il networking automatizzato per le VM con acceleratore, come GPU e TPU, per semplificare la configurazione di rete per i carichi di lavoro con acceleratore Google Kubernetes Engine (GKE). Ciò è essenziale per l'esecuzione di intelligenza artificiale (AI), machine learning (ML) e computing ad alte prestazioni (HPC) su macchine ottimizzate per l'acceleratore.

Questo documento presuppone la conoscenza dei concetti fondamentali di GKE, dei carichi di lavoro GPU e TPU e del networking VPC. Nello specifico, devi avere familiarità con:

Questa pagina è rivolta ad architetti cloud e specialisti di networking che progettano e realizzano l'architettura della rete della loro organizzazione. Per una panoramica di tutti i set di documentazione di GKE, consulta Esplorare la documentazione di GKE. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui viene fatto riferimento nei contenuti diGoogle Cloud , consulta Ruoli utente e attività comuni di GKE.

GKE semplifica l'esecuzione di AI e ML ad alte prestazioni su acceleratori specializzati. Con il networking automatizzato per le VM con acceleratore, puoi attivare la connettività multirete ad alta velocità, essenziale per protocolli come RDMA, con un unico flag di configurazione. Questa automazione elimina il complesso processo manuale di configurazione di più reti VPC, gestione degli intervalli di indirizzi IP e configurazione delle interfacce di rete per ogni pool di nodi e pod. Utilizzando un singolo parametro durante la creazione di un pool di nodi, GKE fornisce tutte le risorse di networking cloud e Kubernetes necessarie.

Terminologia

I seguenti termini sono fondamentali per comprendere l'architettura di networking per le VM con acceleratore.

  • Virtual Private Cloud (VPC): un VPC è una versione virtuale di una rete fisica, implementata all'interno della rete di produzione di Google. Fornisce connettività per le tue istanze di macchine virtuali (VM) di Compute Engine, i cluster GKE e altre risorse.
  • NIC Titanium: una NIC intelligente che trasferisce le attività di elaborazione di rete dalla CPU, consentendo alla CPU di concentrarsi sui carichi di lavoro. Sulle macchine GPU, gestiscono tutto il traffico che non è comunicazione diretta da GPU a GPU. Sulle macchine TPU, tutte le NIC sono NIC Titanium.
  • Subnet: una subnet è una parte segmentata di una VPC più grande. Ogni subnet è associata a una regione e ha un intervallo di indirizzi IP definito.
  • Controller interfaccia di rete (NIC): una NIC è un'interfaccia di rete virtuale che connette un'istanza VM a una rete. Ogni NIC è collegata a una subnet e a un VPC specifici.
  • Rete host: la rete principale utilizzata dalle interfacce di rete (NIC) principali del nodo per la comunicazione generale del cluster, ad esempio il traffico del control plane e il networking regolare dei pod.
  • Rete di dati: una rete dedicata per il trasferimento di dati ad alte prestazioni tra le VM degli acceleratori. Per le GPU, spesso si tratta di un VPC GPUDirect con RDMA. Per le TPU, potrebbe trattarsi di una seconda rete host.
  • Remote Direct Memory Access(RDMA): RDMA è una tecnologia che consente ai dispositivi di rete di scambiare dati direttamente con la memoria principale di un computer senza coinvolgere il sistema operativo o la CPU. Ciò riduce significativamente la latenza e migliora il throughput, il che è fondamentale per i workload HPC e ML.
  • NVLink: NVLink è una tecnologia di interconnessione ad alta velocità sviluppata da NVIDIA per connettere più GPU all'interno di un singolo nodo, consentendo loro di condividere la memoria e lavorare insieme su set di dati di grandi dimensioni.
  • Allocazione dinamica delle risorse (DRA) di Kubernetes: DRA è una funzionalità di Kubernetes che offre un modo più flessibile per i pod di richiedere e utilizzare risorse, come GPU e altro hardware specializzato. Consente un controllo granulare sull'allocazione delle risorse.

Come funziona il networking automatizzato

Le macchine ottimizzate per l'acceleratore hanno un'architettura di rete specializzata per supportare la comunicazione ad alta velocità e bassa latenza tra GPU e TPU. Ogni macchina fisica contiene più GPU o TPU, spesso collegate da interconnessioni ad alta velocità come NVLink. Le macchine hanno anche una o più NIC per il networking generale e più NIC GPU per interconnessioni ad alta velocità.

Quando crei un nodo GKE che utilizza un tipo di macchina ottimizzato per gli acceleratori, GKE configura più NIC sulla VM sottostante. Le NIC host si connettono alle reti VPC host per la comunicazione e la gestione generali del cluster per comunicare con il control plane. Le NIC GPU si connettono a una rete VPC dedicata ad alte prestazioni, spesso con RDMA abilitato e un'impostazione MTU elevata (8896), per facilitare la comunicazione GPUDirect.

Quando un pod richiede GPU o TPU, puoi configurarlo per accedere alle interfacce di rete ad alte prestazioni sul nodo. Puoi richiedere tutte le NIC disponibili o un sottoinsieme specifico. Ogni interfaccia di rete rivendicata è dedicata a un singolo pod e non è condivisa. Questa configurazione di rete garantisce che il pod abbia accesso esclusivo alla larghezza di banda e alle risorse complete di questa interfaccia, un vantaggio fondamentale per i carichi di lavoro sensibili alle prestazioni.

Limitazioni

  • Il networking automatizzato per le VM con acceleratore non è supportato sui cluster Autopilot.
  • Il networking automatizzato richiede che il cluster utilizzi GKE Dataplane V2.
  • Tipi di macchine supportati: il networking automatizzato è supportato sulle famiglie di macchine ottimizzate per l'acceleratore A3, A4 e TPU Trillium (v6e).
  • Sono richiesti node pool a zona singola: devi utilizzare un pool di nodi con una singola zona.
  • Quando utilizzi GKE Managed DRANET per configurare i carichi di lavoro, consulta le considerazioni chiave e le limitazioni per GKE Managed DRANET.
  • Non puoi utilizzare sia l'API multi-rete sia DRANET nello stesso pool di nodi. Devi scegliere un metodo per l'attestazione di rete per i tuoi pod.

Configurazioni di rete delle macchine ottimizzate per l'acceleratore

Le macchine ottimizzate per l'acceleratore hanno configurazioni di rete diverse a seconda del tipo. La tabella seguente riepiloga le specifiche di rete per vari tipi di macchine.

VM con acceleratore GPU

Tipo di macchina Numero di GPU Numero di NIC Titanium Numero di NIC GPU Tecnologia GPUDirect VPC aggiuntive
A3 8 (H100) 1 4 TCPX 4 per le NIC GPU
A3 Mega 8 (H100) 1 8 TCPXO 8 per le NIC GPU
A3 Ultra 8 (H200) 2 8 RDMA 2 (1 per la seconda NIC, 1 per le NIC GPU)
A4 8 (B200) 2 8 RDMA 2 (1 per la seconda NIC, 1 per le NIC GPU)
A4X 4 (GB200) 1 4 RDMA 2 (1 per la seconda NIC, 1 per le NIC GPU)

VM con acceleratore TPU

Tipo di macchina Numero di chip TPU Numero di NIC VPC aggiuntive
TPU Trillium (v6e) (ct6e-standard-4t) 4 2 2 (1 per la seconda NIC, 1 per la VNIC aggiuntiva sulla prima NIC)

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

  • Attiva l'API Google Kubernetes Engine.
  • Attiva l'API Google Kubernetes Engine
  • Se vuoi 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.
  • Assicurati che il cluster utilizzi GKE 1.34.1-gke.1829001 o versioni successive.

  • Assicurati che il cluster abbia GKE Dataplane V2. Puoi attivare questa funzionalità quando crei un nuovo cluster o ne aggiorni uno esistente.

    • Crea un nuovo cluster:

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

      Sostituisci quanto segue:

      • CLUSTER_NAME: il nome del nuovo cluster.
      • CLUSTER_VERSION: la versione del cluster, che deve essere 1.34.1-gke.1829001 o successiva.
    • Aggiorna un cluster esistente:

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

      Sostituisci CLUSTER_NAME con il nome del cluster.

  • Se prevedi di eseguire il deployment di carichi di lavoro GPU che utilizzano RDMA, verifica l'esistenza delle risorse DeviceClass:

    kubectl get deviceclass mrdma.google.com
    

Crea un pool di nodi con un profilo di rete predefinito

Per creare automaticamente una rete che connette tutte le macchine GPU o TPU all'interno di una singola zona, crea un pool di nodi con il profilo di rete auto dell'acceleratore.

gcloud

Per creare un pool di nodi con un profilo di rete configurato automaticamente, esegui il seguente comando:

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

Per saperne di più sulla creazione di node pool con acceleratori, consulta Esegui GPU nei node pool Autopilot e Esegui il deployment di workload TPU in Autopilot. Quando segui le istruzioni riportate in questi documenti, aggiungi il flag --accelerator-network-profile=auto al comando gcloud container node-pools create.

Per i node pool TPU slice multi-host, devi anche aggiungere il flag --tpu-topology.

Sostituisci quanto segue:

  • NODE_POOL_NAME: il nome del nuovo pool di nodi.
  • ZONE: la zona del pool di nodi.
  • MACHINE_TYPE: il tipo di macchina per i nodi, ad esempio a3-ultragpu-8g.

REST

In una richiesta al metodo nodePools.create, specifica il campo accelerator_network_profile:

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

Sostituisci quanto segue:

  • NODE_POOL_NAME: il nome del nuovo pool di nodi.
  • MACHINE_TYPE: il tipo di macchina per i nodi, ad esempio a3-ultragpu-8g.

Pianifica un workload che utilizza le GPU

Le sezioni seguenti mostrano come configurare un pool di nodi GPU e un workload per utilizzare interfacce di rete RDMA con DRANET gestito da GKE. Per maggiori dettagli, consulta Allocare risorse di rete utilizzando GKE Managed 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 node pool.

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 Google Cloud regione del 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 l'avvio flessibile, 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 Visualizzare le richieste di prenotazione futura.

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

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

Esegui il deployment delle risorse RDMA di un workload

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 file 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 carico di lavoro e fai riferimento a ResourceClaimTemplate. Il seguente manifest esegue il deployment di un pod che fa riferimento al modello 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 eth0 e lo predefinite, nonché le interfacce RDMA allocate, ad esempio 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
    

Pianifica un workload che utilizza le TPU

Le sezioni seguenti mostrano come configurare un pool di nodi TPU e un workload per utilizzare interfacce di rete non RDMA con DRANET gestito da GKE. Per maggiori dettagli, consulta Allocare risorse di rete utilizzando GKE Managed DRANET.

Verificare le DeviceClass di rete

Verifica che le risorse DeviceClass per il networking esistano nel 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 slice TPU

Per abilitare il driver GKE DRANET 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 Google Cloud regione o la zona del cluster.
  • CLUSTER_NAME: il nome del cluster.
  • NODE_LOCATIONS: Le Google Cloud zone per i nodi nel pool di nodi.
  • MACHINE_TYPE: Il tipo di macchina da utilizzare per i nodi. Per ulteriori informazioni sui tipi di macchina compatibili con le TPU, vedi Scegliere la versione 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 la sezione Scegliere una topologia.
  • NUM_NODES: il numero di nodi nel pool di nodi.

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

Esegui il deployment di un carico di lavoro che rivendica 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 file 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 carico di lavoro e fai riferimento a ResourceClaimTemplate. Il seguente manifest esegue il deployment di un pod che utilizza il modello all-netdev per concedere al pod l'accesso a tutti i dispositivi di rete non RDMA sul nodo. Salva il file 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 eth0 e lo predefinite, 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
    

Risoluzione dei problemi

Per controllare la configurazione di rete per un pool di nodi, esegui questo comando:

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

Sostituisci quanto segue:

  • NODE_POOL_NAME: il nome del tuo pool di nodi.
  • ZONE: la zona del pool di nodi.
  • CLUSTER_NAME: il nome del tuo cluster.

L'output mostra le reti e le subnet aggiuntive collegate al pool di nodi.

Passaggi successivi