VPC-native Cluster

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

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 wie 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
Älter als 1.21.0-gke.1500 Kubernetes Engine API oder Google Cloud CLI Routenbasiert

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 drei eindeutige Subnetz-IP-Adressbereiche:

  • Der primäre IP-Adressbereich des Subnetzes wird für alle Knoten-IP-Adressen verwendet.
  • Ein sekundärer IP-Adressbereich wird für alle Pod-IP-Adressen verwendet.
  • Ein weiterer sekundärer IP-Adressbereich wird für alle Service-Adressen (Cluster-IP-Adressen) verwendet.

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

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) = 210 = 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) = 218 = 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.

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) = 212 = 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 in privaten Clustern finden Sie unter Privat verwendete öffentliche IP-Adressbereiche aktivieren.

Zuweisungsmethoden für sekundäre Bereiche

Sie können einem VPC-nativen Cluster mithilfe einer der beiden folgenden Methoden Pod-IP-Adressbereiche und Service-Adressbereiche (ClusterIP) zuweisen:

Von GKE verwaltet (Standard)

GKE kann die sekundären Bereiche des Subnetzes für Sie erstellen und verwalten. Beim Erstellen des Clusters geben Sie entweder einen vollständigen CIDR-Bereich oder die Größe einer Netzmaske für die Pods und Dienste an. Sie können z. B. 10.1.0.0/16 für Pods und 10.2.0.0/20 für Dienste oder /16 für Pods und /20 für Dienste angeben.

Wenn Sie den Cluster und das Subnetz gleichzeitig erstellen, werden Pod- und Service-IP-Adressbereiche von GKE verwaltet.

Vom Nutzer verwaltet

Sie können die sekundären IP-Adressbereiche des Subnetzes erstellen und dann einen Cluster, der diese Bereiche verwendet. 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:

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

Jedes Subnetz muss einen primären IP-Adressbereich haben. Dies ist der IP-Adressbereich, den GKE verwendet, um IP-Adressen für interne Load-Balancer und Knoten zuzuweisen.

Der primäre IP-Adressbereich eines Subnetzes kann nicht verkleinert oder geändert werden, nachdem das Subnetz erstellt wurde.

Die ersten beiden und die letzten beiden IP-Adressen eines primären IP-Adressbereichs sind von Google Cloud reserviert.

Die folgende Tabelle zeigt die maximale Anzahl von Knoten, die Sie in allen das Subnetz verwendenden Clustern erstellen können, unter Berücksichtigung der Größe des primären IP-Adressbereichs des Subnetzes.

Primärer IP-Bereich des Subnetzes Maximale Knotenanzahl
/29
Mindestgröße für den primären IP-Bereich eines Subnetzes		 4 Knoten
/28 12 Knoten
/27 28 Knoten
/26 60 Knoten
/25 124 Knoten
/24 252 Knoten
/23 508 Knoten
/22 1.020 Knoten
/21 2.044 Knoten
/20
Standardgröße des primären IP-Bereichs eines Subnetzes in Netzwerken im automatischen Modus		 4.092 Knoten
/19 8.188 Knoten
/8
Maximale Größe für den primären IP-Bereich eines Subnetzes		 16.777.212 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 haben.
  • 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 unterstützen kann. 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 - ⌈log2(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.

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 110 Pods
/23
Nur möglich, wenn die Zuweisungsmethode für sekundäre Bereiche "Vom Nutzer verwaltet" lautet		 512 Adressen 2 Knoten 220 Pods
/22
Nur möglich, wenn die Zuweisungsmethode für sekundäre Bereiche "Vom Nutzer verwaltet" lautet		 1.024 Adressen 4 Knoten 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 880 Pods
/20 4.096 Adressen 16 Knoten 1.760 Pods
/19 8.192 Adressen 32 Knoten 3.520 Pods
/18 16.384 Adressen 64 Knoten 7.040 Pods
/17 32.768 Adressen 128 Knoten 14.080 Pods
/16 65.536 Adressen 256 Knoten 28.160 Pods
/15 131.072 Adressen 512 Knoten 56.320 Pods
/14
Standardgröße für den sekundären IP-Bereich des Subnetzes für Pods, wenn die Zuweisungsmethode für sekundäre Bereiche "Von GKE verwaltet" lautet		 262.144 Adressen 1.024 Knoten 112.640 Pods
/13 524.288 Adressen 2.048 Knoten 225.280 Pods
/12 1.048.576 Adressen 4.096 Knoten 450.560 Pods
/11
2.097.152 Adressen 8.192 Knoten 901.120 Pods
/10
4.194.304 Adressen 16.384 Knoten 1.802.240 Pods
/9
Größtmöglicher Pod-Adressbereich		 8.388.608 Adressen 32.768 Knoten 3.604.480 Pods

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

  1. Berechnen der Größe der Netzmaske des Pod-Bereichs M für jeden Knoten:
    M = 31 - ⌈log2(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

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

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

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-Bereich für Dienste.

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.

Sekundären IP-Adressbereich für Dienste freigeben

Sie können den sekundären IP-Adressbereich für Services in Clustern im selben Subnetz freigeben, wenn Sie nutzerverwaltete sekundäre Bereiche verwenden.

Wenn Sie eine Weiterleitung an eine Dienst-IP-Adresse aus diesem Bereich vornehmen, löst GKE die IP-Adresse in die Back-End-Pod-IP-Adresse am Quell- oder Hostknoten auf. Das bedeutet, dass die Dienst-IP-Adresse nie weitergeleitet wird und in verschiedenen Clustern verwendet werden kann.

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:

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.

In der Google Cloud Console werden Fehlermeldungen wie die folgenden angezeigt, um darauf hinzuweisen, 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-Bereich 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.

Ab GKE Version 1.25 können Sie auch ein Dual-Stack-Netzwerk für vorhandene GKE-Cluster in eigenständigen und freigegebenen VPC-Netzwerken aktivieren.

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 ClusterIP- und NodePort-Services unterstützt, aber nicht für LoadBalancer-Services.
  • 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
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

In einem Autopilot- oder Standard-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 oder NodePort erstellen.

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

Nächste Schritte