Netzwerkressourcen mit dem von GKE verwalteten DRANET zuweisen

Google Kubernetes Engine (GKE) DRANET ist ein verwaltetes GKE-Feature, das auf dem Open-Source-Projekt DRANET basiert, das die Kubernetes DRA API für Netzwerkressourcen implementiert. Mit DRANET können Sie leistungsstarke Netzwerkressourcen für Ihre Pods anfordern und zuweisen, einschließlich Netzwerkschnittstellen, die RDMA (Remote Direct Memory Access) unterstützen. Dieser Ansatz bietet eine portable, Upstream-orientierte API für die Verwaltung von Netzwerkressourcen.

Dieses Dokument bietet eine konzeptionelle Übersicht über GKE DRANET und zeigt, wie Sie Arbeitslasten in Ihren GKE-Clustern Netzwerkressourcen zuweisen.

Dieses Dokument richtet sich an Cloud-Architekten und Netzwerkspezialisten, die Netzwerke für ihre Organisationen entwerfen. Eine Übersicht über die gesamte GKE-Dokumentation finden Sie unter GKE-Dokumentation. Weitere Informationen zu gängigen Rollen und Aufgaben, auf die in Google Cloud -Inhalten verwiesen wird, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Bevor Sie dieses Dokument lesen, sollten Sie mit Folgendem vertraut sein:

Funktionsweise von GKE-verwaltetem DRANET

Von GKE verwaltetes DRANET wird über ein networking-dra-driver-DaemonSet implementiert. Dieses DaemonSet wird auf Knoten mit GPUs, TPUs oder speicheroptimierten VMs ausgeführt, für die GKE DRANET aktiviert ist.

Er fungiert als Agent auf Knotenebene, um Netzwerkschnittstellen über die Kubernetes Dynamic Resource Allocation (DRA) APIs für Pods auffindbar und zuweisbar zu machen.

In GKE-Versionen 1.34.1-gke.1829001 und höher installiert GKE automatisch DeviceClass-Ressourcen für das Netzwerk. Diese Klassen definieren die Typen von Netzwerkgeräten, die Sie anfordern können. GKE erstellt beispielsweise die Klasse mrdma.google.com für GPU-VMs, die Klasse netdev.google.com für TPU- und andere Netzwerkgeräte und die Klasse irdma.google.com für speicheroptimierte VMs (z. B. Z4M).

Wenn Sie GKE DRANET verwenden möchten, müssen Sie zuerst den GKE DRANET-Treiber in einem Knotenpool mit GPUs, TPUs oder speicheroptimierten VMs aktivieren.

Wenn Sie Netzwerkgeräte für eine Arbeitslast anfordern möchten, definieren Sie ein ResourceClaimTemplate. In dieser Vorlage werden die DeviceClass und der Zuweisungsmodus angegeben, z. B. die Anforderung aller verfügbaren Geräte auf einem Knoten. Verweisen Sie in Ihrer Pod-Spezifikation in einem resourceClaims-Feld auf diese Vorlage, um Ihrem Pod Zugriff auf die angeforderten Netzwerkschnittstellen auf dem Knoten zu gewähren.

Wann sollte das von GKE verwaltete DRANET verwendet werden?

GKE DRANET bietet eine standardisierte Möglichkeit, Netzwerkressourcen zu verwalten, die Topologie und Abhängigkeiten berücksichtigen. Diese Standardisierung macht es zu einer geeigneten Lösung für KI und ML, große parallele Dateisysteme und andere datenintensive Speicherarbeitslasten, die ein Hochleistungsnetzwerk erfordern.

Häufige Anwendungsfälle für das Anfordern von Netzwerkschnittstellen für einen Pod:

  • Alle verfügbaren RDMA-fähigen Schnittstellen werden angefordert.
  • Anfordern einer bestimmten Anzahl von RDMA-fähigen Schnittstellen.
  • Alle verfügbaren Nicht-RDMA-Schnittstellen werden angefordert.
  • Anfordern einer bestimmten Anzahl von Nicht-RDMA-Schnittstellen.

Wichtige Überlegungen zur Verwendung von GKE-verwaltetem DRANET für Netzwerke

Beachten Sie die folgenden Punkte, wenn Sie GKE DRANET für das Netzwerk verwenden:

  • Dedizierte Netzwerkschnittstellen

    Wenn Sie GKE DRANET verwenden, um eine Netzwerkschnittstelle für einen Pod anzufordern, ist diese Schnittstelle diesem Pod zugeordnet. Andere Pods auf demselben Knoten können ihn nicht freigeben. Dieser Ansatz sorgt dafür, dass der Pod alleinigen Zugriff auf die gesamte Bandbreite und die Ressourcen dieser Schnittstelle hat. Das ist ein wichtiger Vorteil für leistungssensitive Arbeitslasten.

  • Von GKE verwalteten DRANET-Treiber unabhängig verwenden

    Sie können den GKE-DRA-Treiber aktivieren, um Netzwerkressourcen zu verwalten, ohne andere GKE-DRANET-Treiber aktivieren zu müssen. Fügen Sie dazu das Label cloud.google.com/gke-networking-dra-driver=true einem Knotenpool mit GPUs, TPUs oder speicheroptimierten VMs hinzu.

  • Andere GKE-DRA-Treiber verwenden

    Wenn Sie einen höheren Durchsatz bei anspruchsvollen KI/ML-Arbeitslasten erzielen möchten, kombinieren Sie die DRA API für Beschleuniger (wie GPUs und TPUs) mit dem verwalteten GKE DRANET-Netzwerk. Dieser kombinierte Ansatz verbessert die Ressourcenausrichtung und das Topologiebewusstsein. Weitere Informationen zur Verwendung von DRA für andere Ressourcen finden Sie unter GKE-Infrastruktur für DRA-Arbeitslasten vorbereiten.

  • Konflikte bei Konfigurationen vermeiden

    Der GKE-DRANET-Treiber verwaltet RDMA-Schnittstellen und gVNICs, für die keine sekundären IP-Adressbereiche konfiguriert sind. Verwenden Sie nicht sowohl den GKE-DRANET-Treiber als auch die GKE-Multi-Netzwerk-API mit einer Netzwerkressource vom Typ Device im selben Cluster. Die gemeinsame Verwendung des Treibers und der API wird nicht unterstützt, da beide APIs versuchen, dieselben NICs zu verwalten. Dies kann zu einer fehlerhaften Einrichtung und unvorhersehbarem Verhalten führen.

  • Verwalteter Lebenszyklus des DRANET-Treibers

    In GKE-Version 1.34 und höher erstellt GKE automatisch den verwalteten Namespace gke-managed-networking-dra-driver in Ihrem Cluster. Ähnlich wie bei mehreren anderen GKE-Systemarbeitslasten werden die Pods des DRANET-Treibers nur auf Knoten ausgeführt, auf denen sie relevant sind (z. B. Knoten mit GPUs, TPUs und anderer spezialisierter Hardware). Auf Knoten, für die der Treiber nicht relevant ist, werden keine Pods für diesen Treiber ausgeführt. Ändern Sie das DaemonSet networking-dra-driver nicht manuell. Manuelle Änderungen, z. B. das Aktualisieren des Felds nodeAffinity, können die Verwaltung des DRANET-Features durch GKE beeinträchtigen und dazu führen, dass die DRANET-Daemon-Pods auf nicht unterstützten Knoten geplant werden.

Voraussetzungen

Damit Sie das von GKE verwaltete DRANET verwenden können, muss Ihre Umgebung die folgenden Anforderungen erfüllen:

  • Standard: 1.34.1-gke.1829001 oder höher (1.36.3-gke.1767000 oder höher für Z4M-VMs).
  • Autopilot: 1.35.2-gke.1842000 oder höher (1.37.0-gke.4713000 oder höher für Z4M-VMs).
  • GKE Dataplane V2 ist im Cluster aktiviert.

Außerdem müssen Sie einen der folgenden beschleunigungs- oder speicheroptimierten Maschinentypen verwenden:

Maschinenserie Maschinentyp Beschleunigermodell Netzwerktechnologie DeviceClass
A3 Ultra a3-ultragpu-8g NVIDIA H200-GPU RDMA mrdma.google.com
A4 a4-highgpu-8g NVIDIA B200-GPU RDMA mrdma.google.com
A4X a4x-highgpu-4g NVIDIA GB200-GPU RDMA mrdma.google.com
A4X Max a4x-maxgpu-4g-metal NVIDIA B300-GPU RDMA mrdma.google.com
TPU v7 tpu7x-standard-4t TPU v7 NetDevice netdev.google.com
TPU v6e ct6e-standard-8t Trillium TPU NetDevice netdev.google.com
TPU v6e ct6e-standard-4t Trillium TPU NetDevice netdev.google.com
TPU v6e ct6e-standard-1t Trillium TPU NetDevice netdev.google.com
Z4M Alle Z4M-Maschinentypen, die IRDMA unterstützen Nicht zutreffend (speicheroptimiert) RDMA irdma.google.com

Beschränkungen

Für GKE DRANET gelten die folgenden Einschränkungen:

  • Sie können GKE DRANET nicht verwenden, um die Standard-Netzwerkkarte (NIC) oder virtuelle NICs (z. B. veth) zuzuweisen.
  • Bestimmte Instanztypen, insbesondere Bare-Metal-Knoten wie a4x-max, sind nicht mit Autoscaling- und Autopilot-Clustern kompatibel.

Maschinenspezifische Überlegungen

Je nach zugrunde liegender Hardwarearchitektur Ihrer Knoten sind für einige Maschinenserien zusätzliche Knotenpool-Flags, Container-Image-Pakete oder System-DaemonSets erforderlich, um RDMA-Schnittstellen mit GKE DRANET zu konfigurieren.

A4X Max Bare Metal

  • asapd-lite bereitstellen: Wenn Sie Bare-Metal-GPU-Knoten wie A4X Max verwenden, müssen Sie das DaemonSet asapd-lite in Ihrem Cluster bereitstellen. Das DaemonSet asapd-lite konfiguriert die RDMA-Netzwerkkarten (NICs). Ohne sie werden keine untergeordneten Schnittstellen erstellt und der dranet-Treiber filtert die RDMA-NICs heraus, wodurch die RDMA-Funktionalität in Ihren Pods verhindert wird. Eine vollständige Anleitung zur Einrichtung finden Sie unter MRDMA-NICs mit asapd-lite konfigurieren.

Speicheroptimierte Z4M-VMs

  • Anforderungen an Container-Images: Wenn Sie RDMA auf Z4M-Instanzen verwenden möchten, müssen Sie ein Rocky Linux 8-Container-Image verwenden, das mit den erforderlichen RDMA-Paketen für den Nutzerbereich konfiguriert ist. Andere Distributionen wie Ubuntu oder Debian werden nicht unterstützt. In den Standard-Upstream-Paketen für diese Distributionen fehlen die benutzerdefinierten ABI-Erweiterungen, die der IRDMA-Treiber benötigt. Ohne diese Erweiterungen schlagen die Pakete zur Laufzeit mit einem -ENOSPC-Fehler fehl. Eine Anleitung zur Einrichtung finden Sie unter RDMA-Schnittstellen in einem speicheroptimierten Knotenpool verwenden.

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.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle Kubernetes Engine-Administrator (roles/container.admin) für Ihr Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Erstellen von Knotenpools und Zuweisen von Netzwerkressourcen benötigen. 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.

Cluster erstellen

Erstellen Sie einen GKE-Standardcluster, der GKE Dataplane V2 verwendet:

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

Ersetzen Sie Folgendes:

  • CLUSTER_NAME: Der Name des neuen Clusters.
  • CONTROL_PLANE_LOCATION: die Region oder Zone für die Cluster-Steuerungsebene, z. B. us-central1 oder us-central1-a.
  • PROJECT_ID: Projekt-ID in Google Cloud .
  • CLUSTER_VERSION: die GKE-Version für Ihren Cluster:
    • Z4M-VMs: 1.36.3-gke.1767000 oder höher
    • Alle anderen unterstützten VMs oder Bare-Metal-Instanzen: 1.34.1-gke.1829001 oder höher

RDMA-Schnittstellen aus einem GPU-Knotenpool verwenden

In den folgenden Abschnitten wird beschrieben, wie Sie einen GPU-Knotenpool und eine Arbeitslast für die Verwendung von RDMA-Netzwerkschnittstellen mit GKE DRANET konfigurieren.

Von GKE verwalteten DRANET-Treiber in einem GPU-Knotenpool aktivieren

Wenn Sie den GKE-DRANET-Treiber in einem GPU-Knotenpool aktivieren möchten, der RDMA unterstützt, fügen Sie beim Erstellen des Knotenpools das Label cloud.google.com/gke-networking-dra-driver=true hinzu.

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

Ersetzen Sie Folgendes:

  • NODE_POOL_NAME ist der Name des neuen Knotenpools.
  • REGION: die Google Cloud Region für Ihren Cluster.
  • CLUSTER_NAME: Der Name Ihres Clusters.

  • ACCELERATOR_TYPE: der Typ des GPU-Beschleunigers:

    Beispiel:

    • A4-VMs: Geben Sie nvidia-b200 ein.
    • A3-Ultra-VMs: Geben Sie nvidia-h200-141gb ein.

  • ACCELERATOR_COUNT: Die Anzahl der GPUs, die an Knoten im Knotenpool angehängt werden sollen. Sowohl für a4-highgpu-8g- als auch für a3-ultragpu-8g-VMs beträgt die Anzahl der GPUs beispielsweise 8.

  • DRIVER_VERSION: die zu verwendende GPU-Treiberversion. Beispiel: default oder latest

  • MACHINE_TYPE: der Maschinentyp für den Knotenpool, z. B. a3-ultragpu-8g.

  • NUM_NODES: die Anzahl der Knoten für den Knotenpool. Für „flex-start“ muss dieser Wert auf 0 gesetzt werden.

  • RESERVATION_PROJECT: die Projekt-ID der Reservierung.

  • RESERVATION_NAME: der Name Ihrer Reservierung. Informationen zum Ermitteln dieses Werts finden Sie unter Anfragen für vorausschauende Reservierungen ansehen.

  • RESERVATION_BLOCK: der Name eines bestimmten Blocks innerhalb der Reservierung. Informationen zum Ermitteln dieses Werts finden Sie unter Anfragen für vorausschauende Reservierungen ansehen.

Dieser Befehl verwendet Netzwerkprofile für Beschleuniger, um VPC-Netzwerke und Subnetze für Ihre Beschleuniger-VMs automatisch zu konfigurieren. Alternativ können Sie Ihr VPC-Netzwerk und Ihre Subnetze explizit angeben.

RDMA-Ressourcen für eine Arbeitslast bereitstellen

Geben Sie einen ResourceClaimTemplate an, um RDMA-Ressourcen für einen Pod zuzuweisen.

  1. Erstellen Sie eine ResourceClaimTemplate, um zu definieren, wie die RDMA-Geräte zugewiesen werden sollen. Im folgenden Manifest werden alle verfügbaren mrdma-Geräte auf dem Knoten angefordert. Speichern Sie das Manifest als 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. Wenden Sie das Manifest an:

    kubectl apply -f all-mrdma-template.yaml

  3. Stellen Sie Ihre Arbeitslast bereit und verweisen Sie auf die ResourceClaimTemplate. Mit dem folgenden Manifest wird ein Pod bereitgestellt, der auf die Vorlage all-mrdma verweist. Dadurch erhält der Pod Zugriff auf die RDMA-Schnittstellen auf dem Knoten. Speichern Sie das Manifest als 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. Wenden Sie das Manifest an:

    kubectl apply -f agnhost-rdma-pod.yaml

  5. Prüfen Sie, ob die zusätzlich zugewiesenen Netzwerkschnittstellen im Pod sichtbar sind.

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

    Die folgende Beispielausgabe zeigt die Standardschnittstellen eth0 und lo sowie die zugewiesenen RDMA-Schnittstellen, z. B. gpu0rdma0. Die Anzahl und die Namen der Netzwerkschnittstellen (NICs) variieren je nach Maschinentyp des GKE-Knotens.

    eth0
gpu0rdma0
gpu1rdma0
gpu2rdma0
gpu3rdma0
lo

Nicht-RDMA-Netzwerkschnittstellen in einem TPU-Knotenpool verwenden

In den folgenden Abschnitten wird beschrieben, wie Sie einen TPU-Knotenpool und eine Arbeitslast so konfigurieren, dass Nicht-RDMA-Netzwerkschnittstellen mit GKE DRANET verwendet werden.

Netzwerk-DeviceClasses prüfen

Prüfen Sie, ob die DeviceClass-Ressourcen für das Netzwerk in Ihrem Cluster vorhanden sind.

kubectl get deviceclass netdev.google.com

Die Ausgabe sieht etwa so aus:

NAME                AGE
netdev.google.com   2d22h

Von GKE verwalteten DRANET-Treiber in einem TPU-Slice-Knotenpool aktivieren

Wenn Sie den GKE-DRANET-Treiber beim Erstellen eines TPU-Slice-Knotenpools aktivieren möchten, fügen Sie das Label cloud.google.com/gke-networking-dra-driver=true hinzu.

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

Ersetzen Sie Folgendes:

  • NODE_POOL_NAME: Der Name des neuen Knotenpools.
  • LOCATION: Die Google Cloud Region oder Zone für Ihren Cluster.
  • CLUSTER_NAME ist der Name Ihres Clusters.
  • NODE_LOCATIONS: Die Google Cloud Zonen für die Knoten im Knotenpool.
  • MACHINE_TYPE: Der Maschinentyp für Knoten. Weitere Informationen zu TPU-kompatiblen Maschinentypen finden Sie unter TPU-Version auswählen.
  • TPU_TOPOLOGY: Die TPU-Topologie, z. B. 2x4x4. Das Format der Topologie hängt von der TPU-Version ab. Weitere Informationen zu TPU-Topologien finden Sie unter Topologie auswählen.
  • NUM_NODES: Die maximale Anzahl von Knoten im Knotenpool.

Weitere Informationen finden Sie unter TPU-Slice-Knotenpool mit einem Host erstellen.

Arbeitslast bereitstellen, die alle Netzwerkgeräte beansprucht

Wenn Sie einem Pod Nicht-RDMA-Netzwerkgeräte zuweisen möchten, geben Sie einen ResourceClaimTemplate an.

  1. Erstellen Sie einen ResourceClaimTemplate, der auf die DeviceClass netdev.google.com verweist. Im folgenden Manifest werden alle verfügbaren Nicht-RDMA-Netzwerkgeräte auf dem Knoten angefordert.

    Speichern Sie das Manifest als 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. Wenden Sie das Manifest an:

    kubectl apply -f all-netdev-template.yaml

  3. Stellen Sie Ihre Arbeitslast bereit und verweisen Sie auf die ResourceClaimTemplate. Mit dem folgenden Manifest wird ein Pod bereitgestellt, der die Vorlage all-netdev verwendet, um dem Pod Zugriff auf alle Nicht-RDMA-Netzwerkgeräte auf dem Knoten zu gewähren. Speichern Sie das Manifest als 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

    Ersetzen Sie Folgendes:

    • TPU_ACCELERATOR: Der TPU-Beschleunigertyp, z. B. tpu-v5p-slice.
    • TPU_TOPOLOGY: Die TPU-Topologie, z. B. 2x4x4.

  4. Wenden Sie das Manifest an:

    kubectl apply -f netdev-pod.yaml

  5. Prüfen Sie, ob die zusätzlich zugewiesenen Netzwerkschnittstellen im Pod sichtbar sind.

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

    Die folgende Beispielausgabe zeigt die Standardschnittstellen eth0 und lo sowie die zugewiesenen Netzwerkgeräte mit Namen wie eth1 und eth2. Die Anzahl der NICs und ihre Namen variieren je nach Maschinentyp des GKE-Knotens.

    eth0
eth1
eth2
lo

RDMA-Schnittstellen in einem speicheroptimierten Knotenpool verwenden

In den folgenden Abschnitten wird am Beispiel einer Z4M-VM (z4m-highmem-192) beschrieben, wie Sie einen speicheroptimierten Knotenpool und eine Arbeitslast für die Verwendung von RDMA-Netzwerkschnittstellen mit GKE DRANET konfigurieren.

Speicheroptimierten Knotenpool erstellen

Erstellen Sie einen speicheroptimierten Knotenpool mit dem Flag --accelerator-network-profile=auto, damit GKE die zugrunde liegenden Falcon-VPC-Netzwerke, Subnetze und sekundären Netzwerkschnittstellen automatisch bereitstellt und anhängt. In Z4M-Knotenpools aktiviert GKE DRANET standardmäßig. Sie müssen das Knotenlabel cloud.google.com/gke-networking-dra-driver=true also nicht angeben, wenn Sie den Knotenpool erstellen. In diesem Beispiel wird der Maschinentyp z4m-highmem-192 verwendet, der zwei physische Titanium-NICs hat und zwei RDMA-Schnittstellen bietet. Eine Liste der unterstützten Maschinentypen finden Sie unter Anforderungen.

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --project=PROJECT_ID \
    --zone=ZONE \
    --machine-type=z4m-highmem-192 \
    --num-nodes=NUM_NODES \
    --accelerator-network-profile=auto

Ersetzen Sie Folgendes:

  • NODE_POOL_NAME ist der Name des neuen Knotenpools.
  • CLUSTER_NAME: Der Name Ihres Clusters.
  • PROJECT_ID: Projekt-ID in Google Cloud .
  • ZONE: die Google Cloud -Zone für Ihren Knotenpool.
  • NUM_NODES: Die Anzahl der Knoten im Knotenpool. Wenn Sie den RDMA-Traffic zwischen Knoten mit den Beispiel-Pods rdma-server und rdma-client testen möchten, geben Sie mindestens 2 an.

Speicheroptimiertes Container-Image für die Arbeitslast vorbereiten

Für Arbeitslasten, die Cloud RDMA auf speicheroptimierten Knoten verwenden, ist ein Rocky Linux 8-Container-Image mit den benutzerdefinierten RDMA-Bibliotheken im Nutzerbereich (rdma-core) für Cloud RDMA erforderlich. Verwenden Sie keine Standard-Upstream-Pakete. Ihnen fehlen die benutzerdefinierten ABI-Erweiterungen, die vom Host-IRDMA-Treiber benötigt werden, und sie schlagen zur Laufzeit mit -ENOSPC-Fehlern fehl. Installieren Sie außerdem iproute, libibverbs-utils, librdmacm-utils, infiniband-diags und perftest, um die IP-Adresszuweisungen zu prüfen und die RDMA-Konnektivität zu testen.

Ein Beispiel für ein Dockerfile, das das erforderliche Package Repository konfiguriert, finden Sie unter Docker-Image vorbereiten. Fügen Sie im Befehl dnf install die Option iproute ein, damit Sie IP-Zuweisungen mit dem Befehl ip prüfen können. Weitere Informationen zu den erforderlichen Paketen finden Sie unter Cloud RDMA-RPMs.

Arbeitslast mit RDMA-Ressourcen bereitstellen

Wenn Sie einem Pod auf einem speicheroptimierten Knoten RDMA-Schnittstellen zuweisen möchten, erstellen Sie einen ResourceClaimTemplate, der die DeviceClass irdma.google.com anfordert:

  1. Erstellen Sie ein ResourceClaimTemplate-Manifest und speichern Sie es als irdma-template.yaml:

    apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: irdma-template
spec:
  spec:
    devices:
      requests:
      - name: irdma
        exactly:
          deviceClassName: irdma.google.com
          allocationMode: ExactCount
          count: 2

    In diesem Manifest:

    • deviceClassName: irdma.google.com: Fordert von GKE DRANET verwaltete IRDMA-Netzwerkschnittstellen auf speicheroptimierten Knoten an.
    • allocationMode: ExactCount und count: 2: Fordert beide IRDMA-Schnittstellen an, die auf einem z4m-highmem-192-Knoten verfügbar sind. Wenn Ihre Arbeitslast nur eine einzige RDMA-Schnittstelle benötigt oder wenn Sie einen Z4M-Maschinentyp verwenden, der eine IRDMA-Schnittstelle bereitstellt, geben Sie 1 an.

  2. Wenden Sie das Manifest an:

    kubectl apply -f irdma-template.yaml

  3. Erstellen Sie ein Manifest, das zwei Pods, rdma-server und rdma-client, definiert, damit Sie den RDMA-Traffic zwischen Knoten testen können. Jeder Pod fügt die Funktion IPC_LOCK hinzu und verweist auf die ResourceClaimTemplate irdma-template. Speichern Sie das Manifest als irdma-pods.yaml:

    apiVersion: v1
kind: Pod
metadata:
  name: rdma-server
  labels:
    app: perftest
    role: server
spec:
  restartPolicy: Never
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values: ["perftest"]
        topologyKey: "kubernetes.io/hostname"
  containers:
  - name: perftest
    image: IMAGE_URI
    command: ["sleep", "infinity"]
    securityContext:
      capabilities:
        add: ["IPC_LOCK"]
    resources:
      claims:
      - name: irdma
  resourceClaims:
  - name: irdma
    resourceClaimTemplateName: irdma-template
---
apiVersion: v1
kind: Pod
metadata:
  name: rdma-client
  labels:
    app: perftest
    role: client
spec:
  restartPolicy: Never
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values: ["perftest"]
        topologyKey: "kubernetes.io/hostname"
  containers:
  - name: perftest
    image: IMAGE_URI
    command: ["sleep", "infinity"]
    securityContext:
      capabilities:
        add: ["IPC_LOCK"]
    resources:
      claims:
      - name: irdma
  resourceClaims:
  - name: irdma
    resourceClaimTemplateName: irdma-template

    Ersetzen Sie beide Instanzen von IMAGE_URI durch den URI Ihres Rocky Linux 8-RDMA-Container-Images.

    In diesem Manifest:

    • metadata.labels: weist jedem Pod das Label app: perftest und das Label role zu. Beide Pods haben das Label app: perftest, sodass die Anti-Affinitätsregel für sie gilt. Das Label role unterscheidet den rdma-server-Pod (role: server) vom rdma-client-Pod (role: client), sodass Sie die Pod-zu-Pod-RDMA-Konnektivität über Knoten hinweg testen können.
    • affinity.podAntiAffinity: Verhindert, dass Kubernetes Pods mit dem Label app: perftest auf demselben Knoten plant. Da beide Pods dieses Label haben, werden sie auf separaten physischen Hosts für knotenübergreifende RDMA-Tests ausgeführt, auch wenn Ihre ResourceClaimTemplate nur eine Schnittstelle (count: 1) anfordert. Ihr Knotenpool muss mindestens zwei Knoten haben, um beide Pods zu planen.
    • securityContext.capabilities.add: ["IPC_LOCK"]: Ermöglicht dem Container, Speicherseiten zu sperren. Dies ist erforderlich, damit RDMA-Nutzerbereichsbibliotheken Speicherbereiche für den direkten Speicherzugriff registrieren können.
    • spec.resourceClaims: Generiert einen Pod-spezifischen ResourceClaim (mit dem Namen irdma) aus dem irdma-template ResourceClaimTemplate.
    • containers.resources.claims: Gewährt dem Container perftest Zugriff auf die Schnittstellen, die durch die Anforderung irdma zugewiesen wurden.

  4. Wenden Sie das Manifest an:

    kubectl apply -f irdma-pods.yaml

  5. Prüfen Sie, ob die zugewiesenen RDMA-Schnittstellen (rdma0 und rdma1) im Server-Pod sichtbar sind:

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

    Die Ausgabe sieht etwa so aus:

    lo               UNKNOWN        127.0.0.1/8
rdma1            UP             10.5.0.3/32
rdma0            UP             10.31.0.3/32
eth0@if18        UP             10.120.2.6/32

Führen Sie rping zwischen rdma-server und rdma-client aus, um den RDMA-Traffic zwischen den beiden Pods zu prüfen:

  1. Starten Sie den rping-Server auf dem Server-Pod:

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

    Ersetzen Sie RDMA_IP durch die rdma0- oder rdma1-IP-Adresse des Server-Pods, z. B. 10.31.0.3.

  2. Führen Sie in einem zweiten Terminal den rping-Client auf dem Client-Pod aus:

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

    Prüfen Sie in der Clientausgabe die folgenden Indikatoren für eine erfolgreiche RDMA-Verbindung:

    • RDMA_CM_EVENT_ADDR_RESOLVED und RDMA_CM_EVENT_ROUTE_RESOLVED: Bestätigt, dass der RDMA Communication Manager die Ziel-RDMA-IP-Adresse und -Route aufgelöst hat.
    • ESTABLISHED und rdma_connect successful: Bestätigt, dass der Client das Warteschlangenpaar (qp), die Abschlusswarteschlange (cq) und die Schutzdomain (pd) erstellt und die RDMA-Verbindung hergestellt hat.
    • Fünf send completion-, recv completion- und ping data: rdma-ping--Einträge: Bestätigt, dass fünf RDMA-Lese- und Schreib-Roundtrip-Iterationen über die RDMA-Schnittstelle abgeschlossen wurden, bevor die Verbindung geschlossen wurde (destroy cm_id).

DRANET mit benutzerdefinierter ComputeClass aktivieren

Wenn Sie das von GKE verwaltete DRANET in Autopilot-Clustern oder mit der automatischen Knotenbereitstellung in Standardclustern verwenden möchten, müssen Sie eine benutzerdefinierte ComputeClass-Ressource verwenden, um die Funktion zu aktivieren.

  1. Erstellen Sie ein ComputeClass-Manifest, das den DRANET-Treiber aktiviert und das Netzwerkprofil für Beschleuniger auf auto setzt:

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: dranet-compute-class
spec:
  nodePoolAutoCreation:
    enabled: true
  nodePoolConfig:
    dra:
      networking:
        enabled: true
  priorities:
  - machineType: MACHINE_TYPE
    # Omit the gpu section for storage-optimized VMs (such as Z4M).
    gpu:
      count: GPU_COUNT
      type: GPU_TYPE
    acceleratorNetworkProfile: auto

    Ersetzen Sie Folgendes:

    • MACHINE_TYPE: der Maschinentyp für den Knotenpool, z. B. a3-ultragpu-8g oder z4m-highmem-192.
    • GPU_COUNT: die Anzahl der GPUs für den Maschinentyp.
    • GPU_TYPE: der GPU-Typ, z. B. nvidia-h200.

  2. Wenden Sie das Manifest an:

    kubectl apply -f COMPUTE_CLASS_FILENAME.yaml

  3. Verweisen Sie in Ihrer Pod-Spezifikation mit dem Knotenselektor cloud.google.com/compute-class auf die ComputeClass:

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

Bestimmte Anzahl von Netzwerkgeräten anfordern

Die vorherigen GPU- und TPU-Beispiele zeigen, wie Sie alle verfügbaren Netzwerkgeräte eines bestimmten Typs anfordern, indem Sie allocationMode auf All setzen. Wenn Sie stattdessen eine bestimmte Anzahl von Geräten anfordern möchten, setzen Sie allocationMode in Ihrer ResourceClaimTemplate auf ExactCount, wie unter Arbeitslast mit RDMA-Ressourcen bereitstellen beschrieben.

Im folgenden Beispiel werden zwei RDMA-Netzwerkgeräte angefordert:

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

Nächste Schritte