Routenbasierten Cluster erstellen

Auf dieser Seite wird gezeigt, wie Sie einen routenbasierten Cluster in Google Kubernetes Engine (GKE) erstellen.

Übersicht

In GKE lassen sich Cluster anhand der Methode unterscheiden, mit der sie Traffic von einem Pod zu einem anderen weiterleiten. Ein Cluster, der Google Cloud-Routen verwendet, wird als routenbasierter Cluster bezeichnet. Ein Cluster, der auf Alias-IP-Adressen zurückgreift, wird als VPC-nativer Cluster bezeichnet.

VPC-nativ ist der empfohlene Typ und wird standardmäßig für neue Cluster in den GKE-Versionen 1.21.0-gke.1500 und höher verwendet. Sie müssen die VPC-native Option explizit deaktivieren, um einen routenbasierten Cluster zu erstellen.

Vorbereitung

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API.
    • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.

Routenbasierten Cluster erstellen

Sie können einen routenbasierten Cluster mit der gcloud CLI oder der Google Cloud Console erstellen.

gcloud

Zum Erstellen eines routenbasierten Clusters fügen Sie im Befehl zur Clustererstellung das Flag --no-enable-ip-alias hinzu:

gcloud container clusters create CLUSTER_NAME --no-enable-ip-alias

Ersetzen Sie CLUSTER_NAME durch einen Namen, den Sie für Ihr Cluster auswählen.

Console

  1. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

    Zur Seite „Google Kubernetes Engine“

  2. Klicken Sie auf Erstellen.

  3. Geben Sie einen Namen für den Cluster ein.

  4. Klicken Sie im Navigationsbereich unter Cluster auf Netzwerk.

  5. Entfernen Sie unter Erweiterte Netzwerkoptionen das Häkchen aus dem Kästchen VPC-natives Traffic-Routing aktivieren (verwendet Alias-IP-Adresse).

  6. Klicken Sie auf Erstellen.

Routenbasierten Cluster erstellen und IP-Bereich der Steuerungsebene auswählen

Standardmäßig verwenden Cluster mit Private Service Connect den primären Subnetzbereich, um die interne IP-Adresse bereitzustellen, die dem Endpunkt der Steuerungsebene zugewiesen ist. Sie können diese Standardeinstellung überschreiben, wenn Sie nur während der Clustererstellung einen anderen Subnetzbereich auswählen. In den folgenden Abschnitten erfahren Sie, wie Sie einen Cluster mit Private Service Connect erstellen und den Subnetzbereich überschreiben.

gcloud

Erstellen Sie einen Cluster mit Private Service Connect:

gcloud container clusters create CLUSTER_NAME --no-enable-ip-alias \
    --private-endpoint-subnetwork=SUBNET_NAME \
    --region=COMPUTE_REGION

Ersetzen Sie Folgendes:

  • CLUSTER_NAME ist der Name des GKE-Clusters.
  • SUBNET_NAME: Der Name eines vorhandenen Subnetzes.
  • COMPUTE_REGION: die Compute-Region für den Cluster. Zum Erstellen eines zonalen Clusters ersetzen Sie dieses Flag durch --zone=COMPUTE_ZONE, wobei COMPUTE_ZONE eine Computing-Zone ist.

Console

Voraussetzung

Um ein Subnetz der Steuerungsebene eines neuen Clusters zuzuweisen, müssen Sie zuerst ein Subnetz hinzufügen.

Cluster erstellen und IP-Bereich der Steuerungsebene zuweisen

  1. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

    Zur Seite „Google Kubernetes Engine“

  2. Klicken Sie auf Erstellen.

  3. Geben Sie einen Namen für den Cluster ein.

  4. Klicken Sie im Navigationsbereich unter Cluster auf Netzwerk.

  5. Führen Sie im Abschnitt IPv4-Netzwerkzugriff die folgenden Schritte aus:

    1. Wählen Sie das Optionsfeld Öffentlicher Cluster aus, um einen GKE-Cluster als öffentlich zu erstellen.
    2. Wählen Sie das Optionsfeld Privater Cluster aus, um einen GKE-Cluster als privat zu erstellen.

    In beiden Fällen können Sie später den Modus der Clusterisolierung ändern, wenn Sie die Clusterkonfiguration bearbeiten.

  6. Klicken Sie im Bereich Erweiterte Netzwerkoptionen das Kästchen Standardsubnetz des privaten Endpunkts der Steuerungsebene überschreiben an.

  7. Wählen Sie in der Liste Subnetz des privaten Endpunkts das erstellte Subnetz aus.

  8. Entfernen Sie das Häkchen aus dem Kästchen VPC-natives Traffic-Routing aktivieren (verwendet Alias-IP-Adresse).

  9. Klicken Sie auf Erstellen.

Cluster auf Routen prüfen

gcloud

Listen Sie die Clusterknoten auf:

kubectl get nodes

Die Ausgabe zeigt die Namen der Knoten:

NAME                                 STATUS   ...     AGE    VERSION
gke-xxx-default-pool-83e239a7-kcg8   Ready    ...     42m    v1.9.7-gke.6
gke-xxx-default-pool-83e239a7-qm6b   Ready    ...     42m    v1.9.7-gke.6
gke-xxx-default-pool-83e239a7-wnrq   Ready    ...     42m    1.9.7-gke.6

Listen Sie die Routen auf:

gcloud compute routes list

Suchen Sie in dieser Ausgabe unter der Spalte NEXT_HOP nach dem Namen eines Ihrer Clusterknoten:

NAME                 NETWORK        DEST_RANGE         NEXT_HOP
...
[ROUTE_NAME]         default        10.24.0.0/24       [YOUR_NODE_NAME]
...

In dieser Ausgabe stellt die Route einen nächsten Hop für jedes Paket bereit, das für einen bestimmten Pod-Adressbereich bestimmt ist.

Console

  1. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

    Zur Seite "Google Kubernetes Engine"

  2. Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie inspizieren möchten.

  3. Klicken Sie auf der Seite Clusterdetails auf den Tab Knoten.

  4. Notieren Sie sich im Abschnitt Knoten die Namen der Knoten.

  5. Rufen Sie in der Google Cloud Console die Seite Routen auf.

    Zur Seite „Routes“

  6. Suchen Sie in der Liste der Routen in der Spalte Nächster Hop nach dem Namen eines Ihrer Clusterknoten. Klicken Sie auf den Routennamen in dieser Zeile.

  7. Überprüfen Sie auf der Seite Routendetails den Abschnitt Nächster Hop, um sicherzustellen, dass die Route einen nächsten Hop für alle Pakete vorsieht, die für einen bestimmten Pod-Adressbereich bestimmt sind.

Pods pro Knoten

In einem routenbasierten Cluster wird jedem Knoten ein /24-Bereich von IP-Adressen für Pods zugewiesen. Ein /24-Bereich umfasst 256 Adressen, allerdings liegt die maximale Anzahl von Pods pro Knoten bei 110. Im Verhältnis zu den möglichen Pods sind also etwa doppelt so viele IP-Adressen verfügbar. Die Wiederverwendung von IP-Adressen lässt sich dadurch in Kubernetes reduzieren, wenn Pods einem Knoten hinzugefügt und daraus entfernt werden.

Pod-Adressbereich

Ein routenbasierter Cluster hat einen Bereich von IP-Adressen, die für Pods und Dienste verwendet werden. Obwohl der Bereich sowohl für Pods als auch für Dienste zum Einsatz kommt, wird er Pod-Adressbereich genannt. Der letzte /20-Bereich des Pod-Adressbereichs wird für Dienste verwendet. Ein /20-Bereich hat 212 = 4.096 Adressen. Somit werden 4.096 Adressen für Dienste und der Rest des Bereichs für Pods verwendet.

In der Befehlsausgabe heißt der Pod-Adressbereich clusterIpv4Cidr und der für Dienste verwendete Adressbereich servicesIpv4Cidr. Die Ausgabe von gcloud container clusters describe enthält beispielsweise eine Ausgabe ähnlich der folgenden:

clusterIpv4Cidr: 10.96.0.0/16
...
servicesIpv4Cidr: 10.96.240.0/20

Der Pod-Adressbereich kann aus einem beliebigen RFC 1918-Block stammen: 10.0.0.0/8, 172.16.0.0/12 oder 192.168.0.0/16.

Durch Angabe eines CIDR-Bereichs lässt sich der Pod-Adressbereich anpassen. Beispielsweise könnten Sie den Bereich 10.96.0.0/16 angeben.

gcloud

gcloud container clusters create CLUSTER_NAME \
    --no-enable-ip-alias \
    --cluster-ipv4-cidr 10.96.0.0/16

Ersetzen Sie CLUSTER_NAME durch einen Namen, den Sie für Ihr Cluster auswählen.

Console

  1. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

    Zur Seite „Google Kubernetes Engine“

  2. Klicken Sie auf Erstellen.

  3. Geben Sie einen Namen für den Cluster ein.

  4. Klicken Sie im Navigationsbereich unter Cluster auf Netzwerk.

  5. Entfernen Sie unter Erweiterte Netzwerkoptionen das Häkchen aus dem Kästchen VPC-natives Traffic-Routing aktivieren (verwendet Alias-IP-Adresse).

  6. Geben Sie im Feld Pod-Adressbereich 10.96.0.0/16 ein.

  7. Klicken Sie auf Erstellen.

Hinweise zur Größenanpassung von Clustern

Die maximale Anzahl von Knoten und Diensten für einen bestimmten GKE-Cluster wird durch die Größe des Clustersubnetzes und die Größe des Pod-Adressbereichs bestimmt. Nach dem Erstellen eines Clusters können Sie die Größe des Pod-Adressbereichs nicht mehr ändern. Sorgen Sie beim Erstellen eines Clusters deshalb dafür, dass Sie einen Pod-Adressbereich auswählen, der groß genug ist, um das erwartete Wachstum des Clusters aufzufangen.

In der folgenden Tabelle wird erläutert, wie Sie Adressbereiche auswählen, die für einen Cluster mit 900 Knoten ausreichen:

Bereich Hinweise
Knoten

Knoten-IP-Adressen werden aus dem primären Bereich des Clustersubnetzes zugewiesen. Ihr Clustersubnetz muss groß genug sein, um die Gesamtzahl der Knoten in Ihrem Cluster unterzubringen.

Wenn Sie beispielsweise einen Cluster mit 900 Knoten erstellen möchten, muss das mit dem Cluster verwendete Subnetz mindestens eine Größe von /22 haben. Ein /22-Bereich hat 210 = 1.024 Adressen. Wenn Sie die 4 nicht verwendbaren IP-Adressen abziehen, erhalten Sie 1.020 Adressen, was für die 900 Knoten ausreicht.
Pod-Adressbereich

Jeder Knoten hat einen /24-IP-Adressbereich für Pods. Ein /24-Bereich hat 28 = 256 Adressen. Wie bereits erwähnt, werden 4.096 Adressen im Pod-Adressbereich für Dienste verwendet. Der verbleibende Teil des Pod-Adressbereichs wird für Pods verwendet und muss groß genug sein, um die Anzahl der Knoten x 256 Adressen unterzubringen.

Angenommen, Sie möchten einen Cluster mit 900 Knoten erstellen. In diesem Fall benötigen Sie 900 x 256 = 230.400 Adressen für Pods. Außerdem haben Sie einen /14-Pod-Adressbereich. Ein /14-Bereich hat 218 = 262.144 Adressen. Wenn Sie jetzt die für Dienste verwendeten 4.096 Adressen abziehen, erhalten Sie 258.048 Adressen, was für 900 Knoten ausreicht.

Standardeinstellungen und Limits für Bereichsgrößen

In der folgenden Tabelle sind die Mindest-, Maximal- und Standardgrößen für das Clustersubnetz und den Pod-Adressbereich aufgeführt.

Bereich Standardgröße Mindestgröße Maximalgröße
Knoten

/20, was 212 = 4.096 Adressen sind. Wenn Sie vier reservierte Adressen abziehen, erhalten Sie 4.092 Adressen für Knoten.

/29, was 23 = 8 Adressen sind. Wenn Sie vier reservierte Adressen abziehen, erhalten Sie vier Adressen für Knoten.

/7, was 225 Adressen sind. Dies ergibt ungefähr 33 Millionen Adressen für Knoten.
Pod-Adressbereich

/14, was 218 = 262.144 Adressen sind.

/19, was 213 = 8.192 Adressen sind.

/9, was 223 = 8.388.608 Adressen sind.

Beschränkungen

  • Sie können einen VPC-nativen Cluster nicht zu einem routenbasierten Cluster migrieren.
  • Sie können einen routenbasierten Cluster nicht zu einem VPC-nativen Cluster migrieren.
  • Routenbasierte Cluster können für private IP-Adressen nur Adressen im Bereich RFC 1918 verwenden. VPC-native Cluster haben einen größeren Bereich verwendbarer Adressen.
  • Routenbasierte Cluster unterstützen kein Dual-Stack-Netzwerk.

Nächste Schritte