Diese Seite wurde von der Cloud Translation API übersetzt.

Subnetze zu Clustern hinzufügen

Autopilot Standard

Auf dieser Seite erfahren Sie, wie Sie einem VPC-nativer Cluster zusätzliche Subnetze zuweisen. Wenn einem Cluster zusätzliche Subnetze zugewiesen sind, können Sie neue Knotenpools erstellen, in denen IPv4-Adressen für Knoten und Pods aus den zusätzlichen Subnetzbereichen stammen.

Diese Seite richtet sich an Netzwerkspezialisten, die das Netzwerk für ihre Organisation entwerfen und erstellen. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Übersicht

Wenn Sie einen neuen VPC-nativen GKE-Cluster erstellen, wählen Sie ein Standardsubnetz für den Cluster aus. Das Standardsubnetz des Clusters stellt IPv4-Adressen für Knoten, Pods und Dienste bereit, wie unter IP-Adressbereiche für VPC-native Cluster beschrieben.

Sie können einem VPC-nativen Cluster bis zu acht zusätzliche Subnetze zuweisen, was ein erhebliches Clusterwachstum ermöglicht. Jedes neu zugewiesene zusätzliche Subnetz wird als nicht standardmäßiges Subnetz bezeichnet.

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.

Anforderungen und Einschränkungen

In diesem Abschnitt werden die Anforderungen und Einschränkungen beschrieben, die gelten, wenn Sie einem Cluster zusätzliche Subnetze zuweisen und verwenden. Sie müssen alle Anforderungen erfüllen, bevor Sie zusätzliche Subnetze zuweisen können.

Ihr GKE-Cluster muss ein VPC-nativer Cluster sein, auf dem GKE-Version 1.30.3-gke.1211000 oder höher ausgeführt wird. Routenbasierte Cluster und Cluster in Legacy-Netzwerken unterstützen keine zusätzlichen Subnetze.
Sie können jedem Cluster bis zu acht zusätzliche Subnetze zuweisen.
Die zusätzlichen Subnetze stellen nur IPv4-Adressen für Knoten und Pods bereit. Zusätzliche Subnetze können nicht verwendet werden, um IPv6-Adressen für Knoten oder Pods bereitzustellen.
Die zusätzlichen Subnetze können nur für neue Knotenpools verwendet werden, nicht für bestehende. Wenn Sie einen neuen Knotenpool erstellen und mehrere Subnetze, die nicht dem Standard entsprechen, verfügbar sind, wählt GKE das beste Subnetz für den Knotenpool basierend auf den Anforderungen für IP-Adressen und der Verfügbarkeit von IP-Adressen in allen Cluster-Subnetzen aus.
Sie können nicht festlegen, welches Subnetz, das nicht das Standardsubnetz ist, von einem neuen Knotenpool verwendet wird. Wenn Ihr Cluster beispielsweise ein Standardsubnetz (das beim Erstellen des Clusters verwendet wird) und zwei Nicht-Standardsubnetze hat, können Sie nicht angeben, welches der Nicht-Standardsubnetze ein neuer Knotenpool verwenden soll.
Sekundäre IPv4-Adressbereiche des Subnetzes in einem nicht standardmäßigen Subnetz können nur von einem einzelnen Cluster verwendet werden.
Zusätzliche Subnetze können nicht mit Multi-Cluster-Gateways verwendet werden.
Wenn Sie Unterstützung mehrerer Netzwerke für Pods verwenden, dürfen sich die primären und Pod-IPv4-Adressbereiche eines zusätzlichen Subnetzes nicht mit CIDR-Bereichen überschneiden, die in Ihrer Multi-Netzwerk-Konfiguration konfiguriert sind. Zusätzliche Subnetze, die Sie konfigurieren, gelten nur für das Standardnetzwerk. Diese Einschränkung bedeutet, dass alle zusätzlichen Netzwerkschnittstellen auf Ihren Knoten und Pods die von diesen zusätzlichen Subnetzen bereitgestellten IP-Adressen nicht verwenden können.
Wenn der Pool von IP-Adressen im Standardsubnetz erschöpft ist, können Sie Ihren Cluster nicht automatisch skalieren, auch wenn Sie zusätzliche Subnetze verwenden.
Wenn Sie einem Cluster, für den Cloud Service Mesh aktiviert ist, ein Subnetz hinzufügen, kann das Mesh keinen Traffic an Pods im nicht standardmäßigen Subnetz weiterleiten.

Load-Balancer-Anforderungen für Cluster mit zusätzlichen Subnetzen

In diesem Abschnitt werden die Anforderungen an den Load-Balancer beschrieben, die gelten, wenn Sie zusätzliche Subnetze in Ihrem Cluster verwenden. Diese Anforderungen gelten jedes Mal, wenn Sie ein externes Ingress-Objekt, ein externes Gateway oder einen externen LoadBalancer-Dienst erstellen.

Wenn Sie einen externen Ingress-, Gateway- oder LoadBalancer-Dienst in einem Cluster mit zusätzlichen Subnetzen verwenden möchten, muss auf Ihrem Cluster die GKE-Version 1.33.2-gke.4780000 oder höher ausgeführt werden.
Externe Ingress-Objekte, die den GKE-Ingress-Controller verwenden, müssen containernatives Load-Balancing nutzen.
Aktivieren Sie die GKE-Teilmengeneinstellung für interne LoadBalancer-Dienste. Die GKE-Teilmengeneinstellung wirkt sich nur auf neue interne LoadBalancer-Dienste aus. Daher müssen Sie alle vorhandenen Dienste in Ihrem Cluster löschen und neu erstellen, nachdem Sie die GKE-Teilmengeneinstellung aktiviert haben.
Wenn Sie einen Backend-Dienst-basierten externen Passthrough-Network Load Balancer erstellen möchten, müssen neue externe LoadBalancer-Dienste die Annotation cloud.google.com/l4-rbs: "enabled" enthalten. Diese Annotation wirkt sich nur auf neue externe LoadBalancer-Dienste aus und gilt nicht für vorhandene externe LoadBalancer-Dienste. Löschen Sie alle externen LoadBalancer-Dienste, die ohne die cloud.google.com/l4-rbs: "enabled"-Annotation erstellt wurden, und erstellen Sie sie neu.

Der verwendete Backend-Typ (GCE_VM_IP NEG-Backends oder Instanzgruppen-Backends) hängt von der GKE-Version ab, die beim Erstellen des externen LoadBalancer-Dienstes verwendet wird. Weitere Informationen finden Sie unter Knotengruppierung.

Neues Subnetz mit einem Pod-IPv4-Adressbereich hinzufügen

Erstellen Sie ein neues Subnetz und fügen Sie einen neuen sekundären IPv4-Adressbereich des Subnetzes hinzu. Das Subnetz muss sich in derselben Region und demselben VPC-Netzwerk wie der Cluster befinden:
```
   gcloud compute networks subnets create SUBNET_NAME \
     --network=NETWORK \
     --region=REGION \
     --range=PRIMARY_RANGE \
     --secondary-range=POD_RANGE_NAME=SECONDARY_RANGE \
     --enable-private-ip-google-access
```
Ersetzen Sie Folgendes:
- SUBNET_NAME: der Name des neuen Subnetzes.
- NETWORK: der Name des VPC-Netzwerks, das das neue Subnetz enthält.
- REGION: die Region, in der sich das Subnetz befindet.
- PRIMARY_RANGE: der primäre IPv4-Bereich für das neue Subnetz in CIDR-Notation. Weitere Informationen finden Sie unter IPv4-Subnetzbereiche.
- POD_RANGE_NAME: ein Name für den sekundären Bereich.
- SECONDARY_RANGE: der sekundäre IPv4-Bereich in CIDR-Notation. Informationen zu gültigen Bereichen finden Sie unter IPv4-Subnetzbereiche.
Weitere Informationen finden Sie unter Mit Subnetzen arbeiten.
Aktualisieren Sie Ihren Cluster, um das zusätzliche Subnetz mit der gcloud CLI zu verwenden:
```
   gcloud container clusters update CLUSTER_NAME \
     --additional-ip-ranges=subnetwork=SUBNET_NAME,pod-ipv4-range=POD_RANGE_NAME
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME ist der Name Ihres vorhandenen Clusters.
- SUBNET_NAME: der Name des neuen Subnetzes, das Sie erstellt haben.
- POD_RANGE_NAME: Der Name des sekundären IPv4-Adressbereichs des Subnetzes, den Sie für den Pod-IPv4-Adressbereich verwenden möchten.

Neues Subnetz mit mehreren Pod-IPv4-Adressbereichen hinzufügen

Erstellen Sie ein neues Subnetz in derselben Region und demselben VPC-Netzwerk wie der Cluster. Legen Sie den primären IPv4-Adressbereich des Subnetzes auf einen zusätzlichen IPv4-Adressbereich für Knoten fest.
Fügen Sie für jeden zusätzlichen Pod-IPv4-Adressbereich, den Sie benötigen, dem Subnetz, das Sie im vorherigen Schritt erstellt haben, einen neuen sekundären IPv4-Adressbereich des Subnetzes hinzu.
Aktualisieren Sie Ihren Cluster, um das zusätzliche Subnetz zu verwenden. Verwenden Sie dazu die gcloud CLI. Im folgenden Beispiel wird ein Subnetz mit zwei sekundären IPv4-Adressbereichen für Pods hinzugefügt.
```
   gcloud container clusters update CLUSTER_NAME \
     --additional-ip-ranges=subnetwork=SUBNET_NAME,pod-ipv4-range=POD_RANGE_NAME_1 \
     --additional-ip-ranges=subnetwork=SUBNET_NAME,pod-ipv4-range=POD_RANGE_NAME_2
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME ist der Name Ihres vorhandenen Clusters.
- SUBNET_NAME: der Name des neuen Subnetzes, das Sie erstellt haben.
- POD_RANGE_NAME_1 und POD_RANGE_NAME_2: Die Namen der sekundären IPv4-Adressbereiche des Subnetzes, die Sie für Pod-IPv4-Adressbereiche verwenden möchten.

Subnetze prüfen

Nach Cluster: Führen Sie den folgenden Befehl aus, um die Details aller Subnetze aufzurufen, die einem Cluster zugeordnet sind:

   gcloud container clusters describe CLUSTER_NAME

Ersetzen Sie CLUSTER_NAME durch den Namen Ihres Clusters.

Die Ausgabe sieht etwa so aus:

ipAllocationPolicy:
  additionalIPRangesConfig:
  - podIpv4RangeNames:
    - pod-range-1
    subnetwork: projects/user-gke-dev-2/regions/us-central1/subnetworks/shared-msc-subnets

Nach Knotenpool: Wenn Sie die Details aller Subnetze aufrufen möchten, die einem Knotenpool zugeordnet sind, führen Sie den folgenden Befehl aus:

gcloud container node-pools describe POOL_NAME \
    --cluster=CLUSTER_NAME \

Ersetzen Sie Folgendes:

POOL_NAME ist der Name des Knotenpools.
CLUSTER_NAME ist der Name des Clusters.

Die Ausgabe sieht etwa so aus:

name: pool-1
networkConfig:
  podRange: pod-range-1
  subnetwork: projects/user-gke-dev-2/regions/us-central1/subnetworks/shared-msc-subnets

Nicht standardmäßiges Subnetz entfernen

Wenn Sie ein nicht standardmäßiges Subnetz aus einem Cluster entfernen, wird der Cluster angewiesen, die Bereiche des Subnetzes nicht mehr in den Knotenpools des Clusters zu verwenden. Das Entfernen hat folgende Auswirkungen:

Der primäre IPv4-Adressbereich des Subnetzes, das nicht das Standardsubnetz ist, kann nicht für IPv4-Adressbereiche von Knoten verwendet werden.
Die sekundären IPv4-Bereiche des Subnetzes im Nicht-Standard-Subnetz können nicht für Pod-IPv4-Bereiche verwendet werden.

Bevor Sie ein nicht standardmäßiges Subnetz entfernen, müssen Sie alle Knotenpools löschen, die dieses Subnetz verwenden. Das Subnetz in den Status „Wird geleert“ zu versetzen, ist der empfohlene erste Schritt. Subnetze mit dem Status „Wird geleert“ werden nicht für die Verwendung durch neu erstellte Knotenpools berücksichtigt. So wird verhindert, dass bei Cluster Autoscaler-Vorgängen (z. B. beim Hochskalieren von Knotenpools) das zu entfernende Subnetz ausgewählt wird, ohne dass Sie das Autoscaling für den gesamten Cluster deaktivieren müssen.

So entfernen Sie ein Subnetz:

Setzen Sie das nicht standardmäßige Subnetz auf den Status „Wird geleert“. Dadurch wird verhindert, dass neue Knotenpools dieses Subnetz auswählen. Das ist nützlich, wenn Sie Autoscaling für den Cluster aktivieren.
Löschen Sie alle Knotenpools, die dieses Subnetz verwenden.
Entfernen Sie das Subnetz aus dem Cluster.

Führen Sie den folgenden Befehl aus, um ein nicht standardmäßiges Subnetz aus dem Cluster zu entfernen:

   gcloud container clusters update CLUSTER_NAME \
     --remove-additional-ip-ranges=subnetwork=SUBNET_NAME

Ersetzen Sie Folgendes:

CLUSTER_NAME: Der Name Ihres Clusters.
SUBNET_NAME: Der Name des Subnetzes, das Sie aus dem Cluster entfernen möchten.

Führen Sie den folgenden Befehl aus, um den Status eines Nicht-Standard-Subnetzes auf „Draining“ zu setzen:

   gcloud container clusters update CLUSTER_NAME \
     --drain-additional-ip-ranges=subnetwork=SUBNET_NAME

Ersetzen Sie Folgendes:

CLUSTER_NAME: Der Name Ihres Clusters.
SUBNET_NAME: Der Name des Subnetzes, das Sie auf den Status „Entleeren“ setzen möchten.

Führen Sie den folgenden Befehl aus, um ein nicht standardmäßiges Subnetz zu entleeren:

   gcloud container clusters update CLUSTER_NAME \
     --undrain-additional-ip-ranges=subnetwork=SUBNET_NAME

Ersetzen Sie Folgendes:

CLUSTER_NAME: Der Name Ihres Clusters.
SUBNET_NAME: Der Name des Subnetzes, dessen Training Sie rückgängig machen möchten.

Nachdem Sie ein nicht standardmäßiges Subnetz aus dem Cluster entfernt haben, können Sie das nicht standardmäßige Subnetz löschen.

Sekundären IPv4-Bereich aus einem nicht standardmäßigen Subnetz entfernen

Wenn Sie einen nicht standardmäßigen sekundären IPv4-Bereich des Subnetzes aus einem Cluster entfernen, weist GKE den Cluster an, diesen Bereich nicht für Pod-IPv4-Bereiche in einem Knotenpool zu verwenden. Wenn der sekundäre IPv4-Bereich des Nicht-Standard-Subnetzes, den Sie entfernen, der einzige Bereich des Nicht-Standard-Subnetzes ist, der von diesem Cluster verwendet wird, weist GKE den Cluster auch an, die primäre IPv4-Adresse dieses Subnetzes nicht mehr für Knoten-IPv4-Adressen zu verwenden.

Bevor Sie einen sekundären IPv4-Bereich eines Nicht-Standardsubnetzes entfernen, müssen Sie alle Knotenpools löschen, die den Bereich für Pod-IPv4-Adressen verwenden.

Führen Sie den folgenden Befehl aus, um einen sekundären IPv4-Bereich eines nicht standardmäßigen Subnetzes aus dem Cluster zu entfernen:

   gcloud container clusters update CLUSTER_NAME \
     --remove-additional-ip-ranges=\
       subnetwork=SUBNET_NAME,pod-ipv4-range=POD_RANGE_NAME

Ersetzen Sie Folgendes:

CLUSTER_NAME ist der Name des Clusters.
SUBNET_NAME: der Name des nicht standardmäßigen Subnetzes.
POD_RANGE_NAME: Der Name des sekundären IPv4-Bereichs des Subnetzes, der nicht der Standardbereich ist und den Sie aus dem Cluster entfernen möchten.

Nachdem Sie einen sekundären IPv4-Bereich eines Nicht-Standard-Subnetzes aus dem Cluster entfernt haben, können Sie den sekundären IPv4-Bereich des Nicht-Standard-Subnetzes löschen.

Zusätzliche Subnetze in freigegebene VPC verwenden

Bevor Sie fortfahren, benötigen Sie Folgendes:

Eine funktionierende Umgebung mit freigegebene VPC, in der das Host- und das Dienstprojekt angehängt sind. Eine Anleitung finden Sie unter Cluster mit freigegebener VPC einrichten.
Ein aktiver GKE-Cluster im Dienstprojekt.
Alle erforderlichen APIs sind sowohl im Host- als auch im Dienstprojekt aktiviert.

Erstellen Sie ein zusätzliches Subnetz im Hostprojekt im selben Netzwerk des GKE-Cluster:

gcloud compute networks subnets create ADDITIONAL_SUBNET_NAME \
  --project HOST_PROJECT_ID \
  --network shared-net \
  --range 172.16.4.0/22 \
  --region COMPUTE_REGION \
  --secondary-range ADDITIONAL_SUBNET_NAME-services=172.16.16.0/20,ADDITIONAL_SUBNET_NAME-pods=172.20.0.0/14

Rufen Sie die IAM-Richtlinie ab. Damit der GKE-Cluster im Dienstprojekt auf zusätzliche Subnetze in der freigegebene VPC des Hostprojekts zugreifen kann, müssen Sie die erforderlichen IAM-Berechtigungen konfigurieren. Wenn die Berechtigungen noch nicht konfiguriert sind, fahren Sie mit den folgenden Schritten fort. Wenn die Berechtigungen bereits vorhanden sind, müssen Sie nichts weiter tun.
```
gcloud compute networks subnets get-iam-policy ADDITIONAL_SUBNET_NAME \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION
```
Die Ausgabe enthält das Feld etag. Notieren Sie sich den Wert von etag.

Erstellen Sie eine Datei mit dem Namen ADDITIONAL_SUBNET_NAME-policy.yaml mit folgendem Inhalt:

  bindings:
  - members:
    - serviceAccount:SERVICE_PROJECT_NUM@cloudservices.gserviceaccount.com
    - serviceAccount:service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com
    role: roles/compute.networkUser
  etag: ETAG_STRING

Ersetzen Sie dabei ETAG_STRING durch den zuvor notierten etag-Wert.

Legen Sie die IAM-Richtlinie für das Subnetz ADDITIONAL_SUBNET_NAME fest:

  gcloud compute networks subnets set-iam-policy ADDITIONAL_SUBNET_NAME \
      ADDITIONAL_SUBNET_NAME-policy.yaml \
      --project HOST_PROJECT_ID \
      --region COMPUTE_REGION

Prüfen Sie die verwendbaren Subnetze und sekundären IP-Adressbereiche, wie unter shared vpc verify usable subnets beschrieben.
Aktualisieren Sie den freigegebene VPC-Cluster der zusätzlichen Subnetze:

    gcloud container clusters update CLUSTER_NAME \
        --project=SERVICE_PROJECT_ID \
        --location=CONTROL_PLANE_LOCATION \
        --additional-ip-ranges=subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/ADDITIONAL_SUBNET_NAME,pod-ipv4-range=ADDITIONAL_SUBNET_NAME-pods

Ersetzen Sie Folgendes:

CLUSTER_NAME: der Name Ihres GKE-Cluster im Dienstprojekt.
ADDITIONAL_SUBNET_NAME: Der Name des zusätzlichen Subnetzes, das Sie im Hostprojekt erstellt haben (z.B. „tier-2“).
HOST_PROJECT_ID: die ID des Hostprojekts.
SERVICE_PROJECT_NUM: der Name des Dienstprojekts.
COMPUTE_REGION: die Region, in der sich das Subnetz befindet.

So können Sie die zusätzlichen Subnetze in einer Umgebung mit freigegebene VPC verwenden.

Subnetze zu Clustern hinzufügen Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Übersicht

Hinweise

Anforderungen und Einschränkungen

Load-Balancer-Anforderungen für Cluster mit zusätzlichen Subnetzen

Neues Subnetz mit einem Pod-IPv4-Adressbereich hinzufügen

Neues Subnetz mit mehreren Pod-IPv4-Adressbereichen hinzufügen

Subnetze prüfen

Nicht standardmäßiges Subnetz entfernen

Sekundären IPv4-Bereich aus einem nicht standardmäßigen Subnetz entfernen

Zusätzliche Subnetze in freigegebene VPC verwenden

Nächste Schritte

Subnetze zu Clustern hinzufügen