Einige oder alle Informationen auf dieser Seite gelten möglicherweise nicht für Cloud de Confiance von S3NS. Weitere Informationen finden Sie unter Unterschiede zu Google Cloud.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Subnetze zu Clustern hinzufügen

Autopilot Standard

Auf dieser Seite erfahren Sie, wie Sie einem VPC-nativer Cluster zusätzliche Subnetze zuweisen. Mit zusätzlichen Subnetzen, die einem Cluster 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 Cloud de Confiance by S3NS 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, wodurch ein erhebliches Clusterwachstum möglich ist. Jedes neu zugewiesene zusätzliche Subnetz wird als Nicht-Standardsubnetz 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 diese Aufgabe verwenden möchten, installieren und dann initialisieren Sie die gcloud CLI. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem gcloud components update Befehl ab. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.
Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI das Attribut compute/region 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.

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 pro 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.
Nur neue Knotenpools können die zusätzlichen Subnetze verwenden, nicht vorhandene Knotenpools. Standardmäßig wählt GKE automatisch ein geeignetes Subnetz für den Knotenpool aus. Sie können optional manuell ein Subnetz beim Erstellen eines Knotenpools angeben.
Sekundäre IPv4-Adressbereiche des Subnetzes in einem Nicht-Standardsubnetz können nur von einem einzelnen Cluster verwendet werden.
Wenn Sie die Unterstützung für mehrere 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 Konfiguration für mehrere Netzwerke konfiguriert sind. Zusätzliche Subnetze, die Sie konfigurieren, gelten nur für das Standardnetzwerk. Diese Einschränkung bedeutet, dass zusätzliche Netzwerkschnittstellen auf Ihren Knoten und Pods die IP-Adressen, die von diesen zusätzlichen Subnetzen bereitgestellt werden, nicht verwenden können.
Wenn Sie Clustern, in denen Cloud Service Mesh aktiviert ist, ein Subnetz hinzufügen, kann das Mesh keinen Traffic an Pods im Nicht-Standardsubnetz weiterleiten.

Anforderungen an den Load-Balancer 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 einen externen Ingress, ein externes Gateway oder einen externen LoadBalancer-Dienst erstellen.

Wenn Sie einen externen Ingress, ein externes Gateway oder einen externen LoadBalancer-Dienst in einem Cluster mit zusätzlichen Subnetzen verwenden möchten, muss auf Ihrem Cluster 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 verwenden.
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.
Um einen Backend-Dienst-basierten externen Passthrough-Network-Load-Balancer zu erstellen, müssen neue externe LoadBalancer-Dienste das Feld enthalten, das auf festgelegt ist.spec.loadBalancerClassnetworking.gke.io/l4-regional-external Dieses Feld 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 das Feld spec.loadBalancerClass erstellt wurden, und erstellen Sie sie neu. Für dieses Feld ist GKE-Version 1.33.1-gke.1779000 oder höher erforderlich.

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 Knoten gruppierung.

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-Netzwerk, 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-Subnetz bereiche.
- 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-Subnetz bereiche.
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: 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 im vorherigen Schritt erstellten Subnetz einen neuen sekundären IPv4-Adressbereich des Subnetzes hinzu.
Aktualisieren Sie Ihren Cluster, um das zusätzliche Subnetz mit der gcloud CLI zu verwenden. Im folgenden Beispiel wird ein Subnetz mit zwei sekundären IPv4-Adressbereichen des Subnetzes 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: 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: Führen Sie den folgenden Befehl aus, um die Details aller Subnetze aufzurufen, die mit einem Knotenpool verknüpft sind:

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

Wie Knotenpools ein Subnetz auswählen

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 Clustersubnetzen 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 Pod-IPv4-Bereich angeben, wählt GKE automatisch einen verfügbaren sekundären Bereich aus dem angegebenen Subnetz aus. Wenn das angegebene Subnetz oder der angegebene 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 ist die Region oder Zone des Clusters.
SUBNET_NAME ist der Name oder der vollständige Ressourcenpfad des Subnetzes, das Sie verwenden möchten.
POD_RANGE_NAME ist der Name des sekundären Bereichs des Subnetzes, der für Pods in diesem Knotenpool verwendet werden soll.

Nicht-Standardsubnetz entfernen

Wenn Sie ein Nicht-Standardsubnetz aus einem Cluster entfernen, wird der Cluster angewiesen, die Bereiche des Subnetzes in keinem der Knotenpools des Clusters mehr zu verwenden. Das Entfernen hat folgende Auswirkungen:

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

Bevor Sie ein Nicht-Standardsubnetz entfernen, müssen Sie alle Knotenpools löschen, die dieses Subnetz verwenden. Es wird empfohlen, das Subnetz zuerst in den Status „Wird geleert“ zu versetzen. Subnetze im Status „Wird geleert“ werden für die Verwendung durch neu erstellte Knotenpools nicht berücksichtigt. Dadurch wird verhindert, dass Cluster Autoscaler-Vorgänge (z. B. das vertikale Skalieren von Knotenpools) das Subnetz auswählen, das Sie entfernen möchten, ohne dass Sie die automatische Skalierung für den gesamten Cluster deaktivieren müssen.

So entfernen Sie ein Subnetz:

Setzen Sie das Nicht-Standardsubnetz in den Status „Wird geleert“. Dadurch wird verhindert, dass neue Knotenpools dieses Subnetz auswählen. Das ist nützlich, wenn Sie die automatische Skalierung im 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-Standardsubnetz 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-Standardsubnetzes auf „Wird geleert“ 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 in den Status „Wird geleert“ versetzen möchten.

Führen Sie den folgenden Befehl aus, um den Status eines Nicht-Standardsubnetzes auf „Wird geleert“ zu setzen:

   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 Status Sie auf „Wird geleert“ setzen möchten.

Nachdem Sie ein Nicht-Standardsubnetz aus dem Cluster entfernt haben, können Sie delete the non-default subnet.

Sekundären IPv4-Adressbereich eines Nicht-Standardsubnetzes entfernen

Wenn Sie einen sekundären IPv4-Adressbereich eines Nicht-Standardsubnetzes aus einem Cluster entfernen, weist GKE den Cluster an, diesen Bereich in keinem Knotenpool für Pod-IPv4-Bereiche zu verwenden. Wenn der sekundäre IPv4-Adressbereich des Nicht-Standardsubnetzes, den Sie entfernen, der einzige Bereich des Nicht-Standardsubnetzes 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-Adressbereich 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-Adressbereich eines Nicht-Standardsubnetzes 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: der Name des Clusters.
SUBNET_NAME: der Name des Nicht-Standardsubnetzes.
POD_RANGE_NAME: der Name des sekundären IPv4-Bereichs des Nicht-Standardsubnetzes, den Sie aus dem Cluster entfernen möchten.

Nachdem Sie einen sekundären IPv4-Adressbereich eines Nicht-Standardsubnetzes aus dem Cluster entfernt haben, können Sie ihn löschen.

Zusätzliche Subnetze in einer freigegebene VPC verwenden

Bevor Sie fortfahren, müssen Sie Folgendes haben:

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

Erstellen Sie im Hostprojekt ein zusätzliches Subnetz 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, führen Sie die folgenden Schritte aus. Wenn die Berechtigungen bereits vorhanden sind, ist keine Aktion erforderlich.
```
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.s3ns-system.iam.gserviceaccount.com
    - serviceAccount:service-SERVICE_PROJECT_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com
    role: roles/compute.networkUser
  etag: ETAG_STRING

Ersetzen Sie ETAG_STRING durch den zuvor notierten etag-Wert.

Legen Sie die IAM-Richtlinie für das ADDITIONAL_SUBNET_NAME Subnetz 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 Verwendbare Subnetze in einer gemeinsam genutzten VPC prüfen 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 Hostprojekt-ID.
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 freigegebene VPC-Umgebung verwenden.

Nächste Schritte

Mehr über VPC-native Cluster erfahren.
Weitere Informationen zum Hinzufügen von Pod-IPv4-Adressbereichen
Weitere Informationen zum Optimieren der IP-Adresszuweisung durch Konfigurieren der maximalen Anzahl von Pods pro Knoten.