VPC-native Cluster (original) (raw)

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

Diese Seite richtet sich an Cloud-Architekten und 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-Nutzerrollen und -Aufgaben.

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

Best Practice:

Planen und entwerfen Sie Ihre Clusterkonfiguration mit den Netzwerkarchitekten, Netzwerkadministratoren oder einem anderen Netzwerkentwicklerteam Ihrer Organisation, das für die Definition, Implementierung und Wartung Ihrer Netzwerkarchitektur verantwortlich ist.

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 eine bessere Planung für die Zuweisung von IP-Adressen.
• Pod-IP-Adressbereiche sind nicht von benutzerdefinierten statischen Routen abhängig. Sie verbrauchen nicht das vom System generierte und das benutzerdefinierte Kontingent für statische Routen. Stattdessen werden für das Routing von VPC-nativen Clustern automatisch generierte Subnetzrouten verwendet.
• Sie können Firewallregeln erstellen, die statt auf IP-Adressen der Knoten des Clusters nur auf Pod-IP-Adressbereiche angewendet werden.
• 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 neuen Cluster in allen verfügbaren Versionen, die über eine beliebige Oberfläche erstellt werden,einschließlich Google Cloud CLI, Google Cloud -Konsole oder GKE API. Weitere Informationen zu den verfügbaren Versionen finden Sie unter Aktuelle Versionen.

Wenn Sie den empfohlenen VPC-nativen Netzwerkmodus nicht verwenden möchten, lesen Sie den Abschnitt Routenbasierten Cluster erstellen.

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:

Zuweisung von IPv4-Adressen

In VPC-nativen Clustern werden IPv4-Adressen für Knoten, Pods und Dienste so zugewiesen:

• IPv4-Adressen von Knoten: Der Cluster verwendet den primären IPv4-Adressbereich des Subnetzes, um allen Knoten IP-Adressen zuzuweisen.
• Pod-IPv4-Adressen: Der Cluster verwendet einen oder mehrere sekundäre IPv4-Adressbereiche des Subnetzes für alle Pod-IPv4-Adressen. Auf dieser Seite wird die Verwendung eines einzelnen sekundären IPv4-Adressbereichs des Subnetzes beschrieben. Informationen zur Verwendung mehrerer Bereiche finden Sie unter Pod-IPv4-Adressbereiche hinzufügen.
• IPv4-Adressen für Dienste: Es gibt zwei Optionen:
  • IPv4-Adressen für Dienste aus 34.118.224.0/20: GKE Autopilot-Cluster mit Version 1.27 und höher sowie GKE-Standardcluster mit Version 1.29 und höher verwenden den IPv4-Adressbereich 34.118.224.0/20 für Dienste.Google Cloud verwendet den Adressbereich 34.118.224.0/20 für private Zwecke und veröffentlicht keine Routen im öffentlichen Internet für diesen Bereich. Sie können diesen Bereich nicht für externe IPv4-Adressen Ihrer Ressourcen verwenden.
  • IPv4-Adressen von Diensten aus einem sekundären IPv4-Adressbereich des Subnetzes: Für alle Dienstadressen (ClusterIP) verwendet der Cluster einen sekundären IPv4-Adressbereich des Subnetzes, der sich von den von Pods verwendeten Bereichen unterscheidet.

IPv6-Adresszuweisung (Dual-Stack-Netzwerk)

• IPv6-Adressen von Knoten und Pods: In Clustern, die für Dual-Stack-Netzwerke aktiviert sind, stammen die IPv6-Adresse des Knotens und alle IPv6-Adressen von Pods aus dem zugewiesenen 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.
• IPv6-Adressen für Services: GKE-Cluster verwenden den IPv6-Adressbereich 2600:2D00:0:4::0:0/64 für Services. Google Cloudverwendet den Adressbereich 2600:2D00:0:4::0:0/64 für private Zwecke und veröffentlicht keine Routen im öffentlichen Internet für diesen Bereich. Sie können diesen Bereich nicht für externe IPv6-Adressen Ihrer Ressourcen verwenden.

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

Interne IPv4-Adressen

Die IPv4-Adressen, die Sie für die Subnetze Ihres VPC-nativer Cluster verwenden, müssen aus einem gültigen Subnetzbereich stammen. Gültige Bereiche sind private IPv4-Adressen, z. B. RFC 1918, und privat verwendete öffentliche IP-Adressen. Weitere Informationen zu gültigen IPv4-Bereichen für Subnetze finden Sie unter Gültige Bereiche und Eingeschränkte Bereiche in der VPC-Dokumentation.

Wichtige Informationen zur Verwendung privater Adressen, die keine RFC 1918-Adressen sind, finden Sie unter Private IPv4-Adressbereiche außerhalb von RFC 1918 verwenden.

Wichtige Informationen zur Verwendung privat verwendeter öffentlicher IPv4-Adressbereiche finden Sie unter Privat verwendete öffentliche IP-Adressbereiche aktivieren.

Zuweisungsmethoden für sekundäre IPv4-Bereiche von Subnetzen

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 Schlüsselbegriffe kennen, um die Methoden zur Zuweisung des sekundären Bereichs zu verstehen.

Zuweisung: Das Zuweisen von IP-Adressbereichen bezieht sich auf die Zuweisung eines bestimmten Subnetzbereichs zu einem VPC-nativer 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-nativer Cluster.

Von GKE verwaltete sekundäre Bereiche (Standard)

Für GKE Autopilot-Cluster mit Version 1.27 und höher und GKE-Standardcluster 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. 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.
• Wenn Sie nur eine Größe für den Pod-IP-Adressbereich angeben, z. B. --cluster-ipv4-cidr=/17, wählt GKE automatisch einen verfügbaren sekundären IP-Adressbereich aus Ihrem VPC-Netzwerk aus.
• GKE erstellt keinen separaten sekundären IP-Adressbereich für Services, wenn der von GKE verwaltete Bereich verwendet wird.

Vom Nutzer verwaltet

Wenn Sie die IP-Adressenzuweisung vollständig steuern möchten, können Sie die Subnetze Ihres VPC-nativer Cluster manuell verwalten.

Sie können die sekundären IP-Adressbereiche des Subnetzes erstellen und dann einen Cluster, der diese Bereiche verwendet. Geben Sie beim Erstellen des Clusters 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 Pod-CIDR-Bereiche in Standardclustern 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.

Besonderheiten bei gemeinsam genutzten VPC

Beim Erstellen eines VPC-nativer Cluster in einer gemeinsam genutzten VPC-Umgebung muss ein Projektinhaber, -bearbeiter oder ein Identity and Access Management (IAM)-Hauptkonto mit der Rolle „Netzwerkadministrator“ im Hostprojekt der freigegebene VPC 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 Subnetz im Hostprojekt des freigegebene VPC-Netzwerks haben.

In einer freigegebene VPC-Umgebung können sekundäre IP-Adressbereiche nicht von GKE verwaltet werden. Ein Netzwerkadministrator im freigegebene 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-nativer Cluster in einem freigegebene VPC-Netzwerk finden Sie unter Cluster mit gemeinsam genutzter 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.

GKE-IP-Adressenrechner

Mit diesem Rechner können Sie die IP-Adresszuweisung für Ihre VPC-nativen Cluster planen. Sie können entweder die Anzahl der Knoten und Pods eingeben, um die geeigneten Subnetzpräfixgrößen zu ermitteln, oder die Subnetzgrößen eingeben, um die maximal unterstützten Knoten und Pods zu sehen. Mit diesem Rechner werden genügend IP-Adressbereiche zugewiesen, um eine Erschöpfung zu verhindern, wenn Ihr Cluster skaliert wird.

Primärer IPv4-Adressbereich des Subnetzes

Berücksichtigen Sie Folgendes, wenn Sie den primären IPv4-Adressbereich des Subnetzes eines Clusters planen:

• 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.
• Der primäre IP-Adressbereich eines Subnetzes lässt sich nicht verkleinern oder ändern, nachdem das Subnetz erstellt wurde.
• Nachdem Sie ein Subnetz erstellt haben, können Sie den primären IP-Adressbereich erweitern, aber nicht verkleinern. Wenn Sie ein Subnetz erweitern, das von einem Cluster mit autorisierten Netzwerken verwendet wird, müssen Sie den erweiterten IP-Adressbereich der Liste der autorisierten Netzwerke der Steuerungsebene hinzufügen. Bevor Sie einen Bereich erweitern, sollten Sie die Einschränkungen und Empfehlungen unter Primären IPv4-Bereich erweitern lesen.
• Die ersten beiden und die letzten beiden IP-Adressen eines primären IP-Adressbereichs sind vonGoogle Cloudreserviert.
• 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 diese IP-Adressbereitstellung 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 an Knoten, die Sie in Abhängigkeit von der Größe des primären IPv4-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ä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.

Beachten Sie vor dem Erweitern des primären IP-Adressbereichs Folgendes:

• Es darf keine sich überschneidenden IP-Adressbereiche im Subnetz geben.
• GKE verwendet den primären IP-Adressbereich, um IP-Adressen für interne Load-Balancer und Knoten zuzuweisen.
• Wenn der Cluster autorisierte Netzwerke verwendet, müssen Sie den erweiterten primären IP-Adressbereich der Liste der autorisierten Netzwerke hinzufügen.

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 mit dem Standardsubnetz unterstützen kann. Verwenden Sie S für die Größe der Netzmaske, deren gültiger Bereich zwischen 9 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 9 und 29.

In Private Service Connect-Clustern, in denen das Flag private-endpoint-subnetwork nicht verwendet wird, können Sie die oben genannten Formeln verwenden, müssen aber den Wert von N um 1 reduzieren.

Hinweise zur Clustergröße für den sekundären IP-Adressbereich für Pods

Wenn Sie die maximale Anzahl von Pods berechnen möchten, die Ihr Cluster unterstützen kann, berücksichtigen Sie die Größe des Pod-Subnetzes und die maximale Anzahl von Pods pro Knoten. Die maximale Anzahl von Pods hängt von der Subnetzmaske und der maximalen Anzahl von Pods pro Knoten ab. Denken Sie außerdem daran, dass einige IP-Adressen im primären Bereich reserviert sind.

Wichtige Variablen

• Q: die maximale Anzahl von Pods pro Knoten.
• DS: Die ausgewählte CIDR-Blockgröße für das Pod-Subnetz (z. B. /17).
• M: Die Netzmaskengröße für den Pod-Bereich jedes Knotens.
• HM: Die Anzahl der Host-Bits für die Netzmaske des Pod-Bereichs des Knotens.
• HD: die Anzahl der Host-Bits für den CIDR-Block des Pod-Subnetzes.
• MN: die maximale Anzahl von Knoten, die unterstützt werden können.
• MP: Die maximale Anzahl von Pods, die unterstützt werden können.
• S: die Präfixlänge des primären IP-Adressbereichs des Subnetzes.
• N: Die Anzahl der nutzbaren IP-Adressen im primären IP-Adressbereich des Subnetzes.

Schritte zur Berechnung der maximalen Anzahl von Pods

1. Maximale Anzahl von Pods pro Knoten (Q) ermitteln:
   • Bei Autopilot-Clustern ist der Wert von Q auf 32 festgelegt.
   • Bei Standardclustern können Sie Q konfigurieren.
2. Größe des CIDR-Blocks für das Pod-Subnetz definieren (DS):
   • Bestimmen Sie die ausgewählte CIDR-Blockgröße für das Pod-Subnetz (z. B. /17).
3. Größe der Netzmaske (M) berechnen:

M = 31 - ⌈log₂(Q)⌉  

Ersetzen Sie Q durch den Wert für die maximale Anzahl von Pods pro Knoten. Verwenden Sie die CEILING-Funktion (⌈ ⌉), um auf die nächste Ganzzahl aufzurunden. 4. Host-Bits für den Pod-Bereich berechnen (HM):

HM = 32 - M  

1. Host-Bits für den ausgewählten CIDR-Block (HD) berechnen:

HD = 32 - DS  

1. Maximale Anzahl von Knoten (MN) berechnen:

MN = 2<sup>(HD - HM)</sup>  

Das Ergebnis dieser Berechnung ist die maximale Anzahl von Knoten, die das ausgewählte Pod-Subnetz unterstützen kann. 7. Maximale Anzahl von Pods (MP) berechnen:

MP = MN * Q  

Das Ergebnis dieser Berechnung ist die maximale Anzahl von Pods, die der Cluster unterstützen kann. 8. Anzahl der nutzbaren IP-Adressen im primären Bereich (N) berechnen:none N = 2<sup>(32-S)</sup> - 4Dabei ist S die Präfixlänge des primären CIDR-Bereichs für das Subnetz.

Wichtige Hinweise

• Alle IP-Adressen im sekundären Bereich können für Pods verwendet werden.
• Diese Berechnungen ergeben die theoretischen Höchstwerte. Die tatsächliche Leistung kann durch andere Faktoren beeinflusst werden.

Beispiel

Angenommen, Sie erstellen einen GKE Autopilot-Cluster mit den folgenden Einstellungen:

• Ein Pod-Subnetz-CIDR-Block von /17 (DS = 17).
• Maximal 32 Pods pro Knoten (Q = 32).

Berechnen Sie die maximale Anzahl von Pods:

1. M = 31 - ⌈log₂(32)⌉ = 26
2. HM = 32 - 26 = 6
3. HD = 32 - 17 = 15
4. MN = 2(15 - 6) = 512
5. MP = 512 * 32 = 16,384

Dieser Cluster kann maximal 512 Knoten und 16.384 Pods unterstützen.

Sie können weitere IPv4-Adressen für Pods hinzufügen, indem Sie Pod-IPv4-Adressbereiche hinzufügen oder Subnetze zu Clustern 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. 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 Google 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.

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

Benutzerdefinierten Subnetzbereich für die Steuerungsebene freigeben

Standardmäßig verwendet GKE den primären Subnetzbereich, um den internen Endpunkt der Steuerungsebene bereitzustellen. In Clustern mit Private Service Connect können Sie GKE jedoch so konfigurieren, dass der interne Endpunkt aus einem anderen Subnetz bereitgestellt wird, das Sie erstellt haben. Sie können dieses Subnetz für andere Cluster oder für Projekte freigeben, wenn Sie eine freigegebene VPC verwenden.

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.

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

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 an Pods und Diensten in einem bestimmten GKE-Cluster ist durch die Größe der sekundären Bereiche des Clusters begrenzt. Die maximale Anzahl an 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 weist darauf hin, 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 kostenloser 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 freigegebene VPC-Netzwerken aktivieren. Sie können auch Netzwerkrichtlinien mit aktiviertem Dual-Stack-Netzwerk anwenden. Wenn bei der Aktivierung von Dual-Stack-Netzwerken in GKE-Clustern, die von Version 1.24 auf Version 1.25 oder 1.26 aktualisiert wurden, Validierungsfehler auftreten, wenden Sie sich an das Google Cloud Supportteam.

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 Google Cloud VPC-Netzwerktypen.
• 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. Berücksichtigen 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:

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

Architektur

In 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 einem 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:

IPv6-Adresszuweisung in GKE.

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 IPv4/IPv6-Dual-Stack-Service vom Typ ClusterIP oder NodePort erstellen. Neue GKE-Cluster mit Version 1.29 oder höher unterstützen Dual-Stack-Dienste vom Typ LoadBalancer.

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