Subnetze zu Clustern hinzufügen

Auf dieser Seite wird beschrieben, 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 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, was ein erhebliches Clusterwachstum ermöglicht. 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, 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.

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.
• Die zusätzlichen Subnetze können nur von neuen Knotenpools verwendet werden, nicht von vorhandenen. Standardmäßig wählt GKE automatisch ein geeignetes Subnetz für den Knotenpool aus. Optional können Sie beim Erstellen eines Knotenpools manuell ein Subnetz angeben.
• Sekundäre IPv4-Adressbereiche von Subnetzen in einem nicht standardmäßigen Subnetz können nur von einem einzelnen Cluster 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 regionalen externen Passthrough-Network-Load-Balancer erstellen möchten, muss für neue externe LoadBalancer-Dienste das Feld spec.loadBalancerClass auf networking.gke.io/l4-regional-external festgelegt sein. 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 die 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 Knotengruppierung.

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

1. 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.

2. 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

1. Erstellen Sie ein neues Subnetz in derselben Region und im selben VPC-Netzwerk wie der Cluster. Legen Sie den primären IPv4-Adressbereich des Subnetzes auf einen zusätzlichen IPv4-Adressbereich für Knoten fest.

2. 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 hinzu.

3. 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: Führen Sie den folgenden Befehl aus, um die Details aller Subnetze aufzurufen, die einem Knotenpool zugeordnet 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

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. Dies geschieht basierend auf den Anforderungen für IP-Adressen und der Verfügbarkeit von IP-Adressen in allen Cluster-Subnetzen.

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 mit dem Flag --pod-ipv4-range und dem Flag --subnetwork angeben, 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 nicht standardmäßigen Subnetzes 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 können, 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 im Status „Wird geleert“ werden bei der Verwendung durch neu erstellte Knotenpools nicht berücksichtigt. So wird verhindert, dass bei Cluster Autoscaler-Vorgängen (z. B. Hochskalierung 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:

1. Setzen Sie das nicht standardmäßige Subnetz auf den Status „Drain“. Dadurch wird verhindert, dass neue Knotenpools dieses Subnetz auswählen. Das ist nützlich, wenn Sie Autoscaling für den Cluster aktivieren.
2. Löschen Sie alle Knotenpools, die dieses Subnetz verwenden.
3. 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 den Drain-Vorgang für ein nicht standardmäßiges Subnetz rückgängig zu machen:

   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, das Sie entleeren 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 eines Nicht-Standard-Subnetzes 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 Knotenpools 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 nicht standardmäßigen sekundären IPv4-Bereich eines Subnetzes 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 nicht standardmäßigen Subnetzes, 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 einer freigegebene VPC verwenden

Bevor Sie fortfahren, müssen folgende Voraussetzungen erfüllt sein:

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

1. 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
   

2. 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 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.

3. 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.

4. 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
   

5. Prüfen Sie die verwendbaren Subnetze und sekundären IP-Adressbereiche, wie unter shared vpc verify usable subnets beschrieben.

6. 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.

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