Subnetze zu Clustern hinzufügen

Auf dieser Seite erfahren Sie, wie Sie einem VPC-nativen 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 Enterprise-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 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 gcloud components update ab.

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 verfügbar sind, die nicht dem Standard entsprechen, 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.
  • Sekundäre IPv4-Adressbereiche des Subnetzes 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 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.

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

  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 \
     --add-secondary-ranges=POD_RANGE_NAME=SECONDARY_RANGE

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

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

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

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

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.

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.

Nachdem Sie ein nicht standardmäßiges Subnetz aus dem Cluster entfernt haben, können Sie es 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 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.

Nächste Schritte