Netzwerkressourcen mit dem von GKE verwalteten DRANET zuweisen

Standard

Vorschau

Diese Funktion unterliegt den „Pre-GA-Angebotsbedingungen“ im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Funktionen sind „wie gesehen“ verfügbar und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie in den Beschreibungen der Produkteinführungsphasen.

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

In diesem Dokument finden Sie einen konzeptionellen Überblick über GKE DRANET und erfahren, 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:

• Dynamische Ressourcenzuweisung
• Dynamische Ressourcenzuweisung in GKE
• Kubernetes-Konzepte
• GKE-Netzwerk
• GKE-Netzwerk – Grundlagen

Funktionsweise von GKE Managed DRANET

Das von GKE verwaltete DRANET wird über ein networking-dra-driver-DaemonSet implementiert. Dieses DaemonSet wird auf Knoten mit GPUs oder TPUs ausgeführt, auf denen 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 die Netzwerkkommunikation. Diese Klassen definieren die Arten von Netzwerkgeräten, die Sie anfordern können. GKE erstellt beispielsweise die Klasse mrdma.google.com für RDMA-fähige Geräte und die Klasse netdev.google.com für andere Netzwerkgeräte.

Wenn Sie GKE DRANET verwenden möchten, müssen Sie zuerst den GKE DRANET-Treiber für einen Knotenpool mit GPUs oder TPUs aktivieren.

Wenn Sie Netzwerkgeräte für eine Arbeitslast anfordern möchten, definieren Sie eine ResourceClaimTemplate. In dieser Vorlage werden die DeviceClass und der Zuweisungsmodus angegeben, z. B. das Anfordern 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 GKE Managed 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-Arbeitslasten, die leistungsstarke Netzwerke erfordern.

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

• Alle verfügbaren RDMA-fähigen Schnittstellen werden angefordert.
• Sie fordern eine bestimmte Anzahl von RDMA-fähigen Schnittstellen an.
• Alle verfügbaren Nicht-RDMA-Schnittstellen werden angefordert.
• Sie fordern eine bestimmte Anzahl von Nicht-RDMA-Schnittstellen an.

Wichtige Überlegungen bei der Verwendung von GKE-verwaltetem DRANET für das Netzwerk

Beachten Sie bei der Verwendung von GKE DRANET für die Vernetzung Folgendes:

• Dedizierte Netzwerkschnittstellen

  Wenn Sie GKE DRANET verwenden, um eine Netzwerkschnittstelle für einen Pod zu beanspruchen, ist diese Schnittstelle diesem Pod zugeordnet. Andere Pods auf demselben Knoten können ihn nicht gemeinsam nutzen. So hat der Pod alleinigen Zugriff auf die volle Bandbreite und die Ressourcen dieser Schnittstelle. Das ist ein wichtiger Vorteil für leistungsintensive Arbeitslasten.

• GKE-verwalteten DRANET-Treiber unabhängig verwenden

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

• Andere GKE DRA-Treiber verwenden

  Um einen höheren Durchsatz bei anspruchsvollen KI-/ML-Arbeitslasten zu erzielen, kombinieren Sie die DRA API für Beschleuniger (z. B. GPUs und TPUs) mit dem von GKE DRANET verwalteten Netzwerk. Dieser kombinierte Ansatz verbessert die Ressourcenabstimmung und die Topologieerkennung. Eine Anleitung zur Verwendung von DRA für andere Ressourcen finden Sie unter GKE-Infrastruktur für DRA-Arbeitslasten vorbereiten.

• Konflikte bei der Konfiguration 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-Network 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 falschen Einrichtung und zu unvorhersehbarem Verhalten führen.

Voraussetzungen

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

• GKE-Version 1.34.1-gke.1829001 oder höher.
• GKE Dataplane V2 ist im Cluster aktiviert.
• (Vorabversion) GKE DRANET ist auf A4X Max-Maschinen verfügbar.

Beschränkungen

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

• Sie können GKE DRANET nicht verwenden, um die Standardnetzwerkschnittstellenkarte (NIC) oder virtuelle NICs (z. B. veth) zuzuweisen.
• Cluster-Autoscaling und Autopilot werden nicht unterstützt.
• Sie können GKE DRANET nicht mit Schnittstellen verwenden, für die Sie eine secondaryPodRange konfiguriert haben.

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.
  Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI das compute/region-Attribut fest. Wenn Sie hauptsächlich zonale Cluster verwenden, legen Sie stattdessen compute/zone fest. Wenn Sie einen standardmäßigen Speicherort festlegen, können Sie in der gcloud CLI Fehler wie diesen vermeiden: One of [--zone, --region] must be supplied: Please specify location. Bei bestimmten Befehlen müssen Sie möglicherweise den Speicherort angeben, wenn er sich von dem von Ihnen festgelegten Standard unterscheidet.

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 Standard-Cluster, 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 Clustersteuerungsebene, z. B. us-central1 oder us-central1-a.
• PROJECT_ID: Projekt-ID in Google Cloud .
• CLUSTER_VERSION: die GKE-Version für Ihren Cluster. Diese Version muss 1.34.1-gke.1829001 oder höher sein.

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 für einen 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: defaultoder latest

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

• NUM_NODES: Die Anzahl der Knoten für den Knotenpool. Bei flexiblem Start muss dieser Wert auf 0 gesetzt werden.

• RESERVATION_PROJECT: die Projekt-ID der Reservierung.

• RESERVATION_NAME: Der Name Ihrer Reservierung. Weitere Informationen zum Ermitteln dieses Werts

• RESERVATION_BLOCK: der Name eines bestimmten Blocks innerhalb der Reservierung. Weitere Informationen zum Ermitteln dieses Werts

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

RDMA-Ressourcen für eine Arbeitslast bereitstellen

Wenn Sie RDMA-Ressourcen für einen Pod zuweisen möchten, geben Sie einen ResourceClaimTemplate an.

1. Erstellen Sie eine ResourceClaimTemplate, um festzulegen, wie die RDMA-Geräte zugewiesen werden sollen. Das folgende Manifest fordert alle verfügbaren mrdma-Geräte auf dem Knoten an. 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. Das folgende Manifest stellt einen Pod bereit, 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 Standard-eth0- und lo-Schnittstellen sowie die zugewiesenen RDMA-Schnittstellen, z. B. gpu0rdma0. Die Anzahl und die Namen der Netzwerkschnittstellen (Network Interface Cards, 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 für die Verwendung von Nicht-RDMA-Netzwerkschnittstellen mit GKE DRANET konfigurieren.

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 Nicht-RDMA-Netzwerkgeräte für einen Pod zuweisen möchten, geben Sie ein ResourceClaimTemplate an.

1. Erstellen Sie eine ResourceClaimTemplate, die auf die netdev.google.com DeviceClass 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. Das folgende Manifest stellt einen Pod bereit, 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
   

Eine bestimmte Anzahl von Netzwerkgeräten anfordern

In den vorherigen Beispielen wird gezeigt, 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, können Sie allocationMode in Ihrem ResourceClaimTemplate auf ExactCount festlegen.

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

• Weitere Informationen zur dynamischen Ressourcenzuweisung
• Weitere Informationen