Benutzerdefinierten KI-optimierten GKE-Cluster erstellen, der A4X verwendet

Auf dieser Seite wird beschrieben, wie Sie einen KI-optimierten Google Kubernetes Engine-Cluster (GKE) erstellen, in dem A4X-VMs verwendet werden, um Ihre KI- und ML-Arbeitslasten zu unterstützen. Weitere Informationen zu A4X finden Sie unter A4X-Serie.

Die A4X-Maschinenreihe wurde entwickelt, um die Ausführung von KI/ML-Clustern im großen Maßstab zu ermöglichen. Sie bietet Funktionen wie die gezielte Platzierung von Arbeitslasten, erweiterte Steuerelemente für die Clusterwartung und Topology Aware Scheduling. Weitere Informationen finden Sie unter Clusterverwaltung – Übersicht.

GKE bietet eine einheitliche Plattform, auf der Sie eine Vielzahl von Arbeitslasten für Ihre Organisationen ausführen können. So wird der Betriebsaufwand für die Verwaltung mehrerer Plattformen reduziert. Sie können Arbeitslasten wie leistungsstarkes verteiltes Vortraining, Modellabstimmung, Modellinferenz, Anwendungsbereitstellung und unterstützende Dienste ausführen.

Auf dieser Seite erfahren Sie, wie Sie einen GKE-Cluster mit der Google Cloud CLI erstellen, um Ihren Cluster basierend auf den Anforderungen Ihrer Arbeitslast maximal flexibel zu konfigurieren. Alternativ können Sie das Cluster Toolkit verwenden, um Ihren Cluster schnell mit Standardeinstellungen bereitzustellen, die Best Practices für viele Anwendungsfälle entsprechen.

Optionen für die Clusterkonfiguration mit GPUDirect RDMA

Wenn Sie Ihren Cluster mit der Google Cloud CLI erstellen möchten, können Sie eine der folgenden Clusterkonfigurationsoptionen auswählen:

  • Wenn Sie verteilte KI-Arbeitslasten ausführen möchten: Erstellen Sie einen GKE-Cluster mit GPUDirect RDMA. Folgen Sie dazu der Anleitung auf dieser Seite.
  • Wenn Sie keine verteilten KI-Arbeitslasten ausführen möchten: Erstellen Sie einen GKE-Cluster ohne GPUDirect RDMA. Weitere Informationen finden Sie unter Cluster ohne GPUDirect RDMA erstellen.

Hinweise

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API.
    • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diesen Task verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl gcloud components update ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für das Projekt zuzuweisen, damit Sie die nötigen Berechtigungen zum Erstellen und Verwalten eines GKE-Cluster haben:

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Kapazität erhalten

Sie können Kapazität für A4X-VMs erhalten, indem Sie eine zukünftige Reservierung erstellen. Weitere Informationen zu vorausschauenden Reservierungen finden Sie in der Tabelle unter Verbrauchsoption auswählen> Vorausschauende Reservierungen in AI Hypercomputer.

Informationen zum Abrufen von Kapazität mit einer vorausschauenden Reservierung finden Sie in der Tabelle unter Kapazität abrufen in der Zeile Vorausschauende Reservierungen in AI Hypercomputer.

Voraussetzungen

Für einen KI-optimierten GKE-Cluster mit A4X-VMs gelten die folgenden Anforderungen:

  • Für A4X müssen Sie für Version 1.33 oder höher die GKE-Version 1.33.4-gke.1036000 oder höher verwenden. Oder verwenden Sie für 1.32 die GKE-Version 1.32.8-gke.1108000 oder höher. Mit diesen Versionen wird sichergestellt, dass A4X Folgendes verwendet:

    • R580, die Mindest-GPU-Treiberversion für A4X.
    • Coherent Driver-based Memory Management (CDMM), das standardmäßig aktiviert ist. NVIDIA empfiehlt, diesen Modus in Kubernetes-Clustern zu aktivieren, um zu hohe Arbeitsspeicherangaben zu vermeiden. Mit CDMM kann der GPU-Speicher über den Treiber anstelle des Betriebssystems verwaltet werden. So wird vermieden, dass das Betriebssystem den GPU-Arbeitsspeicher online schaltet, und der GPU-Arbeitsspeicher wird dem Betriebssystem als NUMA-Knoten (Non-Uniform Memory Access) zur Verfügung gestellt. GPUs mit mehreren Instanzen werden nicht unterstützt, wenn CDMM aktiviert ist. Weitere Informationen zu CDMM finden Sie unter Hardware- und Software-Support.
    • GPUDirect RDMA, das empfohlen wird, damit A4X-Knotenpools die Netzwerkfunktionen von A4X nutzen können.

  • Die GKE-Knoten müssen ein Knoten-Image für Container-Optimized OS verwenden. Ubuntu- und Windows-Knotenimages werden nicht unterstützt.

  • Ihre GKE-Arbeitslast muss alle verfügbaren GPUs und Ihr Pod alle verfügbaren sekundären NICs auf einem einzelnen GKE-Knoten verwenden. Mehrere Pods können RDMA nicht auf einem einzelnen GKE-Knoten gemeinsam nutzen.

  • Bei dieser Einrichtung wird ein NCCL-Test ausgeführt. Um diesen NCCL-Test auszuführen, benötigen Sie ein VM-Mindestkontingent von 2 (4 GPUs pro VM bei Verwendung von a4x-highgpu-4g oder a4x-highgpu-4g-nolssd).

  • Sie müssen das Bereitstellungsmodell reservierungsgebunden verwenden, um Cluster mit A4X zu erstellen. Andere Bereitstellungsmodelle werden nicht unterstützt.

  • GPUDirect RDMA ist nicht mit NCCL Fast Socket oder GPUDirect TCPX/TCPXO kompatibel. Aktivieren Sie NCCL Fast Socket nicht und installieren Sie das TCPX-/TCPXO-Plug-in nicht in Clustern, die GPUDirect RDMA verwenden.

Hinweise zum Erstellen eines Clusters

Beachten Sie beim Erstellen eines Clusters Folgendes:

  • Clusterstandort auswählen:
    • Prüfen Sie, ob der von Ihnen ausgewählte Maschinentyp am von Ihnen verwendeten Standort verfügbar ist. Weitere Informationen finden Sie unter GPU-Standorte.
    • Für dichte Reservierungen können Sie einen zonalen Cluster erstellen. Ersetzen Sie in diesem Fall das Flag --region durch das Flag --zone=COMPUTE_ZONE, wobei COMPUTE_ZONE die Zone Ihrer Steuerungsebene ist.
    • Wenn Sie Knotenpools in einem regionalen Cluster erstellen, können Sie mit dem Flag --node-locations die Zonen für Ihre GKE-Knoten angeben.
  • Treiberversion auswählen:
    • Die Treiberversion kann einen der folgenden Werte haben:
      • default: Installieren Sie die Standardtreiberversion für Ihre GKE-Knotenversion. Weitere Informationen zu den Anforderungen an Standardtreiberversionen finden Sie im Abschnitt Anforderungen.
      • latest: Installieren Sie die neueste verfügbare Treiberversion für Ihre GKE-Version. Diese Option ist nur für Knoten verfügbar, die Container-Optimized OS verwenden.
      • disabled: Automatische Treiberinstallation überspringen. Sie müssen einen Treiber manuell installieren, nachdem Sie den Knotenpool erstellt haben.
    • Weitere Informationen zu den standardmäßigen und neuesten GPU-Treiberversionen für GKE-Knotenversionen finden Sie in der Tabelle im Abschnitt NVIDIA-GPU-Treiber manuell installieren.

  • Reservierungsaffinität auswählen:

    • Hier finden Sie Informationen zu Ihrer Reservierung, z. B. den Namen Ihrer Reservierung oder den Namen eines bestimmten Blocks in Ihrer Reservierung. Informationen zum Ermitteln dieser Werte finden Sie unter Zukünftige Reservierungsanfragen anzeigen.
    • Das Flag --reservation-affinity kann die Werte specific oder any haben. Für verteilte KI-Arbeitslasten mit hoher Leistung empfehlen wir jedoch, eine bestimmte Reservierung zu verwenden.

    • Wenn Sie eine bestimmte Reservierung verwenden, einschließlich freigegebener Reservierungen, geben Sie den Wert des Flags --reservation im folgenden Format an:

      projects/PROJECT_ID/reservations/RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Ersetzen Sie die folgenden Werte:

      • PROJECT_ID: Projekt-ID in Google Cloud .
      • RESERVATION_NAME: der Name Ihrer Reservierung.
      • BLOCK_NAME: der Name eines bestimmten Blocks innerhalb der Reservierung.

      Wenn Sie eine Reservierung mit untergeordneten Blöcken verwenden möchten, damit VMs in einem einzelnen untergeordneten Block innerhalb von BLOCK_NAME platziert werden, fügen Sie Folgendes am Ende des Pfads hinzu:

      /reservationSubBlocks/SUB_BLOCK_NAME

      Ersetzen Sie SUB_BLOCK_NAME durch den Namen des Unterblocks.

KI-optimierten GKE-Cluster erstellen, der A4X und GPUDirect RDMA verwendet

Bei verteilten KI-Arbeitslasten werden häufig mehrere GPU-Knoten miteinander verbunden, um als ein einzelner Computer zu fungieren. A4X ist eine Exascale-Plattform, die auf der Rack-Scale-Architektur NVIDIA GB200 NVL72 basiert. Dieser Maschinentyp ermöglicht die Skalierung und Zusammenarbeit über mehrere GPUs hinweg und bietet eine leistungsstarke Cloud-Umgebung für KI-Arbeitslasten. Weitere Informationen zur Netzwerkarchitektur für A4X, einschließlich der Netzwerkbandbreite und der NIC-Anordnung, finden Sie unter A4X-Maschinentypen.

Führen Sie die folgenden Schritte aus, um Ihre GKE-Standardcluster mit A4X und GPUDirect RDMA zu erstellen. Die Schritte werden in den nächsten Abschnitten beschrieben:

  1. VPCs und Subnetze erstellen
  2. GKE-Cluster mit Multi-Networking erstellen
  3. GKE-Netzwerkobjekte erstellen
  4. Arbeitslastrichtlinie erstellen
  5. Knotenpool mit A4X erstellen
  6. RDMA-Binärprogramm installieren und NCCL konfigurieren
  7. NVIDIA Compute Domain CRD und DRA-Treiber installieren

VPCs und Subnetze erstellen

A4X-VMs haben die folgende Konfiguration:

  • Vier NVIDIA B200-GPUs pro virtueller Maschine, die über NVLink verbunden sind
  • Zwei Arm-basierte NVIDIA Grace-CPUs
  • Vier CX-7-Netzwerkkarten (NICs) mit 400 Gbit/s für die GPU-zu-GPU-Vernetzung
  • Zwei Google Titanium-Netzwerkkarten (NICs) mit 200 Gbit/s für externe Dienste

KI- und ML-Arbeitslasten wie verteiltes Training erfordern eine leistungsstarke Beschleunigung, um die Leistung zu optimieren, indem die Ausführungszeiten von Jobs verkürzt werden. Für Arbeitslasten, die hohe Leistung, hohen Durchsatz und niedrige Latenz erfordern, reduziert GPUDirect RDMA die Netzwerk-Hops, die für die Übertragung von Nutzlasten zu und von GPUs erforderlich sind. Bei diesem Ansatz wird die verfügbare Netzwerkbandbreite effizienter genutzt.

Eine der Google Titanium-NICs, die der CPU zugeordnet ist, verwendet das Standardnetzwerk in GKE. Sie müssen also keine neue VPC für diese NIC erstellen, solange Sie genügend IP-Adressbereiche für das Standardnetzwerk haben.

Sie können mit den folgenden Befehlen eine VPC für die zweite CPU-Titanium-NIC (gVNIC) und eine weitere VPC für die vier CX-7-RDMA-NICs erstellen.

Um die Netzwerkbandbreite zu maximieren, wird mit dem Befehl zum Erstellen eines VPC für die zusätzlichen GVNIC-Sets die maximale Übertragungseinheit (Maximum Transmission Unit, MTU) auf 8.896 festgelegt. Der RDMA-VPC-Standardport ist die empfohlene Einstellung 8896. Weitere Informationen finden Sie unter MTU-Einstellungen und GPU-Maschinentypen.

  1. Legen Sie Umgebungsvariablen fest, die Ihrer Bereitstellung entsprechen:

    export REGION="COMPUTE_REGION"
export ZONE="COMPUTE_ZONE"
export PROJECT="PROJECT_ID"
export GVNIC_NETWORK_PREFIX="GVNIC_NETWORK_PREFIX"
export RDMA_NETWORK_PREFIX="RDMA_NETWORK_PREFIX"

    Ersetzen Sie die folgenden Variablen:

    • COMPUTE_REGION: Die Region Ihres Clusters.
    • COMPUTE_ZONE: die Zone des Knotenpools.
    • PROJECT_ID: Projekt-ID in Google Cloud .
    • GVNIC_NETWORK_PREFIX: Das GVNIC-Netzwerkpräfix, z. B. a4x-gvnic.
    • RDMA_NETWORK_PREFIX: Das RDMA-Netzwerkpräfix, z. B. a4x-rdma.

  2. Zwei VPC-Netzwerke erstellen:

    # Create a VPC for the additional GVNIC
gcloud compute --project=${PROJECT} \
  networks create \
  GVNIC_NETWORK_PREFIX-net \
  --subnet-mode=custom \
  --mtu=8896

gcloud compute --project=${PROJECT} \
  networks subnets create \
  GVNIC_NETWORK_PREFIX-sub \
  --network=GVNIC_NETWORK_PREFIX-net \
  --region=${REGION} \
  --range=192.168.0.0/24

gcloud compute --project=${PROJECT} \
  firewall-rules create \
  GVNIC_NETWORK_PREFIX-internal \
  --network=GVNIC_NETWORK_PREFIX-net \
  --action=ALLOW \
  --rules=tcp:0-65535,udp:0-65535,icmp \
  --source-ranges=192.168.0.0/16

# Create HPC VPC for the RDMA NICs with 4 subnets.
gcloud compute --project=${PROJECT} \
  networks create RDMA_NETWORK_PREFIX-net \
  --network-profile=${ZONE}-vpc-roce \
  --subnet-mode=custom

# Create subnets for the HPC VPC.
for N in $(seq 0 3); do
  gcloud compute --project=${PROJECT} \
    networks subnets create \
    RDMA_NETWORK_PREFIX-sub-$N \
    --network=RDMA_NETWORK_PREFIX-net \
    --region=${REGION} \
    --range=192.168.$((N+1)).0/24 &  # offset to avoid overlap with gvnics
done

GKE-Cluster mit Multi-Networking erstellen

  1. GKE-Standardcluster mit mehreren Netzwerken erstellen:

    gcloud container clusters create CLUSTER_NAME \
    --enable-dataplane-v2 --enable-ip-alias --location=COMPUTE_REGION \
    --enable-multi-networking --cluster-version=CLUSTER_VERSION \
    --enable-kubernetes-unstable-apis=resource.k8s.io/v1beta1/deviceclasses,resource.k8s.io/v1beta1/resourceclaims,resource.k8s.io/v1beta1/resourceclaimtemplates,resource.k8s.io/v1beta1/resourceslices \
    [--services-ipv4-cidr=SERVICE_CIDR \
    --cluster-ipv4-cidr=POD_CIDR]

    Gehen Sie beim Vorbereiten dieses Befehls so vor:

    • Entfernen Sie das Flag --enable-kubernetes-unstable-apis, das zum Aktivieren von DRA verwendet wird, wenn Sie einen Cluster mit GKE-Version 1.34 oder höher erstellen. Dieses Flag ist nur erforderlich, wenn Sie einen Cluster mit Version 1.32 oder 1.33 erstellen. Wenn Sie eine Beta API aktivieren, müssen Sie schließlich von der Beta API migrieren, wenn sie verworfen und mit späteren Kubernetes-Nebenversionen entfernt wird. Weitere Informationen finden Sie unter Einstellung von Beta APIs.

    • Ersetzen Sie Folgendes:

      • CLUSTER_NAME: Der Name Ihres Clusters.
      • CLUSTER_VERSION: die Version Ihres neuen Clusters. Weitere Informationen dazu, welche Version von GKE Ihre Konfiguration unterstützt, finden Sie in diesem Dokument unter Anforderungen.
      • COMPUTE_REGION: der Name der Compute-Region.

    • Optional können Sie die sekundären CIDR-Bereiche für Dienste und Pods explizit angeben. Wenn Sie diese optionalen Flags verwenden, ersetzen Sie die folgenden Variablen:

      • SERVICE_CIDR: der sekundäre CIDR-Bereich für Dienste.
      • POD_CIDR: der sekundäre CIDR-Bereich für Pods.

      Wenn Sie diese Flags verwenden, müssen Sie prüfen, ob sich die CIDR-Bereiche nicht mit Subnetzbereichen für zusätzliche Knotennetzwerke überschneiden. Beispiel: SERVICE_CIDR=10.65.0.0/19 und POD_CIDR=10.64.0.0/19. Weitere Informationen finden Sie unter Pod-IPv4-Adressbereiche hinzufügen.

GKE-Netzwerkobjekte erstellen

Sie müssen die im vorherigen Abschnitt erstellten VPC-Netzwerke über GKE-Netzwerkparametersätze konfigurieren. Insbesondere muss die zweite CPU-Titanium-NIC (gVNIC) im NetDevice-Modus konfiguriert werden und jede der vier CX-7-RDMA-NICs im RDMA-Modus.

Dieser Befehl verwendet die folgenden Namen:

  • Das VPC-Netzwerk für die Titanium-NIC (gVNIC) der CPU heißt GVNIC_NETWORK_PREFIX-net und das Subnetz GVNIC_NETWORK_PREFIX-sub.
  • Die VPC für CX-7-RDMA-NICs heißt RDMA_NETWORK_PREFIX-net und die Subnetze heißen RDMA_NETWORK_PREFIX-sub-[0…3].

Erstellen Sie die GKE-Netzwerkobjekte mit dem folgenden Befehl:

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: gvnic-1
spec:
  vpc: GVNIC_NETWORK_PREFIX-net
  vpcSubnet: GVNIC_NETWORK_PREFIX-sub
  deviceMode: NetDevice
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: gvnic-1
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: gvnic-1
---
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: rdma-0
spec:
  vpc: RDMA_NETWORK_PREFIX-net
  vpcSubnet: RDMA_NETWORK_PREFIX-sub-0
  deviceMode: RDMA
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: rdma-0
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: rdma-0
---
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: rdma-1
spec:
  vpc: RDMA_NETWORK_PREFIX-net
  vpcSubnet: RDMA_NETWORK_PREFIX-sub-1
  deviceMode: RDMA
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: rdma-1
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: rdma-1
---
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: rdma-2
spec:
  vpc: RDMA_NETWORK_PREFIX-net
  vpcSubnet: RDMA_NETWORK_PREFIX-sub-2
  deviceMode: RDMA
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: rdma-2
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: rdma-2
---
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: rdma-3
spec:
  vpc: RDMA_NETWORK_PREFIX-net
  vpcSubnet: RDMA_NETWORK_PREFIX-sub-3
  deviceMode: RDMA
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: rdma-3
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: rdma-3
EOF

Arbeitslastrichtlinie erstellen

Zum Erstellen einer Partition ist eine Arbeitslastrichtlinie erforderlich. Weitere Informationen finden Sie unter Arbeitslastrichtlinie für MIGs.

Erstellen Sie eine HIGH_THROUGHPUT-Arbeitslastrichtlinie, in der das Feld accelerator_topology auf 1x72 festgelegt ist.

gcloud beta compute resource-policies create workload-policy WORKLOAD_POLICY_NAME \
    --type HIGH_THROUGHPUT \
    --accelerator-topology 1x72 \
    --project PROJECT \
    --region COMPUTE_REGION

Ersetzen Sie Folgendes:

  • WORKLOAD_POLICY_NAME: der Name Ihrer Arbeitslastrichtlinie.
  • PROJECT: Name Ihres Projekts
  • COMPUTE_REGION: der Name der Compute-Region.

Knotenpool mit A4X erstellen

Wir empfehlen, einen Knotenpool zu erstellen, der das GKE-GPU-Geräte-Plug-in verwendet. Dieses Plug-in bietet die von GKE verwaltete GPU-Ressourcenverwaltung. Dieser Ansatz bietet folgende Vorteile:

  • Einfache Bereitstellung und Upgrades
  • Automatische Treiberinstallation
  • Von GKE verwaltete GPU-Funktionen wie Messwerte und partitionierte GPUs
  • Wichtige Korrekturen bei Sicherheitslücken

Alternativ können Sie den NVIDIA GPU-Operator verwenden, falls dies für Ihren Anwendungsfall erforderlich ist. Weitere Informationen finden Sie unter Warum den NVIDIA GPU-Operator verwenden?.

A4X-Knotenpool mit dem GKE-GPU-Geräte-Plug-in erstellen

Erstellen Sie einen A4X-Knotenpool, der das GKE-GPU-Geräte-Plug-in verwendet:

gcloud container node-pools create NODE_POOL_NAME \
    --location COMPUTE_REGION \
    --node-locations COMPUTE_ZONE \
    --cluster CLUSTER_NAME \
    --num-nodes=NODE_COUNT \
    --machine-type MACHINE_TYPE \
    --accelerator type=nvidia-gb200,count=4,gpu-driver-version=DRIVER_VERSION \
    --additional-node-network network=GVNIC_NETWORK_PREFIX-net,subnetwork=GVNIC_NETWORK_PREFIX-sub \
    --additional-node-network network=RDMA_NETWORK_PREFIX-net,subnetwork=RDMA_NETWORK_PREFIX-sub-0 \
    --additional-node-network network=RDMA_NETWORK_PREFIX-net,subnetwork=RDMA_NETWORK_PREFIX-sub-1 \
    --additional-node-network network=RDMA_NETWORK_PREFIX-net,subnetwork=RDMA_NETWORK_PREFIX-sub-2 \
    --additional-node-network network=RDMA_NETWORK_PREFIX-net,subnetwork=RDMA_NETWORK_PREFIX-sub-3 \
    --scopes "https://www.googleapis.com/auth/cloud-platform" \
    --reservation-affinity=specific \
    --reservation=RESERVATION_NAME/reservationBlocks/BLOCK_NAME \
    --placement-policy=WORKLOAD_POLICY_NAME

Ersetzen Sie Folgendes:

  • NODE_POOL_NAME ist der Name des Knotenpools.
  • COMPUTE_REGION: Die Region Ihres Clusters.
  • COMPUTE_ZONE: die Zone des Knotenpools.
  • CLUSTER_NAME: Der Name Ihres Clusters.
  • NODE_COUNT: Die Anzahl der Knoten für den Knotenpool, die maximal 18 betragen darf. Wir empfehlen, 18 Knoten zu verwenden, um die GPU-Topologie von 1x72 in einem Unterblock mit einer NVLink-Domain zu erhalten.
  • MACHINE_TYPE: a4x-highgpu-4g oder a4x-highgpu-4g-nolssd, je nachdem, ob Sie lokale SSDs verwenden möchten.
  • DRIVER_VERSION: die zu installierende NVIDIA-Treiberversion. Er kann einen der folgenden Werte haben: default, latest oder disabled.
  • RESERVATION_NAME: Der Name Ihrer Reservierung. Informationen zum Ermitteln dieses Werts finden Sie unter Zukünftige Reservierungsanfragen ansehen.
  • BLOCK_NAME: der Name eines bestimmten Blocks innerhalb der Reservierung. Informationen zum Ermitteln dieses Werts finden Sie unter Zukünftige Reservierungsanfragen ansehen.
  • WORKLOAD_POLICY_NAME: Der Name der Workload-Richtlinie, die Sie zuvor erstellt haben.

A4X-Knotenpool mit dem NVIDIA GPU Operator erstellen

Alternativ können Sie den NVIDIA GPU-Operator verwenden. Gehen Sie dazu so vor:

  1. Führen Sie den Befehl gcloud container node-pools create aus dem vorherigen Abschnitt mit den folgenden Änderungen aus:

    • Ändern Sie gpu-driver-version=latest zu gpu-driver-version=disabled. Bei dieser Änderung wird die automatische Installation von GPU-Treibern übersprungen, da sie bei Verwendung des NVIDIA GPU-Operators nicht unterstützt wird.
    • Legen Sie --node-labels="gke-no-default-nvidia-gpu-device-plugin=true" fest, um das von GKE verwaltete GPU-Geräte-Plug-in-DaemonSet zu deaktivieren.

  2. Wenden Sie das Manifest des GKE-GPU-Treiberinstallations-DaemonSets an. Mit diesem Manifest wird ein GPU-Treiberinstallations-Pod auf jedem A4X-Knoten bereitgestellt:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/refs/heads/master/nvidia-driver-installer/cos/daemonset-preloaded.yaml

  3. GPU-Stack mit dem NVIDIA GPU Operator in Google Kubernetes Engine (GKE) verwalten:

    1. Folgen Sie im Abschnitt zum Erstellen und Einrichten des GPU-Knotenpools der Anleitung ab dem Schritt zum Abrufen von Anmeldedaten für die Authentifizierung.

    2. NVIDIA GPU Operator installieren Führen Sie alle Schritte aus, ersetzen Sie aber den Befehl im referenzierten Abschnitt, mit dem der NVIDIA GPU Operator mit Helm installiert wird. Verwenden Sie stattdessen den folgenden Befehl:

      helm install --wait --generate-name \
  -n gpu-operator \
  nvidia/gpu-operator \
  --version="25.3.0" \
  -f <(cat <<EOF
hostPaths:
  driverInstallDir: /home/kubernetes/bin/nvidia
toolkit:
  installDir: /home/kubernetes/bin/nvidia
cdi:
  enabled: true
  default: true
driver:
  enabled: false

daemonsets:
  tolerations:
    - key: nvidia.com/gpu
      operator: Equal
      value: present
      effect: NoSchedule
    - key: kubernetes.io/arch
      operator: Equal
      value: arm64
      effect: NoSchedule

node-feature-discovery:
  worker:
    tolerations:
      - key: kubernetes.io/arch
        operator: Equal
        value: arm64
        effect: NoSchedule
      - key: "node-role.kubernetes.io/master"
        operator: "Equal"
        value: ""
        effect: "NoSchedule"
      - key: "node-role.kubernetes.io/control-plane"
        operator: "Equal"
        value: ""
        effect: "NoSchedule"
      - key: nvidia.com/gpu
        operator: Exists
        effect: NoSchedule
EOF
)

RDMA-Binärprogramm installieren und NCCL konfigurieren

Wenden Sie das folgende DaemonSet an, um die RDMA-Binärdateien und die NCCL-Bibliothek auf jedem Knoten zu installieren. Auf jeder zugrunde liegenden VM werden die RDMA-Binärdateien im Verzeichnis /home/kubernetes/bin/gib und die NCCL-Bibliothek im Verzeichnis /home/kubernetes/bin/nvidia/lib64 installiert.

  kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/gpudirect-rdma/nccl-rdma-installer-a4x.yaml

NVIDIA Compute Domain CRD und DRA-Treiber installieren

Installieren Sie die CRD für die NVIDIA-Compute-Domain und den DRA-Treiber. Weitere Informationen finden Sie unter NVIDIA DRA Driver for GPUs.

  1. Prüfen Sie, ob Helm in Ihrer Entwicklungsumgebung installiert ist. Helm ist in der Cloud Shell vorinstalliert.

    Es gibt keine spezielle Helm-Versionsanforderung. Sie können jedoch mit dem folgenden Befehl prüfen, ob Helm installiert ist.

    helm version

    Wenn die Ausgabe ähnlich wie Command helm not found ist, können Sie die Helm-CLI mit diesem Befehl installieren:

    curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 \
  && chmod 700 get_helm.sh \
  && ./get_helm.sh

  2. Fügen Sie das NVIDIA-Helm-Repository hinzu:

    helm repo add nvidia https://helm.ngc.nvidia.com/nvidia \
  && helm repo update

  3. Erstellen Sie ein ResourceQuota für den DRA-Treiber:

    export POD_QUOTA=POD_QUOTA

kubectl create ns nvidia-dra-driver-gpu

kubectl apply -n nvidia-dra-driver-gpu -f - << EOF
apiVersion: v1
kind: ResourceQuota
metadata:
  name: nvidia-dra-driver-gpu-quota
spec:
  hard:
    pods: ${POD_QUOTA}
  scopeSelector:
    matchExpressions:
    - operator: In
      scopeName: PriorityClass
      values:
        - system-node-critical
        - system-cluster-critical
EOF

    Ersetzen Sie POD_QUOTA durch eine Zahl, die mindestens das Doppelte der Anzahl der A4X-Knoten im Cluster plus 1 ist. Wenn Sie beispielsweise 18 A4X-Knoten in Ihrem Cluster haben, müssen Sie die Variable auf mindestens 37 festlegen.

  4. Installieren Sie den DRA-Treiber:

    helm install nvidia-dra-driver-gpu nvidia/nvidia-dra-driver-gpu \
    --version="DRIVER_VERSION" \
    --create-namespace \
    --namespace nvidia-dra-driver-gpu \
    -f <(cat <<EOF
nvidiaDriverRoot: /home/kubernetes/bin/nvidia
resources:
  gpus:
    enabled: false

controller:
  affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: "nvidia.com/gpu"
              operator: "DoesNotExist"

kubeletPlugin:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: cloud.google.com/gke-accelerator
                operator: In
                values:
                  - nvidia-gb200
              - key: kubernetes.io/arch
                operator: In
                values:
                  - arm64

  tolerations:
    - key: nvidia.com/gpu
      operator: Equal
      value: present
      effect: NoSchedule
    - key: kubernetes.io/arch
      operator: Equal
      value: arm64
      effect: NoSchedule
EOF
)

    Ersetzen Sie DRIVER_VERSION durch Version 25.3.1 oder höher.

Arbeitslastmanifest für Multi-Networking, RDMA und die IMEX-Domain konfigurieren

  1. Fügen Sie den Pod-Metadaten die folgenden Annotationen hinzu:

    metadata:
  annotations:
    networking.gke.io/default-interface: 'eth0'
    networking.gke.io/interfaces: |
      [
        {"interfaceName":"eth0","network":"default"},
        {"interfaceName":"eth2","network":"rdma-0"},
        {"interfaceName":"eth3","network":"rdma-1"},
        {"interfaceName":"eth4","network":"rdma-2"},
        {"interfaceName":"eth5","network":"rdma-3"}
      ]

  2. So fügen Sie eine Knotenaffinitätsregel hinzu, um die Planung auf Arm-Knoten zu ermöglichen:

    spec:
affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/arch
          operator: In
          values:
          - arm64

    Weitere Informationen finden Sie unter Arbeitslast für eine einzelne Architektur planen.

  3. Fügen Sie der Pod-Spezifikation die folgenden Volumes hinzu:

    spec:
volumes:
  - name: library-dir-host
    hostPath:
      path: /home/kubernetes/bin/nvidia
  - name: gib
    hostPath:
      path: /home/kubernetes/bin/gib

  4. Fügen Sie dem Container, der GPUs anfordert, die folgenden Mounts, Umgebungsvariablen und Ressourcen hinzu. Der Arbeitslastcontainer muss alle vier GPUs anfordern:

    containers:
- name: my-container
  volumeMounts:
    - name: library-dir-host
      mountPath: /usr/local/nvidia
    - name: gib
   mountPath: /usr/local/gib
  env:
    - name: LD_LIBRARY_PATH
      value: /usr/local/nvidia/lib64
  resources:
    limits:
      nvidia.com/gpu: 4

  5. Erstellen Sie die ComputeDomain-Ressource für die Arbeitslast:

    apiVersion: resource.nvidia.com/v1beta1
kind: ComputeDomain
metadata:
  name: a4x-compute-domain
spec:
  numNodes: NUM_NODES
  channel:
    resourceClaimTemplate:
      name: a4x-compute-domain-channel

    Ersetzen Sie NUM_NODES durch die Anzahl der Knoten, die für die Arbeitslast erforderlich sind.

  6. Geben Sie die ResourceClaimTemplate an, die der Pod verwenden soll:

    spec:
  ...
  volumes:
    ...
  containers:
    - name: my-container
      ...
      resources:
        limits:
          nvidia.com/gpu: 4
  claims:
          - name: compute-domain-channel
        ...
resourceClaims:
  - name: compute-domain-channel
    resourceClaimTemplateName: a4x-compute-domain-channel

  7. Legen Sie alle erforderlichen Umgebungsvariablen fest, um NCCL zu konfigurieren. Verwenden Sie das folgende Shell-Skript aus dem Arbeitslastcontainer:

    source /usr/local/gib/scripts/set_nccl_env.sh

Eine vollständige Pod-Spezifikation sieht so aus:

apiVersion: resource.nvidia.com/v1beta1
kind: ComputeDomain
metadata:
  name: a4x-compute-domain
spec:
  numNodes: NUM_NODES
  channel:
    resourceClaimTemplate:
      name: a4x-compute-domain-channel
---
apiVersion: apps/v1
kind: Pod
metadata:
  name: my-pod
  labels:
    k8s-app: my-pod
  annotations:
    networking.gke.io/default-interface: 'eth0'
    networking.gke.io/interfaces: |
      [
        {"interfaceName":"eth0","network":"default"},
        {"interfaceName":"eth2","network":"rdma-0"},
        {"interfaceName":"eth3","network":"rdma-1"},
        {"interfaceName":"eth4","network":"rdma-2"},
        {"interfaceName":"eth5","network":"rdma-3"},
      ]
spec:
  ...
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/arch
            operator: In
            values:
            - arm64
  volumes:
    - name: library-dir-host
      hostPath:
        path: /home/kubernetes/bin/nvidia
    - name: gib
      hostPath:
        path: /home/kubernetes/bin/gib
  containers:
    - name: my-container
      volumeMounts:
        - name: library-dir-host
          mountPath: /usr/local/nvidia
        - name: gib
       mountPath: /usr/local/gib
      env:
        - name: LD_LIBRARY_PATH
          value: /usr/local/nvidia/lib64
      resources:
        limits:
          nvidia.com/gpu: 4
        claims:
          - name: compute-domain-channel
        ...
resourceClaims:
  - name: compute-domain-channel
    resourceClaimTemplateName: a4x-compute-domain-channel

Netzwerkleistung testen

Wir empfehlen, die Funktionalität der bereitgestellten Cluster zu prüfen. Verwenden Sie dazu NCCL/gIB-Tests, die NVIDIA Collective Communications Library (NCCL)-Tests sind, die für die Google-Umgebung optimiert wurden.

Nächste Schritte