VPC-native Cluster

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.

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 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 Dienstadressen (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 erstellen können, ist ein /28. Sie sollten jedoch einen Bereich verwenden, der groß genug ist, um mindestens einen Knoten zu erstellen. Der minimal nutzbare Bereich hängt 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 Maximum Pods per Node.

Wenn Sie Ihren IP-Adressbereich für Pods erschöpfen, müssen Sie entweder einen neuen Cluster mit einem größeren Pod-Adressbereich erstellen oder Ihre Knotenpools neu erstellen, nachdem Sie --max-pods-per-node für die Knotenpools verringert haben.

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. Sie können den primären IP-Adressbereich jederzeit erweitern, auch wenn Google Cloud-Ressourcen das Subnetz verwenden. Sie können jedoch das primäre IP-Adressschema 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.

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

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. Es ist zwar möglich, den sekundären IP-Adressbereich eines Subnetzes zu ersetzen. Das wird jedoch nicht unterstützt, da es den Cluster in einen instabilen Zustand versetzen könnte.

Sie können jedoch zusätzliche Pod-IP-Adressbereiche erstellen, indem Sie nicht zusammenhängende CIDRs mit mehreren Pods verwenden.

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 und größtmögliche 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
  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.
  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.

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

Planen Sie Ihren sekundären IP-Adressbereich für Services sorgfältig. Da dies auch ein sekundärer Subnetz-IP-Adressbereich ist, können Sie ihn nur ersetzen, wenn er nicht von Google Cloud-Ressourcen verwendet wird. Dieser Bereich kann nicht geändert werden, solange er von einem Cluster für Dienste verwendet wird (Cluster-IP-Adressen).

Im Gegensatz zu Knoten- und Pod-IP-Bereichen muss jeder Cluster einen eindeutigen sekundären Subnetz-IP-Adressbereich für Services haben und darf nicht aus einem gemeinsamen primären oder sekundären IP-Adressbereich stammen.

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

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

Nächste Schritte