Automatisierte Netzwerkfunktionen für Accelerator-VMs konfigurieren

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.

In diesem Dokument erfahren Sie, wie Sie automatische Netzwerke für VMs mit Beschleunigern wie GPUs und TPUs verwenden, um die Netzwerkkonfiguration für GKE-Arbeitslasten (Google Kubernetes Engine) mit Beschleunigern zu vereinfachen. Dies ist unerlässlich, um künstliche Intelligenz (KI), maschinelles Lernen (ML) und Hochleistungs-Computing (HPC) auf beschleunigeroptimierten Maschinen auszuführen.

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

• Kubernetes
• GKE-Netzwerk
• VPC-Netzwerkkonzepte

Diese Seite richtet sich an Cloud-Architekten und Netzwerkspezialisten, die das Netzwerk ihrer Organisation entwerfen und erstellen. Eine Übersicht über alle GKE-Dokumentationssets 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.

GKE vereinfacht die Ausführung von leistungsstarker KI und ML auf speziellen Beschleunigern. Mit der automatisierten Vernetzung für Accelerator-VMs können Sie mit einem einzigen Konfigurationsflag Hochgeschwindigkeitsverbindungen über mehrere Netzwerke hinweg aktivieren, die für Protokolle wie RDMA unerlässlich sind. Durch diese Automatisierung entfällt der komplexe, manuelle Prozess der Einrichtung mehrerer VPC-Netzwerke, der Verwaltung von IP-Adressbereichen und der Konfiguration 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 Accelerator-VMs zu verstehen.

• Virtual Private Cloud (VPC): Eine VPC ist eine virtuelle Version eines physischen Netzwerks, das im Produktionsnetzwerk von Google implementiert wird. Es stellt die Verbindung für Ihre Compute Engine-VM-Instanzen, GKE-Cluster und andere Ressourcen her.
• Titanium-NIC: Eine intelligente NIC, die Netzwerkverarbeitungsaufgaben von der CPU auslagert, sodass sich die CPU auf Ihre Arbeitslasten konzentrieren kann. Auf GPU-Maschinen verarbeiten sie den gesamten Traffic, der nicht direkt zwischen GPUs erfolgt. Auf TPU-Maschinen sind alle NICs Titanium-NICs.
• Subnetzwerk: Ein Subnetzwerk ist ein segmentierter Teil einer größeren VPC. Jedes Subnetz ist einer Region zugeordnet und hat einen definierten IP-Adressbereich.
• Netzwerkschnittstellen-Controller (NIC): Eine NIC ist eine virtuelle Netzwerkschnittstelle, die eine VM-Instanz mit einem Netzwerk verbindet. Jede NIC ist mit einem bestimmten VPC-Netzwerk und Subnetzwerk verbunden.
• Hostnetzwerk: Das primäre Netzwerk, das von den primären Netzwerkschnittstellen (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 Accelerator-VMs. Bei 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, mit der Netzwerkgeräte Daten direkt mit dem Hauptspeicher eines Computers austauschen können, ohne das Betriebssystem oder die CPU zu verwenden. Dadurch werden Latenz und Durchsatz erheblich reduziert, was für HPC- und ML-Arbeitslasten entscheidend ist.
• NVLink: NVLink ist eine von NVIDIA entwickelte Hochgeschwindigkeits-Verbindungstechnologie, mit der mehrere GPUs innerhalb eines einzelnen Knotens verbunden werden können. So können sie gemeinsam auf den Arbeitsspeicher zugreifen und große Datasets bearbeiten.
• Dynamische Ressourcenzuweisung (Dynamic Resource Allocation, DRA) in Kubernetes: DRA ist eine Kubernetes-Funktion, die Pods eine flexiblere Möglichkeit bietet, Ressourcen wie GPUs und andere spezielle Hardware anzufordern und zu nutzen. Dies ermöglicht eine detaillierte Steuerung der Ressourcenzuweisung.

Funktionsweise der automatischen Vernetzung

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

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 für die allgemeine Clusterkommunikation und ‑verwaltung her, um mit der Steuerungsebene zu kommunizieren. GPU-NICs werden mit einem dedizierten, leistungsstarken VPC-Netzwerk verbunden, das häufig RDMA aktiviert und eine hohe MTU-Einstellung (8896) hat, um die GPUDirect-Kommunikation zu ermöglichen.

Wenn ein Pod GPUs oder TPUs anfordert, können Sie ihn so konfigurieren, dass er auf die leistungsstarken Netzwerkschnittstellen auf dem Knoten zugreifen kann. Sie können alle verfügbaren NICs oder eine bestimmte Teilmenge anfordern. Jede beanspruchte Netzwerkschnittstelle ist einem einzelnen Pod zugewiesen und wird nicht gemeinsam genutzt. Diese Netzwerkkonfiguration sorgt dafür, dass der Pod alleinigen Zugriff auf die volle Bandbreite und die Ressourcen dieser Schnittstelle hat. Das ist ein wichtiger Vorteil für leistungsintensive Arbeitslasten.

Beschränkungen

• Die automatische Netzwerkkonfiguration für Accelerator-VMs wird in Autopilot-Clustern nicht unterstützt.
• Für die automatisierte Vernetzung muss der Cluster GKE Dataplane V2 verwenden.
• Unterstützte Maschinentypen: Die automatische Vernetzung wird für die beschleunigungsoptimierten Maschinenfamilien A3, A4 und TPU Trillium (v6e) unterstützt.
• Einzelzonen-Knotenpools erforderlich: Sie müssen einen Knotenpool mit einer einzelnen Zone verwenden.
• Wenn Sie GKE-verwaltetes DRANET zum Konfigurieren von Arbeitslasten verwenden, beachten Sie die wichtigen Überlegungen und Einschränkungen für GKE-verwaltetes DRANET.
• Sie können nicht sowohl die Multi-Network API als auch DRANET im selben Knotenpool verwenden. Sie müssen eine Methode für die Netzwerkverbindung für Ihre Pods auswählen.

Netzwerkkonfigurationen für beschleunigungsoptimierte Maschinen

Beschleunigungsoptimierte Maschinen haben je nach Typ unterschiedliche Netzwerkkonfigurationen. In der folgenden Tabelle sind die Netzwerkspezifikationen für verschiedene Maschinentypen zusammengefasst.

VMs mit GPU-Beschleuniger

Maschinentyp	Anzahl der GPUs	Anzahl der Titanium-NICs	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 NIC, 1 für GPU-NICs)
A4	8 (B200)	2	8	RDMA	2 (1 für die zweite NIC, 1 für GPU-NICs)
A4X	4 (GB200)	1	4	RDMA	2 (1 für die zweite NIC, 1 für GPU-NICs)

TPU-Beschleuniger-VMs

Maschinentyp	Anzahl der TPU-Chips	Anzahl der NICs	Zusätzliche VPCs
TPU Trillium (v6e) (ct6e-standard-4t)	4	2	2 (1 für die zweite NIC, 1 für die zusätzliche vNIC auf der ersten NIC)

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.

• Ihr Cluster muss die GKE-Version 1.34.1-gke.1829001 oder höher verwenden.

• Prüfen Sie, ob Ihr Cluster GKE Dataplane V2 verwendet. Sie können dieses Feature aktivieren, wenn Sie einen neuen Cluster erstellen oder einen vorhandenen Cluster aktualisieren.

  • Erstellen Sie einen neuen Cluster:

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

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name des neuen Clusters.
    • CLUSTER_VERSION: Die Version Ihres Clusters, die 1.34.1-gke.1829001 oder höher sein muss.

  • So aktualisieren Sie einen vorhandenen Cluster:

    gcloud container clusters update CLUSTER_NAME \
        --enable-dataplane-v2
    

    Ersetzen Sie CLUSTER_NAME durch den Namen Ihres Clusters.

• Wenn Sie GPU-Arbeitslasten bereitstellen möchten, die RDMA verwenden, prüfen Sie, ob die DeviceClass-Ressourcen vorhanden sind:

  kubectl get deviceclass mrdma.google.com
  

Knotenpool mit einem Standardnetzwerkprofil erstellen

Wenn Sie automatisch ein Netzwerk erstellen möchten, das alle GPU- oder TPU-Maschinen in einer einzelnen Zone verbindet, erstellen Sie einen Knotenpool mit dem Beschleunigernetzwerkprofil 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

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 dem Befehl gcloud container node-pools create das Flag --accelerator-network-profile=auto 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.

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 dem von GKE verwalteten DRANET konfigurieren. Weitere Informationen finden Sie unter Netzwerkressourcen mit dem von GKE verwalteten DRANET zuweisen.

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
   

Arbeitslast planen, die TPUs verwendet

In den folgenden Abschnitten erfahren Sie, wie Sie einen TPU-Knotenpool und eine Arbeitslast für die Verwendung von Nicht-RDMA-Netzwerkschnittstellen mit dem von GKE verwalteten DRANET konfigurieren. Weitere Informationen finden Sie unter Netzwerkressourcen mit dem von GKE verwalteten 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 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
   

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

• Weitere Informationen zu beschleunigungsoptimierten Maschinen
• GPUs mit DRA bereitstellen
• Informationen zum Einrichten der Unterstützung mehrerer Netzwerke für Pods
• Netzwerkressourcen mit dem von GKE verwalteten DRANET zuweisen