Automatische Netzwerke für Beschleuniger-VMs konfigurieren

In diesem Dokument wird beschrieben, wie Sie das automatisierte Netzwerk für Beschleuniger-VMs wie GPUs und TPUs verwenden, um die Netzwerkkonfiguration für GKE-Beschleuniger-Arbeitslasten (Google Kubernetes Engine) zu vereinfachen. Dies ist für die Ausführung von künstlicher Intelligenz (KI), maschinellem Lernen (ML) und Hochleistungs-Computing (HPC) auf beschleunigungsoptimierten Maschinen unerlässlich.

In diesem Dokument wird davon ausgegangen, dass Sie mit den grundlegenden GKE-Konzepten, GPU- und TPU-Arbeitslasten sowie VPC-Netzwerken vertraut sind. Sie sollten insbesondere mit Folgendem vertraut sein:

Diese Seite richtet sich an Cloud-Architekten und Netzwerkspezialisten, die das Netzwerk ihrer Organisation entwerfen und erstellen. Eine Übersicht über alle GKE-Dokumentationen finden Sie unter GKE-Dokumentation. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir inGoogle Cloud -Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Die GKE vereinfacht die Ausführung von leistungsstarker KI und ML auf speziellen Beschleunigern. Mit der automatischen Vernetzung für Beschleuniger-VMs können Sie mit einem einzigen Konfigurations-Flag eine Hochgeschwindigkeits-Multi-Netzwerk-Verbindung aktivieren, die für Protokolle wie RDMA unerlässlich ist. Durch diese Automatisierung entfällt der komplexe, manuelle Prozess zum Einrichten mehrerer VPC-Netzwerke, Verwalten von IP-Adressbereichen und Konfigurieren von Netzwerkschnittstellen für jeden Knotenpool und Pod. Wenn Sie beim Erstellen eines Knotenpools einen einzelnen Parameter verwenden, stellt GKE alle erforderlichen Cloud- und Kubernetes-Netzwerkressourcen bereit.

Terminologie

Die folgenden Begriffe sind wichtig, um die Netzwerkarchitektur für Beschleuniger-VMs zu verstehen.

  • Virtual Private Cloud (VPC): Eine VPC ist eine virtuelle Version eines physischen Netzwerks, die innerhalb des Produktionsnetzwerks von Google implementiert wurde. Sie ermöglicht eine Verbindung für Ihre Compute Engine-VM-Instanzen, GKE-Cluster und andere Ressourcen.
  • Titanium-NIC: Eine intelligente NIC, die Netzwerkverarbeitungsaufgaben von der CPU auslagert, damit sich die CPU auf Ihre Arbeitslasten konzentrieren kann. Auf GPU-Maschinen verarbeiten sie den gesamten Traffic, der nicht direkte GPU-zu-GPU-Kommunikation ist. Auf TPU-Maschinen sind alle NICs Titanium-NICs.
  • Subnetzwerk: Ein Subnetzwerk ist ein segmentierter Teil einer größeren VPC. Jedes Subnetzwerk ist einer Region zugeordnet und hat einen definierten IP-Adressbereich.
  • Netzwerkschnittstellen-Controller (NIC): Ein NIC ist eine virtuelle Netzwerkschnittstelle, die eine VM-Instanz mit einem Netzwerk verbindet. Jede Netzwerkkarte ist mit einer bestimmten VPC und einem bestimmten Subnetzwerk verbunden.
  • Hostnetzwerk: Das primäre Netzwerk, das von den Hauptnetzwerkschnittstellen (NICs) des Knotens für die allgemeine Clusterkommunikation verwendet wird, z. B. für den Traffic der Steuerungsebene und das reguläre Pod-Netzwerk.
  • Datennetzwerk: Ein dediziertes Netzwerk für die leistungsstarke Datenübertragung zwischen Beschleuniger-VMs. Für GPUs ist dies oft eine GPUDirect-VPC mit RDMA. Bei TPUs kann dies ein zweites Hostnetzwerk sein.
  • Remote Direct Memory Access(RDMA): RDMA ist eine Technologie, die es Netzwerkgeräten ermöglicht, Daten direkt mit dem Hauptspeicher eines Computers auszutauschen, ohne das Betriebssystem oder die CPU einzubeziehen. Dadurch werden die Latenz erheblich reduziert und der Durchsatz verbessert, was für HPC- und ML-Arbeitslasten entscheidend ist.
  • NVLink: NVLink ist eine von NVIDIA entwickelte Hochgeschwindigkeits-Interconnect-Technologie, mit der mehrere GPUs innerhalb eines einzelnen Knotens verbunden werden können. So können sie Arbeitsspeicher gemeinsam nutzen und zusammen an großen Datasets arbeiten.
  • Dynamische Ressourcenzuweisung (DRA) von Kubernetes: DRA ist ein Kubernetes-Feature, das Pods eine flexiblere Möglichkeit bietet, Ressourcen wie GPUs und andere spezialisierte Hardware anzufordern und zu nutzen. Sie ermöglicht eine detaillierte Kontrolle über die Ressourcenzuweisung.

Funktionsweise des automatisierten Netzwerks

Beschleunigungsoptimierte Maschinen haben eine spezielle Netzwerkarchitektur, die eine Kommunikation mit hohem Durchsatz und niedriger Latenz zwischen GPUs und TPUs unterstützt. Jede physische Maschine enthält mehrere GPUs oder TPUs, die häufig über Hochgeschwindigkeitsverbindungen wie NVLink verbunden sind. Die Maschinen haben außerdem eine oder mehrere NICs für allgemeine Netzwerke und mehrere GPU-NICs für Hochgeschwindigkeits-Interconnect-Verbindungen.

Wenn Sie einen GKE-Knoten erstellen, der einen beschleunigungsoptimierten Maschinentyp verwendet, konfiguriert GKE mehrere NICs auf der zugrunde liegenden VM. Host-NICs stellen eine Verbindung zu Host-VPC-Netzwerken her, um die allgemeine Clusterkommunikation und -verwaltung für die Kommunikation mit der Steuerungsebene zu ermöglichen. GPU-NICs stellen eine Verbindung zu einem dedizierten Hochleistungs-VPC-Netzwerk her, häufig mit aktiviertem RDMA und einer hohen MTU-Einstellung (8896), um die GPUDirect-Kommunikation zu ermöglichen.

Wenn ein Pod GPUs oder TPUs anfordert, können Sie ihn so konfigurieren, dass er auf die Hochleistungs-Netzwerkschnittstellen auf dem Knoten zugreift. Sie können alle verfügbaren NICs oder eine bestimmte Teilmenge anfordern. Jede beanspruchte Netzwerkschnittstelle ist einem einzelnen Pod zugeordnet und wird nicht freigegeben. Diese Netzwerkkonfiguration 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.

Beschränkungen

  • Für das automatisierte Netzwerk muss der Cluster GKE Dataplane V2 verwenden.
  • Automatisierte Netzwerke werden für die beschleunigungsoptimierten Maschinenfamilien A3, A4 und TPU Trillium (v6e) sowie für die speicheroptimierte Maschinenserie Z4M unterstützt.
  • Sie müssen einen Knotenpool mit einer einzelnen Zone verwenden.
  • Sie können die automatisierte Netzwerkerstellung nicht in einem Cluster verwenden, der eine gemeinsam genutzte VPC verwendet.
  • Wenn Sie von GKE verwaltete DRANET zum Konfigurieren von Arbeitslasten verwenden, beachten Sie die wichtigen Überlegungen und Einschränkungen für von GKE verwaltete DRANET.
  • Sie können die Multi-Netzwerk-API und DRANET nicht im selben Knotenpool verwenden. Sie müssen eine Methode für den Netzwerkanhang für Ihre Pods auswählen.
  • Bei regionalen Clustern müssen Sie die Zielzone angeben, wenn Sie Netzwerkprofile für Beschleuniger aktivieren. Wenn sich Ihre Arbeitslast über mehrere Zonen erstreckt, müssen Sie das Netzwerkprofil für jede Zone einzeln aktivieren.

Maschinennetzwerkkonfigurationen

Beschleunigungsoptimierte und speicheroptimierte Maschinen haben je nach Typ unterschiedliche Netzwerkkonfigurationen. In den folgenden Tabellen sind die Netzwerkspezifikationen für verschiedene Maschinentypen zusammengefasst.

GPU-Beschleuniger-VMs

Maschinentyp Anzahl der GPUs Anzahl der Titanium-Netzwerkkarten Anzahl der GPU-NICs GPUDirect-Technologie Zusätzliche VPCs
A3 8 (H100) 1 4 TCPX 4 für GPU-NICs
A3 Mega 8 (H100) 1 8 TCPXO 8 für GPU-NICs
A3 Ultra 8 (H200) 2 8 RDMA 2 (1 für die zweite Netzwerkkarte, 1 für die GPU-Netzwerkkarten)
A4 8 (B200) 2 8 RDMA 2 (1 für die zweite Netzwerkkarte, 1 für die GPU-Netzwerkkarten)
A4X 4 (GB200) 2 4 RDMA 2 (1 für die zweite Netzwerkkarte, 1 für die GPU-Netzwerkkarten)
A4X BM 8 2 8 BM-RDMA 2 (1 für die zweite Netzwerkkarte, 1 für die GPU-Netzwerkkarten)

TPU-Beschleuniger-VMs

Maschinentyp Anzahl der TPU-Chips Anzahl der NICs Zusätzliche VPCs
TPU Trillium (v6e) (ct6e-standard-1t) 1 0,25 1
TPU Trillium (v6e) (ct6e-standard-4t) 4 2 2 (1 für die 2. NIC, 1 für die zusätzliche VNIC auf der 1. NIC)
TPU Trillium (v6e) (ct6e-standard-8t) 8 4 4
tpu7x-standard-4t 4 2 2

Speicheroptimierte VMs

Auf Z4M-Instanzen unterstützen die beiden physischen Titanium-NICs sowohl allgemeinen Netzwerkverkehr (gVNIC) als auch bis zu zwei virtuelle IRDMA-Netzwerkschnittstellen (vNICs) für die Cloud RDMA-Kommunikation.

Maschinentyp Anzahl der physischen Titanium-Netzwerkkarten Anzahl der RDMA-vNICs Netzwerktechnologie Zusätzliche VPCs
Z4M (z4m-highmem-192) 2 Bis zu 2 (auf physischen NICs freigegeben) RDMA 2 für RDMA-vNICs

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.
  • Ihr Cluster muss die GKE-Version 1.34.1-gke.2037000 oder höher verwenden.

  • Wenn Sie die automatische Knotenbereitstellung und benutzerdefinierte ComputeClasses aktivieren möchten, muss Ihr Cluster die GKE-Version 1.35.2-gke.1302000 oder höher verwenden.

  • Prüfen Sie, ob das GKE-Dienstkonto in Ihrem Projekt die Rolle compute.networkAdmin hat.

  • Prüfen Sie, ob GKE Dataplane V2 für Ihren Cluster aktiviert ist. Sie können GKE Dataplane V2 nur aktivieren, wenn Sie einen neuen Cluster mit GKE-Version 1.34.1-gke.2037000 oder höher erstellen. Sie können GKE Dataplane V2 nicht für Cluster vor dieser Version aktivieren.

      gcloud container clusters create CLUSTER_NAME \
    --cluster-version=CLUSTER_VERSION \
    --enable-dataplane-v2

  • Wenn Sie GPU- oder Z4M-Arbeitslasten bereitstellen möchten, die RDMA verwenden, prüfen Sie, ob die DeviceClass-Ressourcen vorhanden sind (mrdma.google.com für GPUs oder irdma.google.com für Z4M):

    kubectl get deviceclass mrdma.google.com

Automatische Netzwerke konfigurieren

Sie können automatisierte Netzwerke aktivieren, indem Sie beim Erstellen eines Knotenpools ein Netzwerkprofil für Beschleuniger angeben. Sie können auch eine ComputeClass-Ressource für Cluster erstellen, die die automatische Knotenbereitstellung verwenden.

Knotenpool mit einem Standardnetzwerkprofil erstellen

Wenn Sie automatisch ein Netzwerk erstellen möchten, das alle GPU- oder TPU-Maschinen innerhalb einer einzelnen Zone verbindet, erstellen Sie einen Knotenpool mit dem Netzwerkprofil für Beschleuniger auto.

gcloud

Führen Sie den folgenden Befehl aus, um einen Knotenpool mit einem automatisch konfigurierten Netzwerkprofil zu erstellen:

gcloud beta container node-pools create NODE_POOL_NAME \
    --accelerator-network-profile=auto \
    --node-locations=ZONE \
    --machine-type=MACHINE_TYPE

Wenn Sie einen Knotenpool mit dem Flag --accelerator-network-profile=auto erstellen, fügt GKE den Knoten automatisch das Label gke.networks.io/accelerator-network-profile: auto hinzu. Wenn Sie Arbeitslasten auf diesen Knoten planen möchten, müssen Sie dieses Label in die nodeSelector Ihrer Arbeitslast aufnehmen.

Weitere Informationen zum Erstellen von Knotenpools mit Beschleunigern finden Sie unter GPUs in Autopilot-Knotenpools ausführen und TPU-Arbeitslasten in Autopilot bereitstellen. Wenn Sie der Anleitung in diesen Dokumenten folgen, hängen Sie das Flag --accelerator-network-profile=auto an den Befehl gcloud container node-pools create an.

Für TPU-Slice-Knotenpools mit mehreren Hosts müssen Sie auch das Flag --tpu-topology hinzufügen.

Ersetzen Sie Folgendes:

  • NODE_POOL_NAME ist der Name des neuen Knotenpools.
  • ZONE: Die Zone für den Knotenpool.
  • MACHINE_TYPE: Der Maschinentyp für die Knoten, z. B. a3-ultragpu-8g.

REST

Geben Sie in einer Anfrage an die Methode nodePools.create das Feld accelerator_network_profile an:

{
  "nodePool": {
    "name": "NODE_POOL_NAME",
    "machineType": "MACHINE_TYPE",
    ...
    "accelerator_network_profile": "auto"
  }
}

Ersetzen Sie Folgendes:

  • NODE_POOL_NAME ist der Name des neuen Knotenpools.
  • MACHINE_TYPE: Der Maschinentyp für die Knoten, z. B. a3-ultragpu-8g.

Automatische Netzwerke mit automatischer Knotenbereitstellung aktivieren

Wenn Sie das automatisierte Netzwerk in Autopilot-Clustern oder Standardclustern konfigurieren möchten, die die automatische Knotenbereitstellung verwenden, fügen Sie das Feld acceleratorNetworkProfile einer ComputeClass-Ressource hinzu.

  1. Das folgende ComputeClass-Beispielmanifest aktiviert die automatisierte Netzwerkverwaltung für A3 Mega-Maschinen. Speichern Sie das folgende Manifest als anp-compute-class.yaml:

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: anp-a3-mega-class
spec:
  autopilot:
    enabled: true
  nodePoolAutoCreation:
    enabled: true
  priorities:
  # Priority 1: A3 Mega in us-central1-a
  - machineType: a3-megagpu-8g
    gpu:
      count: 8
      driverVersion: default
      type: nvidia-h100-mega-80gb
    flexStart:
      enabled: true
    location:
      zones: [us-central1-a]
    acceleratorNetworkProfile: auto
  whenUnsatisfiable: DoNotScaleUp

  2. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f anp-compute-class.yaml

Wenn Sie eine Arbeitslast bereitstellen, die diese ComputeClass-Ressource auswählt, konfiguriert GKE automatisch die erforderlichen Netzwerkschnittstellen für die bereitgestellten Knoten.

Arbeitslast planen, die GPUs verwendet

In den folgenden Abschnitten erfahren Sie, wie Sie einen GPU-Knotenpool und eine Arbeitslast für die Verwendung von RDMA-Netzwerkschnittstellen mit von GKE verwaltetem DRANET konfigurieren. Weitere Informationen finden Sie unter Netzwerkressourcen mit von GKE verwaltetem DRANET zuweisen.

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

Arbeitslast planen, die TPUs verwendet

In den folgenden Abschnitten erfahren Sie, wie Sie einen TPU-Knotenpool und eine Arbeitslast so konfigurieren, dass nicht-RDMA-Netzwerkschnittstellen mit dem von GKE verwalteten DRANET verwendet werden. Weitere Informationen finden Sie unter Netzwerkressourcen mit von GKE verwaltetem DRANET zuweisen.

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

Fehlerbehebung

Führen Sie den folgenden Befehl aus, um die Netzwerkeinrichtung für einen Knotenpool zu prüfen:

gcloud beta container node-pools describe NODE_POOL_NAME \
    --zone=ZONE \
    --cluster=CLUSTER_NAME

Ersetzen Sie Folgendes:

  • NODE_POOL_NAME: Der Name des Knotenpools.
  • ZONE: die Zone des Knotenpools.
  • CLUSTER_NAME: Der Name Ihres Clusters.

In der Ausgabe werden die zusätzlichen Netzwerke und Subnetzwerke angezeigt, die an den Knotenpool angehängt sind.

Nächste Schritte