Il networking multi-cluster è uno strumento prezioso che consente casi d'uso come l'alta disponibilità a livello di regione, la vicinanza agli utenti distribuita a livello globale per una minore latenza e l'isolamento organizzativo tra i team. Google Kubernetes Engine (GKE) offre funzionalità integrate per il networking multi-cluster che puoi abilitare e utilizzare su larga scala in un parco risorse di cluster GKE. Questa funzionalità consente inoltre di combinare o migrare l'infrastruttura di cui è stato eseguito il deployment tra GKE Standard e Autopilot per soddisfare le esigenze di architettura di ogni applicazione.
Questo documento illustra queste funzionalità attraverso diverse topologie di deployment. Imparerai a eseguire il deployment di un'applicazione in un singolo cluster GKE e a eseguirne la migrazione a un deployment multi-cluster nei cluster GKE Standard e Autopilot. Puoi utilizzare i servizi multi-cluster GKE per il traffico est-ovest e i gateway multi-cluster per abilitare il networking nord-sud multi-cluster.
Il documento è rivolto ai cloud architect e ai team operativi che utilizzano, o intendono utilizzare, GKE per eseguire il deployment di servizi in più cluster Kubernetes. Questo documento presuppone la conoscenza di Kubernetes.
GKE Standard e GKE Autopilot
GKE offre un deployment Kubernetes gestito con un set completo di funzionalità, compreso un piano di controllo I cluster GKE possono essere avviati rapidamente e scalare fino a 15.000 nodi. Con i cluster GKE Autopilot, Google gestisce l'infrastruttura, inclusi il piano di controllo e i nodi. Se invece vuoi configurare e gestire i tuoi nodi, GKE offre la modalità Standard.
Per ulteriori informazioni sulle differenze tra le modalità, consulta Scegliere la modalità operativa dei cluster.
Servizi multi-cluster e gateway multi-cluster
Kubernetes può essere eseguito utilizzando un unico piano di controllo in diverse zone cloud per fornire resilienza e maggiore disponibilità per i tuoi servizi.
GKE fa un ulteriore passo in avanti e fornisce
servizi multi-cluster
(MCS) di GKE che forniscono un meccanismo di chiamata e rilevamento dei servizi tra cluster.
I servizi che utilizzano questa funzionalità sono rilevabili e accessibili in tutti i cluster con un IP virtuale, il che corrisponde al comportamento di un servizio ClusterIP accessibile in un cluster. Questo approccio offre i seguenti vantaggi:
- Il bilanciamento del carico dei servizi può avvenire in più cluster nella stessa regione o in regioni diverse (traffico est-ovest).
- Le opzioni per l'alta disponibilità del servizio tra regioni sono realizzabili.
- È possibile eseguire il deployment dei carichi di lavoro stateful e stateless e gestirli in cluster separati.
- I servizi condivisi sono disponibili in tutti i cluster.
Per saperne di più su come eseguire il deployment di MCS, consulta Configurazione dei servizi multi-cluster.
GKE fornisce un'implementazione dell'API Kubernetes Gateway che utilizza il controller GKE Gateway. Gateway consente a GKE di eseguire il deployment dei bilanciatori del carico Google Cloud per fornire il routing del traffico in entrata (nord-sud) per i servizi di cui è stato eseguito il deployment su GKE. GKE offre inoltre gateway multi-cluster (MCG) che estendono il controller gateway GKE per eseguire il provisioning di bilanciatori del carico che instradano il traffico a servizi di cui è stato eseguito il deployment in cluster GKE diversi.
Il seguente diagramma mostra come, quando combini MCS e MCG, sei in grado di gestire gli aspetti complementari del deployment dei servizi e del routing del traffico da un unico piano di controllo:
Per ulteriori informazioni, consulta Deployment di gateway multi-cluster.
Panoramica della migrazione
Le funzionalità di networking multi-cluster GKE favoriscono carichi di lavoro di vari profili. Ad esempio, potresti avere componenti stateless con traffico bursty che vuoi spostare ad Autopilot a causa del suo modello di costo più efficiente.
In alternativa, potresti voler posizionare i frontend dell'applicazione più vicino agli utenti. Questo approccio fornisce latenza e memorizzazione nella cache inferiori, migliorando le prestazioni dell'applicazione e l'esperienza utente. Allo stesso tempo, potresti avere alcuni componenti stateful basati sulla tua applicazione che possono risiedere in una sola località. Questa configurazione richiede il bilanciamento del carico multi-cluster nord-sud per inviare il traffico client al cluster corretto in quella località. Hai inoltre bisogno del bilanciamento del carico multi-cluster est-ovest per inviare il traffico tra i cluster e raggiungere i componenti stateful.
Questo documento utilizza l'applicazione demo dei microservizi cloud Online Boutique per dimostrare un pattern multi-cluster che può essere utilizzato per migliorare il deployment della demo a zona singola. Inizi con una versione a zona singola dell'applicazione. Puoi quindi aggiungere elementi di alta disponibilità e resilienza utilizzando servizi multi-cluster e gateway multi-cluster e ridurre il lavoro manuale utilizzando Autopilot.
Deployment iniziale su cluster singolo
Nel diagramma seguente, il deployment dell'applicazione Online Boutique viene inizialmente eseguito
in un singolo cluster in modalità GKE Standard denominato
std-west ed è esposta utilizzando un servizio LoadBalancer:
Esegui la migrazione ai servizi multi-cluster
Nel passaggio intermedio successivo, creerai due cluster aggiuntivi e verrà eseguito il deployment dei servizi stateless in altre regioni. Creerai due cluster GKE Autopilot denominati auto-east e auto-central in due regioni separate dal singolo cluster GKE Standard std-west e registri i cluster nel parco risorse di Google Cloud.
I parchi risorse sono un concetto di Google Cloud per l'organizzazione logica dei cluster e di altre risorse e consentono di utilizzare e gestire le funzionalità multi-cluster e di applicare criteri coerenti tra i sistemi.
Puoi esportare cartservice sul cluster std-west nello spazio dei nomi onlineboutique nei nuovi cluster del parco risorse utilizzando ServiceExport.
Esegui il deployment del servizio frontend di Online Boutique su tutti e tre i cluster e lo esponi tramite un servizio ClusterIP. Quindi esporterai il servizio nel parco risorse utilizzando ServiceExports.
In tutti e tre i cluster viene eseguito anche il deployment di servizi come il livello middleware di Online Boutique (come productcatalog, shipping e adservice).
Un Pod in esecuzione in qualsiasi cluster nel parco risorse può accedere a un Service esportato
inviando una richiesta all'URI ClusterSet di quel servizio. La richiesta
instrada a un endpoint che supporta il servizio.
Il servizio frontend è in grado di utilizzare i servizi middleware (come productcatalogservice o currencyservice) localmente nello stesso cluster. Questa architettura consente di mantenere le richieste in entrata locali nelle regioni il cui frontend risponde alla richiesta ed evita addebiti non necessari per il traffico di rete tra regioni.
Il seguente diagramma illustra i due servizi multi-cluster. Il deployment del servizio frontend stateless viene eseguito in tre cluster e del servizio di backend stateful cartservice in un cluster. Il diagramma mostra anche che in questo passaggio intermedio, il traffico in entrata per il servizio frontend rimane instradato al cluster GKE Standard originale in us-west1 utilizzando un bilanciatore del carico di rete passthrough esterno creato dal servizio LoadBalancer frontend-external:
Esegui la migrazione a un gateway multi-cluster
Nel passaggio finale, instrada il traffico in entrata per il servizio frontend dalle richieste dei client esterni ai servizi in più cluster del parco risorse utilizzando un gateway multi-cluster.
Al parco risorse viene aggiunto un quarto cluster denominato config-central per ospitare e gestire la configurazione delle risorse Gateway e HTTPRoute create nell'ambito di questa configurazione. La risorsa HTTPRoute
mappa il prefisso / al frontend
ServiceImport.
Il traffico per il frontend di Online Boutique viene inviato a un endpoint integro in una delle regioni disponibili. Questo approccio aggiunge elementi di alta disponibilità all'architettura dell'applicazione Online Boutique.
Nel diagramma seguente, il gateway multi-cluster esegue il deployment di un bilanciatore del carico Cloud globale che instrada il traffico esterno al servizio frontend stateless di cui è stato eseguito il deployment in ciascuno dei tre cluster di applicazioni del parco risorse.
Nello stato finale, questo pattern controllato dimostra un basso accoppiamento tra le parti stateful (cartservice e redis-cart) e stateless dell'applicazione (frontend, emailservice, checkoutservice, recommendationservice, paymentservice, productcatalogservice, currencyservice, shippingservice e adservice). Sebbene non rientri nell'ambito di questo documento, questo approccio ti offre l'opportunità futura di aggiungere resilienza e alta disponibilità al livello dei servizi stateful.
Obiettivi
- Creare e configurare cluster GKE Standard eAutopilotL.
- Esegui il deployment di Online Boutique su un cluster GKE Standard a livello di zona.
- Esporta multi-cluster
Services. - Esegui il deployment dei manifest nei cluster Standard e Autopilot.
- Abilita e configura i gateway multi-cluster.
- Testa il comportamento delle applicazioni multiregionali.
Costi
In questo documento, utilizzi i seguenti componenti fatturabili di Google Cloud:
Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi.
Prima di iniziare
I vincoli di sicurezza definiti dalla tua organizzazione potrebbero impedirti di completare i passaggi seguenti. Per informazioni sulla risoluzione dei problemi, vedi Sviluppare applicazioni in un ambiente Google Cloud vincolato.
Prima di iniziare, assicurati che siano soddisfatti i seguenti requisiti:
- Ti consigliamo di utilizzare un nuovo progetto per questa guida, poiché il modo più semplice per ripulire il progetto è eliminarlo al termine dell'operazione.
- Questa guida presuppone che tu disponga del ruolo IAM di proprietario per il progetto Google Cloud. Per le impostazioni di produzione o reali, la best practice prevede di definire l'ambito delle autorizzazioni in base al privilegio minimo. Per ulteriori informazioni, consulta Utilizzare IAM in modo sicuro e Gestire identità e accesso.
- Acquisisci familiarità con l'architettura delle applicazioni demo dei microservizi Online Boutique.
prepara l'ambiente
In questa guida, utilizzerai Cloud Shell per inserire i comandi. Cloud Shell ti dà accesso alla riga di comando nella console Google Cloud e include Google Cloud SDK e altri strumenti, come Google Cloud CLI. Cloud Shell viene visualizzato come finestra nella parte inferiore della console Google Cloud. L'inizializzazione può richiedere diversi minuti, ma la finestra viene visualizzata immediatamente.
Nella console Google Cloud, attiva Cloud Shell.
In Cloud Shell, definisci le variabili di ambiente utilizzate in questa guida. Sostituisci PROJECT_ID con il tuo ID progetto:
export PROJECT=PROJECT_ID gcloud config set project ${PROJECT}Abilita i servizi richiesti per questo documento:
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 enableI servizi multi-cluster gestiscono i componenti di Google Cloud come Cloud DNS, le regole firewall e Cloud Service Mesh, quindi anche queste API devono essere abilitate. Per ulteriori informazioni, consulta Panoramica di Cloud Service Mesh.
L'output è simile all'esempio seguente:
Operation "operations/acf.p2-822685001869-ee4ebe78-6dd8-465e-b0fd-3b0e5f964bad" finished successfully. Waiting for Feature Multi-cluster Services to be created...done.Verifica che i servizi multi-cluster mostrino lo stato ATTIVO:
gcloud container fleet multi-cluster-services describeL'output è simile all'esempio seguente:
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'Se il valore di state non è ACTIVE, consulta la sezione relativa alla risoluzione dei problemi della documentazione MCS.
Crea e configura cluster GKE
Per dimostrare il pattern multi-cluster in questa guida, utilizzi tre cluster di applicazioni in tre regioni cloud separate e un cluster per ospitare la configurazione per le risorse gateway. Puoi registrare tutti i cluster con il parco risorse associato al tuo progetto. A un progetto Google Cloud può essere associato un solo parco risorse. Questo progetto è noto come progetto host del parco risorse.
Crea cluster GKE Standard e Autopilot:
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 \ --asyncLa federazione delle identità per i carichi di lavoro per GKE è abilitata per impostazione predefinita sui cluster GKE Autopilot, quindi non devi utilizzare il flag
--workload-poolquando crei questi cluster come fai con i cluster GKE Standard.Attendi che lo STATO dei cluster passi da PROVISIONING a RUNNING. Questa procedura può richiedere fino a 10 minuti. Puoi monitorare l'avanzamento utilizzando un cinturino mentre prendi una tazza di caffeina o esegui qualche esercizio di stretching leggero prima di procedere con il resto del documento:
watch -n 20 --difference=permanent "gcloud container clusters list"L'output è simile all'esempio seguente:
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: PROVISIONINGQuando tutti i cluster sono nello stato IN ESECUZIONE, premi
CTRL-Cper interrompere il comando.Aggiungi un'associazione dei criteri IAM (Identity and Access Management) per concedere all'account di servizio MCS del progetto host del parco risorse il ruolo Utente di rete per il proprio progetto:
gcloud projects add-iam-policy-binding ${PROJECT} \ --member "serviceAccount:${PROJECT}.svc.id.goog[gke-mcs/gke-mcs-importer]" \ --role "roles/compute.networkViewer"Puoi utilizzare la federazione delle identità per i carichi di lavoro per GKE per concedere al servizio MCS l'accesso in lettura alla configurazione della rete VPC del progetto. Di conseguenza, l'account di servizio MCS Importer GKE del progetto host del parco risorse richiede questo ruolo.
L'output è simile all'esempio seguente:
- members: - serviceAccount:PROJECT_ID.svc.id.goog[gke-mcs/gke-mcs-importer] role: roles/compute.networkViewer [...]Registra i cluster GKE Standard e Autopilot nel parco risorse del tuo progetto. Per ulteriori dettagli, consulta Registrazione di un cluster. Questo passaggio può richiedere fino a 5 minuti:
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}L'output di ogni comando è simile all'esempio seguente:
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.Connettiti ai cluster e genera voci kubeconfig:
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 $PROJECTL'output di ogni comando è simile all'esempio seguente:
Fetching cluster endpoint and auth data. kubeconfig entry generated for std-west.Rinomina i contesti per i cluster in modo da utilizzarli più facilmente nel resto di questo documento:
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 questa guida, i contesti sono denominati in base alla loro posizione. Anche se puoi fornire nomi alternativi, nei passaggi rimanenti di questa guida vengono utilizzati i nomi utilizzati in questo passaggio.
Esegui il deployment di Boutique online su GKE Standard
Nel primo passaggio del deployment dimostrativo, esegui il deployment del set completo di servizi delle applicazioni Online Boutique nel singolo cluster GKE Standard std-west in us-west1.
Crea lo spazio dei nomi onlineboutique su std-west:
kubectl create namespace onlineboutique --context std-westL'output è simile all'esempio seguente:
namespace/onlineboutique createdClona il repository GitHub di Online Boutique e imposta una variabile WORKDIR:
cd ~ git clone --branch release/v0.4.1 \ https://github.com/GoogleCloudPlatform/microservices-demo.git cd microservices-demo/release && export WORKDIR=`pwd`Esegui il deployment di Online Boutique su std-west. Questo processo crea
DeploymentseServicesper tutti i microservizi di Online Boutique e include un servizio di tipo LoadBalancer che espone esternamente il servizio di frontend di Online Boutique:cd $WORKDIR kubectl apply -f kubernetes-manifests.yaml \ -n onlineboutique --context=std-westAttendi che il servizio
LoadBalancerottenga un IP esterno:watch -n 20 --difference=permanent \ "kubectl get svc frontend-external -n onlineboutique --context=std-west"Inizialmente, l'output è simile all'esempio seguente:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE frontend-external LoadBalancer 10.60.5.62 <pending> 80:30359/TCP 43sQuando
Serviceè pronto, la colonna EXTERNAL-IP mostra l'indirizzo IP pubblico del bilanciatore del carico.Quando
Serviceè pronto, recupera l'indirizzo IP esterno del bilanciatore del carico e utilizza curl per verificare che il frontend sia pronto. Se questo comando curl restituisce un errore, attendi qualche istante prima di riprovare:curl $(kubectl get svc frontend-external \ -n onlineboutique --context=std-west \ -o=jsonpath="{.status.loadBalancer.ingress[0].ip}") | \ grep -e Cluster -e Zone -e PodL'output corretto del comando curl è simile al seguente esempio:
<b>Cluster: </b>std-west<br/> <b>Zone: </b>us-west1-a<br/> <b>Pod: </b>frontend-b7bddcc97-wdjsk
Ora hai una versione a zona singola di Online Boutique in esecuzione in us-west1-a.
Puoi anche utilizzare un browser web per passare all'IP esterno assegnato al servizio LoadBalancer frontend-external per accedere all'applicazione e osservarne il comportamento. Questo singolo deployment iniziale è mostrato nel seguente diagramma:
Esporta cartservice come servizio multi-cluster
In questa sezione, inizierai ad aggiungere all'applicazione elementi di alta disponibilità. Esporta il backend cartservice di backend come servizio multi-cluster nei cluster GKE Autopilot.
Crea lo spazio dei nomi onlineboutique sui cluster rimanenti:
kubectl create namespace onlineboutique --context auto-east kubectl create namespace onlineboutique --context auto-central kubectl create namespace onlineboutique --context config-centralL'output di ogni comando è simile all'esempio seguente:
namespace/onlineboutique createdEsporta cartservice dal cluster std-west a tutti gli altri cluster in
ClusterSet. L'oggettoServiceExportregistra il servizio cartservice con i servizi multi-cluster GKE, per l'esportazione in tutti i cluster nel parco risorse in cui è presente lo spazio dei nomi onlineboutique. Per ulteriori dettagli, consulta la sezione sulla registrazione di un servizio per l'esportazione.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
Applica i manifest dell'applicazione per pattern multi-cluster
In questa sezione vengono applicati due manifest selezionati per il deployment del pattern multi-cluster. Questi manifest contengono parti selezionate di kubernetes-manifests.yaml che hai applicato in precedenza al cluster std-west:
- Il primo manifest viene utilizzato per il frontend
Deployment,ServiceeServiceExport. - Il secondo manifest viene utilizzato per eseguire il deployment del middleware
Services(emailservice, checkoutservice, recommendationservice, paymentservice, productcatalogservice, currencyservice, shippingservice e adservice) in tutte le regioni in cui è in esecuzione un frontend. Mantenendo una richiesta locale in una regione per il più a lungo possibile, eviterai addebiti inutili per il traffico di rete tra regioni.
Un Pod in esecuzione in qualsiasi cluster nel parco risorse può accedere a un Service esportato inviando una richiesta all'URI ClusterSet del servizio nel formato SERVICE_NAME.NAMESPACE.svc.clusterset.local. Ad esempio, il frontend
Deployments in tutti e tre i cluster di esempio è in grado di utilizzare il
cartservice, nello spazio dei nomi onlineboutique, effettuando una richiesta a
cartservice.onlineboutique.svc.clusterset.local.
Per questo motivo, in ogni manifest, il nome host per cartservice è stato
aggiornato nell'URI ClusterSet. Questo passaggio è fondamentale. Se il nome host di questo servizio non viene aggiornato, il servizio di frontend chiederà a kube-dns di cartservice anziché di cartservice.onlineboutique.svc.clusterset.local. Questo comportamento
comporterebbe errori HTTP Status 500 nei cluster in cui non è disponibile una versione locale di
cartservice e causa uno stato non integro dei pod del frontend.
Imposta una variabile di ambiente per il repository GitHub che contiene i manifest:
export MANIFEST_REPO_PATH=https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/cluster-migrationApplica i manifest per eseguire il deployment del livello di frontend a tutti e tre i cluster dei carichi di lavoro:
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-centralApplica i manifest per eseguire il deployment del livello middleware a tutti e tre i cluster dei carichi di lavoro:
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
Ora il frontend Deployment, Service e ServiceExport è attivo nei cluster std-west, auto-east e auto-central. Disponi anche di servizi middleware Online Boutique
in esecuzione localmente in ogni cluster. Tuttavia, il traffico esterno viene comunque instradato solo verso Service in esecuzione nel cluster iniziale in us-west1, come mostrato nel seguente diagramma:
Abilita e configura gateway multi-cluster
In questa sezione, instrada il traffico e bilancia il carico del traffico esterno tra i frontend di tutti e tre i cluster. Per ottenere questa configurazione, usa i gateway multi-cluster. Questo documento segue le indicazioni per configurare la rete multicanale, come descritto in Abilitazione dei gateway multi-cluster.
In questa guida utilizzerai il cluster config-central per ospitare la configurazione delle risorse del gateway.
Verifica che tutti i cluster siano stati registrati correttamente nel parco risorse:
gcloud container fleet memberships list --project=$PROJECTL'output di esempio seguente mostra che tutti i cluster sono stati registrati correttamente:
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-612f14810012Installa la definizione di risorsa personalizzata dell'API Gateway sul cluster config-central:
kubectl --context=config-central kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v0.5.0" \ | kubectl apply -f -Questo passaggio installa le definizioni delle risorse personalizzate dell'API Gateway, incluse le risorse
GatewayClass,GatewayeHTTPRoute. Le definizioni delle risorse personalizzate sono gestite dal Network Special Interest Group di Kubernetes. Dopo l'installazione, puoi utilizzare il controller gateway GKE.Abilita Ingress multi-cluster per il tuo parco risorse se non lo hai già fatto. L'attivazione di questa funzionalità abilita anche il controller gateway multi-cluster.
gcloud container fleet ingress enable \ --config-membership=config-central \ --project=$PROJECT gcloud container fleet ingress describe --project=$PROJECTL'output è simile all'esempio seguente:
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'Se il valore di state non è ACTIVE, consulta Risoluzione dei problemi e operazioni per Ingress multi-cluster.
Verifica che
GatewayClassessiano disponibili nel cluster config-central:kubectl get gatewayclasses --context=config-centralL'output è simile all'esempio seguente:
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 16sRisorse
GatewayClassdiverse hanno funzionalità diverse. Per ulteriori informazioni su quando utilizzare quale tipo, consulta Funzionalità di GatewayClass.Esegui il deployment della risorsa gateway di
external-httpinconfig-central: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-centralCome indicato dal campo
gatewayClassName, questa risorsa è diGatewayClassgke-l7-global-external-managed-mc che gestisce Cloud Load Balancing esterno di livello 7 ed espone l'applicazione multi-clusterEsegui il deployment di
HTTPRoutedenominato public-frontend-route su config-central: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-centralQuando esegui il deployment della risorsa
HTTPRoute, viene creata una risorsa Cloud Load Balancing esterno di livello 7 ed espone il frontendServiceImportsupportato dai servizi frontend eseguiti nei cluster std-west, auto-east e auto-central.Il seguente diagramma mostra come, dopo il deployment del gateway multi-cluster, il traffico può essere instradato a qualsiasi servizio multi-cluster frontend su uno qualsiasi dei tre cluster di applicazioni:
Attendi che il bilanciatore del carico sia pronto con un indirizzo IP esterno di cui è stato eseguito il provisioning prima di procedere con il passaggio successivo. L'assegnazione dell'indirizzo IP può richiedere fino a 10 minuti. Puoi monitorare l'avanzamento usando un loop di visualizzazione. Il bilanciatore del carico ha un nome nel pattern simile a gkemcg-onlineboutique-external-http-k09mfhk74gop:
watch -n 20 --difference=permanent \ "gcloud compute forwarding-rules list \ | grep -A 5 NAME..*external-http"L'output è simile all'esempio seguente:
NAME: gkemcg-onlineboutique-external-http-k09mfhk74gop REGION: IP_ADDRESS: 34.149.29.176 IP_PROTOCOL: TCP TARGET: gkemcg-onlineboutique-external-http-k09mfhk74gopQuando il bilanciatore del carico è pronto, esegui questo comando in Cloud Shell per esportare l'indirizzo IP esterno del bilanciatore del carico creato tramite l'applicazione dei manifest external-http-gateway.yaml e public-frontend-route.yaml:
export EXTERNAL_LB_IP=$(kubectl --context=config-central \ -n onlineboutique get gateway external-http \ -o=jsonpath='{.status.addresses[0].value}')Quando invii una richiesta al bilanciatore del carico con le intestazioni appropriate, restituisce i contenuti HTML forniti dal servizio frontend. Ad esempio, poiché hai configurato la risorsa
HTTPRouteper mappare il nome hoststore.example.comal frontendServiceImport, devi fornire l'intestazioneHOSTquando effettui la richiesta HTTP. Se il seguente esempio di curl restituisce un errore, attendi qualche minuto e riprova:curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e PodL'output corretto del comando curl è simile al seguente esempio:
<b>Cluster: </b>auto-central<br/> <b>Zone: </b>us-central1-f<br/> <b>Pod: </b>frontend-7c7d596ddc-jdh8f
Testa il comportamento del routing multiregionale dell'applicazione
Una delle potenti funzionalità offerte dai servizi multi-cluster e dai gateway multi-cluster è che le richieste esterne vengono instradate al cluster geograficamente più vicino.
Per testare il comportamento dell'applicazione in più regioni, genera traffico che ha origine dalle varie regioni in cui è stato eseguito il deployment dei cluster. Crea tre piccoli pod, uno in ciascuno dei cluster di gestione (std-west, auto-east e auto-central), che puoi utilizzare per inviare richieste HTTP all'endpoint del bilanciatore del carico. I risultati ti consentono di vedere quale frontend Pod risponde.
Crea i pod del client:
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'Quando i pod sono in esecuzione, utilizza un comando curl per inviare una richiesta all'endpoint del bilanciatore del carico dal client
Podnel cluster std-west ed esamina la risposta:kubectl exec -it --context=std-west client-west \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e PodL'output corretto del comando curl è simile al seguente esempio:
<b>Cluster: </b>std-west<br/> <b>Zone: </b>us-west1-a<br/> <b>Pod: </b>frontend-7cf48b79cf-trzc4Esegui la stessa richiesta curl dal client
Podnel cluster auto-east e osserva la risposta:kubectl exec -it --context=auto-east client-east \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e PodL'output corretto del comando curl è simile al seguente esempio:
<b>Cluster: </b>auto-east<br/> <b>Zone: </b>us-east1-d<br/> <b>Pod: </b>frontend-6784b6df98-scdwsPoiché questo è un cluster Autopilot, potrebbe essere necessario eseguire il provisioning di risorse aggiuntive per pianificare
Pod. Se vedi un output simile all'esempio seguente, attendi un istante e riprova:Error from server (BadRequest): pod client-east does not have a host assignedEsegui il comando curl dal client
Podnel cluster auto-central e controlla la risposta:kubectl exec -it --context=auto-central client-central \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e PodL'output corretto del comando curl è simile al seguente esempio:
<b>Cluster: </b>auto-central<br/> <b>Zone: </b>us-central1-b<br/> <b>Pod: </b>frontend-6784b6df98-x2fv4Questi risultati confermano che il traffico viene instradato verso i pod corrispondenti nelle località più vicine all'origine della richiesta.
Testa la resilienza multiregionale dell'applicazione
Oltre a un routing efficiente del traffico, l'esecuzione dei servizi in più regioni offre resilienza nei rari casi in cui è ancora possibile un errore dell'infrastruttura.
Verifica il comportamento eliminando il frontend Deployments in cluster specifici e poi riprova a eseguire il comando curl dal client Pod in quelle regioni. Osserva
che l'applicazione è ancora disponibile e osserva la posizione del Pod
che risponde alla richiesta.
Esegui il comando curl da client-west
Podnel cluster std-west e vedrai che il risultato proviene dal frontend in us-west1:kubectl exec -it --context=std-west client-west \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e PodL'output corretto del comando curl è simile al seguente esempio:
<b>Cluster: </b>std-west<br/> <b>Zone: </b>us-west1-a<br/> <b>Pod: </b>frontend-7cf48b79cf-trzc4Elimina il
Deploymentfrontend nel cluster std-west:kubectl delete deploy frontend \ -n onlineboutique --context=std-westL'output è simile all'esempio seguente:
deployment.apps "frontend" deletedInvia un'altra richiesta da
Podclient-west nel cluster std-west. Dovresti visualizzare una risposta da uno dei restantiDeploymentsfrontend che si trovano nei cluster auto-east o auto-central:kubectl exec -it --context=std-west client-west \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e PodUn output simile all'esempio seguente indica la località dell'elemento
Podintegro che risponde a questa richiesta:<b>Cluster: </b>auto-central<br/> <b>Zone: </b>us-central1-b<br/> <b>Pod: </b>frontend-6784b6df98-x2fv4o
<b>Cluster: </b>auto-east<br/> <b>Zone: </b>us-east1-d<br/> <b>Pod: </b>frontend-6784b6df98-scdwsEsegui il comando più volte per visualizzare risultati alternati.
Con questo deployment dimostrativo, hai aggiunto elementi di resilienza e distribuzione geografica all'applicazione Online Boutique utilizzando servizi multi-cluster e gateway multi-cluster. Le richieste vengono instradate alla regione geografica più vicina e, anche se i servizi frontend o middleware in una regione riscontrano problemi, l'utente finale è comunque in grado di utilizzare correttamente l'applicazione.
Esegui la pulizia
Per evitare che al tuo Account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.
- Nella console Google Cloud, vai alla pagina Gestisci risorse.
- Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
- Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.
Passaggi successivi
- Scopri di più sulla gestione dei parchi risorse e dei cluster Google Cloud.
- Scopri come registrare un cluster, inclusi i cluster GKE Enterprise, in un parco risorse Google Cloud.
- Approfondisci l'API Kubernetes Gateway e il Gateway GKE.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center.