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.

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 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. Standardmäßig wählt GKE automatisch ein geeignetes Subnetz für den Knotenpool aus. Sie können beim Erstellen eines Knotenpools optional manuell ein Subnetz angeben.
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 für zusätzliche Netzwerkschnittstellen auf Ihren Knoten und Pods nicht die IP-Adressen verwendet werden können, die von diesen zusätzlichen Subnetzen bereitgestellt werden.
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 Sie beim Erstellen des externen LoadBalancer-Dienstes verwenden. 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 zu verwenden, indem Sie die gcloud CLI 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 mit einem Cluster verknüpft 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

So wird ein Subnetz für Knotenpools ausgewählt

Wenn Sie einen neuen Knotenpool erstellen und mehrere Subnetze verfügbar sind, wählt GKE standardmäßig automatisch ein geeignetes Subnetz für den Knotenpool aus. Dabei werden die Anforderungen an IP-Adressen und die Verfügbarkeit von IP-Adressen in allen Cluster-Subnetzen berücksichtigt.

Subnetz beim Erstellen des Knotenpools manuell angeben

Wenn Sie beim Erstellen eines Knotenpools ein Subnetz angeben möchten, verwenden Sie das Flag --subnetwork mit dem Befehl gcloud container node-pools create. Das von Ihnen angegebene Subnetz muss dem Cluster bereits zugewiesen sein (entweder als Standardsubnetz oder als zusätzliches Subnetz). Wenn Sie keinen IPv4-Bereich für Pods angeben, wählt GKE automatisch einen verfügbaren sekundären Bereich aus dem angegebenen Subnetz aus. Wenn das angegebene Subnetz oder der Pod-Bereich nicht genügend verfügbare IP-Adressen für den Knotenpool hat, gibt GKE einen Fehler zurück.

gcloud container node-pools create POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --subnetwork=SUBNET_NAME

Pod-IPv4-Adressbereich zusammen mit dem Subnetz angeben

Wenn das angegebene Subnetz mehrere sekundäre IPv4-Adressbereiche hat, können Sie sowohl das Flag --pod-ipv4-range als auch das Flag --subnetwork verwenden, um anzugeben, welcher Bereich für die Pods im Knotenpool verwendet werden soll.

gcloud container node-pools create POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --subnetwork=SUBNET_NAME \
    --pod-ipv4-range=POD_RANGE_NAME

Ersetzen Sie Folgendes:

POOL_NAME ist der Name für den neuen Knotenpool.
CLUSTER_NAME ist der Name des Clusters.
LOCATION: Die Region oder Zone des Clusters.
SUBNET_NAME: Der Name oder vollständige Ressourcenpfad des Subnetzes, das Sie verwenden möchten.
POD_RANGE_NAME: Der Name des sekundären Subnetzbereichs, der für Pods in diesem Knotenpool verwendet werden soll.

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 auf den Status „Wird geleert“ zu setzen, ist der empfohlene erste Schritt. Subnetze im 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 Subnetz ausgewählt wird, das Sie entfernen möchten, ohne dass Sie das Autoscaling für den gesamten Cluster deaktivieren müssen.

So entfernen Sie ein Subnetz:

Legen Sie für das nicht standardmäßige Subnetz den Status „Wird geleert“ fest. 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 „drain“ 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 funktionale Umgebung für 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

Hinweis

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

So wird ein Subnetz für Knotenpools ausgewählt

Subnetz beim Erstellen des Knotenpools manuell angeben

Pod-IPv4-Adressbereich zusammen mit dem Subnetz angeben

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