Allocare risorse di rete utilizzando DRANET gestito da GKE

Google Kubernetes Engine (GKE) DRANET è una funzionalità GKE gestita che si basa sul progetto open source DRANET, che implementa l'API Kubernetes DRA per le risorse di networking. DRANET ti consente di richiedere e allocare risorse di rete ad alte prestazioni per i tuoi pod, incluse interfacce di rete che supportano l'accesso diretto alla memoria remota (RDMA). Questo approccio fornisce un'API portabile e allineata all'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 cluster GKE.

Questo documento è destinato agli architetti cloud e agli 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 viene fatto riferimento nei contenuti di Google Cloud , consulta Ruoli e attività comuni degli utenti GKE.

Prima di leggere questo documento, assicurati di conoscere 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 o TPU su cui è abilitato GKE DRANET. Funziona come 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 i dispositivi compatibili con RDMA e la classe netdev.google.com per gli altri dispositivi di rete.

Per utilizzare GKE DRANET, devi prima abilitare il driver GKE DRANET su unpool di nodil con GPU o TPU.

Per richiedere dispositivi di rete per un workload, definisci un ResourceClaimTemplate. Questo modello 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 modello in un campo resourceClaims per concedere al pod l'accesso alle interfacce di rete richieste sul nodo.

Quando utilizzare GKE managed DRANET

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 i workload di AI e ML che richiedono networking ad alte prestazioni.

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

  • Richiesta di tutte le interfacce compatibili con RDMA disponibili.
  • Richiesta di 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 chiave quando utilizzi GKE managed DRANET per il networking

Tieni presente i seguenti punti quando utilizzi GKE DRANET per il networking:

  • Interfacce di rete dedicate

    Quando utilizzi GKE DRANET per richiedere un'interfaccia di rete per un pod, questa interfaccia è dedicata a quel pod. Gli altri pod sullo stesso nodo non possono condividerlo. In questo modo, il pod ha accesso esclusivo alla larghezza di banda e alle risorse complete di questa interfaccia, il che è un vantaggio fondamentale per i carichi di lavoro sensibili al rendimento.

  • Utilizzare il driver DRANET gestito da GKE in modo indipendente

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

  • Utilizzare altri driver GKE DRA

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

  • Evitare configurazioni in conflitto

    Il driver GKE DRANET gestisce le interfacce RDMA e le gVNIC che non hanno intervalli di indirizzi IP secondari configurati. Non utilizzare sia il driver GKE DRANET sia l'API multi-rete 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.

Requisiti

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

  • GKE 1.34.1-gke.1829001 o versioni successive.
  • GKE Dataplane V2 è abilitato sul cluster.
  • (Anteprima) GKE DRANET è disponibile sulle macchine A4X Max.

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).
  • La scalabilità automatica del cluster e Autopilot non sono supportati.
  • Non puoi utilizzare GKE DRANET con interfacce in cui hai configurato un secondaryPodRange.

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.

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per creare pool di nodi 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 per il 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. Questa versione deve essere 1.34.1-gke.1829001 o successiva.

Utilizzare interfacce RDMA da un pool di nodi GPU

Le sezioni seguenti descrivono come configurare un pool di nodi GPU e un workload per utilizzare 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 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 aggiuntive allocate 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
    

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

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
    

Richiedere un numero specifico di dispositivi di rete

Gli esempi precedenti mostrano come richiedere tutti i dispositivi di rete disponibili di un determinato tipo impostando allocationMode su All. Se invece devi richiedere un numero specifico di dispositivi, puoi impostare allocationMode su ExactCount nel tuo ResourceClaimTemplate.

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