Pod-IP-Adressbereiche hinzufügen

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Auf dieser Seite wird beschrieben, wie Sie in zusammenhängenden VPC-Clustern (GKE) den Multi-Pod-CIDR aktivieren.

Übersicht

Mit dem zusammenhängenden Multi-Pod-CIDR können Sie den GKE-Clustern neue oder vorhandene sekundäre Pod-IP-Adressbereiche hinzufügen.

Wenn Sie einen neuen Knotenpool erstellen, verwendet der Knotenpool standardmäßig den Standard-Pod-IP-Adressbereich des Clusters, der als Cluster-CIDR bezeichnet wird. Mit dieser Funktion können Sie beim Erstellen des Knotenpools einen Pod-IP-Adressbereich angeben, der dann anstelle des Standard-Pod-IP-Adressbereichs des Clusters verwendet wird.

Das folgende Diagramm zeigt einen nutzerverwalteten Cluster mit einem /24-CIDR-Block als sekundären Pod-IP-Adressbereich (256 IP-Adressen) und zwei Knoten, die /25-CIDR-Blöcke für Pod-IP-Adressen (jeweils 128 IP-Adressen) verwenden. Der sekundäre Pod-IP-Adressbereich ist ausgeschöpft und Sie können dem Cluster keinen weiteren Knoten hinzufügen. Anstatt den Cluster zu löschen und neu zu erstellen, können Sie einen nicht zusammenhängenden Multi-Pod-CIDR-Bereich verwenden, um einen Knotenpool zu erstellen. Der Cluster wird um einen dritten Knoten erweitert, der einen /28-CIDR-Block für Pod-IP-Adressen verwendet.

Knotenpool zu einem Cluster mit einem aufgebrauchten sekundären Pod-IP-Adressbereich mithilfe eines nicht zusammenhängenden Multi-Pod-CIDR hinzufügen
Diagramm: Nicht zusammenhängende Multi-Pod-CIDR-Bereich verwenden

Vorteile

  • Sie müssen kein künftiges Wachstum planen, bevor Sie Cluster erstellen. Das führt zu einer effizienteren IP-Zuordnung.
  • Sie können Cluster in fragmentierte IP-Adressbereiche umwandeln.
  • Sie können IP-Adressen entsprechend den sich ändernden Geschäftsanforderungen neu zuweisen.

Beschränkungen

  • Ein zusammenhängendes Multi-Pod-CIDR ist nur in VPC-nativen Clustern verfügbar.
  • Alle Knotenpools im Cluster müssen die Versionen 1.19.8-gke.1000 bis 1.20 oder 1.20.4-gke.500 und höher haben.
  • Für ein zusammenhängendes Multi-Pod-CIDR ist die Google Cloud CLI Version 353 oder höher erforderlich.
  • Der sekundäre Pod-IP-Bereich eines Knotenpools kann nach dem Erstellen nicht mehr geändert werden. Sie können jedoch einen Knotenpool mit einem neuen Bereich erstellen und Arbeitslasten auf den neuen Knotenpool rotieren.

Vorsichtsmaßnahmen

  • Wenn Sie ip-masq-agent mit dem Parameter nonMasqueradeCIDRs verwenden, müssen Sie nonMasqueradeCIDRs so aktualisieren, dass alle Pod-CIDR-Bereiche enthalten sind.
  • Wenn Sie mit ipBlock eine NetworkPolicy konfigurieren, um Traffic anzugeben, müssen Sie den Wert cidr aktualisieren, um alle Pod-CIDR-Bereiche einzuschließen.

Geänderte Firewallregel

Wenn GKE einen Cluster erstellt, wird eine Firewallregel erstellt, um die Pod-zu-Pod-Kommunikation gke-[cluster-name]-[cluster-hash]-all zu aktivieren.

Wenn Sie einen Knotenpool erstellen und löschen, wobei der CIDR-Wert für mehrere Pods gleichzeitig aktiviert ist, aktualisiert GKE den Quellwert dieser Firewallregel auf alle CIDRs, die vom Cluster für Pod-IPs verwendet werden.

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.

Knotenpool mit einem neuen sekundären IP-Bereich erstellen

In diesem Abschnitt erstellen Sie einen Knotenpool mit einem sekundären Pod-IP-Adressbereich.

Sie können dazu das Google Cloud CLI oder die GKE API verwenden.

gcloud

gcloud container node-pools create POOL_NAME \
  --cluster CLUSTER_NAME \
  --create-pod-ipv4-range name=RANGE_NAME,range=RANGE

Dabei gilt:

  • POOL_NAME: der Name des neuen Knotenpools.
  • CLUSTER_NAME: der Name des Clusters.
  • RANGE_NAME: ein optionaler Name des neuen sekundären Pod-IP-Adressbereichs.
  • RANGE: ein optionaler Pod-IP-Adressbereich, der entweder als Netzmaske (/20) oder als CIDR-Bereich (10.12.4.0/20) angegeben wird. Wenn Sie eine Netzmaske angeben, weist GKE einen Bereich aus den verfügbaren Bereichen im Clusternetzwerk zu. Wenn Sie keinen Wert für range angeben, weist GKE automatisch eine Netzmaske vom Typ /14 zu, die Standardgröße für den sekundären IP-Bereich des Subnetzes für Pods des Subnetzes.

API

"nodePool": {
  "name": "POOL_NAME",
  ...
  "networkConfig": {
    "createPodRange": true,
    "podRange": "RANGE_NAME",
    "podIpv4CidrBlock": "RANGE"
  }
}

Dabei gilt:

  • POOL_NAME: der Name des neuen Knotenpools.
  • RANGE_NAME: ein optionaler Name des neuen sekundären Pod-IP-Adressbereichs.
  • RANGE ist ein optionaler Pod-IP-Adressbereich, der entweder als Netzmaske (/20) oder als CIDR-Bereich (10.12.0.0/20) bereitgestellt wird. Wenn eine Netzmaske angegeben ist, wird der IP-Bereich automatisch aus dem freien Bereich im Netzwerk des Clusters zugewiesen. Wenn kein Wert angegeben ist, weist GKE automatisch eine /14-Netzmaske zu. Dies ist die Standardgröße für den sekundären IP-Bereich des Subnetzes für Pods.

Knotenpool mit einem vorhandenen sekundären Pod-IP-Bereich erstellen

In diesem Abschnitt erstellen Sie einen Knotenpool mit einem vorhandenen sekundären Pod-IP-Adressbereich.

Sie können die gcloud CLI oder die GKE API verwenden.

gcloud

gcloud container node-pools create POOL_NAME \
  --cluster CLUSTER_NAME \
  --pod-ipv4-range RANGE_NAME

Dabei gilt:

  • POOL_NAME: der Name des neuen Knotenpools.
  • CLUSTER_NAME: der Name des Clusters.
  • RANGE_NAME: der Name eines vorhandenen sekundären Pod-IP-Adressbereichs im Subnetzwerk des Clusters.

API

"nodePool": {
  "name": "POOL_NAME",
  ...
  "networkConfig": {
    "podRange": "RANGE_NAME"
  }
}

Dabei gilt:

  • POOL_NAME: der Name des neuen Knotenpools.
  • RANGE_NAME: der Name eines vorhandenen sekundären Pod-IP-Adressbereichs im Subnetzwerk des Clusters.

Pod-CIDR-Block für einen Knotenpool überprüfen

Mit dem folgenden Befehl können Sie ermitteln, welcher Pod-CIDR-Block für Pods in einem bestimmten Knotenpool verwendet wird:

gcloud container node-pools describe POOL_NAME \
  --cluster CLUSTER_NAME

Die Ausgabe sieht etwa so aus:

...
networkConfig:
  podIpv4CidrBlock: 192.168.0.0/18
  podRange: podrange
...

Wenn der Knotenpool nicht zusammenhängende Multi-Pod-CIDRs verwendet, zeigen podRange und podIpv4CidrBlock die konfigurierten Werte für diesen Knotenpool an.

Wenn der Knotenpool nicht zusammenhängende Multi-Pod-CIDRs verwendet, zeigen podRange und podIpv4CidrBlock die Standardwerte des Clusters clusterSecondaryRangeName und clusterIpv4CidrBlock von IPAllocationPolicy an.

Fehlerbehebung

Sie können VPC-Flusslogs aktivieren, um festzustellen, ob Pakete an Knoten gesendet werden.

Nächste Schritte