Pod-IPv4-Adressbereiche hinzufügen

Autopilot Standard

Auf dieser Seite erfahren Sie, wie Sie zusätzliche Pod-IPv4-Adressbereiche für einen VPC-nativen Cluster konfigurieren und benutzerdefinierte Pod-IPv4-Adressbereiche für Knotenpools eines VPC-nativen Clusters angeben.

Pod-IPv4-Adressbereiche in VPC-nativen Clustern stammen immer aus sekundären IPv4-Adressbereichen des Subnetzes. Beim Erstellen eines neuen Clusters weisen Sie diesem einen Standard-Pod-IPv4-Adressbereich zu.

• Für Autopilot- und Standard-Cluster können Sie einen Cluster so konfigurieren, dass er zusätzliche Pod-IPv4-Adressbereiche verwendet. GKE verwendet diese zusätzlichen Pod-IPv4-Adressbereiche für Pod-IPv4-Adressen auf Knoten, die in zukünftigen Knotenpools erstellt werden.
• Für Standard-Cluster können Sie Knotenpools erstellen, die jeweils einen benutzerdefinierten sekundären IPv4-Adressbereich des Subnetzes für ihre Pod-IPv4-Adressen verwenden.

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.

• Sie benötigen die IAM-Rolle (Identity and Access Management) Compute-Netzwerkadministrator für das Projekt, zu dem das Subnetz des Clusters gehört. Dies ist erforderlich, um neue sekundäre IPv4-Adressbereiche für Subnetze zu erstellen. Wenn Sie eine freigegebene VPC verwenden, müssen Sie sich mit dem Netzwerkadministrator für das freigegebene VPC-Hostprojekt abstimmen.
• Standardmäßig sind alle neuen Cluster VPC-nativ. Wenn Sie einen neuen benötigen, erstellen Sie einen Autopilot-Cluster. Routenbasierte Cluster unterstützen weder zusätzliche Pod-IPv4-Adressbereiche noch benutzerdefinierte Pod-IPv4-Adressbereiche für Knotenpools.
• Lesen Sie den Abschnitt weiterführende Schritte.

Neuen sekundären Subnetz-IPv4-Adressbereich erstellen

Verwenden Sie zum Erstellen eines neuen sekundären IPv4-Adressbereichs eines Subnetzes dieGoogle Cloud Console oder die Google Cloud CLI. Jedes Subnetz unterstützt bis zu 170 sekundäre IPv4-Adressbereiche. Weitere Informationen finden Sie in der VPC-Dokumentation unter Sekundäre IPv4-Bereiche bearbeiten.

Console

1. Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.

   Zur Seite VPC-Netzwerke

2. Wählen Sie in der Liste VPC-Netzwerke das Netzwerk aus, das Sie erweitern möchten.

3. Wählen Sie in der Liste Subnetze das gewünschte Subnetz aus.

4. Klicken Sie auf Bearbeiten.

5. Klicken Sie auf IP-Bereich hinzufügen.

6. Geben Sie unter Name des Subnetzbereichs den Namen des neuen sekundären IPv4-Adressbereichs des Subnetzes ein. Beispiel: pod-range-2.

7. Geben Sie für Sekundärer IP-Bereich den IPv4-Adressbereich im CIDR-Format ein. Beispiel: 10.2.204.0/22.

8. Klicken Sie auf Speichern.

gcloud

gcloud compute networks subnets update SUBNET_NAME \
    --region=REGION \
    --secondary-range=POD_RANGE_NAME=SECONDARY_RANGE

Ersetzen Sie Folgendes:

• SUBNET_NAME – den Namen des Subnetzes des Clusters (das Subnetz, das dem Cluster bei seiner Erstellung zugewiesen wurde).
• REGION – die Region des Subnetzsubnetzes des Clusters. Die Region des Subnetzes des Clusters ist die Region, die den GKE-Cluster enthält.
• SECONDARY_RANGE_NAME – den Namen des neuen sekundären IPv4-Adressbereichs des Subnetzes, der als zusätzlicher Pod-IPv4-Adressbereich für den Cluster dient. Beispiel: pod-range-2.
• SECONDARY_RANGE_CIDR das CIDR, das vom neuen sekundären IPv4-Adressbereich des Subnetzes verwendet werden soll. Beispiel: 10.2.204.0/22.

Sie können zwei oder mehr neue sekundäre Subnetz-IPv4-Adressbereiche hinzufügen. Geben Sie dazu nach dem Flag --add-secondary-ranges zusätzliche, durch Kommas getrennte SECONDARY_RANGE_NAME=SECONDARY_RANGE_CIDR-Paare an.

Einem Cluster zusätzliche Pod-IPv4-Bereiche zuweisen

Sie können zusätzliche Pod-IPv4-Adressbereiche auf Clusterebene zuweisen, die für neue Knoten gelten, die in neuen Knotenpools erstellt werden, die Sie im Cluster erstellen. Wenn Sie einem Cluster zusätzliche Pod-IPv4-Adressbereiche zuweisen möchten, müssen Sie zuerst einen neuen sekundären Subnetz-IPv4-Adressbereich erstellen.

Das Zuweisen zusätzlicher Pod-IPv4-Adressbereiche zu einem Cluster wird unterstützt von:

• Autopilot-Cluster mit GKE-Version 1.26 und höher

• Standardcluster

Console

1. Öffnen Sie in der Google Cloud Console die Seite Google Kubernetes Engine.

   Zur Seite "Google Kubernetes Engine"

2. Klicken Sie neben dem Cluster, den Sie bearbeiten möchten, auf Aktionen und dann auf Bearbeiten.

3. Klicken Sie im Abschnitt Netzwerk neben Pod-IPv4-Bereiche des Clusters (zusätzliche) auf Bearbeiten.

4. Klicken Sie im Dialogfeld Zusätzliche IPv4-Bereiche für Cluster-Pods bearbeiten auf Sekundäre Pod-CIDR-Bereiche und wählen Sie die Namen eines oder mehrerer vorhandener sekundärer Subnetz-IPv4-Adressbereichen im Subnetz des Clusters. Wenn keine zusätzlichen sekundären IPv4-Adressbereiche des Subnetzes verfügbar sind, erstellen Sie zuerst einen neuen sekundären Subnetze-IPv4-Adressbereich und wiederholen diese Schritte.

5. Klicken Sie auf Änderungen speichern.

gcloud

1. Aktualisieren Sie Ihren Cluster mit dem Flag --additional-pod-ipv4-ranges:

   gcloud container clusters update CLUSTER_NAME \
       --additional-pod-ipv4-ranges=SECONDARY_RANGE_NAME \
       --location=COMPUTE_LOCATION
   

   Ersetzen Sie Folgendes:

   • CLUSTER_NAME: Der Name des Clusters.
   • SECONDARY_RANGE_NAME: Der Name eines oder mehrerer vorhandener sekundärer Subnetz-IPv4-Adressbereiche im Subnetz des Clusters, durch Kommas getrennt. Wenn keine sekundären Subnetze-IPv4-Adressbereiche verfügbar sind, erstellen Sie zuerst einen neuen sekundären Subnetze-IPv4-Adressbereich.
   • COMPUTE_LOCATION: der Compute Engine-Standort für den Cluster.

Pod-IPv4-Bereiche des Clusters anzeigen

Mit dem folgenden Befehl können Sie den standardmäßigen Pod-IPv4-Adressbereich eines Clusters und alle zusätzlichen Pod-IPv4-Adressbereiche, die dem Cluster zugewiesen wurden, aufrufen:

gcloud container clusters describe CLUSTER_NAME \
    --location=COMPUTE_LOCATION

Ersetzen Sie Folgendes:

• CLUSTER_NAME ist der Name des Clusters.
• COMPUTE_LOCATION: der Compute Engine-Standort für den Cluster.

Die Ausgabe sieht etwa so aus und enthält die IPAllocationPolicy des Clusters:

ipAllocationPolicy:
  clusterSecondaryRangeName: cluster-pods
  clusterIpv4CidrBlock: 10.10.0.0/23
  additionalPodRangesConfig:
    podRangeNames:
      - pod-range-1
      - pod-range-2

Dabei gilt:

• clusterSecondaryRangeName: Der Name des sekundären IPv4-Adressbereichs des Subnetzes, der als Standard-Pod-IPv4-Adressbereich des Clusters verwendet und beim Erstellen des Clusters definiert wurde.
• clusterIpv4CidrBlock: Der CIDR des sekundären IPv4-Adressbereichs des Subnetzes für Pod-IPv4-Adressen, der beim Erstellen des Clusters definiert wurde.
• additionalPodRangesConfig.podRangeNames: Eine Liste aller zusätzlich zugewiesenen sekundären IPv4-Adressbereiche des Subnetzes für Pod-IPv4-Adressen.

Hinweis :Die ipAllocationPolicy-Ausgabe enthält auch das verworfene Attribut clusterIpv4Cidr. Verweisen Sie stattdessen auf das Attribut clusterIpv4CidrBlock in der Ausgabe.

Benutzerdefinierte Pod-IPv4-Adressbereiche für Knotenpools

Bei Standardclustern mit GKE 1.20.4-gke.500 oder höher können Sie neuen Knotenpools mit einer der folgenden Methoden einen benutzerdefinierten Pod-IPv4-Bereich zuweisen:

• Benutzerdefinierter Pod-IPv4-Adressbereich des Knotenpools, von GKE verwaltet: Mit dieser Option erstellen Sie einen neuen Knotenpool und senden GKE die erforderlichen Informationen zum Erstellen eines neuen sekundären IPv4-Adressbereich im Subnetz des Clusters. Jedem neuen, im neuen Knotenpool erstellten Knoten wird ein Alias-IP-Adressbereich für dessen Pod-IPv4-Adressen zugewiesen. Dabei stammt jeder Alias-IP-Adressbereich aus dem neuen sekundären IPv4-Adressbereich des Subnetzes, den GKE erstellt. Diese Option kann nur verwendet werden, wenn sich sowohl der Cluster als auch das VPC-Netzwerk, das das Subnetz des Clusters enthält, im selben Projekt befinden.

• Benutzerdefinierter Pod-IPv4-Adressbereich des vom Nutzer verwalteten Knotenpools: Mit dieser Option erstellen Sie einen neuen Knotenpool, in dem GKE einen vorhandenen sekundären IPv4-Adressbereich des Subnetzes verwendet. Jedem im neuen Knotenpool erstellten neuen Knoten wird ein Alias-IP-Adressbereich für dessen Pod-IPv4-Adressen zugewiesen. Dabei stammt jeder Alias-IP-Adressbereich aus dem sekundären Subnetzes-IPv4-Adressbereich, den GKE laut Ihren Anweisungen verwenden soll. Wenn sich Ihr Cluster in einem Dienstprojekt mit freigegebener VPC befindet und das Subnetz Ihres Clusters im freigegebene VPC-Netzwerk des Hostprojekts liegt, müssen Sie diese Option verwenden.

Der benutzerdefinierte Pod-IPv4-Adressbereich eines Knotenpools überschreibt alle Pod-IPv4-Adressbereiche, die auf Clusterebene definiert sind, einschließlich zusätzlicher, dem Cluster zugewiesener Pod-IPv4-Adressbereiche. Benutzerdefinierte Pod-IPv4-Adressbereiche, die Knotenpools zugewiesen sind, werden auch als nicht zusammenhängende Multi-Pod-CIDRs bezeichnet.

Beispiel: Benutzerdefinierter Pod-IPv4-Adressbereich für Knotenpools

Das folgende Diagramm zeigt einen VPC-nativer Cluster mit nutzerverwalteten Pod-IPv4-Adressbereichen:

Diagramm : Beispiel für benutzerdefinierten Pod-IPv4-Adressbereich für Knotenpools

Im vorherigen Diagramm gilt:

• Die maximale Anzahl von Pods pro Knoten für jeden Knotenpool im Cluster wurde auf 64 festgelegt. Zur Unterstützung von maximal 64 Pods pro Knoten erstellt GKE jeden Knoten mit einem /25-Alias-IP-Adressbereich und stellt 128 Pod-IPv4-Adressen pro Knoten bereit.
• Der Standard-Pod-IPv4-Adressbereich des Clusters ist ein /24. Da jeder Knoten ein /25 für Pod-IPv4-Adressen benötigt, unterstützt der standardmäßige Pod-IPv4-Adressbereich des Clusters nur zwei Knoten.
• Zur Unterstützung zusätzlicher Knoten hat ein Clusteradministrator einen zusätzlichen Knotenpool erstellt, wobei die maximale Anzahl von 64 Pods pro Knoten beibehalten wurde. Der zusätzliche Knotenpool verwendet einen benutzerdefinierten /20-Pod-IPv4-Adressbereich, der 32 zusätzliche Knoten unterstützt.

GKE-verwalteter benutzerdefinierter Pod-IPv4-Adressbereich des Knotenpools

Verwenden Sie zum Erstellen eines Knotenpools mit einem von GKE verwalteten benutzerdefinierten Pod-IPv4-Adressbereich die gcloud CLI oder die GKE API:

gcloud

gcloud container node-pools create POOL_NAME \
  --cluster=CLUSTER_NAME \
  --location=COMPUTE_LOCATION \
  --create-pod-ipv4-range=name=SECONDARY_RANGE_NAME,range=CIDR_OR_NETMASK

Ersetzen Sie Folgendes:

• POOL_NAME: Der Name des neuen Knotenpools.
• CLUSTER_NAME ist der Name des Clusters.
• COMPUTE_LOCATION: der Compute Engine-Standort für den Cluster.
• SECONDARY_RANGE_NAME: Der Name des sekundären IPv4-Adressbereichs des Subnetzes, den GKE erstellt. Wenn Sie name=SECONDARY_RANGE_NAME weglassen, generiert GKE den Namen des neuen sekundären IPv4-Adressbereichs des Subnetzes automatisch.
• CIDR_OR_NETMASK: Der Pod-IPv4-Adressbereich, entweder im CIDR-Format (z. B. 10.12.4.0/20) oder als Subnetzmaske (z. B. /20) angegeben.
  • Wenn Sie nur eine Subnetzmaske angeben, versucht GKE, einen neuen sekundären Subnetz-IPv4-Adressbereich zu erstellen, der nicht mit vorhandenen Subnetz-IPv4-Adressbereichen in dem VPC-Netzwerk in Konflikt steht, welches das Subnetz des Clusters enthält.
  • Wenn Sie range=CIDR_OR_NETMASK weglassen, versucht GKE, einen neuen sekundären Subnetz-IPv4-Adressbereich /14 zu erstellen, der nicht mit vorhandenen Subnetz-IPv4-Adressbereichen im VPC-Netzwerk in Konflikt steht, welches das Subnetz des Clusters enthält.

Hinweis :Sie können "" als Wert für das Flag --create-pod-ipv4-range verwenden. In diesem Fall versucht GKE, einen neuen sekundären Subnetz-IPv4-Adressbereich /14 zu erstellen, der nicht mit vorhandenen Subnetz-IPv4-Adressbereichen in dem VPC-Netzwerk in Konflikt steht, welches das Subnetz des Clusters enthält. GKE generiert den Namen des neuen sekundären IPv4-Adressbereichs des Subnetzes automatisch. Weitere Informationen finden Sie in der Dokumentation zu gcloud container node-pools create.

API

"nodePool": {
  "name": "POOL_NAME",
  ...
  "networkConfig": {
    "createPodRange": true,
    "podRange": "SECONDARY_RANGE_NAME",
    "podIpv4CidrBlock": "CIDR_OR_NETMASK"
    }
}

Ersetzen Sie Folgendes:

• POOL_NAME: Der Name des neuen Knotenpools.
• SECONDARY_RANGE_NAME: (Optional) Der Name des sekundären IPv4-Adressbereichs des Subnetzes, den GKE erstellt. Wenn Sie "" als Wert für networkConfig.podRange verwenden oder den Parameter podRange in der Anfrage weglassen, generiert GKE den Namen des neuen sekundären IPv4-Adressbereichs des Subnetzes automatisch.
• CIDR_OR_NETMASK: Der Pod-IPv4-Adressbereich, entweder im CIDR-Format (z. B. 10.12.4.0/20) oder als Subnetzmaske (z. B. /20) angegeben.
  • Wenn Sie nur eine Subnetzmaske angeben, versucht GKE, einen neuen sekundären Subnetz-IPv4-Adressbereich zu erstellen, der nicht mit vorhandenen Subnetz-IPv4-Adressbereichen in dem VPC-Netzwerk in Konflikt steht, welches das Subnetz des Clusters enthält.
  • Wenn Sie "" als Wert für networkConfig.podIpv4CidrBlock verwenden, versucht GKE, einen neuen sekundären Subnetz-IPv4-Adressbereich /14 zu erstellen, der nicht mit vorhandenen Subnetz-IPv4-Adressbereichen im VPC-Netzwerk, welches das Subnetz des Clusters enthält, in Konflikt steht.

Vom Nutzer verwalteter benutzerdefinierter Pod-IPv4-Adressbereich des Knotenpools

Verwenden Sie zum Erstellen eines Knotenpools mit einem vom Nutzer verwalteten benutzerdefinierten Pod-IPv4-Adressbereich die gcloud CLI oder die GKE API:

gcloud

gcloud container node-pools create POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --pod-ipv4-range SECONDARY_RANGE_NAME

Ersetzen Sie Folgendes:

• POOL_NAME: Der Name des neuen Knotenpools.
• CLUSTER_NAME ist der Name des Clusters.
• COMPUTE_LOCATION: der Compute Engine-Standort für den Cluster.
• SECONDARY_RANGE_NAME: Der Name eines vorhandenen sekundären Subnetz-IPv4-Adressbereichs im Subnetz des Clusters. Erstellen Sie bei Bedarf zuerst einen neuen sekundären Subnetz-IPv4-Adressbereich.

API

"nodePool": {
  "name": "POOL_NAME",
  ...
  "networkConfig": {
    "createPodRange": false,
    "podRange": "SECONDARY_RANGE_NAME"
    }
}

Ersetzen Sie Folgendes:

• POOL_NAME: Der Name des neuen Knotenpools.
• SECONDARY_RANGE_NAME: Der Name eines vorhandenen sekundären Subnetz-IPv4-Adressbereichs im Subnetz des Clusters. Erstellen Sie bei Bedarf zuerst einen neuen sekundären Subnetz-IPv4-Adressbereich.

Pod-IPv4-Bereiche von Knotenpools anzeigen

Verwenden Sie den folgenden Befehl, um den Pod-IPv4-Adressbereich eines Knotenpools aufzurufen:

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

Ersetzen Sie Folgendes:

• POOL_NAME: Der Name des Knotenpools.
• CLUSTER_NAME ist der Name des Clusters.
• COMPUTE_LOCATION: der Compute Engine-Standort für den Cluster.

Die Ausgabe sieht etwa so aus und enthält die NodeNetworkConfig des Knotenpools:

  networkConfig:
    podRange: podrange
    podIpv4CidrBlock: 192.168.0.0/18

Dabei gilt:

• podRange: Der Name des sekundären IPv4-Adressbereichs des Subnetzes für die Pod-IPv4-Adressen des Knotenpools.
• podIpv4CidrBlock: Der CIDR des sekundären IPv4-Adressbereichs des Subnetzes für die Pod-IPv4-Adressen des Knotenpools.

Wenn der Knotenpool einen benutzerdefinierten Pod-IPv4-Adressbereich verwendet, unterscheiden sich die Werte podRange und podIpv4CidrBlock vom standardmäßigen Pod-IPv4-Adressbereich des Clusters.

Weitere Schritte

Nachdem Sie einem Cluster zusätzliche Pod-IPv4-Adressbereiche zugewiesen oder benutzerdefinierte Pod-IPv4-Adressbereiche für Knotenpools konfiguriert haben, aktualisiert GKE die automatisch erstellte VPC-Firewallregel gke-[cluster-name]-[cluster-hash]-all, damit der Quellbereich alle Pod-IPv4-Adressen enthält.

Möglicherweise müssen Sie auch Folgendes tun:

• Aktualisieren Sie die Konfiguration des IP-Masquerading-Agents Ihres Clusters. Der effektive Satz von CIDRs ohne Maskierung muss alle Pod-IPv4-Adressbereiche enthalten, die von Ihrem Cluster (und dessen Knotenpools) verwendet werden. Weitere Informationen finden Sie unter ip-masq-agent-Status prüfen und ip-masq-agent konfigurieren und bereitstellen.

• Überprüfen Sie die NetworkPolicy-Konfiguration Ihres Clusters. Möglicherweise müssen Sie ipBlock-Attribute aktualisieren, die auf IPv4-Adressbereiche von Pods verweisen.

• Verbindungsfehler mithilfe von VPC-Flusslogs und Firewall-Regelprotokollen beheben.

Nächste Schritte

• Mehr über VPC-native Cluster erfahren
• GKE-Netzwerk –Übersicht
• Weitere Informationen zu IP-Adresszuweisung optimieren
• Informationen zu Statistiken zur GKE-IP-Adressauslastung