Routenbasierten Cluster erstellen

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

Übersicht

In Google Kubernetes Engine 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 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:

Mit den folgenden Methoden können Sie die gcloud-Einstellungen festlegen:

  • Verwenden Sie gcloud init, wenn Sie die Standardeinstellungen ansehen möchten.
  • Verwenden Sie gcloud config, um Ihre Projekt-ID, Zone und Region individuell festzulegen.

gcloud init verwenden

Wenn Sie die Fehlermeldung One of [--zone, --region] must be supplied: Please specify location erhalten, führen Sie diesen Abschnitt aus.

  1. Führen Sie gcloud init aus und folgen Sie der Anleitung:

    gcloud init

    Wenn Sie SSH auf einem Remote-Server verwenden, können Sie mit dem Flag --console-only verhindern, dass mit dem Befehl ein Browserfenster geöffnet wird:

    gcloud init --console-only
  2. Folgen Sie der Anleitung, um gcloud zur Verwendung Ihres Google Cloud-Kontos zu autorisieren.
  3. Erstellen Sie eine neue Konfiguration oder wählen Sie eine vorhandene aus.
  4. Wählen Sie ein Google Cloud-Projekt aus.
  5. Wählen Sie eine Compute Engine-Standardzone aus.

gcloud config verwenden

  • Legen Sie Ihre standardmäßige Projekt-ID fest:
    gcloud config set project project-id
  • Wenn Sie mit zonalen Clustern arbeiten, legen Sie die Compute-Standardzone fest: 
    gcloud config set compute/zone compute-zone
  • Wenn Sie mit regionalen Clustern arbeiten, legen Sie die Standardregion für Compute Engine fest:
    gcloud config set compute/region compute-region
  • Aktualisieren Sie gcloud auf die neueste Version:
    gcloud components update

Routenbasierten Cluster erstellen

Sie können einen routenbasierten Cluster mit dem gcloud-Tool 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

Dabei ist [CLUSTER_NAME] der Name, den Sie für Ihren Cluster auswählen.

Console

  1. Rufen Sie in der Cloud Console das Kubernetes Engine-Menü auf.

    Zum Google Kubernetes Engine-Menü

  2. Klicken Sie auf Cluster erstellen.

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

  4. Klicken Sie im Navigationsbereich unter Cluster auf Netzwerke.

  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.

Prüfen, ob der Cluster Routen verwendet

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 der 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 der Ausgabe sehen Sie, dass die Route einen nächsten Hop für jedes Paket bereitstellt, das für einen bestimmten Pod-Adressbereich bestimmt ist.

Console

  1. Rufen Sie in der Cloud Console das Kubernetes Engine-Menü auf.

    Zum Google Kubernetes Engine-Menü

  2. Klicken Sie auf den Namen Ihres Clusters, um eine Seite mit Details zum Cluster zu öffnen.

  3. Suchen Sie unter Knotenpools den Eintrag Instanzgruppen und klicken Sie auf den Namen Ihrer Instanzgruppe. Die Seite Instanzgruppen wird mit einer Liste der Clusterknoten geöffnet. Notieren Sie sich die Knotennamen.

  4. Rufen Sie in der GCP Console die Seite "Routen" auf.

    Seite "Routen" aufrufen

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

  6. Auf der daraufhin geöffneten Seite Routendetails sehen Sie, dass die Route einen nächsten Hop für jedes Paket bereitstellt, das für einen bestimmten Pod-Adressbereich bestimmt ist.

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. Beispielsweise sieht die Ausgabe von gcloud container clusters describe in etwa so aus:

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

Ab GKE-Version 1.7 kann der Pod-Adressbereich aus einem beliebigen RFC 1918-Block stammen: 10.0.0.0/8, 172.16.0.0/12 oder 192.168.0.0/16. Bei früheren Versionen muss der Pod-Adressbereich aus 10.0.0.0/8 stammen.

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

Dabei ist [CLUSTER_NAME] der Name, den Sie für den Cluster auswählen.

Console

  1. Rufen Sie in der Cloud Console das Kubernetes Engine-Menü auf.

    Zum Google Kubernetes Engine-Menü

  2. Klicken Sie auf Cluster erstellen.

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

  4. Klicken Sie im Navigationsbereich unter Cluster auf Netzwerke.

  5. Geben Sie unter Erweiterte Netzwerkoptionen für das Feld Pod-Adressbereich den Wert 10.96.0.0/16 ein.

  6. Klicken Sie auf Erstellen.

Hinweise zur Größenanpassung bei 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 vier reservierten 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.

Nächste Schritte