Multi-Cluster-Ingress einrichten


Auf dieser Seite wird beschrieben, wie Sie Traffic mithilfe von Multi-Cluster-Ingress über mehrere Google Kubernetes Engine-Cluster (GKE) in verschiedenen Regionen weiterleiten, anhand eines Beispiels mit zwei Clustern.

Einen detaillierten Vergleich zwischen dem Multi-Cluster-Ingress (MCI), Multi-Cluster-Gateway (MCG) und dem Load Balancer mit eigenständigen Netzwerk-Endpunktgruppen (LB und eigenständige NEGs) finden Sie unter Multi-Cluster-Load-Balancing-API für GKE auswählen.

Weitere Informationen zum Bereitstellen von Multi-Cluster-Ingress finden Sie unter Ingress clusterübergreifend bereitstellen.

Diese Schritte erfordern erhöhte Berechtigungen und sollten von einem GKE-Administrator ausgeführt werden.

Hinweis

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.

Anforderungen und Einschränkungen

Für Multi-Cluster-Ingress gelten folgende Anforderungen:

  • Google Cloud CLI ab Version 290.0.0

Wenn Sie Cluster im Standardmodus verwenden, müssen Sie die folgenden Anforderungen erfüllen. Autopilot-Cluster erfüllen diese Anforderungen bereits.

  • Bei Clustern muss das Add-on HttpLoadBalancing aktiviert sein. Dieses Add-on ist standardmäßig aktiviert. Sie dürfen es nicht deaktivieren.
  • Cluster müssen VPC-nativ sein.
  • Für Cluster muss die Workload Identity-Föderation für GKE aktiviert sein.

Für den Multi-Cluster-Ingress gelten folgende Einschränkungen:

  • Wird nur mit einem externen Application Load Balancer unterstützt.
  • Erstellen Sie keine Compute Engine-Load-Balancer im selben Projekt mit dem Präfix mci-, die nicht von Multi-Cluster-Ingress verwaltet werden, da sie sonst gelöscht werden. Google Cloud verwendet das Präfix mci-[6 char hash], um die Compute Engine-Ressourcen zu verwalten, die von Multi-Cluster-Ingress bereitgestellt werden.
  • Die Konfiguration von HTTPS erfordert eine vorab zugewiesene statische IP-Adresse. HTTPS wird nicht für sitzungsspezifische IP-Adressen unterstützt.

Übersicht

Führen Sie in dieser Übung die folgenden Schritte aus:

  1. Wählen Sie die Preise aus, die Sie verwenden möchten.
  2. Stellen Sie Cluster bereit.
  3. Konfigurieren Sie Clusteranmeldedaten.
  4. Registrieren Sie die Cluster bei einer Flotte.
  5. Geben Sie ein Konfigurationscluster an. Dieser Cluster kann als dedizierte Steuerungsebene dienen oder andere Arbeitslasten ausführen.

Das folgende Diagramm zeigt, wie Ihre Umgebung nach Abschluss der Übung aussehen wird:

Grafik: Clustertopologie zeigt die Beziehungen zwischen Regionen, Flotte und Projekt

Im Diagramm gibt es zwei GKE-Cluster mit den Namen gke-us und gke-eu in den Regionen europe-west1 und us-central1. Die Cluster werden zu einer Flotte registriert, damit der Multi-Cluster-Ingress-Controller sie erkennen kann. Mit einer Flotte können Sie GKE-Cluster logisch gruppieren und normalisieren, um die Verwaltung der Infrastruktur zu vereinfachen und die Verwendung von Multi-Cluster-Features wie Multi-Cluster-Ingress zu ermöglichen. Weitere Informationen zu den Vorteilen von Flotten und deren Erstellung finden Sie in der Dokumentation zur Flottenverwaltung.

Preise auswählen

Wenn Multi-Cluster-Ingress die einzige GKE Enterprise-Funktion ist, die Sie verwenden, empfehlen wir die Verwendung eines eigenständigen Preises. Wenn Ihr Projekt andere Komponenten oder Funktionen von GKE Enterprise in Google Cloud verwendet, sollten Sie die gesamte GKE Enterprise-Plattform aktivieren. So können Sie alle GKE Enterprise-Features für eine einzelne vCPU pro Nutzung verwenden.

Welche APIs aktiviert werden müssen, hängt von den verwendeten Multi-Cluster-Ingress-Preisen ab.

  • Wenn die GKE Enterprise API (anthos.googleapis.com) aktiviert ist, wird Ihr Projekt entsprechend der Anzahl der Cluster-vCPUs und der GKE Enterprise-Preise in Rechnung gestellt.
  • Wenn die GKE Enterprise API deaktiviert ist, wird Ihr Projekt entsprechend der Anzahl der Backend-Multi-Cluster-Ingress-Pods in Ihrem Projekt abgerechnet.

Sie können das Abrechnungsmodell für Multi-Cluster-Ingress jederzeit von eigenständig zu GKE Enterprise ändern oder umgekehrt von GKE Enterprise zu einem eigenständigen, ohne Auswirkungen auf Multi-Cluster-Ingress-Ressourcen oder Traffic.

Eigenständige Preise

Führen Sie die folgenden Schritte aus, um die eigenständige Preisgestaltung zu aktivieren:

  1. Prüfen Sie, ob die GKE Enterprise API in Ihrem Projekt deaktiviert ist:

    gcloud services list --project=PROJECT_ID | grep anthos.googleapis.com
    

    Ersetzen Sie PROJECT_ID durch die Projekt-ID, auf der die GKE-Cluster ausgeführt werden.

    Wenn die Ausgabe eine leere Antwort ist, ist die GKE Enterprise API in Ihrem Projekt deaktiviert und alle Multi-Cluster-Ingress-Ressourcen werden über eigenständige Preise abgerechnet.

  2. Erforderliche APIs im Projekt aktivieren:

    gcloud services enable \
        multiclusteringress.googleapis.com \
        gkehub.googleapis.com \
        container.googleapis.com \
        multiclusterservicediscovery.googleapis.com \
        --project=PROJECT_ID
    

GKE Enterprise – Preise

Zum Aktivieren der GKE Enterprise-Preise aktivieren Sie die erforderlichen APIs in Ihrem Projekt:

gcloud services enable \
    anthos.googleapis.com \
    multiclusteringress.googleapis.com \
    gkehub.googleapis.com \
    container.googleapis.com \
    multiclusterservicediscovery.googleapis.com \
    --project=PROJECT_ID

Nachdem anthos.googleapis.com in Ihrem Projekt aktiviert ist, werden alle bei Connect registrierten Cluster gemäß den GKE Enterprise-Preisen abgerechnet.

Cluster bereitstellen

Erstellen Sie zwei GKE-Cluster mit den Namen gke-us und gke-eu in den Regionen europe-west1 und us-central1.

Autopilot

  1. Erstellen Sie den Cluster gke-us in der Region us-central1:

    gcloud container clusters create-auto gke-us \
        --region=us-central1 \
        --release-channel=stable \
        --project=PROJECT_ID
    

    Ersetzen Sie PROJECT_ID durch die Google Cloud-Projekt-ID.

  2. Erstellen Sie den Cluster gke-eu in der Region europe-west1:

    gcloud container clusters create-auto gke-eu \
        --region=europe-west1 \
        --release-channel=stable \
        --project=PROJECT_ID
    

Standard

Erstellen Sie die beiden Cluster mit aktivierter Workload Identity-Föderation für GKE.

  1. Erstellen Sie den Cluster gke-us in der Region us-central1:

    gcloud container clusters create gke-us \
        --region=us-central1 \
        --enable-ip-alias \
        --workload-pool=PROJECT_ID.svc.id.goog \
        --release-channel=stable \
        --project=PROJECT_ID
    

    Ersetzen Sie PROJECT_ID durch die Google Cloud-Projekt-ID.

  2. Erstellen Sie den Cluster gke-eu in der Region europe-west1:

    gcloud container clusters create gke-eu \
        --region=europe-west1 \
        --enable-ip-alias \
        --workload-pool=PROJECT_ID.svc.id.goog \
        --release-channel=stable \
        --project=PROJECT_ID
    

Clusteranmeldedaten konfigurieren

Konfigurieren Sie die Anmeldeinformationen für Ihre Cluster und benennen Sie die Clusterkontexte um, damit Sie bei der Bereitstellung von Ressourcen leichter zwischen den Clustern wechseln können.

  1. Rufen Sie die Anmeldedaten für Ihre Cluster ab:

    gcloud container clusters get-credentials gke-us \
        --region=us-central1 \
        --project=PROJECT_ID
    
    gcloud container clusters get-credentials gke-eu \
        --region=europe-west1 \
        --project=PROJECT_ID
    

    Die Anmeldedaten werden lokal gespeichert, damit Sie mit dem kubectl-Client auf die Cluster API-Server zugreifen können. Standardmäßig wird für die Anmeldedaten ein automatisch generierter Name erstellt.

  2. Benennen Sie die Clusterkontexte um:

    kubectl config rename-context gke_PROJECT_ID_us-central1_gke-us gke-us
    kubectl config rename-context gke_PROJECT_ID_europe-west1_gke-eu gke-eu
    

Cluster in einer Flotte registrieren

Registrieren Sie Ihre Cluster so in der Flotte Ihres Projekts:

  1. Cluster registrieren

    gcloud container fleet memberships register gke-us \
        --gke-cluster us-central1/gke-us \
        --enable-workload-identity \
        --project=PROJECT_ID
    
    gcloud container fleet memberships register gke-eu \
        --gke-cluster europe-west1/gke-eu \
        --enable-workload-identity \
        --project=PROJECT_ID
    
  2. Prüfen Sie, ob Ihre Cluster erfolgreich für die Flotte registriert wurden:

    gcloud container fleet memberships list --project=PROJECT_ID
    

    Die Ausgabe sieht in etwa so aus:

    NAME                                  EXTERNAL_ID
    gke-us                                0375c958-38af-11ea-abe9-42010a800191
    gke-eu                                d3278b78-38ad-11ea-a846-42010a840114
    

Nachdem Sie Ihre Cluster registriert haben, stellt GKE den Pod gke-mcs-importer in Ihrem Cluster bereit.

Weitere Informationen zum Registrieren von Clustern finden Sie unter GKE-Cluster bei Ihrer Flotte registrieren.

Konfigurationscluster angeben

Der Konfigurationscluster ist ein GKE-Cluster, den Sie als zentralen Kontrollpunkt für Ingress in den Mitgliedsclustern festlegen. Dieser Cluster muss bereits bei der Flotte registriert sein. Weitere Informationen finden Sie unter Clusterdesign konfigurieren.

Aktivieren Sie Multi-Cluster-Ingress und wählen Sie gke-us als Konfigurationscluster aus:

gcloud container fleet ingress enable \
    --config-membership=gke-us \
    --location=us-central1 \
    --project=PROJECT_ID

Die Registrierung des Konfigurationsclusters dauert bis zu 15 Minuten. Die Ausgabe sieht etwa so aus:

Waiting for Feature to be created...done.
Waiting for controller to start...done.

Die nicht erfolgreiche Ausgabe sieht etwa so aus:

Waiting for controller to start...failed.
ERROR: (gcloud.container.fleet.ingress.enable) Controller did not start in 2 minutes. Please use the `describe` command to check Feature state for debugging information.

Wenn im vorherigen Schritt ein Fehler aufgetreten ist, überprüfen Sie den Funktionsstatus:

gcloud container fleet ingress describe \
    --project=PROJECT_ID

Die erfolgreiche Ausgabe sieht etwa so aus:

createTime: '2021-02-04T14:10:25.102919191Z'
membershipStates:
 projects/PROJECT_ID/locations/global/memberships/CLUSTER_NAME:
 state:
   code: ERROR
   description: '...is not a VPC-native GKE Cluster.'
   updateTime: '2021-08-10T13:58:50.298191306Z'
 projects/PROJECT_ID/locations/global/memberships/CLUSTER_NAME:
 state:
   code: OK
   updateTime: '2021-08-10T13:58:08.499505813Z'

Weitere Informationen zur Fehlerbehebung bei Multi-Cluster-Ingress finden Sie unter Fehlerbehebung und Betrieb.

Freigegebene VPC

Sie können eine MultiClusterIngress-Ressource für Cluster in einem freigegebenen VPC-Netzwerk bereitstellen, aber alle zugehörigen Backend-GKE-Cluster müssen sich im selben Projekt befinden. GKE-Cluster in verschiedenen Projekten mit derselben Cloud Load Balancing-VIP werden nicht unterstützt.

In nicht freigegebenen VPC-Netzwerken verwaltet der Multi-Cluster-Ingress-Controller Firewallregeln, um Systemdiagnosen vom Load-Balancer an Containerarbeitslasten zu ermöglichen.

In einem freigegebenen VPC-Netzwerk muss ein Hostprojektadministrator die Firewallregeln für den Load-Balancer-Traffic manuell im Namen des Multi-Cluster-Ingress-Controllers erstellen.

Der folgende Befehl zeigt die Firewallregel, die Sie erstellen müssen, wenn sich Ihre Cluster in einem freigegebenen VPC-Netzwerk befinden. Die Quellbereiche sind die Bereiche, über die der Load-Balancer Traffic an Back-Ends sendet. Diese Regel muss für die Betriebsdauer einer MultiClusterIngress-Ressource vorhanden sein.

Wenn sich Ihre Cluster in einem freigegebenen VPC-Netzwerk befinden, erstellen Sie die Firewallregel:

gcloud compute firewall-rules create FIREWALL_RULE_NAME \
    --project=HOST_PROJECT \
    --network=SHARED_VPC \
    --direction=INGRESS \
    --allow=tcp:0-65535 \
    --source-ranges=130.211.0.0/22,35.191.0.0/16

Dabei gilt:

  • FIREWALL_RULE_NAME: der Name der neuen Firewallregel, die Sie auswählen.
  • HOST_PROJECT: ID des freigegebenen VPC-Hostprojekts.
  • SHARED_VPC: Name des freigegebenen VPC-Netzwerks.

Bekannte Probleme

In diesem Abschnitt werden bekannte Probleme für Multi-Cluster-Ingress beschrieben.

InvalidValueError für das Feld config_membership

Ein bekanntes Problem verhindert, dass das Google Cloud CLI mit Multi Cluster Ingress interagiert. Dieses Problem wurde in Version 346.0.0 eingeführt und in Version 348.0.0 behoben. Die Verwendung der gcloud CLI-Versionen 346.0.0 und 347.0.0 mit Multi-Cluster-Ingress wird nicht empfohlen.

Ungültiger Wert für das Feld "resource"

Google Cloud Armor kann nicht mit Konfigurationsclustern mit Multi-Cluster-Ingress kommunizieren, die auf den folgenden GKE-Versionen ausgeführt werden:

  • 1.18.19-gke.1400 und höher
  • 1.19.10-gke.700 und höher
  • 1.20.6-gke.700 und höher

Wenn Sie eine Google Cloud Armor-Sicherheitsrichtlinie konfigurieren, wird die folgende Meldung angezeigt:

Invalid value for field 'resource': '{"securityPolicy": "global/securityPolicies/"}': The given policy does not exist

Um dieses Problem zu vermeiden, aktualisieren Sie Ihren Konfigurationscluster auf Version 1.21 oder höher oder aktualisieren Sie die BackendConfig CustomResourceDefinition mit dem folgenden Befehl:

kubectl patch crd backendconfigs.cloud.google.com --type='json' -p='[{"op": "replace", "path": "/spec/versions/1/schema/openAPIV3Schema/properties/spec/properties/securityPolicy", "value":{"properties": {"name": {"type": "string"}}, "required": ["name" ],"type": "object"}}]'

Nächste Schritte