Multi-Cluster-Netzwerke sind ein wertvolles Tool, das Anwendungsfälle wie regionale Hochverfügbarkeit, global verteilte Nähe zu Nutzern für geringere Latenz und die organisatorische Isolierung zwischen Teams ermöglicht. Google Kubernetes Engine (GKE) bietet integrierte Funktionen für Multi-Cluster-Netzwerke, die Sie in großem Maßstab für eine Flotte von GKE-Clustern aktivieren und verwenden können. Mit diesem Feature können Sie auch die bereitgestellte Infrastruktur zwischen GKE Standard und Autopilot kombinieren oder migrieren, um die Architekturanforderungen jeder Anwendung zu erfüllen.
In diesem Dokument werden diese Features anhand mehrerer Bereitstellungstopologien veranschaulicht. Sie erfahren, wie Sie eine Anwendung in einem einzelnen GKE-Cluster verwenden und zu einer Multi-Cluster-Bereitstellung in GKE Standard- und Autopilot-Clustern migrieren. Sie verwenden Multi-Cluster-Services von GKE für Ost-West-Traffic sowie Multi-Cluster-Gateways, um Multi-Cluster-Nord-Süd-Netzwerke zu ermöglichen.
Das Dokument richtet sich an Cloud-Architekten und operative Teams, die GKE verwenden oder zu verwenden planen, um Dienste in mehreren Kubernetes-Clustern bereitzustellen. In diesem Dokument wird davon ausgegangen, dass Sie mit Kubernetes vertraut sind.
GKE Standard und GKE Autopilot
GKE bietet eine verwaltete Kubernetes-Bereitstellung mit einem umfassenden Feature-Set, einschließlich einer Steuerungsebene mit Hochverfügbarkeit. GKE-Cluster können schnell gestartet und auf bis zu 15.000 Knoten skaliert werden. Mit GKE-Autopilot-Clustern verwaltet Google die Infrastruktur, einschließlich der Steuerungsebene und der Knoten. Wenn Sie Ihre Knoten stattdessen konfigurieren und verwalten möchten, bietet GKE den Standardmodus.
Weitere Informationen zu den Unterschieden zwischen den Modi finden Sie unter Clustermodus auswählen.
Multi-Cluster-Services und Multi-Cluster-Gateways
Kubernetes kann mit einer einzigen Steuerungsebene für verschiedene Cloud-Zonen ausgeführt werden, um Ausfallsicherheit und Hochverfügbarkeit für Ihre Dienste zu gewährleisten.
GKE geht noch einen Schritt weiter und bietet Multi-Cluster-Services (MCS) von GKE, die einen clusterübergreifenden Service-Discovery- und Aufrufmechanismus bieten.
Dienste, die dieses Feature verwenden, sind durch eine virtuelle IP-Adresse über Cluster hinweg sichtbar und zugänglich, was dem Verhalten eines ClusterIP-Service entspricht, auf den in einem Cluster zugegriffen werden kann. Dieser Ansatz bietet folgende Vorteile:
- Für Dienste kann ein Load-Balancing über mehrere Cluster hinweg in derselben Region oder in verschiedenen Regionen (Ost-West-Traffic) erfolgen.
- Hochverfügbarkeitsoptionen für regionenübergreifende Dienste sind erreichbar.
- Zustandsorientierte und zustandslose Arbeitslasten können in separaten Clustern bereitgestellt und verwaltet werden.
- Freigegebene Dienste sind clusterübergreifend verfügbar.
Weitere Informationen zum Bereitstellen von MCS finden Sie unter Multi-Cluster-Services konfigurieren.
GKE bietet eine Implementierung der Kubernetes Gateway API, die den GKE-Gateway-Controller verwendet. Das Gateway ermöglicht GKE, Google Cloud-Load-Balancer bereitzustellen, um Routing von eingehendem Nord-Süd-Traffic für in GKE bereitgestellte Dienste zu bieten. GKE bietet außerdem Multi-Cluster-Gateways (MCG), die den GKE-Gateway-Controller erweitern, um Load-Balancer bereitzustellen, die Traffic an Dienste weiterleiten, die in verschiedenen GKE-Clustern bereitgestellt sind.
Das folgende Diagramm zeigt, wie Sie bei der Kombination von MCS und MCG die ergänzenden Aspekte der Dienstbereitstellung und des Traffic-Routings über eine einzige Steuerungsebene verwalten können:
Weitere Informationen finden Sie unter Multi-Cluster-Gateways bereitstellen.
Übersicht über die Migration
GKE-Multi-Cluster-Netzwerkfunktionen sind vorteilhaft für Arbeitslasten unterschiedlicher Profile. Angenommen, Sie haben zustandslose Komponenten mit stoßweisem Traffic, die Sie aufgrund des effizienteren Kostenmodells zu Autopilot verschieben möchten.
Oder Sie möchten die Anwendungs-Front-Ends näher an den Nutzern platzieren. Dieser Ansatz bietet eine geringere Latenz und weniger Caching, wodurch die Anwendungsleistung und die Nutzerfreundlichkeit verbessert werden. Gleichzeitig haben Sie möglicherweise zustandsorientierte Komponenten, auf die Ihre Anwendung angewiesen ist und die sich nur an einem Standort befinden können. Diese Konfiguration erfordert Nord-Süd-Multi-Cluster-Load-Balancing, um Client-Traffic an den richtigen Cluster an diesem Standort zu senden. Außerdem benötigen Sie Ost-West-Multi-Cluster-Load-Balancing, um Traffic zwischen Clustern zu senden, um die zustandsorientierten Komponenten zu erreichen.
In diesem Dokument wird mit der Cloud-Mikrodienste-Demoanwendung Online Boutique ein Multi-Cluster-Muster demonstriert, mit dem die Bereitstellung der Demo in einer einzelnen Zone verbessert werden kann. Sie beginnen mit einer Version einer Anwendung in einer einzelnen Zone. Anschließend fügen Sie Elemente mit Hochverfügbarkeit und Ausfallsicherheit hinzu, indem Sie Multi-Cluster-Services und Multi-Cluster-Gateways verwenden. Durch den Einsatz von Autopilot reduzieren Sie außerdem den operativen Aufwand.
Anfängliche Bereitstellung mit einem Cluster
Im folgenden Diagramm wird die Anwendung "Online Boutique" anfänglich in einem einzelnen Cluster im GKE Standard-Modus std-west bereitgestellt und mithilfe eines LoadBalancer-Service verfügbar gemacht:
Zu Multi-Cluster-Services migrieren
Im nächsten Zwischenschritt erstellen Sie zwei zusätzliche Cluster und die zustandslosen Dienste werden in zusätzlichen Regionen bereitgestellt. Sie erstellen zwei GKE Autopilot-Cluster mit den Namen auto-east und auto-central in zwei separaten Regionen, die sich vom einzelnen std-west-GKE Standard-Cluster unterscheiden, und registrieren die Cluster bei der Google Cloud-Flotte.
Flotten sind ein Google Cloud-Konzept für die logische Organisation von Clustern und anderen Ressourcen. Durch sie können Sie Multi-Cluster-Funktionen nutzen und verwalten und einheitliche Richtlinien auf Ihre Systeme anwenden.
Sie exportieren den cartservice für den std-west-Cluster im onlineboutique-Namespace zu den neuen Flottenclustern mithilfe von ServiceExport.
Sie stellen den Frontend-Service von Online Boutique in allen drei Clustern bereit und machen ihn über einen ClusterIP-Dienst verfügbar. Anschließend exportieren Sie den Dienst mit ServiceExports in die Flotte.
Dienste wie die Middleware-Ebene von Online Boutique (z. B. productcatalog, shipping und adservice) werden ebenfalls in allen drei Clustern bereitgestellt.
Ein Pod, der in einem beliebigen Cluster in der Flotte ausgeführt wird, kann durch Senden einer Anfrage an den ClusterSet-URI für diesen Dienst auf einen exportierten Service zugreifen. Die Anfrage wird an einen Endpunkt weitergeleitet, der den Dienst unterstützt.
Der frontend-Service kann die Middleware-Dienste (z. B. productcatalogservice oder currencyservice) lokal im selben Cluster verwenden. Mit dieser Architektur können Sie eingehende Anfragen lokal in den Regionen halten, deren Frontend auf die Anfrage antwortet, und unnötige Gebühren für interregionalen Netzwerk-Traffic vermeiden.
Das folgende Diagramm veranschaulicht die beiden Multi-Cluster-Services. Der zustandslose frontend-Dienst wird in drei Clustern und der zustandsorientierte Backend-cartservice in einem einzelnen Cluster bereitgestellt. Das Diagramm zeigt außerdem, dass in diesem Zwischenschritt eingehender Traffic für den Frontend-Dienst unter Verwendung eines externen Passthrough-Network Load Balancer, der vom LoadBalancer-Service „frontend-external“ erstellt wurde, weiterhin an den ursprünglichen GKE Standard-Cluster in us-west1 weitergeleitet wird:
Zu Multi-Cluster-Gateway migrieren
Im letzten Schritt leiten Sie eingehenden Traffic für den frontend-Service von externen Clientanfragen über ein Multi-Cluster-Gateway an Dienste in mehreren Clustern in der Flotte weiter.
Ein vierter Cluster namens config-central wird der Flotte hinzugefügt, um die Konfiguration für die Gateway- und die HTTPRoute-Ressource, die als Teil dieser Konfiguration erstellt werden, zu hosten und zu verwalten. Die HTTPRoute-Ressource ordnet das Präfix / dem Frontend-ServiceImport zu.
Der Traffic für das Frontend von Online Boutique wird an einen fehlerfreien Endpunkt in einer der verfügbaren Regionen gesendet. Dieser Ansatz fügt Elemente mit Hochverfügbarkeit der Anwendungsarchitektur von Online Boutique hinzu.
Im folgenden Diagramm wird vom Multi-Cluster-Gateway ein globaler Cloud-Load-Balancer bereitgestellt, der externen Traffic an den zustandslosen frontend-Service weiterleitet, der in jedem der drei Anwendungscluster in der Flotte bereitgestellt ist.
Im endgültigen Zustand veranschaulicht dieses Muster die lose Kopplung zwischen den zustandsorientierten (cartservice und redis-cart) und zustandslosen Teilen der Anwendung (frontend, emailservice, checkoutservice, recommendationservice, paymentservice, productcatalogservice, currencyservice, shippingservice und adservice). Dieser Ansatz würde zwar den Rahmen dieses Dokuments sprengen, aber er bietet Ihnen in Zukunft die Möglichkeit, der Ebene der zustandsorientierten Dienste Ausfallsicherheit und Hochverfügbarkeit hinzuzufügen.
Ziele
- GKE Standard- und Autopilot-Cluster erstellen und konfigurieren
- Online Boutique in einem zonalen GKE Standard-Cluster bereitstellen
- Multi-Cluster-
Servicesexportieren - Manifeste in Standard- und Autopilot-Clustern bereitstellen
- Multi-Cluster-Gateways aktivieren und konfigurieren
- Verhalten multiregionaler Anwendungen testen
Kosten
In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:
Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen.
Hinweise
Von Ihrer Organisation definierte Sicherheitsbeschränkungen verhindern möglicherweise, dass die folgenden Schritte ausgeführt werden. Informationen zur Fehlerbehebung finden Sie unter Anwendungen in einer eingeschränkten Google Cloud-Umgebung entwickeln.
Bevor Sie beginnen, sollten Sie prüfen, ob die folgenden Anforderungen erfüllt sind:
- Wir empfehlen, ein neues Projekt für diese Anleitung zu verwenden. Am einfachsten bereinigen Sie das Projekt am Ende, indem Sie es löschen.
- In dieser Anleitung wird davon ausgegangen, dass Sie die IAM-Rolle "Inhaber" für Ihr Google Cloud-Projekt haben. Für die Produktion und den praktischen Einsatz hat es sich bewährt, die Berechtigungen auf die geringstmöglichen einzuschränken. Weitere Informationen finden Sie unter IAM sicher verwenden und Identität und Zugriff verwalten.
- Machen Sie sich mit der Demoanwendungsarchitektur von Online Boutique für Mikrodienste vertraut.
Umgebung vorbereiten
In dieser Anleitung verwenden Sie Cloud Shell zum Eingeben von Befehlen. Cloud Shell bietet Zugriff auf die Befehlszeile in der Google Cloud Console und umfasst das Google Cloud SDK und andere Tools wie die Google Cloud CLI. Cloud Shell wird am unteren Rand der Google Cloud Console als Fenster angezeigt. Die Initialisierung kann einige Minuten dauern, aber das Fenster ist sofort sichtbar.
Aktivieren Sie Cloud Shell in der Google Cloud Console.
Definieren Sie in Cloud Shell die in dieser Anleitung verwendeten Umgebungsvariablen. Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID:
export PROJECT=PROJECT_ID gcloud config set project ${PROJECT}Aktivieren Sie die für dieses Dokument erforderlichen Dienste:
gcloud services enable \ gkehub.googleapis.com \ multiclusteringress.googleapis.com \ dns.googleapis.com \ trafficdirector.googleapis.com \ cloudresourcemanager.googleapis.com \ multiclusterservicediscovery.googleapis.com \ container.googleapis.com gcloud container fleet multi-cluster-services enableMulti-Cluster-Services verwalten Google Cloud-Komponenten wie Cloud DNS, Firewallregeln und Traffic Director. Daher müssen diese APIs ebenfalls aktiviert sein. Weitere Informationen finden Sie unter Traffic Director – Übersicht.
Die Ausgabe sieht etwa so aus wie im folgenden Beispiel.
Operation "operations/acf.p2-822685001869-ee4ebe78-6dd8-465e-b0fd-3b0e5f964bad" finished successfully. Waiting for Feature Multi-cluster Services to be created...done.Prüfen Sie, ob Multi-Cluster-Services den Status ACTIVE haben:
gcloud container fleet multi-cluster-services describeDie Ausgabe sieht etwa so aus wie im folgenden Beispiel.
createTime: '2021-11-30T21:59:25.245190894Z' name: projects/PROJECT_ID/locations/global/features/multiclusterservicediscovery resourceState: state: ACTIVE spec: {} updateTime: '2021-11-30T21:59:27.459063070Z'Wenn der Wert von state nicht ACTIVE ist, lesen Sie den Abschnitt zur Fehlerbehebung in der MCS-Dokumentation.
GKE-Cluster erstellen und konfigurieren
Zur Veranschaulichung des Multi-Cluster-Musters in dieser Anleitung verwenden Sie drei Anwendungscluster in drei separaten Cloud-Regionen sowie einen Cluster zum Hosten der Konfiguration für Gateway-Ressourcen. Sie registrieren alle Cluster bei der Flotte, die mit Ihrem Projekt verknüpft ist. Mit einem Google Cloud-Projekt kann nur eine einzelne Flotte verknüpft sein. Dieses Projekt wird als Flotten-Hostprojekt bezeichnet.
Erstellen Sie Standard- und Autopilot-GKE-Cluster:
gcloud container clusters create std-west \ --zone us-west1-a \ --num-nodes=6 \ --enable-ip-alias \ --release-channel regular \ --workload-pool=${PROJECT}.svc.id.goog \ --async gcloud container clusters create-auto auto-east \ --region us-east1 \ --release-channel regular \ --async gcloud container clusters create-auto auto-central \ --region us-central1 \ --release-channel regular \ --async gcloud container clusters create config-central \ --region us-central1 \ --num-nodes=1 \ --enable-ip-alias \ --release-channel regular \ --workload-pool=${PROJECT}.svc.id.goog \ --asyncWorkload Identity Federation for GKE ist in GKE Autopilot-Clustern standardmäßig aktiviert. Sie müssen also nicht wie bei den GKE-Standardclustern das Flag
--workload-poolverwenden, wenn Sie diese Cluster erstellen.Warten Sie, bis sich der STATUS der Cluster von PROVISIONING zu RUNNING ändert. Der gesamte Vorgang kann bis zu 10 Minuten dauern. Sie können den Fortschritt nebenbei mithilfe einer Überwachungsschleife verfolgen, bevor Sie mit dem Rest des Dokuments fortfahren:
watch -n 20 --difference=permanent "gcloud container clusters list"Die Ausgabe sieht etwa so aus wie im folgenden Beispiel.
NAME: auto-central LOCATION: us-central1 MASTER_VERSION: 1.21.5-gke.1802 MASTER_IP: 107.178.213.138 MACHINE_TYPE: e2-medium NODE_VERSION: 1.21.5-gke.1802 NUM_NODES: 3 STATUS: PROVISIONING NAME: config-central LOCATION: us-central1 MASTER_VERSION: 1.21.5-gke.1802 MASTER_IP: MACHINE_TYPE: e2-medium NODE_VERSION: 1.21.5-gke.1802 NUM_NODES: 9 STATUS: PROVISIONING NAME: auto-east LOCATION: us-east1 MASTER_VERSION: 1.21.5-gke.1802 MASTER_IP: 35.229.88.209 MACHINE_TYPE: e2-medium NODE_VERSION: 1.21.5-gke.1802 NUM_NODES: 3 STATUS: PROVISIONING NAME: std-west LOCATION: us-west1-a MASTER_VERSION: 1.21.5-gke.1802 MASTER_IP: 35.197.93.113 MACHINE_TYPE: e2-medium NODE_VERSION: 1.21.5-gke.1802 NUM_NODES: 6 STATUS: PROVISIONINGNachdem alle Cluster den Status RUNNING haben, drücken Sie
CTRL-C, um den Befehl zu unterbrechen.Fügen Sie eine IAM-Richtlinienbindung (Identity and Access Management) hinzu, die dem MCS-Dienstkonto des Flotten-Hostprojekts die Rolle Netzwerknutzer für sein eigenes Projekt zuweist:
gcloud projects add-iam-policy-binding ${PROJECT} \ --member "serviceAccount:${PROJECT}.svc.id.goog[gke-mcs/gke-mcs-importer]" \ --role "roles/compute.networkViewer"Sie verwenden Workload Identity Federation for GKE, um dem MCS-Dienst Lesezugriff auf die Projekt-VPC-Netzwerkkonfiguration zu gewähren. Daher benötigt das MCS-Dienstkonto Importer GKE des Flotten-Hostprojekts diese Rolle.
Die Ausgabe sieht etwa so aus wie im folgenden Beispiel.
- members: - serviceAccount:PROJECT_ID.svc.id.goog[gke-mcs/gke-mcs-importer] role: roles/compute.networkViewer [...]Registrieren Sie die GKE Standard- und Autopilot-Cluster in der Flotte Ihres Projekts. Weitere Informationen finden Sie unter Cluster registrieren. Dieser Schritt kann bis zu 5 Minuten dauern:
gcloud container fleet memberships register std-west \ --gke-cluster us-west1-a/std-west \ --enable-workload-identity \ --project=${PROJECT} gcloud container fleet memberships register auto-east \ --gke-cluster us-east1/auto-east \ --enable-workload-identity \ --project=${PROJECT} gcloud container fleet memberships register auto-central \ --gke-cluster us-central1/auto-central \ --enable-workload-identity \ --project=${PROJECT} gcloud container fleet memberships register config-central \ --gke-cluster us-central1/config-central \ --enable-workload-identity \ --project=${PROJECT}Die Ausgabe für jeden Befehl sieht in etwa so aus:
Waiting for membership to be created...done. Created a new membership [projects/PROJECT_ID/locations/global/memberships/std-west] for the cluster [std-west] Generating the Connect Agent manifest... Deploying the Connect Agent on cluster [std-west] in namespace [gke-connect]... Deployed the Connect Agent on cluster [std-west] in namespace [gke-connect]. Finished registering the cluster [std-west] with the Hub.Stellen Sie eine Verbindung zu den Clustern her und generieren Sie kubeconfig-Einträge:
gcloud container clusters get-credentials std-west \ --zone us-west1-a --project $PROJECT gcloud container clusters get-credentials auto-east \ --region us-east1 --project $PROJECT gcloud container clusters get-credentials auto-central \ --region us-central1 --project $PROJECT gcloud container clusters get-credentials config-central \ --region us-central1 --project $PROJECTDie Ausgabe für jeden Befehl sieht in etwa so aus:
Fetching cluster endpoint and auth data. kubeconfig entry generated for std-west.Benennen Sie Kontexte für Cluster um, damit sie im Rest dieses Dokuments einfacher zu verwenden sind:
kubectl config rename-context \ gke_${PROJECT}_us-west1-a_std-west \ std-west kubectl config rename-context \ gke_${PROJECT}_us-east1_auto-east \ auto-east kubectl config rename-context \ gke_${PROJECT}_us-central1_auto-central \ auto-central kubectl config rename-context \ gke_${PROJECT}_us-central1_config-central \ config-centralIn dieser Anleitung werden die Kontexte nach ihrem Standort benannt. Sie können zwar alternative Namen angeben, die verbleibenden Schritte in dieser Anleitung verwenden aber die in diesem Schritt verwendeten Namen.
Online Boutique in GKE Standard bereitstellen
Im ersten Schritt der Demobereitstellung stellen Sie den vollständigen Satz von Online Boutique-Anwendungsdiensten im einzelnen GKE-Standardcluster std-west in us-west bereit.
Erstellen Sie den Namespace onlineboutique in std-west:
kubectl create namespace onlineboutique --context std-westDie Ausgabe sieht etwa so aus wie im folgenden Beispiel.
namespace/onlineboutique createdKlonen Sie das GitHub-Repository von Online Boutique und richten Sie die Variable WORKDIR ein:
cd ~ git clone --branch release/v0.4.1 \ https://github.com/GoogleCloudPlatform/microservices-demo.git cd microservices-demo/release && export WORKDIR=`pwd`Stellen Sie Online Boutique in std-west bereit. Dieser Prozess erstellt
DeploymentsundServicesfür alle Mikrodienste von Online Boutique und umfasst einen Service vom Typ LoadBalancer, der den Frontend-Dienst von Online Boutique extern verfügbar macht:cd $WORKDIR kubectl apply -f kubernetes-manifests.yaml \ -n onlineboutique --context=std-westWarten Sie, bis der
LoadBalancer-Service eine externe IP-Adresse abruft:watch -n 20 --difference=permanent \ "kubectl get svc frontend-external -n onlineboutique --context=std-west"Die Ausgabe sieht anfangs etwa so aus wie im folgenden Beispiel:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE frontend-external LoadBalancer 10.60.5.62 <pending> 80:30359/TCP 43sWenn der
Servicebereit ist, wird in der Spalte EXTERNAL-IP die öffentliche IP-Adresse des Load-Balancers angezeigt.Wenn der
Servicebereit ist, rufen Sie die externe IP-Adresse des Load-Balancers ab und prüfen Sie mit curl, ob das Frontend bereit ist. Wenn dieser curl-Befehl einen Fehler zurückgibt, warten Sie einen Moment, bevor Sie es noch einmal versuchen:curl $(kubectl get svc frontend-external \ -n onlineboutique --context=std-west \ -o=jsonpath="{.status.loadBalancer.ingress[0].ip}") | \ grep -e Cluster -e Zone -e PodDie erfolgreiche Ausgabe des curl-Befehls sieht in etwa so aus:
<b>Cluster: </b>std-west<br/> <b>Zone: </b>us-west1-a<br/> <b>Pod: </b>frontend-b7bddcc97-wdjsk
Sie haben jetzt eine Einzelzonenversion von Online Boutique, die in us-west1-a ausgeführt wird.
Sie können auch mit einem Webbrowser die externe IP-Adresse aufrufen, die dem frontend-external-LoadBalancer-Dienst zugewiesen ist, um auf die Anwendung zuzugreifen und ihr Verhalten zu beobachten. Diese erste Bereitstellung wird im folgenden Diagramm dargestellt:
cartservice als Multi-Cluster-Service exportieren
In diesem Abschnitt fügen Sie der Anwendung Elemente mit Hochverfügbarkeit hinzu. Sie exportieren den Backend-cartservice als Multi-Cluster-Service in die GKE Autopilot-Cluster.
Erstellen Sie den Namespace onlineboutique für die verbleibenden Cluster:
kubectl create namespace onlineboutique --context auto-east kubectl create namespace onlineboutique --context auto-central kubectl create namespace onlineboutique --context config-centralDie Ausgabe für jeden Befehl sieht in etwa so aus:
namespace/onlineboutique createdExportieren Sie cartservice aus dem Cluster std-west in alle anderen Cluster im
ClusterSet. DasServiceExport-Objekt registriert den cartservice-Service mit GKE-Multi-Cluster-Services für den Export in alle Cluster in der Flotte, in denen der Namespace onlineboutique vorhanden ist. Weitere Informationen finden Sie unter Dienst für den Export registrieren.cat <<EOF>> $WORKDIR/cartservice-export.yaml kind: ServiceExport apiVersion: net.gke.io/v1 metadata: namespace: onlineboutique name: cartservice EOF kubectl apply -f $WORKDIR/cartservice-export.yaml \ -n onlineboutique --context=std-west
Anwendungsmanifeste für Multi-Cluster-Muster anwenden
In diesem Abschnitt wenden Sie zwei ausgewählte Manifeste an, um das Multi-Cluster-Muster bereitzustellen. Diese Manifeste enthalten ausgewählte Teile der Datei kubernetes-manifests.yaml, die Sie zuvor auf den Cluster std-west angewendet haben:
- Das erste Manifest wird für frontend-
Deployment, -Serviceund -ServiceExportverwendet. - Das zweite Manifest wird verwendet, um die Middleware-
Services(emailservice, checkoutservice, recommendationservice, paymentservice, productcatalogservice, currencyservice, shippingservice und adservice) in alle Regionen bereitzustellen, in denen ein Frontend ausgeführt wird. Wenn Sie eine Anfrage so lange wie möglich lokal in einer Region aufbewahren, vermeiden Sie dadurch unnötige Gebühren für interregionalen Netzwerk-Traffic.
Ein Pod, der in einem beliebigen Cluster in der Flotte ausgeführt wird, kann durch Senden einer Anfrage im Format SERVICE_NAME.NAMESPACE.svc.clusterset.local an den ClusterSet-URI für diesen Dienst auf einen exportierten Service zugreifen. Die frontend-Deployments in allen drei Beispielclustern können z. B. den cartservice im Namespace onlineboutique verwenden, indem sie eine Anfrage an cartservice.onlineboutique.svc.clusterset.local senden.
Aus diesem Grund wurde in jedem Manifest der Hostname für den cartservice auf den zugehörigen ClusterSet-URI aktualisiert. Dieser Schritt ist entscheidend. Wenn dieser Hostname des Dienstes nicht aktualisiert wird, würde der frontend-Service kube-dns nach cartservice anstelle von cartservice.onlineboutique.svc.clusterset.local fragen. Dieses Verhalten würde zu HTTP Status 500-Fehlern in Clustern führen, in denen keine lokale Version von cartservice verfügbar ist, und die frontend-Pods fehlerhaft machen.
Legen Sie eine Umgebungsvariable für das GitHub-Repository fest, das die Manifeste enthält:
export MANIFEST_REPO_PATH=https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/cluster-migrationWenden Sie die Manifeste an, um die Frontend-Ebene in allen drei Arbeitslastclustern bereitzustellen:
kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-frontend-manifests.yaml \ -n onlineboutique --context=std-west kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-frontend-manifests.yaml \ -n onlineboutique --context=auto-east kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-frontend-manifests.yaml \ -n onlineboutique --context=auto-centralWenden Sie die Manifeste an, um die Middleware-Ebene in allen drei Arbeitslastclustern bereitzustellen:
kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-middleware-manifests.yaml \ -n onlineboutique --context=std-west kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-middleware-manifests.yaml \ -n onlineboutique --context=auto-east kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-middleware-manifests.yaml \ -n onlineboutique --context=auto-central
Sie sind frontend-Deployment, -Service und -ServiceExport in den Clustern std-west, auto-east und auto-central aktiv. In jedem Cluster werden außerdem lokale Middleware-Dienste für Online Boutique. Externer Traffic wird jedoch weiterhin nur an den Service weitergeleitet, der im ersten Cluster in us-west1 ausgeführt wird, wie im folgenden Diagramm dargestellt:
Multi-Cluster-Gateways aktivieren und konfigurieren
In diesem Abschnitt leiten Sie Traffic an alle Front-Ends in allen drei Clustern weiter und sorgen für das zugehörige Load-Balancing. Für diese Konfiguration verwenden Sie Multi-Cluster-Gateways (MCG). In diesem Dokument wird MCG eingerichtet, wie unter Multi-Cluster-Gateways aktivieren beschrieben.
In dieser Anleitung verwenden Sie den Cluster config-central, um die Konfiguration für Gateway-Ressourcen zu hosten.
Prüfen Sie, ob alle Cluster erfolgreich bei der Flotte registriert wurden:
gcloud container fleet memberships list --project=$PROJECTDie folgende Beispielausgabe zeigt, dass alle Cluster erfolgreich registriert wurden:
NAME: auto-central EXTERNAL_ID: 21537493-32ea-4a41-990d-02be2c1b319f NAME: config-central EXTERNAL_ID: 4369423e-ea7b-482d-a0eb-93b560e67b98 NAME: std-west EXTERNAL_ID: 7fcb048b-c796-476b-9698-001a00f91ab3 NAME: auto-east EXTERNAL_ID: aae2d2ff-b861-4a38-bcaf-612f14810012Installieren Sie die benutzerdefinierte Ressourcendefinition der Gateway API im Cluster config-central:
kubectl --context=config-central kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v0.5.0" \ | kubectl apply -f -In diesem Schritt werden die benutzerdefinierten Ressourcendefinitionen für die Gateway API installiert, einschließlich der Ressourcen
GatewayClass,GatewayundHTTPRoute. Die benutzerdefinierten Ressourcendefinitionen werden von der Network Special Group Group für Kubernetes verwaltet. Nach der Installation können Sie den GKE-Gateway-Controller verwenden.Aktivieren Sie Multi Cluster Ingress für Ihre Flotte, falls Sie dies noch nicht getan haben. Wenn Sie diese Funktion aktivieren, wird auch der Multi-Cluster-Gateway-Controller aktiviert.
gcloud container fleet ingress enable \ --config-membership=config-central \ --project=$PROJECT gcloud container fleet ingress describe --project=$PROJECTDie Ausgabe sieht etwa so aus wie im folgenden Beispiel.
createTime: '2021-12-08T23:10:52.505888854Z' name: projects/PROJECT_ID/locations/global/features/multiclusteringress resourceState: state: ACTIVE spec: multiclusteringress: configMembership: projects/zl-mcs-expf61cbd13/locations/global/memberships/config-central state: state: code: OK description: Ready to use updateTime: '2021-12-08T23:11:37.994971649Z' updateTime: '2021-12-08T23:11:38.098244178Z'Wenn der Wert von state nicht ACTIVE ist, finden Sie weitere Informationen unter Fehlerbehebung und Vorgänge für Multi-Cluster-Ingress.
Prüfen Sie, ob
GatewayClassesim Cluster config-central verfügbar sind:kubectl get gatewayclasses --context=config-centralDie Ausgabe sieht etwa so aus wie im folgenden Beispiel.
NAME CONTROLLER AGE gke-l7-global-external-managed networking.gke.io/gateway 18s gke-l7-global-external-managed-mc networking.gke.io/gateway 19s gke-l7-regional-external-managed networking.gke.io/gateway 18s gke-l7-regional-external-managed-mc networking.gke.io/gateway 19s gke-l7-gxlb networking.gke.io/gateway 74s gke-l7-gxlb-mc networking.gke.io/gateway 16s gke-l7-rilb networking.gke.io/gateway 74s gke-l7-rilb-mc networking.gke.io/gateway 16sVerschiedene
GatewayClass-Ressourcen haben unterschiedliche Funktionen. Weitere Informationen zur Verwendung des richtigen Typs finden Sie unter GatewayClass-Funktionen.Stellen Sie die
external-http-Gateway-Ressource inconfig-centralbereit:cat <<EOF>> $WORKDIR/external-http-gateway.yaml kind: Gateway apiVersion: gateway.networking.k8s.io/v1beta1 metadata: name: external-http namespace: onlineboutique spec: gatewayClassName: gke-l7-global-external-managed-mc listeners: - protocol: HTTP port: 80 name: http EOF kubectl apply -f external-http-gateway.yaml \ -n onlineboutique --context=config-centralWie im Feld
gatewayClassNameangegeben, gehört diese Ressource zurGatewayClassgke-l7-global-external-managed-mc, die das externe Layer-7-Cloud Load Balancing verwaltet und die Multi-Cluster-Anwendung verfügbar machtStellen Sie die
HTTPRoutemit dem Namen public-frontend-route in config-central bereit:cat <<EOF>> $WORKDIR/public-frontend-route.yaml kind: HTTPRoute apiVersion: gateway.networking.k8s.io/v1beta1 metadata: name: public-frontend-route namespace: onlineboutique spec: parentRefs: - name: "external-http" hostnames: - "store.example.com" rules: - matches: - path: type: PathPrefix value: / backendRefs: - name: frontend group: net.gke.io kind: ServiceImport port: 80 EOF kubectl apply -f public-frontend-route.yaml \ -n onlineboutique --context=config-centralWenn Sie die
HTTPRoute-Ressource bereitstellen, erstellt sie eine externe Layer-7-Cloud Load Balancing-Ressource und macht den Frontend-ServiceImportverfügbar, der von den Diensten unterstützt wird, die in den Clustern std-west, auto-east und auto-central ausgeführt werden.Das folgende Diagramm zeigt, wie Traffic nach der Bereitstellung des Multi-Cluster-Gateways an einen der Frontend-Multi-Cluster-Services in einem der drei Anwendungscluster weitergeleitet werden kann:
Warten Sie, bis der Load-Balancer mit einer bereitgestellten externen IP-Adresse bereit ist, bevor Sie mit dem nächsten Schritt fortfahren. Es kann bis zu 10 Minuten dauern, bis die IP-Adresse zugewiesen wird. Sie können den Fortschritt mithilfe einer Überwachungsschleife verfolgen. Der Load-Balancer hat einen Namen wie gkemcg-onlineboutique-external-http-k09mfhk74gop:
watch -n 20 --difference=permanent \ "gcloud compute forwarding-rules list \ | grep -A 5 NAME..*external-http"Die Ausgabe sieht etwa so aus wie im folgenden Beispiel.
NAME: gkemcg-onlineboutique-external-http-k09mfhk74gop REGION: IP_ADDRESS: 34.149.29.176 IP_PROTOCOL: TCP TARGET: gkemcg-onlineboutique-external-http-k09mfhk74gopWenn der Load-Balancer bereit ist, führen Sie in Cloud Shell den folgenden Befehl aus, um die externe IP-Adresse des Load-Balancers zu exportieren, der durch das Anwenden der Manifeste external-http-gateway.yaml und public-frontend-route.yaml erstellt wurde:
export EXTERNAL_LB_IP=$(kubectl --context=config-central \ -n onlineboutique get gateway external-http \ -o=jsonpath='{.status.addresses[0].value}')Wenn Sie eine Anfrage mit den Load-Balancer mit den entsprechenden Headern senden, werden die vom Frontend-Dienst bereitgestellten HTML-Inhalte zurückgegeben. Da Sie beispielsweise die
HTTPRoute-Ressource so konfiguriert haben, dass der Hostnamestore.example.comdem frontend-ServiceImportzugeordnet wird, müssen Sie denHOST-Header angeben, wenn Sie die HTTP-Anfrage senden. Wenn im folgenden curl-Beispiel ein Fehler zurückgegeben wird, warten Sie einige Minuten und versuchen Sie es noch einmal:curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e PodDie erfolgreiche Ausgabe des curl-Befehls sieht in etwa so aus:
<b>Cluster: </b>auto-central<br/> <b>Zone: </b>us-central1-f<br/> <b>Pod: </b>frontend-7c7d596ddc-jdh8f
Multiregionales Routingverhalten der Anwendung testen
Eines der leistungsstarken Features von Multi-Cluster-Services und Multi-Cluster-Gateways besteht darin, dass externe Anfragen an den geografisch nächstgelegenen Cluster weitergeleitet werden.
Generieren Sie zum Testen des multiregionalen Verhaltens der Anwendung Traffic, der aus den verschiedenen Regionen stammt, in denen Sie Cluster bereitgestellt haben. Erstellen Sie drei kleine Pods, und zwar einen in jedem der Cluster (std-west, auto-east und auto-central), über die Sie HTTP-Anfragen an den Load-Balancer-Endpunkt senden können. In den Ergebnissen sehen Sie, welcher Frontend-Pod antwortet.
Erstellen Sie die Client-Pods:
kubectl run --context=std-west \ --image=radial/busyboxplus:curl client-west \ -- sh -c 'while sleep 3600; do :; done' kubectl run --context=auto-east \ --image=radial/busyboxplus:curl client-east \ -- sh -c 'while sleep 3600; do :; done' kubectl run --context=auto-central \ --image=radial/busyboxplus:curl client-central \ -- sh -c 'while sleep 3600; do :; done'Sobald die Pods ausgeführt werden, senden Sie mit einem curl-Befehl eine Anfrage an den Load-Balancer-Endpunkt vom Client
Podim Cluster std-west und sehen Sie sich die Antwort an:kubectl exec -it --context=std-west client-west \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e PodDie erfolgreiche Ausgabe des curl-Befehls sieht in etwa so aus:
<b>Cluster: </b>std-west<br/> <b>Zone: </b>us-west1-a<br/> <b>Pod: </b>frontend-7cf48b79cf-trzc4Führen Sie dieselbe curl-Anfrage vom Client
Podim Cluster auto-east aus und sehen Sie sich die Antwort an:kubectl exec -it --context=auto-east client-east \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e PodDie erfolgreiche Ausgabe des curl-Befehls sieht in etwa so aus:
<b>Cluster: </b>auto-east<br/> <b>Zone: </b>us-east1-d<br/> <b>Pod: </b>frontend-6784b6df98-scdwsDa es sich um einen Autopilot-Cluster handelt, muss der Cluster möglicherweise zusätzliche Ressourcen bereitstellen, um den
Podzu planen. Wenn die Ausgabe ähnlich wie im folgenden Beispiel aussieht, warten Sie einen Moment und versuchen Sie es dann noch einmal:Error from server (BadRequest): pod client-east does not have a host assignedFühren Sie den curl-Befehl vom Client
Podim Cluster auto-central aus und sehen Sie sich die Antwort an:kubectl exec -it --context=auto-central client-central \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e PodDie erfolgreiche Ausgabe des curl-Befehls sieht in etwa so aus:
<b>Cluster: </b>auto-central<br/> <b>Zone: </b>us-central1-b<br/> <b>Pod: </b>frontend-6784b6df98-x2fv4Diese Ergebnisse bestätigen, dass Traffic an die entsprechenden Pods an den Standorten weitergeleitet wird, die dem Anfrageursprung am nächsten sind.
Multiregionale Ausfallsicherheit der Anwendung testen
Zusätzlich zum effizienten Traffic-Routing bietet die Ausführung Ihrer Dienste in mehreren Regionen Ausfallsicherheit im seltenen, aber möglichen Fall eines Infrastrukturausfalls.
Testen Sie das Verhalten. Löschen Sie dazu die frontend Deployments in bestimmten Clustern und wiederholen Sie dann den curl-Befehl vom Client Pod in diesen Regionen. Prüfen Sie, ob die Anwendung immer noch verfügbar ist, und prüfen Sie den Standort des Pod, der auf die Anfrage antwortet.
Führen Sie den curl-Befehl vom client-west-
Podim Cluster std-west aus. Sie sehen dann, dass das Ergebnis vom Frontend in us-west1 stammt:kubectl exec -it --context=std-west client-west \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e PodDie erfolgreiche Ausgabe des curl-Befehls sieht in etwa so aus:
<b>Cluster: </b>std-west<br/> <b>Zone: </b>us-west1-a<br/> <b>Pod: </b>frontend-7cf48b79cf-trzc4Löschen Sie das frontend-
Deploymentim Cluster std-west:kubectl delete deploy frontend \ -n onlineboutique --context=std-westDie Ausgabe sieht etwa so aus wie im folgenden Beispiel.
deployment.apps "frontend" deletedSenden Sie eine weitere Anfrage vom client-west-
Podim Cluster std-west. Sie sollten eine Antwort von einem der verbleibenden frontend-Deploymentssehen, die sich im Cluster auto-east bzw. auto-central befinden:kubectl exec -it --context=std-west client-west \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e PodEine ähnliche Ausgabe wie im folgenden Beispiel gibt den Standort des fehlerfreien
Podan, der auf diese Anfrage antwortet:<b>Cluster: </b>auto-central<br/> <b>Zone: </b>us-central1-b<br/> <b>Pod: </b>frontend-6784b6df98-x2fv4oder
<b>Cluster: </b>auto-east<br/> <b>Zone: </b>us-east1-d<br/> <b>Pod: </b>frontend-6784b6df98-scdwsFühren Sie den Befehl mehrmals aus, um unterschiedliche Ergebnisse zu sehen.
Bei dieser Demonstrationsbereitstellung haben Sie der Anwendung "Online Boutique" mithilfe von Multi-Cluster-Services und Multi-Cluster-Gateways Elemente mit Ausfallsicherheit und geografischer Verteilung hinzugefügt. Anfragen werden an die nächstgelegene geografische Region weitergeleitet. Und selbst wenn die Frontend- oder Middleware-Dienste in einer Region Probleme haben, kann der Endnutzer die Anwendung weiterhin erfolgreich verwenden.
Bereinigen
Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder das Projekt, das die Ressourcen enthält, oder Sie behalten das Projekt und löschen die einzelnen Ressourcen.
- Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.
- Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
- Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.
Nächste Schritte
- Weitere Informationen zur Google Cloud-Flotte und Multi-Cluster-Verwaltung
- Registrieren eines Clusters, einschließlich GKE Enterprise-Clustern, bei einer Google Cloud-Flotte
- Weitere Informationen zur Kubernetes Gateway API und zum GKE-Gateway
- Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center