VPC-native Cluster

Autopilot Standard

Diese Seite bietet eine allgemeine Übersicht über VPC-native Cluster in Google Kubernetes Engine (GKE).

Übersicht

In GKE lassen sich Cluster anhand der Methode unterscheiden, mit der sie Traffic von einem Pod zu einem anderen weiterleiten.

Ein Cluster, der Alias-IP-Adressbereiche verwendet, wird als VPC-nativer Cluster bezeichnet.

Ein Cluster, der benutzerdefinierte statische Routen in einem VPC-Netzwerk verwendet, wird als routenbasierter Cluster bezeichnet.

Vorteile von VPC-nativen Clustern

VPC-native Cluster haben mehrere Vorteile:

Pod-IP-Adressen sind nativ routingfähig im VPC-Netzwerk des Clusters und in anderen VPC-Netzwerken, die per VPC-Netzwerk-Peering damit verbunden sind.
Pod-IP-Adressen werden im VPC-Netzwerk reserviert, bevor die Pods in Ihrem Cluster erstellt werden. Das verhindert Konflikte mit anderen Ressourcen im VPC-Netzwerk und ermöglicht es, die Zuweisung von IP-Adressen besser zu planen.
Pod-IP-Adressbereiche sind nicht von benutzerdefinierten statischen Routen abhängig. Sie verbrauchen nicht das vom System erzeugte und benutzerdefinierte Kontingent für statische Routen. Stattdessen werden für das Routing von VPC-nativen Clustern automatisch erzeugte Subnetzrouten verwendet.
Sie können Firewallregeln erstellen, die nur auf Pod-IP-Adressbereiche angewendet werden, statt auf IP-Adressen auf den Knoten des Clusters.
Pod-IP-Adressbereiche und sekundäre Subnetz-IP-Adressbereiche sind im Allgemeinen über lokale Netzwerke zugänglich, die über Cloud Router mit Cloud VPN oder Cloud Interconnect verbunden sind.
Einige Funktionen, z. B. Netzwerk-Endpunktgruppen (NEGs), funktionieren nur mit VPC-nativen Clustern.

Standard-Cluster-Netzwerkmodus

VPC-nativ ist der Standard-Netzwerkmodus für alle Cluster in den GKE-Versionen 1.21.0-gke.1500 und höher. Der älteren Versionen hängt der Standard-Cluster-Netzwerkmodus davon ab, wie Sie den Cluster erstellen.

In der folgenden Tabelle ist der Standardmodus für das Clusternetzwerk für GKE-Clusterversionen und Methoden zur Clustererstellung aufgeführt.

GKE-Versionen	Methode der Clustererstellung	Cluster-Netzwerkmodus
Alle Versionen	Die Google Cloud Console	VPC-nativ
1.21.0-gke.1500 und höher	Kubernetes Engine API oder Google Cloud CLI	VPC-nativ

Sie können auch einen routenbasierten Cluster erstellen. Geben Sie dazu beim Erstellen des Clusters das Flag --no-enable-ip-alias an.

IP-Adressbereiche für VPC-native Cluster

Beim Erstellen eines VPC-nativen Clusters legen Sie ein Subnetz in einem VPC-Netzwerk fest. Der Cluster verwendet die folgenden Subnetz-IP-Adressbereiche:

IPv4-Adresszuweisung

VPC-native Cluster weisen IPv4-Adressen für Knoten, Pods und Services mithilfe unterschiedlicher Bereiche innerhalb des angegebenen Subnetzes so zu.

Knoten-IP-Adressen: Der Cluster verwendet den primären IPv4-Adressbereich des Subnetzes, um allen Knoten IP-Adressen zuzuweisen.
Pod-IP-Adressen: Der Cluster verwendet den sekundären IPv4-Adressbereich im Subnetz für alle Pod-IPv4-Adressen im Cluster. Für mehr Flexibilität können Sie zusätzliche sekundäre IPv4-Adressbereiche des Subnetzes verwenden. Konfigurieren Sie dazu nicht zusammenhängende Multi-Pod-CIDRs.
Dienst-IP-Adressen: Der Cluster verwendet einen separaten sekundären IP-Adressbereich für alle Dienst-Adressen (Cluster-IP-Adressen). Informationen zum Aktivieren mehrerer Cluster für die gemeinsame Nutzung desselben IPv4-Dienstbereichs finden Sie unter IP-Adressbereiche für GKE-Cluster freigeben.

IPv6-Adresszuweisung (Dual-Stack-Netzwerk)

Knoten- und Pod-IPv6-Adressen: In Clustern, die für Dual-Stack-Netzwerke aktiviert sind, stammen die IPv6-Adresse des Knotens und alle Pod-IPv6-Adressen aus dem designierten IPv6-Adressbereich /96 des Knotens. Die Knoten-IP-Adresse selbst ist die erste /128 (einzelne IPv6-Adresse) in diesem Bereich. Weitere Informationen finden Sie unter Dual-Stack-Netzwerke.

Die folgende Tabelle enthält eine Zusammenfassung der IP-Adressbereiche für Knoten, Pods und Services:

Bereich Erklärung Beispiel

Knoten

Bereich	Erklärung	Beispiel
Knoten	Knoten-IP-Adressen werden über den primären IP-Adressbereich des mit Ihrem Cluster verbundenen Subnetzes zugewiesen. Die Anzahl der Knoten, die ein Cluster unterstützen kann, wird sowohl vom Knoten-IP-Adressbereich als auch von der Größe des sekundären IP-Adressbereichs des Subnetzes für Pods begrenzt. Weitere Informationen finden Sie unter Knotenbegrenzungsbereiche.	Wenn Sie einen Cluster mit 900 Knoten erstellen möchten, muss der primäre IP-Adressbereich des Clustersubnetzes mindestens `/22` sein (2^(32-22) = 2¹⁰ = 1.024 Adressen). Von diesen 1.024 Adressen sind 1.020 nutzbar, da 4 IP-Adressen in jedem primären IP-Adressbereich reserviert sind. Weitere Informationen finden Sie unter Primärer IP-Adressbereich des Subnetzes und Sekundärer IP-Adressbereich des Subnetzes für Pods.
Pods	Pod-IP-Adressen werden aus dem sekundären IP-Adressbereich des Clustersubnetzes für Pods entnommen. Wenn Sie keine andere Höchstzahl von Pods pro Knoten festlegen, weist GKE jedem Knoten einen Alias-IP-Adressbereich von `/24` (256 Adressen) für die darauf ausgeführten Pods zu. Auf jedem Knoten werden diese 256 Alias-IP-Adressen zur Unterstützung von bis zu 110 Pods verwendet.	Für einen Cluster mit 900 Knoten, der bis zu 110 Pods pro Knoten unterstützt, benötigen Sie 900 × 256 = 230.400 IP-Adressen für Pods. Jedem Knoten wird ein Alias-IP-Bereich zugewiesen, dessen Netzmaske die Größe /24 hat. Für diesen Cluster ist ein Subnetz erforderlich, dessen sekundärer IP-Bereich für Pods eine Subnetzmaske mit einer maximalen Größe von /14 hat. Dieser sekundäre IP-Bereich umfasst 2^(32-14) = 2¹⁸ = 262.144 IP-Adressen für Pods. Weitere Informationen finden Sie unter Sekundärer IP-Adressbereich des Subnetzes für Pods.
Dienste	Dienstadressen (ClusterIP) werden aus dem sekundären IP-Adressbereich des Clusters für Dienste übernommen. Dieser Bereich muss groß genug sein, um Adressen für alle Kubernetes-Dienste bereitzustellen, die Sie in Ihrem Cluster hosten. In GKE Autopilot-Clustern mit Version 1.27 und höher und GKE-Standardclustern mit Version 1.29 und höher weist GKE IP-Adressen für GKE-Dienste aus einem von GKE verwalteten Bereich zu: `34.118.224.0/20` ist dabei Standard. Auf diese Weise müssen Sie keinen eigenen IP-Adressbereich für Services angeben. Weitere Informationen finden Sie unter Sekundärer IP-Adressbereich des Subnetzes für Services.	Für einen Cluster mit bis zu 3.000 Diensten benötigen Sie 3.000 Cluster-IP-Adressen. Dafür benötigen Sie einen sekundären Bereich mit einer Größe von /20 oder größer. Ein IP-Adressbereich von /20 ergibt 2^(32-20) = 2¹² = 4.096 IP-Adressen. Weitere Informationen finden Sie unter Sekundärer IP-Adressbereich des Subnetzes für Dienste.

Knoten-IP-Adressen werden über den primären IP-Adressbereich des mit Ihrem Cluster verbundenen Subnetzes zugewiesen.

Die Anzahl der Knoten, die ein Cluster unterstützen kann, wird sowohl vom Knoten-IP-Adressbereich als auch von der Größe des sekundären IP-Adressbereichs des Subnetzes für Pods begrenzt. Weitere Informationen finden Sie unter Knotenbegrenzungsbereiche.

Wenn Sie einen Cluster mit 900 Knoten erstellen möchten, muss der primäre IP-Adressbereich des Clustersubnetzes mindestens /22 sein (2^(32-22) = 2¹⁰ = 1.024 Adressen). Von diesen 1.024 Adressen sind 1.020 nutzbar, da 4 IP-Adressen in jedem primären IP-Adressbereich reserviert sind.

Weitere Informationen finden Sie unter Primärer IP-Adressbereich des Subnetzes und Sekundärer IP-Adressbereich des Subnetzes für Pods.

Pods

Pod-IP-Adressen werden aus dem sekundären IP-Adressbereich des Clustersubnetzes für Pods entnommen. Wenn Sie keine andere Höchstzahl von Pods pro Knoten festlegen, weist GKE jedem Knoten einen Alias-IP-Adressbereich von /24 (256 Adressen) für die darauf ausgeführten Pods zu. Auf jedem Knoten werden diese 256 Alias-IP-Adressen zur Unterstützung von bis zu 110 Pods verwendet.

Für einen Cluster mit 900 Knoten, der bis zu 110 Pods pro Knoten unterstützt, benötigen Sie 900 × 256 = 230.400 IP-Adressen für Pods. Jedem Knoten wird ein Alias-IP-Bereich zugewiesen, dessen Netzmaske die Größe /24 hat. Für diesen Cluster ist ein Subnetz erforderlich, dessen sekundärer IP-Bereich für Pods eine Subnetzmaske mit einer maximalen Größe von /14 hat. Dieser sekundäre IP-Bereich umfasst 2^(32-14) = 2¹⁸ = 262.144 IP-Adressen für Pods.

Weitere Informationen finden Sie unter Sekundärer IP-Adressbereich des Subnetzes für Pods.

Dienste

Dienstadressen (ClusterIP) werden aus dem sekundären IP-Adressbereich des Clusters für Dienste übernommen. Dieser Bereich muss groß genug sein, um Adressen für alle Kubernetes-Dienste bereitzustellen, die Sie in Ihrem Cluster hosten.

In GKE Autopilot-Clustern mit Version 1.27 und höher und GKE-Standardclustern mit Version 1.29 und höher weist GKE IP-Adressen für GKE-Dienste aus einem von GKE verwalteten Bereich zu: 34.118.224.0/20 ist dabei Standard. Auf diese Weise müssen Sie keinen eigenen IP-Adressbereich für Services angeben. Weitere Informationen finden Sie unter Sekundärer IP-Adressbereich des Subnetzes für Services.

Für einen Cluster mit bis zu 3.000 Diensten benötigen Sie 3.000 Cluster-IP-Adressen. Dafür benötigen Sie einen sekundären Bereich mit einer Größe von /20 oder größer. Ein IP-Adressbereich von /20 ergibt 2^(32-20) = 2¹² = 4.096 IP-Adressen.

Weitere Informationen finden Sie unter Sekundärer IP-Adressbereich des Subnetzes für Dienste.

Interne IP-Adressen

Die IP-Adressen, die Sie für die Subnetze Ihres VPC-nativen Clusters verwenden, müssen aus einem gültigen Subnetzbereich stammen. Gültige Bereiche sind private IP-Adressen (RFC 1918 und andere) und privat wiederverwendete öffentliche IP-Adressen. Weitere Informationen zu gültigen Subnetzbereichen finden Sie unter Gültige Bereiche und Eingeschränkte Bereiche in der VPC-Dokumentation.

Eine Anleitung zum Aktivieren dieser Bereiche finden Sie unter Private IP-Adressbereiche außerhalb von RFC 1918 verwenden.

Eine Anleitung zum Verwenden dieser Bereiche finden Sie unter Privat verwendete öffentliche IP-Adressbereiche aktivieren.

Zuweisungsmethoden für sekundäre Bereiche

Sie können einem VPC-nativen Cluster Pod-IP-Adressbereiche und Service-Adressbereiche (ClusterIP) zuweisen: Diese IP-Adressbereiche können von GKE oder vom Nutzer verwaltet werden.

Sie müssen die folgenden wichtigen Begriffe verstehen, um die Zuweisungsmethoden für sekundäre Bereiche zu verstehen.

Zuweisung: Die Zuweisung von IP-Adressbereichen bezieht sich auf die Zuweisung eines bestimmten Subnetzbereichs zu einem VPC-nativen Cluster. Dadurch wird ein Pool von IP-Adressen eingerichtet, die die Komponenten im Cluster verwenden können, z. B. Pods und Dienste.

Verwaltung: Die Verwaltung des IP-Adressbereichs bezieht sich auf die laufenden CRUD-Vorgänge (Erstellen, Aktualisieren, Löschen, Lesen) auf Cluster-, Knotenpool- oder Pod-Ebene in Bezug auf die zugewiesenen Subnetzbereiche und Ressourcenzuweisung innerhalb Ihres VPC-nativen Clusters.

Von GKE verwaltete sekundäre Bereiche (Standard)

Für GKE Autopilot-Cluster mit Version 1.27 und höher und GKE-Standardclustern mit Version 1.29 und höher weist GKE standardmäßig IP-Adressen für Dienste aus einem von GKE verwalteten Bereich zu: 34.118.224.0/20 ist dabei Standard. Auf diese Weise müssen Sie keinen eigenen IP-Adressbereich für Dienste angeben. Dabei gilt Folgendes:

Mit dem Flag --services-ipv4-cidr können Sie optional benutzerdefinierte Bereiche für Dienste angeben.
Wenn Sie nur den Bereich Größe mit dem Flag --services-ipv4-cidr (z. B. /22) angeben, verwendet GKE weiterhin den von GKE verwalteten Bereich, um den untergeordneten Adressbereich abzurufen.
GKE erstellt keinen separaten sekundären IP-Adressbereich für Services, wenn der von GKE verwaltete Bereich verwendet wird.

Vom Nutzer verwaltet

Für vollständige Kontrolle über die Zuweisung von IP-Adressen können Sie die Subnetze Ihres VPC-nativen Clusters manuell verwalten.

Sie können die sekundären IP-Adressbereiche des Subnetzes erstellen und dann einen Cluster, der diese Bereiche verwendet. Geben Sie während der Clustererstellung den Namen des Subnetzbereichs für Pods und Dienste an. Wenn Sie sekundäre Bereiche manuell erstellen, müssen Sie sie selbst verwalten.

Der kleinste IP-Adressbereich, den Sie ohne nicht zusammenhängendes Multi-Pod-CIDR erstellen können, ist /28. Mit diesem Bereich können Sie jedoch nur einen Knoten mit maximal acht Pods erstellen. Verwenden Sie einen Bereich, der groß genug für die maximale Anzahl der benötigten Knoten ist. Der minimal nutzbare Bereich hängt auch von der maximalen Anzahl von Pods pro Knoten ab.

In der Tabelle unter IP-Adresszuweisung optimieren finden Sie Informationen zum minimal verwendbaren CIDR-Bereich für verschiedene Werte von „Maximale Anzahl Pods pro Knoten“.

Wenn Sie Ihren IP-Adressbereich für Pods aufgebraucht haben, müssen Sie einen der folgenden Schritte ausführen:

Neuen Cluster mit einem größeren Pod-Adressbereich erstellen
Die Knotenpools neu erstellen, nachdem Sie die --max-pods-per-node für die Knotenpools verringert haben
Den sekundären Pod-IP-Adressbereich mithilfe eines nicht zusammenhängenden Multi-Pod-CIDR erweitern

Unterschiede bei routenbasierten Clustern

Das Zuweisungsschema für Pod- und Service-Adressen (ClusterIP) unterscheidet sich von dem Schema, das von einem routenbasierten Cluster verwendet wird. Anstatt ein einzelnes CIDR für Pods und Services zusammen festzulegen, müssen Sie zwei sekundäre IP-Adressbereiche im Subnetz des Clusters auswählen oder erstellen: einen für Pods und einen für Services.

Überlegungen zu freigegebenen VPC-Netzwerken

Beim Erstellen eines VPC-nativen Clusters in einer freigegebenen VPC-Umgebung muss ein Projektinhaber, -bearbeiter oder ein IAM-Hauptkonto mit der Rolle „Netzwerkadministrator“ im freigegebenen VPC-Hostprojekt das Subnetz und die sekundären IP-Adressbereiche des Clusters manuell erstellen. Ein Dienstprojektadministrator, der einen Cluster erstellt, muss mindestens Berechtigungen auf Subnetzebene für das gewünschte Subnetz im Hostprojekt des freigegebenen VPC-Netzwerks haben.

In einer freigegebenen VPC-Umgebung können sekundäre IP-Adressbereiche nicht von GKE verwaltet werden. Ein Netzwerkadministrator im freigegebenen VPC-Hostprojekt muss das Subnetz und die sekundären IP-Adressbereiche erstellen, bevor Sie den Cluster erstellen können. Ein Beispiel für die Einrichtung eines VPC-nativen Clusters in einem freigegebenen VPC-Netzwerk finden Sie unter Cluster mit freigegebener VPC einrichten.

IP-Adressbereichsplanung

Anhand der Informationen in den folgenden Abschnitten können Sie Größen für primäre und sekundäre IP-Adressbereiche des Subnetzes berechnen, das von Ihrem Cluster verwendet wird.

Primärer IP-Adressbereich des Subnetzes

Beachten Sie beim Planen des IP-Adressbereichs des primären Knotens die folgenden Bedingungen:

Jedes Subnetz muss einen primären IP-Adressbereich haben. Dies ist der IP-Adressbereich, den GKE zum Zuweisen von IP-Adressen für interne Load-Balancer und Knoten verwendet.
Sie können den primären IP-Adressbereich eines Subnetzes nicht verkleinern oder ändern, nachdem das Subnetz erstellt wurde.
Die ersten beiden und die letzten beiden IP-Adressen eines primären IP-Adressbereichs sind von Google Cloud reserviert.
Cluster mit Private Service Connect verwenden den primären Subnetzbereich, um die interne IP-Adresse bereitzustellen, die dem Endpunkt der Steuerungsebene zugewiesen ist. Sie können die Bereitstellung dieser IP-Adresse jedoch mit dem Flag private-endpoint-subnetwork überschreiben. Weitere Informationen finden Sie unter Cluster erstellen und IP-Adressbereich der Steuerungsebene auswählen.

Die folgende Tabelle zeigt die maximale Anzahl von Knoten, die Sie unter Berücksichtigung der Größe des primären IP-Adressbereichs des Subnetzes und der Clusterkonfiguration erstellen können:

Szenario 1: Maximale Anzahl von Knoten in einem Cluster, der das Standardsubnetz verwendet.
Szenario 2: Maximale Anzahl von Knoten in einem Private Service Connect-Cluster, der das Flag private-endpoint-subnetwork nicht verwendet.

Primärer IP-Bereich des Subnetzes	Szenario 1	Szenario 2
/29 Mindestgröße für den primären IP-Bereich eines Subnetzes	4 Knoten	3 Knoten
/28	12 Knoten	Knoten
/27	28 Knoten	27 Knoten
/26	60 Knoten	59 Knoten
/25	124 Knoten	123 Knoten
/24	252 Knoten	251 Knoten
/23	508 Knoten	Knoten
/22	1.020 Knoten	1.019 Knoten
/21	2.044 Knoten	2.043 Knoten
/20 Standardgröße des primären IP-Bereichs eines Subnetzes in Netzwerken im automatischen Modus	4.092 Knoten	4.091 Knoten
/19	8.188 Knoten	8.187 Knoten
/8 Maximale Größe für den primären IP-Bereich eines Subnetzes	16.777.212 Knoten	16.777.211 Knoten

Primären IP-Adressbereich erweitern

Wenn Ihnen die IP-Adressen im primären IP-Adressbereich ausgehen, können Sie den primären IP-Adressbereich jederzeit erweitern, auch wenn Google Cloud-Ressourcen wie Load-Balancer und Netzwerk-Endpunktgruppen das Subnetz nutzen.

Bevor Sie den primären IP-Adressbereich erweitern, sollten Sie Folgendes berücksichtigen:

Das Subnetz darf keine überlappenden IP-Adressbereiche enthalten.
GKE verwendet den primären IP-Adressbereich, um IP-Adressen für interne Load-Balancer und Knoten zuzuweisen.

Nützliche Formeln

Sie können die folgenden Formeln für diese Zwecke verwenden:

Berechnen der maximalen Anzahl von Knoten N, die eine bestimmte Netzmaske in Clustern unterstützen kann, die das Standardsubnetz verwenden. Verwenden Sie S für die Größe der Netzmaske, deren gültiger Bereich zwischen 8 und 29 liegt.

N = 2^{(32 - S)} - 4
Berechnen der Größe der Netzmaske S, die für die Unterstützung von maximal N Knoten erforderlich ist:

S = 32 - ⌈log₂(N + 4)⌉

⌈⌉ ist die CEILING-Funktion (kleinste Ganzzahl), d. h., dass sie auf die nächste ganze Zahl aufgerundet wird. Der gültige Bereich für die Größe der Netzmaske S liegt zwischen 8 und 29.

In Private Service Connect-Clustern, die das Flag private-endpoint-subnetwork nicht verwenden, können Sie die vorherigen Formeln verwenden, aber den Wert von N um 1 reduzieren.

Sekundärer IP-Adressbereich des Subnetzes für Pods

Planen Sie Ihren sekundären IP-Adressbereich für Pods sorgfältig.

Die folgende Tabelle zeigt die maximale Anzahl von Knoten und Pods, die Sie in allen das Subnetz verwendenden Clustern erstellen können, unter Berücksichtigung der Größe des von Pods verwendeten sekundären IP-Adressbereichs des Subnetzes. In dieser Tabelle wird davon ausgegangen, dass die maximale Anzahl von Pods pro Knoten 110 beträgt. Das ist die standardmäßige Pod-Dichte.

Sekundärer IP-Bereich des Subnetzes für Pods	Maximale Pod-IP-Adressen	Maximale Knotenanzahl	Maximale Anzahl von Pods
/24 Kleinstmöglicher Pod-IP-Bereich, wenn die Zuweisungsmethode für sekundäre Bereiche "Vom Nutzer verwaltet" lautet	256 Adressen	1 Knoten	Autopilot: 32 Pods Standard: 110 Pods
/23 Nur möglich, wenn die Zuweisungsmethode für sekundäre Bereiche "Vom Nutzer verwaltet" lautet	512 Adressen	2 Knoten	Autopilot: 64 Pods Standard: 220 Pods
/22 Nur möglich, wenn die Zuweisungsmethode für sekundäre Bereiche "Vom Nutzer verwaltet" lautet	1.024 Adressen	4 Knoten	Autopilot: 128 Pods Standard: 440 Pods
/21 Kleinstmöglicher Pod-IP-Bereich, wenn die Zuweisungsmethode für sekundäre Bereiche "Von GKE verwaltet" lautet	2.048 Adressen	8 Knoten	Autopilot: 256 Pods Standard: 880 Pods
/20	4.096 Adressen	16 Knoten	Autopilot: 512 Pods Standard: 1760 Pods
/19	8.192 Adressen	32 Knoten	Autopilot: 1.024 Pods Standard: 3520 Pods
/18	16.384 Adressen	64 Knoten	Autopilot: 2.048 Pods Standard: 7040 Pods
/17	32.768 Adressen	128 Knoten	Autopilot: 4.096 Pods Standard: 14080 Pods
/16	65.536 Adressen	256 Knoten	Autopilot: 8.192 Pods Standard: 28160 Pods
/15	131.072 Adressen	512 Knoten	Autopilot: 16.384 Pods Standard: 56320
/14 Standardgröße für den sekundären IP-Adressbereich des Subnetzes für Pods, wenn die Zuweisungsmethode für sekundäre Bereiche "Von GKE verwaltet" wird.	262.144 Adressen	1.024 Knoten	Autopilot: 32.768 Pods Standard: 112640 Pods
/13	524.288 Adressen	2.048 Knoten	Autopilot: 65.536 Pods Standard: 225280
/12	1.048.576 Adressen	4.096 Knoten	Autopilot: 131.072 Pods Standard: 450560 Pods
/11	2.097.152 Adressen	8.192 Knoten	Autopilot: 262.144 Pods Standard: 901120
/10	4.194.304 Adressen	16.384 Knoten	Autopilot: 524.288 Pods Standard: 1.802.240 Pods
/9 Größtmöglicher Pod-Adressbereich	8.388.608 Adressen	32.768 Knoten	Autopilot: 1.048.576 Pods Standard: 3.604.480 Pods

Wenn Sie die maximale Anzahl von Pods pro Knoten geändert haben, können Sie mithilfe der folgenden Formeln die maximale Anzahl von Knoten und Pods berechnen, die der sekundäre IP-Adressbereich eines Subnetzes für Pods unterstützen kann:

Berechnen der Größe der Netzmaske des Pod-Bereichs M für jeden Knoten:
M = 31 - ⌈log₂(Q)⌉, wobei Folgendes gilt:
- Q ist die Anzahl der Pods pro Knoten.
- ⌈⌉ ist die CEILING-Funktion (kleinste Ganzzahl), die auf die nächste Ganzzahl aufrundet
- Beispiel: Wenn Q 110 ist, dann: M = 24
Berechnen der maximalen Anzahl an Knoten N, die der sekundäre IP-Adressbereich des Subnetzes für Pods unterstützen kann:
N = 2^{(M - S)}, wobei Folgendes gilt:
- M ist die im ersten Schritt berechnete Größe der Netzmaske für den Alias-IP-Adressbereich jedes Knotens für Pods.
- S ist die Größe der Subnetzmaske für den sekundären IP-Adressbereich des Subnetzes.
- Beispiel: Wenn M 24 und S 20 ist, dann: N = 16
Berechnen der maximalen Anzahl an Pods P, die der sekundäre IP-Adressbereich des Subnetzes für Pods unterstützen kann:
P = N × Q, wobei Folgendes gilt:
- N ist die maximale Anzahl von Knoten, die im vorherigen Schritt berechnet wurde.
- Q ist die Anzahl der Pods pro Knoten.
- Beispiel: Wenn N 16 und Q 110 ist, dann: P = 1760

Sie können mit nicht zusammenhängenden Multi-Pod-CIDRs weitere IP-Adressen für Pods hinzufügen.

Sekundärer IP-Adressbereich des Subnetzes für Dienste

Planen Sie Ihren sekundären IP-Adressbereich für Services sorgfältig. Da dies auch ein sekundärer Subnetz-IP-Adressbereich ist, kann dieser Bereich nicht mehr geändert werden, nachdem der Cluster erstellt wurde.

Wenn Sie Multi-Cluster-Dienste verwenden, verwendet das Objekt ServiceImport IP-Adressen aus dem sekundären IP-Adressbereich für Dienste.

In GKE Autopilot-Clustern mit Version 1.27 und höher und GKE-Standardclustern mit Version 1.29 und höher weist GKE standardmäßig IP-Adressen für Dienste aus einem von GKE verwalteten Bereich zu: 34.118.224.0/20 ist dabei Standard. Auf diese Weise müssen Sie keinen eigenen IP-Adressbereich für Dienste angeben. Dabei gilt Folgendes:

Mit dem Flag --services-ipv4-cidr oder dem Flag --services-secondary-range-name können Sie optional benutzerdefinierte Bereiche für Services angeben.
Wenn Sie nur den Bereich Größe mit dem Flag --services-ipv4-cidr (z. B. /22) angeben, verwendet GKE weiterhin den von GKE verwalteten Bereich, um den untergeordneten Adressbereich abzurufen.
GKE erstellt keinen separaten sekundären IP-Adressbereich für Services, wenn der von GKE verwaltete Bereich verwendet wird. Der von GKE verwaltete Bereich verwendet nicht das Kontingent für den sekundären IP-Adressbereich für Ihr Subnetz.

In der folgenden Tabelle sehen Sie die maximale Anzahl von Diensten, die Sie in einem einzelnen Cluster mit dem Subnetz erstellen können, unter Berücksichtigung der Größe des sekundären IP-Adressbereichs des Subnetzes für Dienste.

Sekundärer IP-Bereich für Dienste	Maximale Anzahl an Diensten
/28 Kleinstmöglicher Dienstadressbereich, wenn die Methode der Zuweisung des sekundären Bereichs nutzergesteuert ist	16 Dienste
/27 Kleinstmöglicher Dienstadressbereich, wenn die Methode der sekundären Bereichszuweisung von GKE verwaltet wird	32 Dienste
/26	64 Dienste
/25	128 Dienste
/24	256 Dienste
/23	512 Dienste
/22	1.024 Dienste
/21	2.048 Dienste
/20 Standardgröße für den sekundären IP-Bereich des Subnetzes für Dienste, wenn die Zuweisungsmethode für sekundäre Bereiche "Von GKE verwaltet" lautet	4.096 Dienste
/19	8.192 Dienste
/18	16.384 Dienste
/17	32.768 Dienste
/16 Größtmöglicher Dienstadressbereich	65.536 Dienste

IP-Adressbereiche für GKE-Cluster freigeben

Sie können den primären Bereich, den sekundären IP-Adressbereich für Pods und den sekundären IP-Adressbereich für Dienste zwischen Clustern im selben Subnetzwerk freigeben.

Dieses Verhalten ist sowohl für Standard- als auch für Autopilot-Cluster verfügbar.

Sie können IP-Adressbereiche freigeben, wenn Sie ein zentrales Team haben, das die Infrastruktur für Cluster verwaltet. Sie können den Aufwand reduzieren, indem Sie drei Bereiche für Pods, Dienste und Knoten erstellen und diese wiederverwenden oder freigeben, insbesondere in einem freigegebenen VPC-Modell. Außerdem können Netzwerkadministratoren die Verwaltung von IP-Adressen vereinfachen, da sie nicht für jeden Cluster bestimmte Subnetze erstellen müssen.

Primären IP-Adressbereich für Knoten freigeben

Wenn Sie mehr als einen Cluster im Subnetz erstellen, wird der primäre IP-Adressbereich für Knoten standardmäßig freigegeben.

Die Freigabe der primären IP-Adresse für Knoten unterliegt den folgenden Einschränkungen:

Wenn Sie den primären IP-Adressbereich für Knoten mit zwei oder mehr VPC-nativen Clustern teilen, kann ein Cluster einen großen Teil des freigegebenen IP-Adressbereichs nutzen, sodass die anderen Cluster nicht auf ausreichend IP-Adressen erweitert werden können.

Sekundären IP-Adressbereich für Pods freigeben

Wenn Sie den sekundären Bereich für Pods freigeben, erhält jeder Pod trotzdem eine eindeutige IP-Adresse.

Die Freigabe des sekundären IP-Adressbereichs für Pods unterliegt den folgenden Einschränkungen:

Wenn Sie den sekundären IP-Adressbereich für Pods mit zwei oder mehr VPC-nativen Clustern teilen, kann ein Cluster einen großen Teil des freigegebenen IP-Adressbereichs verwenden, sodass die anderen Cluster nicht auf ausreichend IP-Adressen erweitert werden können.
Von den verschiedenen Arten von sekundären Bereichen sind sowohl von GKE verwaltete als auch zusätzliche Pod-Bereiche nicht für mehrere Cluster freigegeben.
Um einen sekundären IP-Bereich freizugeben, übergeben Sie ihn in der Befehlszeile mit --cluster-secondary-range. Sie können beim Erstellen von Clustern in der Benutzeroberfläche keinen freigegebenen sekundären Bereich verwenden.

Sekundären IP-Adressbereich für Dienste freigeben

Wenn Sie nutzerverwaltete sekundäre Bereiche verwenden, können zwei oder mehr Cluster gleichzeitig denselben sekundären IPv4-Adressbereich für Subnetze verwenden.

Wenn Sie zwei oder mehr Cluster so konfigurieren möchten, dass sie einen gemeinsamen sekundären IPv4-Adressbereich für Subnetze verwenden, verwenden Sie beim Erstellen jedes Clusters denselben sekundären Subnetz-IPv4-Adressbereich. Es ist kein separates Konfigurations-Flag erforderlich, um einen gemeinsamen IPv4-Adressbereich für Dienste freizugeben.

Wenn Sie einen gemeinsamen IPv4-Adressbereich für Dienste freigeben, verwendet jeder Cluster intern den gesamten sekundären IPv4-Adressbereich des Subnetzes für Dienste. Die IP-Adressen für Dienste werden in den Knoten jedes Clusters programmiert, sie werden jedoch nicht der Netzwerkschnittstelle eines Knotens zugewiesen. Dienst-IP-Adressen können innerhalb des VPC-Netzwerks des Clusters nicht weitergeleitet werden. Dienst-IP-Adressen können nur von Client-Pods im selben Cluster wie der Dienst verwendet werden.

Wenn ein Pod ein Paket an eine Dienst-IP-Adresse sendet, führt die iptables- oder eBPF-Konfiguration auf dem Knoten eine Zielnetzwerkadressübersetzung (NAT) durch und ändert die Ziel-IP-Adresse des Pakets von der Dienst-IP-Adresse in eine bereitstellende Pod-IP-Adresse. Das Paket wird anhand der Ziel-Pod-IP-Adresse weitergeleitet.

Die gemeinsame Nutzung des sekundären IP-Adressbereichs für Services bietet folgende Vorteile:

Die Anzahl der eindeutigen sekundären IP-Adressbereiche für Services, die in einem Subnetz erstellt werden, wird reduziert
Weniger IP-Adressen werden verwendet

Die Freigabe des sekundären IP-Adressbereichs für Services unterliegt folgenden Einschränkungen:

Die Freigabe des sekundären IP-Adressbereichs für Dienste wird beim VPC-Bereich Cloud DNS für GKE nicht unterstützt.
Sie können keine Bereiche freigeben, die dem folgenden regulären Ausdruck entsprechen:
```
^gke-.*-services-[abcdef0-9]{8}
```
Um einen sekundären IP-Adressbereich für Dienste freizugeben, übergeben Sie ihn in der Befehlszeile mit --cluster-secondary-range. Sie können beim Erstellen von Clustern in der Benutzeroberfläche keinen freigegebenen sekundären Bereich für Dienste verwenden.

Knotenbegrenzungsbereiche

Die maximale Anzahl von Pods und Diensten in einem bestimmten GKE-Cluster wird durch die Größe der sekundären Bereiche des Clusters begrenzt. Die maximale Anzahl von Knoten im Cluster ist durch die Größe des primären IP-Adressbereichs des Clustersubnetzes und des Pod-Adressbereichs des Clusters begrenzt.

Die folgende Fehlermeldung gibt an, dass entweder der primäre IP-Adressbereich des Subnetzes oder der Pod-IP-Adressbereich des Clusters (der sekundäre IP-Adressbereich des Subnetzes für Pods) ausgeschöpft ist:

Instance [node name] creation failed: IP space of [cluster subnet] is
exhausted

Sie können weitere IP-Adressen für Knoten hinzufügen, indem Sie das primäre Subnetz erweitern. Sie können auch neue IP-Adressen für Pods hinzufügen, indem Sie nicht zusammenhängendes CIDR für mehrere Pods verwenden. Weitere Informationen finden Sie unter Nicht genügend freier IP-Adressbereich für Pods.

IPv4/IPv6-Dual-Stack-Netzwerk

Mit dem IPv4/IPv6-Dual-Stack-Netzwerk können Sie definieren, wie GKE IP-Adressen (ipFamilies) den folgenden Objekten zuweist:

GKE weist Pods und Knoten sowohl IPv4- als auch IPv6-Adressen zu.
Bei Services weist GKE entweder einzelne Stack-Adressen (nur IPv4 oder IPv6) oder Dual-Stack-Adressen zu.

Ab GKE-Version 1.24 können Sie ein Dual-Stack-Netzwerk für neue GKE-Cluster in eigenständigen und freigegebenen VPC-Netzwerken aktivieren. Sie können auch Netzwerkrichtlinien mit aktiviertem Dual-Stack-Netzwerk anwenden.

Vorteile

Dual-Stack-Netzwerke bieten folgende Vorteile:

Aktiviert die End-to-End-IPv6-Kommunikation.
Ermöglicht eine bessere Leistung im Vergleich zu NAT (Network Address Translation) oder IP-Tunneling. Das wird erreicht, da keine IPv6-zu-IPv4-Übersetzung vorhanden ist.

Verfügbarkeit

Für Dual-Stack-Netzwerke mit GKE gelten die folgenden Einschränkungen:

Dual-Stack-Netzwerke sind nur für VPC-native Cluster mit aktiviertem GKE Dataplane V2 verfügbar.
Dual-Stack-Netzwerke werden nur in Subnetzen in VPCs im benutzerdefinierten Modus unterstützt. Weitere Informationen finden Sie unter VPC-Netzwerke von Google Cloud.
Single-Stack-IPv6-Adressen für Pods oder Knoten werden nicht unterstützt.
Dual-Stack-Cluster belegen zusätzlichen Speicher pro Knoten, um im Vergleich zu reinen IPv4-Clustern sowohl IPv4 als auch IPv6 zu unterstützen. Beachten Sie dieses Merkmal beim Einrichten großer Cluster.
Dual-Stack-Cluster unterstützen keinen privaten Google-Zugriff über IPv6.
Die GKE-Versionen ab 1.26.0-gke.2200 unterstützen IPv6-Einträge (AAAA-Einträge) mit Cloud DNS für clusterinterne Vorgänge und externe DNS-Abfragen.
Dual-Stack-Dienste werden für die Dienste ClusterIP, NodePort und LoadBalancer unterstützt.

IPv6 wird für Windows-Knoten nicht unterstützt.

Beachten Sie die vorherigen Einschränkungen, bevor Sie einen Cluster mit Dual-Stack-Netzwerken erstellen. Weitere Informationen finden Sie unter VPC-nativen Cluster mit Dual-Stack-Netzwerk erstellen.

Zuweisung öffentlicher und privater IPv6-Adressen

Die folgende Tabelle enthält eine Zusammenfassung der öffentlichen und privaten IPv6-Adressen mit Dual-Stack-Netzwerkverhalten und -Konfigurationen:

ipv6-access-type Flag Zuweisung von IP-Adressen Subnetzbereich

`ipv6-access-type` Flag	Zuweisung von IP-Adressen	Subnetzbereich
`EXTERNAL`	GKE weist externe IPv6-Adressen zu, die an das Internet weitergeleitet werden können.	Ab `2600:1900/28`
`INTERNAL`	GKE weist interne IPv6-Adressen zu, die nicht mit dem Internet verbunden werden können. Cluster mit dem IPv6-Zugriffstyp `INTERNAL` können nicht über IPv6-Adressen auf das Internet zugreifen. Cloud NAT unterstützt keine IPv6-Adressen.	Aus `fd20::/20` (eine Teilmenge des gesamten ULA-Bereichs: `fc00::/7`).

EXTERNAL

GKE weist externe IPv6-Adressen zu, die an das Internet weitergeleitet werden können.

Ab 2600:1900/28

INTERNAL

GKE weist interne IPv6-Adressen zu, die nicht mit dem Internet verbunden werden können.

Cluster mit dem IPv6-Zugriffstyp INTERNAL können nicht über IPv6-Adressen auf das Internet zugreifen. Cloud NAT unterstützt keine IPv6-Adressen.

Aus fd20::/20 (eine Teilmenge des gesamten ULA-Bereichs: fc00::/7).

Weitere Informationen finden Sie unter Dual-Stack-Netzwerk für einen VPC-nativen Cluster verwenden.

Architektur

Einem Cluster mit IPv4/IPv6-Dual-Stack-Netzwerk werden die folgenden Bereiche zugewiesen:

Ein Bereich von /64 für jedes Subnetz als primärer Bereich.
Ein Knotenbereich von /96 aus dem primären Bereich, der als IP-Adressbereich des primären Knotens verwendet wird.
Ein Knotenbereich von /112 aus dem IP-Adressbereich des primären Knotens, der als Pod-IP-Adressbereich für diesen Knoten verwendet wird. Beim Dual-Stack-Netzwerk erhalten Pods ihre IPv6-Adressen aus dem Gesamt-IP-Adressbereich des Pods (ähnlich wie Knoten) und nicht aus dem sekundären Bereich für Pods, die für IPv4-Adressen reserviert sind.

Der gesamte Pod-IP-Adressbereich besteht aus nicht überlappenden Bereichen aus dem IP-Bereich des primären Knotens. Daher ist der Pod-IP-Bereich nicht eindeutig.
Ein Bereich von /112 für Services. Dieser Bereich stammt aus einem /64-Bereich aus dem privaten Google-Adressbereich, der für den sekundären IP-Adressbereich der GKE-Services reserviert wurde.

Das folgende Diagramm zeigt, wie Google Cloud und GKE IPv6-Adressen zuweisen:

Im Diagramm ist der primäre Bereich des VPC-Subnetzes 2600:1900:0:1::/64 und der reservierte Bereich für GKE-Service ist 2600:2D00:0:4::0:0/64. Jeder Knoten im Cluster hat einen /96-Bereich für den IP-Adressbereich des primären Knotens und einen /112-Bereich für den Pod-IP-Adressbereich. Der Cluster hat auch einen /112-Bereich für den sekundären IP-Adressbereich des Services.

Dienste

Sie können einen IPv6-Service vom Typ ClusterIP, NodePort oder LoadBalancererstellen.

Sie können ein Deployment mit einem Service vom Typ ClusterIP, NodePort oder LoadBalancer freigeben. Für jeden dieser Diensttypen können Sie die Felder ipFamilies und ipFamilyPolicy entweder als IPv4-, IPv6- oder als Dual-Stack-Dienst definieren. Weitere Informationen finden Sie in einem Beispiel für die Einrichtung eines Deployments.

Nächste Schritte

Weitere Informationen zum VPC-Netzwerk-Peering.
VPC-nativen Cluster erstellen
Informationen zu Statistiken zur GKE-IP-Adressauslastung