KI-optimierten GKE-Cluster mit Cluster Toolkit erstellen

In diesem Dokument wird beschrieben, wie Sie einen KI-optimierten GKE-Cluster (Google Kubernetes Engine) erstellen, der Compute Engine-Instanzen vom Typ A4X, A4, A3 Ultra, A3 Mega und A3 High (8 GPUs) verwendet, um Ihre KI- und ML-Arbeitslasten zu unterstützen.

Die Maschinenserien A4X, A4, A3 Ultra, A3 Mega und A3 High (8 GPUs) sind für die Ausführung großer KI/ML-Cluster mit Funktionen wie gezielter Arbeitslastplatzierung, erweiterten Steuerelementen für die Clusterwartung und Topology Aware Scheduling konzipiert. Weitere Informationen finden Sie unter Clusterverwaltung – Übersicht.

Die GKE bietet eine zentrale Plattformoberfläche, auf der Sie eine Vielzahl von Arbeitslasten für die Anforderungen Ihres Unternehmens ausführen können. Zu diesen Arbeitslasten gehören leistungsstarkes verteiltes Vortraining, Modellfeinabstimmung, Modellinferenz, Anwendungsbereitstellung und unterstützende Dienste. GKE reduziert den operativen Aufwand für die Verwaltung mehrerer Plattformen.

Methode zum Erstellen eines KI-optimierten GKE-Cluster auswählen

Die folgenden Optionen für die Clustererstellung bieten jeweils unterschiedliche Grade an Einfachheit und Flexibilität bei der Clusterkonfiguration und der Arbeitslastplanung:

Hinweis

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 diese Aufgabe 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. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.
  • Prüfen Sie, ob Sie die erforderlichen Berechtigungen zum Erstellen und Verwalten des GKE-Cluster und der zugehörigen Dienstkonten haben:
    • Kubernetes Engine-Administrator roles/container.admin
    • Compute-Administrator (roles/compute.admin)
    • Storage-Administrator (roles/storage.admin)
    • Projekt-IAM-Administrator (roles/resourcemanager.projectIamAdmin)
    • Dienstkontoadministrator (roles/iam.serviceAccountAdmin)
    • Dienstkontonutzer (roles/iam.serviceAccountUser)
    • Service Usage Consumer (roles/serviceusage.serviceUsageConsumer)
    • Rollenadministrator (roles/iam.roleAdmin)
    • Secret Manager Secret Version Manager (roles/secretmanager.secretVersionManager)
    • Zum Nutzen einer Reservierung für ein Einzelprojekt: Compute Instance Admin (v1) (roles/compute.instanceAdmin.v1) für das Projekt
    • Zum Nutzen einer freigegebenen Reservierung: Compute-Instanzadministrator (v1) (roles/compute.instanceAdmin.v1) sowohl für das Inhaberprojekt als auch für alle Nutzerprojekte, in denen Sie die Reservierung nutzen möchten

Nutzungsoption auswählen und Kapazität erhalten

So erhalten Sie Kapazität:

  1. Nutzungsoption auswählen: Treffen Sie Ihre Auswahl basierend darauf, wie Sie GPU-Ressourcen abrufen und verwenden möchten. Weitere Informationen finden Sie unter Nutzungsoption auswählen.

    Beachten Sie bei der Auswahl einer Nutzungsoption für GKE die folgenden zusätzlichen Informationen:

  2. Kapazität erhalten: Der Prozess zum Erhalten von Kapazität unterscheidet sich je nach Verbrauchsoption. Informationen zum Prozess für die von Ihnen gewählte Verbrauchsoption finden Sie unter Kapazitätsübersicht.

Voraussetzungen

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

  • Für A4X Max müssen Sie eine der folgenden Versionen verwenden:

    • Verwenden Sie für 1.35 oder höher die GKE-Version 1.35.0-gke.2745000 oder höher.
    • Verwenden Sie für 1.34 die GKE-Version 1.34.3-gke.1318000 oder höher.

    Diese Versionen tragen dazu bei, dass A4X Max Folgendes verwendet:

    • R580.95.05, die Mindest-GPU-Treiberversion für A4X Max, die standardmäßig aktiviert ist.
    • Coherent Driver-based Memory Management (CDMM), das standardmäßig aktiviert ist. NVIDIA empfiehlt, diesen Modus für Kubernetes-Cluster zu aktivieren, um das Problem der Übermeldung von Arbeitsspeicher zu beheben. Mit CDMM kann der GPU-Speicher über den Treiber statt über das Betriebssystem verwaltet werden. Mit diesem Ansatz können Sie das Onlining des GPU-Arbeitsspeichers durch das Betriebssystem vermeiden und den GPU-Arbeitsspeicher als NUMA-Knoten (Non-Uniform Memory Access) für das Betriebssystem verfügbar machen. GPUs mit mehreren Instanzen werden nicht unterstützt, wenn CDMM aktiviert ist. Weitere Informationen zu CDMM finden Sie unter Hardware- und Softwaresupport.
    • GPUDirect RDMA und MNNVL, die empfohlen werden, um A4X Max-Knotenpools die Nutzung der Netzwerkfunktionen von A4X Max zu ermöglichen.

  • Für A4X müssen Sie eine der folgenden Versionen verwenden:

    • Verwenden Sie für Version 1.33 oder höher die GKE-Version 1.33.4-gke.1036000 oder höher.
    • Verwenden Sie für 1.32 die GKE-Version 1.32.8-gke.1108000 oder höher.

    Diese Versionen tragen dazu bei, dass A4X Folgendes verwendet:

    • R580, die Mindest-GPU-Treiberversion für A4X, die standardmäßig aktiviert ist.
    • Coherent Driver-based Memory Management (CDMM), das standardmäßig aktiviert ist. NVIDIA empfiehlt, diesen Modus für Kubernetes-Cluster zu aktivieren, um das Problem der Übermeldung von Arbeitsspeicher zu beheben. Mit CDMM kann der GPU-Speicher über den Treiber statt über das Betriebssystem verwaltet werden. Mit diesem Ansatz können Sie das Onlining des GPU-Arbeitsspeichers durch das Betriebssystem vermeiden und den GPU-Arbeitsspeicher als NUMA-Knoten (Non-Uniform Memory Access) für das Betriebssystem verfügbar machen. GPUs mit mehreren Instanzen werden nicht unterstützt, wenn CDMM aktiviert ist. Weitere Informationen zu CDMM finden Sie unter Hardware- und Softwaresupport.
    • GPUDirect RDMA und MNNVL, die empfohlen werden, um A4X-Knotenpools die Nutzung der Netzwerkfunktionen von A4X zu ermöglichen.

  • Achten Sie darauf, dass Sie je nach Maschinentyp die Mindestversion des GPU-Treibers verwenden:

    • A4X Max: Für die GB300-GPUs in A4X Max-Bare-Metal-Instanzen ist mindestens die GPU-Treiberversion R580.95.05 erforderlich. Weitere Informationen finden Sie in den oben genannten Versionsanforderungen.
    • A4X: Für die GB200-GPUs in A4X-Instanzen ist mindestens die GPU-Treiberversion R580 erforderlich. Beachten Sie die zuvor genannten Versionsanforderungen.
    • A4 Die B200-GPUs in A4-Instanzen erfordern mindestens die GPU-Treiberversion R570. Die GKE installiert diese Treiberversion standardmäßig automatisch auf allen A4-Knoten, auf denen die erforderliche Mindestversion für A4, 1.32.1-gke.1729000 oder höher, ausgeführt wird.
    • A3 Ultra: Die H200-GPUs in A3 Ultra-Instanzen erfordern mindestens die GPU-Treiberversion R550, die in GKE 1.31 als Treiberversion latest verfügbar ist. Für A3 Ultra müssen Sie gpu-driver-version=latest mit GKE 1.31 festlegen. In GKE-Version 1.31.5-gke.1169000 oder höher installiert GKE standardmäßig automatisch R550-GPU-Treiberversionen auf A3 Ultra-Knoten.
    • A3 Mega und A3 High: Die H100-GPUs in A3 High- und A3 Mega-Instanzen werden von der Standard-GPU-Treiberversion in allen unterstützten GKE-Versionen unterstützt. Sie können auch gpu-driver-version=latest festlegen, um auf neuere Produktionstreiber zuzugreifen, die in unterstützten GKE-Versionen verfügbar sind.

  • Bei A3-Ultra-Knotenpools müssen Sie den Laufwerkstyp auf hyperdisk-balanced festlegen.

  • Wenn Sie GPUDirect RDMA verwenden möchten, müssen Sie je nach Maschinentyp die folgenden Mindestversionen verwenden:

    • A4X Max: Siehe die oben genannten Versionsanforderungen.
    • A4X: siehe die zuvor erwähnten Versionsanforderungen.
    • A4: Verwenden Sie 1.32.2-gke.1475000 oder höher.
    • A3 Ultra: Verwenden Sie 1.31.4-gke.1183000 oder höher.

  • Verwenden Sie die folgenden GKE-Versionen, um GPUDirect-TCPXO (für A3 Mega) und GPUDirect-TCPX (für A3 High) zu verwenden:

    • A3 High: Verwenden Sie eine beliebige verfügbare GKE-Version vor 1.34.
    • A3 Mega: Verwenden Sie eine beliebige verfügbare GKE-Version.

  • Wenn Sie GPUDirect RDMA verwenden möchten, müssen die GKE-Knoten ein Container-Optimized OS-Knoten-Image verwenden. Ubuntu- und Windows-Knoten-Images werden nicht unterstützt.

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

Cluster mit dem Cluster Toolkit erstellen

Mit der folgenden Anleitung können Sie einen Cluster mit dem Cluster Toolkit erstellen. In diesem Abschnitt werden Sie durch den Prozess der Clustererstellung geführt. So wird sichergestellt, dass Ihr Projekt den Best Practices folgt und die Anforderungen für einen KI-optimierten GKE-Cluster erfüllt. In diesem Abschnitt erfahren Sie auch, wie Sie mit Terraform die Infrastruktur für Ihre Bereitstellung bereitstellen und verwalten.

A4X Max

  1. Cloud Shell starten Sie können zwar eine andere Umgebung verwenden, wir empfehlen jedoch die Verwendung von Cloud Shell, da die Abhängigkeiten für das Cluster Toolkit bereits vorinstalliert sind. Wenn Sie Cloud Shell nicht verwenden möchten, folgen Sie der Anleitung zum Installieren von Abhängigkeiten, um eine andere Umgebung vorzubereiten.

  2. Cluster Toolkit installieren

  3. Erstellen Sie einen Cloud Storage-Bucket mit aktivierter Versionsverwaltung, um den Status Ihrer Terraform-Bereitstellung zu speichern:

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    Ersetzen Sie die folgenden Variablen:

    • BUCKET_NAME: Der Name des neuen Cloud Storage-Bucket, der den Anforderungen für Bucket-Namen entsprechen muss.
    • PROJECT_ID: Projekt-ID in Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE: die Compute-Region, in der Sie den Status der Terraform-Bereitstellung speichern möchten.

  4. Geben Sie im examples/gke-a4x-max-bm/gke-a4x-max-bm-deployment.yaml-Blueprint aus dem GitHub-Repository die folgenden Einstellungen in den Abschnitten terraform_backend_defaults und vars ein, um die spezifischen Werte für Ihre Bereitstellung anzupassen:

    • BUCKET: Der Name des Cloud Storage-Bucket, den Sie im vorherigen Schritt erstellt haben.
    • PROJECT_ID: Projekt-ID in Google Cloud .
    • DEPLOYMENT_NAME: ein eindeutiger Name für die Bereitstellung, der zwischen 6 und 30 Zeichen lang sein muss. Wenn der Bereitstellungsname innerhalb eines Projekts nicht eindeutig ist, schlägt die Clustererstellung fehl. Der Standardwert ist gke-a4x-max-bm.
    • REGION: die Compute-Region für den Cluster.
    • ZONE: die Computing-Zone für den Knotenpool von A4X Max-Maschinen. Diese Zone muss mit der Zone übereinstimmen, in der Maschinen in Ihrer Reservierung verfügbar sind.
    • STATIC_NODE_COUNT: die Anzahl der A4X Max-Knoten im Knotenpool Ihres Clusters, die maximal 18 Knoten betragen darf. Wir empfehlen, 18 Knoten zu verwenden, um die GPU-Topologie von 1x72 in einem Unterblock mithilfe einer NVLink-Domain zu erhalten.
    • AUTHORIZED_CIDR: der IP-Adressbereich, der eine Verbindung zum Cluster herstellen darf. Dieser CIDR-Block muss die IP-Adresse des Computers enthalten, der Terraform aufruft. Weitere Informationen finden Sie unter Funktionsweise autorisierter Netzwerke.

    • Verwenden Sie für das Feld reservation eine der folgenden Optionen, je nachdem, ob Sie beim Bereitstellen des Knotenpools auf bestimmte Blöcke in einer Reservierung abzielen möchten:

    • Wenn Sie den Knotenpool an einer beliebigen Stelle in der Reservierung platzieren möchten, geben Sie den Namen Ihrer Reservierung (RESERVATION_NAME) an.

    • Wenn Sie einen bestimmten Block in Ihrer Reservierung als Ziel festlegen möchten, verwenden Sie die Reservierungs- und Blocknamen im folgenden Format:

      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Wenn Sie nicht wissen, welche Blöcke in Ihrer Reservierung verfügbar sind, lesen Sie den Abschnitt Topologie einer Reservierung ansehen.

    • RESERVATION_PROJECT_ID: die Google Cloud-Projekt-ID, die die Reservierung enthält. Ihre Reservierung befindet sich möglicherweise in einem anderen Projekt als PROJECT_ID.

    • NUM_NODE_POOLS: Die Anzahl der Knotenpools, die in Ihrem Cluster aktiviert werden sollen. Wenn Sie einen Cluster mit mehr als 18 Knoten benötigen, können Sie mehrere Knotenpools angeben. Der Standardwert ist 1.

    Wenn Sie erweiterte Einstellungen ändern möchten, bearbeiten Sie die examples/gke-a4x-max-bm/gke-a4x-max-bm.yaml-Blueprint-Datei.

  5. Generieren Sie Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC), um Zugriff auf Terraform zu gewähren. Wenn Sie Cloud Shell verwenden, geben Sie den Befehl gcloud auth application-default login ein:

    gcloud auth application-default login

  6. Verwenden Sie den Befehl gcluster deploy, um den Blueprint bereitzustellen und die GKE-Infrastruktur mit A4X Max-Maschinentypen bereitzustellen:

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a4x-max-bm/gke-a4x-max-bm-deployment.yaml \
    examples/gke-a4x-max-bm/gke-a4x-max-bm.yaml

  7. Wählen Sie bei entsprechender Aufforderung (A)pply aus, um den Blueprint bereitzustellen.

    • Der Blueprint erstellt VPC-Netzwerke, ein GPU-RDMA-VPC-Netzwerk, Dienstkonten, einen Cluster und einen Knotenpool.
    • Zur Unterstützung der Jobvorlage fio-bench-job-template im Blueprint werdenGoogle Cloud -Buckets, Netzwerkspeicher und nichtflüchtige Volume-Ressourcen erstellt.

A4X

  1. Cloud Shell starten Sie können zwar eine andere Umgebung verwenden, wir empfehlen jedoch die Verwendung von Cloud Shell, da die Abhängigkeiten für das Cluster Toolkit bereits vorinstalliert sind. Wenn Sie Cloud Shell nicht verwenden möchten, folgen Sie der Anleitung zum Installieren von Abhängigkeiten, um eine andere Umgebung vorzubereiten.

  2. Cluster Toolkit installieren

  3. Erstellen Sie einen Cloud Storage-Bucket mit aktivierter Versionsverwaltung, um den Status Ihrer Terraform-Bereitstellung zu speichern:

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    Ersetzen Sie die folgenden Variablen:

    • BUCKET_NAME: Der Name des neuen Cloud Storage-Bucket, der den Anforderungen für Bucket-Namen entsprechen muss.
    • PROJECT_ID: Projekt-ID in Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE: die Compute-Region, in der Sie den Status der Terraform-Bereitstellung speichern möchten.

  4. Geben Sie im examples/gke-a4x/gke-a4x-deployment.yaml-Blueprint aus dem GitHub-Repository die folgenden Einstellungen in den Abschnitten terraform_backend_defaults und vars ein, um die spezifischen Werte für Ihre Bereitstellung anzugeben:

    • BUCKET: Der Name des Cloud Storage-Bucket, den Sie im vorherigen Schritt erstellt haben.
    • PROJECT_ID: Projekt-ID in Google Cloud .
    • DEPLOYMENT_NAME: ein eindeutiger Name für die Bereitstellung, der zwischen 6 und 30 Zeichen lang sein muss. Wenn der Bereitstellungsname innerhalb eines Projekts nicht eindeutig ist, schlägt die Clustererstellung fehl. Der Standardwert ist gke-a4x.
    • REGION: die Compute-Region für den Cluster.
    • ZONE: die Computing-Zone für den Knotenpool von A4X-Maschinen. Diese Zone muss mit der Zone übereinstimmen, in der Maschinen in Ihrer Reservierung verfügbar sind.
    • STATIC_NODE_COUNT: die Anzahl der A4X-Knoten im Knotenpool Ihres Clusters, die maximal 18 Knoten betragen darf. Wir empfehlen, 18 Knoten zu verwenden, um die GPU-Topologie von 1x72 in einem Unterblock mithilfe einer NVLink-Domain zu erhalten.
    • AUTHORIZED_CIDR: der IP-Adressbereich, der eine Verbindung zum Cluster herstellen darf. Dieser CIDR-Block muss die IP-Adresse des Computers enthalten, der Terraform aufruft. Weitere Informationen finden Sie unter Funktionsweise autorisierter Netzwerke.

    • Verwenden Sie für das Feld reservation eine der folgenden Optionen, je nachdem, ob Sie beim Bereitstellen des Knotenpools auf bestimmte Blöcke in einer Reservierung abzielen möchten:

    • Wenn Sie den Knotenpool an einer beliebigen Stelle in der Reservierung platzieren möchten, geben Sie den Namen Ihrer Reservierung (RESERVATION_NAME) an.

    • Wenn Sie einen bestimmten Block in Ihrer Reservierung als Ziel festlegen möchten, verwenden Sie die Reservierungs- und Blocknamen im folgenden Format:

      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Wenn Sie nicht wissen, welche Blöcke in Ihrer Reservierung verfügbar sind, lesen Sie den Abschnitt Topologie einer Reservierung ansehen.

    • RESERVATION_PROJECT_ID: die Google Cloud-Projekt-ID, die die Reservierung enthält. Ihre Reservierung befindet sich möglicherweise in einem anderen Projekt als PROJECT_ID.

    • NUM_NODE_POOLS: Die Anzahl der Knotenpools, die in Ihrem Cluster aktiviert werden sollen. Wenn Sie einen Cluster mit mehr als 18 Knoten benötigen, können Sie mehrere Knotenpools angeben. Der Standardwert ist 1.

    Wenn Sie erweiterte Einstellungen ändern möchten, bearbeiten Sie die examples/gke-a4x/gke-a4x.yaml-Blueprint-Datei.

  5. Generieren Sie Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC), um Zugriff auf Terraform zu gewähren. Wenn Sie Cloud Shell verwenden, geben Sie den Befehl gcloud auth application-default login ein:

    gcloud auth application-default login

  6. Verwenden Sie den Befehl gcluster deploy, um den Blueprint bereitzustellen und die GKE-Infrastruktur mit A4X-Maschinentypen bereitzustellen:

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a4x/gke-a4x-deployment.yaml \
    examples/gke-a4x/gke-a4x.yaml

  7. Wählen Sie bei entsprechender Aufforderung (A)pply aus, um den Blueprint bereitzustellen.

    • Der Blueprint erstellt VPC-Netzwerke, ein GPU-RDMA-VPC-Netzwerk, Dienstkonten, einen Cluster und einen Knotenpool.
    • Zur Unterstützung der Jobvorlage fio-bench-job-template im Blueprint werdenGoogle Cloud -Buckets, Netzwerkspeicher und nichtflüchtige Volume-Ressourcen erstellt.

A4

  1. Cloud Shell starten Sie können zwar eine andere Umgebung verwenden, wir empfehlen jedoch die Verwendung von Cloud Shell, da die Abhängigkeiten für das Cluster Toolkit bereits vorinstalliert sind. Wenn Sie Cloud Shell nicht verwenden möchten, folgen Sie der Anleitung zum Installieren von Abhängigkeiten, um eine andere Umgebung vorzubereiten.

  2. Cluster Toolkit installieren

  3. Erstellen Sie einen Cloud Storage-Bucket mit aktivierter Versionsverwaltung, um den Status Ihrer Terraform-Bereitstellung zu speichern:

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    Ersetzen Sie die folgenden Variablen:

    • BUCKET_NAME: Der Name des neuen Cloud Storage-Bucket, der den Anforderungen für Bucket-Namen entsprechen muss.
    • PROJECT_ID: Projekt-ID in Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE: die Compute-Region, in der Sie den Status der Terraform-Bereitstellung speichern möchten.

  4. Wählen Sie eine Option für die Nutzung Ihrer GKE-Bereitstellung aus:

    Standardmäßig ist die Bereitstellungsdatei so konfiguriert, dass bestimmte Reservierungen verwendet werden. Wenn Sie ein alternatives Nutzungsmodell (z. B. Spot-VMs oder den Bereitstellungsmodus „Flex-Start“) verwenden möchten, aktualisieren Sie die YAML-Datei für die Bereitstellung. Weitere Informationen finden Sie unter GKE-Nutzungsoptionen.

  5. Geben Sie im examples/gke-a4/gke-a4-deployment.yaml-Blueprint aus dem GitHub-Repository die folgenden Einstellungen in den Abschnitten terraform_backend_defaults und vars ein, um die spezifischen Werte für Ihre Bereitstellung anzugeben:

    • BUCKET: Der Name des Cloud Storage-Bucket, den Sie im vorherigen Schritt erstellt haben.
    • PROJECT_ID: Projekt-ID in Google Cloud .
    • DEPLOYMENT_NAME: ein eindeutiger Name für die Bereitstellung, der zwischen 6 und 30 Zeichen lang sein muss. Wenn der Bereitstellungsname innerhalb eines Projekts nicht eindeutig ist, schlägt die Clustererstellung fehl. Der Standardwert ist gke-a4.
    • REGION: die Compute-Region für den Cluster.
    • ZONE: die Computing-Zone für den Knotenpool von A4-Maschinen. Diese Zone muss mit der Zone übereinstimmen, in der Maschinen in Ihrer Reservierung verfügbar sind.
    • AUTHORIZED_CIDR: der IP-Adressbereich, der eine Verbindung zum Cluster herstellen darf. Dieser CIDR-Block muss die IP-Adresse des Computers enthalten, der Terraform aufruft. Weitere Informationen finden Sie unter Funktionsweise autorisierter Netzwerke.
    • Konfigurieren Sie im Abschnitt für die spezifische Reservierung die folgenden Einstellungen:

    • Geben Sie im Block reservation_affinity in der Liste specific_reservations das Feld name für die Reservierung an:

      • Wenn Sie den Knotenpool an einer beliebigen Stelle in der Reservierung platzieren möchten, geben Sie den Namen Ihrer Reservierung (RESERVATION_NAME) an.
      • Wenn Sie einen bestimmten Block in Ihrer Reservierung als Ziel festlegen möchten, verwenden Sie die Reservierungs- und Blocknamen im folgenden Format:
      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Wenn Sie nicht wissen, welche Blöcke in Ihrer Reservierung verfügbar sind, lesen Sie den Abschnitt Topologie einer Reservierung ansehen.

    • STATIC_NODE_COUNT: die Anzahl der A4-Knoten in Ihrem Cluster.

    Wenn Sie erweiterte Einstellungen ändern möchten, bearbeiten Sie die examples/gke-a4/gke-a4.yaml-Blueprint-Datei.

  6. Generieren Sie Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC), um Zugriff auf Terraform zu gewähren. Wenn Sie Cloud Shell verwenden, geben Sie den Befehl gcloud auth application-default login ein:

    gcloud auth application-default login

  7. Verwenden Sie den Befehl gcluster deploy, um den Blueprint bereitzustellen und die GKE-Infrastruktur mit A4-Maschinentypen bereitzustellen:

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a4/gke-a4-deployment.yaml \
    examples/gke-a4/gke-a4.yaml

  8. Wählen Sie bei entsprechender Aufforderung (A)pply aus, um den Blueprint bereitzustellen.

    • Der Blueprint erstellt VPC-Netzwerke, ein GPU-RDMA-VPC-Netzwerk, Dienstkonten, einen Cluster und einen Knotenpool.
    • Zur Unterstützung der Jobvorlage fio-bench-job-template im Blueprint werdenGoogle Cloud -Buckets, Netzwerkspeicher und nichtflüchtige Volume-Ressourcen erstellt.

A3 Ultra

  1. Cloud Shell starten Sie können zwar eine andere Umgebung verwenden, wir empfehlen jedoch die Verwendung von Cloud Shell, da die Abhängigkeiten für das Cluster Toolkit bereits vorinstalliert sind. Wenn Sie Cloud Shell nicht verwenden möchten, folgen Sie der Anleitung zum Installieren von Abhängigkeiten, um eine andere Umgebung vorzubereiten.

  2. Cluster Toolkit installieren

  3. Erstellen Sie einen Cloud Storage-Bucket mit aktivierter Versionsverwaltung, um den Status Ihrer Terraform-Bereitstellung zu speichern:

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    Ersetzen Sie die folgenden Variablen:

    • BUCKET_NAME: Der Name des neuen Cloud Storage-Bucket, der den Anforderungen für Bucket-Namen entsprechen muss.
    • PROJECT_ID: Projekt-ID in Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE: die Compute-Region, in der Sie den Status der Terraform-Bereitstellung speichern möchten.

  4. Wählen Sie eine Option für die Nutzung Ihrer GKE-Bereitstellung aus:

    Standardmäßig ist die Bereitstellungsdatei so konfiguriert, dass bestimmte Reservierungen verwendet werden. Wenn Sie ein alternatives Nutzungsmodell (z. B. Spot-VMs oder den Bereitstellungsmodus „Flex-Start“) verwenden möchten, aktualisieren Sie die YAML-Datei für die Bereitstellung. Weitere Informationen finden Sie unter GKE-Nutzungsoptionen.

  5. Geben Sie im examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml-Blueprint aus dem GitHub-Repository die folgenden Einstellungen in den Abschnitten terraform_backend_defaults und vars ein, um die spezifischen Werte für Ihre Bereitstellung anzupassen:

    • BUCKET: Der Name des Cloud Storage-Bucket, den Sie im vorherigen Schritt erstellt haben.
    • PROJECT_ID: Projekt-ID in Google Cloud .
    • DEPLOYMENT_NAME: ein eindeutiger Name für die Bereitstellung, der zwischen 6 und 30 Zeichen lang sein muss. Wenn der Bereitstellungsname innerhalb eines Projekts nicht eindeutig ist, schlägt die Clustererstellung fehl. Der Standardwert ist gke-a3-ultragpu.
    • REGION: die Compute-Region für den Cluster.
    • ZONE: die Computing-Zone für den Knotenpool von A3 Ultra-Maschinen. Diese Zone muss mit der Zone übereinstimmen, in der Maschinen in Ihrer Reservierung verfügbar sind.
    • AUTHORIZED_CIDR: der IP-Adressbereich, der eine Verbindung zum Cluster herstellen darf. Dieser CIDR-Block muss die IP-Adresse des Computers enthalten, der Terraform aufruft. Weitere Informationen finden Sie unter Funktionsweise autorisierter Netzwerke.
    • Konfigurieren Sie im Abschnitt für die spezifische Reservierung die folgenden Einstellungen:

    • Geben Sie im Block reservation_affinity in der Liste specific_reservations das Feld name für die Reservierung an:

      • Wenn Sie den Knotenpool an einer beliebigen Stelle in der Reservierung platzieren möchten, geben Sie den Namen Ihrer Reservierung (RESERVATION_NAME) an.
      • Wenn Sie einen bestimmten Block in Ihrer Reservierung als Ziel festlegen möchten, verwenden Sie die Reservierungs- und Blocknamen im folgenden Format:
      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Wenn Sie nicht wissen, welche Blöcke in Ihrer Reservierung verfügbar sind, lesen Sie den Abschnitt Topologie einer Reservierung ansehen.

    • STATIC_NODE_COUNT: die Anzahl der A3 Ultra-Knoten in Ihrem Cluster.

    Wenn Sie erweiterte Einstellungen ändern möchten, bearbeiten Sie die examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml-Blueprint-Datei.

  6. Generieren Sie Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC), um Zugriff auf Terraform zu gewähren. Wenn Sie Cloud Shell verwenden, geben Sie den Befehl gcloud auth application-default login ein:

    gcloud auth application-default login

  7. Verwenden Sie den Befehl gcluster deploy, um den Blueprint bereitzustellen und die GKE-Infrastruktur mit A3 Ultra-Maschinentypen bereitzustellen:

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml \
    examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml

  8. Wählen Sie bei entsprechender Aufforderung (A)pply aus, um den Blueprint bereitzustellen.

    • Der Blueprint erstellt VPC-Netzwerke, ein GPU-RDMA-VPC-Netzwerk, Dienstkonten, einen Cluster und einen Knotenpool.
    • Zur Unterstützung der Jobvorlage fio-bench-job-template im Blueprint werdenGoogle Cloud -Buckets, Netzwerkspeicher und nichtflüchtige Volume-Ressourcen erstellt.

A3 Mega

  1. Cloud Shell starten Sie können zwar eine andere Umgebung verwenden, wir empfehlen jedoch die Verwendung von Cloud Shell, da die Abhängigkeiten für das Cluster Toolkit bereits vorinstalliert sind. Wenn Sie Cloud Shell nicht verwenden möchten, bereiten Sie eine andere Umgebung vor. Folgen Sie dazu der Anleitung zum Installieren von Abhängigkeiten.

  2. Cluster Toolkit installieren

  3. Erstellen Sie einen Cloud Storage-Bucket mit aktivierter Versionsverwaltung, um den Status Ihrer Terraform-Bereitstellung zu speichern:

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    Ersetzen Sie die folgenden Variablen:

    • BUCKET_NAME: Der Name des neuen Cloud Storage-Bucket, der den Anforderungen für Bucket-Namen entsprechen muss.
    • PROJECT_ID: Projekt-ID in Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE: die Compute-Region, in der Sie den Status der Terraform-Bereitstellung speichern möchten.

  4. Ersetzen Sie im examples/gke-a3-megagpu/gke-a3-megagpu-deployment.yaml-Blueprint aus dem GitHub-Repository die folgenden Variablen in den Abschnitten terraform_backend_defaults und vars durch die spezifischen Werte für Ihre Bereitstellung:

    • BUCKET: Der Name des Cloud Storage-Bucket, den Sie im vorherigen Schritt erstellt haben.
    • DEPLOYMENT_NAME: ein eindeutiger Name für die Bereitstellung, der zwischen 6 und 30 Zeichen lang sein muss. Wenn der Bereitstellungsname innerhalb eines Projekts nicht eindeutig ist, schlägt die Clustererstellung fehl.
    • PROJECT_ID: Projekt-ID in Google Cloud .
    • REGION: die Compute-Region für den Cluster.
    • ZONE: die Computing-Zone für den Knotenpool von A3 Mega-Maschinen. Diese Zone muss mit der Zone übereinstimmen, in der Maschinen in Ihrer Reservierung verfügbar sind.
    • AUTHORIZED_CIDR: der IP-Adressbereich, der eine Verbindung zum Cluster herstellen darf. Dieser CIDR-Block muss die IP-Adresse des Computers enthalten, der Terraform aufruft. Weitere Informationen finden Sie unter Funktionsweise autorisierter Netzwerke. Führen Sie den Befehl curl -s https://ifconfig.me aus, um die IP-Adresse Ihres Hostcomputers abzurufen.

  5. Wählen Sie eine Option für die Nutzung Ihrer GKE-Bereitstellung aus:

    Standardmäßig ist die Bereitstellungsdatei so konfiguriert, dass Standardreservierungen oder vorausschauende Reservierungen verwendet werden. Wenn Sie ein alternatives Nutzungsmodell verwenden möchten (z. B. On-Demand-Kapazität, Spot-VMs oder den Bereitstellungsmodus „Flex-Start“), aktualisieren Sie die YAML-Bereitstellungsdatei. Weitere Informationen finden Sie unter GKE-Nutzungsoptionen.

    Wenn Sie eine Reservierung konfigurieren möchten, legen Sie im entsprechenden Reservierungsabschnitt die folgenden Werte fest:

    • Geben Sie im Block reservation_affinity in der Liste specific_reservations das Feld name für die Reservierung an:
    • Wenn Sie den Knotenpool an einer beliebigen Stelle in der Reservierung platzieren möchten, geben Sie den Namen Ihrer Reservierung (RESERVATION_NAME) an.

    • Wenn Sie einen bestimmten Block in Ihrer Reservierung als Ziel festlegen möchten, verwenden Sie die Reservierungs- und Blocknamen im folgenden Format:

      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Wenn Sie nicht wissen, welche Blöcke in Ihrer Reservierung verfügbar sind, lesen Sie den Abschnitt Topologie einer Reservierung ansehen.

    • STATIC_NODE_COUNT: die Anzahl der A3 Mega-Knoten in Ihrem Cluster.

    Wenn Sie erweiterte Einstellungen ändern möchten, bearbeiten Sie den Blueprint examples/gke-a3-megagpu/gke-a3-megagpu.yaml aus dem GitHub-Repository.

  6. Generieren Sie Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC), um Zugriff auf Terraform zu gewähren. Wenn Sie Cloud Shell verwenden, geben Sie den Befehl gcloud auth application-default login ein:

    gcloud auth application-default login

  7. Verwenden Sie den Befehl gcluster deploy, um den Blueprint bereitzustellen und die GKE-Infrastruktur mit A3 Mega-Maschinentypen bereitzustellen:

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a3-megagpu/gke-a3-megagpu-deployment.yaml \
    examples/gke-a3-megagpu/gke-a3-megagpu.yaml

  8. Wählen Sie bei entsprechender Aufforderung (A)pply aus, um den Blueprint bereitzustellen. Der Blueprint erstellt VPC-Netzwerke, Dienstkonten, einen Cluster und einen Knotenpool.

A3 High

  1. Cloud Shell starten Sie können zwar eine andere Umgebung verwenden, wir empfehlen jedoch die Verwendung von Cloud Shell, da die Abhängigkeiten für das Cluster Toolkit bereits vorinstalliert sind. Wenn Sie Cloud Shell nicht verwenden möchten, bereiten Sie eine andere Umgebung vor. Folgen Sie dazu der Anleitung zum Installieren von Abhängigkeiten.

  2. Cluster Toolkit installieren

  3. Erstellen Sie einen Cloud Storage-Bucket mit aktivierter Versionsverwaltung, um den Status Ihrer Terraform-Bereitstellung zu speichern:

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    Ersetzen Sie die folgenden Variablen:

    • BUCKET_NAME: Der Name des neuen Cloud Storage-Bucket, der den Anforderungen für Bucket-Namen entsprechen muss.
    • PROJECT_ID: Projekt-ID in Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE: die Compute-Region, in der Sie den Status der Terraform-Bereitstellung speichern möchten.

  4. Ersetzen Sie im examples/gke-a3-highgpu/gke-a3-highgpu-deployment.yaml-Blueprint aus dem GitHub-Repository die folgenden Variablen in den Abschnitten terraform_backend_defaults und vars durch die spezifischen Werte für Ihre Bereitstellung:

    • BUCKET: Der Name des Cloud Storage-Bucket, den Sie im vorherigen Schritt erstellt haben.
    • DEPLOYMENT_NAME: ein eindeutiger Name für die Bereitstellung, der zwischen 6 und 30 Zeichen lang sein muss. Wenn der Bereitstellungsname innerhalb eines Projekts nicht eindeutig ist, schlägt die Clustererstellung fehl.
    • PROJECT_ID: Projekt-ID in Google Cloud .
    • REGION: die Compute-Region für den Cluster.
    • ZONE: die Computing-Zone für den Knotenpool von A3 High-Maschinen. Diese Zone muss mit der Zone übereinstimmen, in der Maschinen in Ihrer Reservierung verfügbar sind.
    • AUTHORIZED_CIDR: der IP-Adressbereich, der eine Verbindung zum Cluster herstellen darf. Dieser CIDR-Block muss die IP-Adresse des Computers enthalten, der Terraform aufruft. Weitere Informationen finden Sie unter Funktionsweise autorisierter Netzwerke. Führen Sie den Befehl curl -s https://ifconfig.me aus, um die IP-Adresse für Ihren Hostcomputer abzurufen.

  5. Wählen Sie eine Option für die Nutzung Ihrer GKE-Bereitstellung aus:

    Standardmäßig ist die Bereitstellungsdatei so konfiguriert, dass Standardreservierungen oder vorausschauende Reservierungen verwendet werden. Wenn Sie ein alternatives Nutzungsmodell verwenden möchten (z. B. On-Demand-Kapazität, Spot-VMs oder den Bereitstellungsmodus „Flex-Start“), aktualisieren Sie die YAML-Bereitstellungsdatei. Weitere Informationen finden Sie unter GKE-Nutzungsoptionen.

    Wenn Sie eine Reservierung konfigurieren möchten, legen Sie im entsprechenden Reservierungsabschnitt die folgenden Werte fest:

    • Geben Sie im Block reservation_affinity in der Liste specific_reservations das Feld name für die Reservierung an:
    • Wenn Sie den Knotenpool an einer beliebigen Stelle in der Reservierung platzieren möchten, geben Sie den Namen Ihrer Reservierung (RESERVATION_NAME) an.

    • Wenn Sie einen bestimmten Block in Ihrer Reservierung als Ziel festlegen möchten, verwenden Sie die Reservierungs- und Blocknamen im folgenden Format:

      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Wenn Sie nicht wissen, welche Blöcke in Ihrer Reservierung verfügbar sind, lesen Sie den Abschnitt Topologie einer Reservierung ansehen.

    • STATIC_NODE_COUNT: die Anzahl der A3 High-Knoten in Ihrem Cluster.

    Wenn Sie erweiterte Einstellungen ändern möchten, bearbeiten Sie den Blueprint examples/gke-a3-highgpu/gke-a3-highgpu.yaml aus dem GitHub-Repository.

  6. Generieren Sie Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC), um Zugriff auf Terraform zu gewähren. Wenn Sie Cloud Shell verwenden, geben Sie den Befehl gcloud auth application-default login ein:

    gcloud auth application-default login

  7. Verwenden Sie den Befehl gcluster deploy, um den Blueprint bereitzustellen und die GKE-Infrastruktur mit A3 High-Maschinentypen bereitzustellen:

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a3-highgpu/gke-a3-highgpu-deployment.yaml \
    examples/gke-a3-highgpu/gke-a3-highgpu.yaml

  8. Wählen Sie bei entsprechender Aufforderung (A)pply aus, um den Blueprint bereitzustellen. Der Blueprint erstellt VPC-Netzwerke, Dienstkonten, einen Cluster und einen Knotenpool.

Dynamic Workload Scheduler-Beispieljobs ausführen

Wenn Sie Ihren Cluster mit Dynamic Workload Scheduler (entweder Flex-Start oder Bereitstellung per Warteschlange) bereitgestellt haben, können Sie die Planung von Arbeitslasten validieren, indem Sie Kubernetes-Beispieljobs einreichen.

Weitere Informationen zu den Bereitstellungsmodi des Dynamic Workload Schedulers finden Sie unter Dynamic Workload Scheduler-Flex-Start mit Bereitstellung per Warteschlange.

Beispieljob senden

Wählen Sie den Tab aus, der Ihrer Nutzungsoption entspricht:

Flex-Start

Diese Aufgabe ist optional und gilt nur, wenn Sie Ihren Cluster mit „Flex-Start“ bereitgestellt haben. Für Arbeitslasten, die für Flex-Start konfiguriert sind, ist die Knotenauswahl cloud.google.com/gke-flex-start: "true" in der Pod-Spezifikation erforderlich.

  1. Senden Sie den Flex-Start-Beispieljob:

    kubectl apply -f examples/dws-sample-workloads/sample-job-flex.yaml

  2. Überwachen Sie den Status des Jobs und der Pods:

    kubectl get jobs
kubectl describe job JOB_NAME
kubectl get pods
kubectl describe pod POD_NAME

    Ersetzen Sie Folgendes:

    • JOB_NAME: der Name des Jobs.
    • POD_NAME: der Name Ihres Pods.

  3. Löschen Sie die Jobressourcen, wenn der Job abgeschlossen ist:

    kubectl delete -f examples/dws-sample-workloads/sample-job-flex.yaml

Bereitstellung per Warteschlange

Diese Aufgabe ist optional und gilt nur, wenn Sie Ihren Cluster mit der Funktion „Bereitstellung per Warteschlange“ bereitgestellt haben. Für Arbeitslasten, die für die Bereitstellung per Warteschlange konfiguriert sind, sind das folgende Label und die folgende Annotation in der Pod-Spezifikation erforderlich:

  • Label: kueue.x-k8s.io/queue-name: dws-local-queue
  • Anmerkung: provreq.kueue.x-k8s.io/maxRunDurationSeconds: "MAX_RUN_DURATION"

Weitere Informationen finden Sie unter Anforderungen an das Arbeitslastmanifest für die Bereitstellung per Warteschlange.

  1. Senden Sie den Beispieljob für die Bereitstellung per Warteschlange:

    kubectl apply -f examples/dws-sample-workloads/sample-job-flex-queue.yaml

  2. Überwachen Sie den Status des Jobs und der Pods:

    kubectl get jobs
kubectl describe job JOB_NAME
kubectl get pods
kubectl describe pod POD_NAME

    Ersetzen Sie Folgendes:

    • JOB_NAME: der Name des Jobs.
    • POD_NAME: der Name Ihres Pods.

  3. Löschen Sie die Jobressourcen, wenn der Job abgeschlossen ist:

    kubectl delete -f examples/dws-sample-workloads/sample-job-flex-queue.yaml

Netzwerkleistung testen

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

Reproduzierbare Benchmarks ausführen

Nachdem Sie einen Cluster mit dem Cluster Toolkit erstellt haben, können Sie Benchmarks für das Vortraining für große offene Machine-Learning-Modelle auf der von Ihnen ausgewählten Maschinenserie reproduzieren. Folgen Sie dazu den Anleitungen auf GitHub.

Jedes Rezept enthält eine Anleitung zum Ausführen der folgenden Aufgaben:

  • Bereiten Sie Ihre Umgebung vor.
  • Führen Sie den Benchmark aus.
  • Analysieren Sie die Benchmark-Ergebnisse. Diese Überprüfung umfasst die Benchmark-Ergebnisse und detaillierte Logs für weitere Analysen.

Alle verfügbaren Rezepte für das Training und andere Arten von Arbeitslasten finden Sie im GitHub-Repository GPU-Rezepte.

Vom Cluster Toolkit erstellte Ressourcen bereinigen

Damit Ihnen die auf dieser Seite verwendeten Ressourcen nicht wiederholt in Rechnung gestellt werden, verwenden Sie den Befehl gcluster destroy, um die vom Cluster Toolkit bereitgestellten Ressourcen zu bereinigen, einschließlich der VPC-Netzwerke und des GKE-Cluster:

   cd ~/cluster-toolkit
   ./gcluster destroy CLUSTER_NAME/

Ersetzen Sie CLUSTER_NAME durch den Namen Ihres Clusters. Bei Clustern, die mit dem Cluster Toolkit erstellt wurden, basiert der Clustername auf dem DEPLOYMENT_NAME-Namen.

Nächste Schritte