La rete multicluster è uno strumento prezioso che consente casi d'uso come l'alta disponibilità a livello regionale, la vicinanza agli utenti distribuita a livello globale per una latenza inferiore e l'isolamento organizzativo tra i team. Google Kubernetes Engine (GKE) offre funzionalità integrate per il networking multi-cluster che puoi attivare e utilizzare su larga scala in un parco di cluster GKE. Questa funzionalità consente inoltre di combinare o eseguire la migrazione dell'infrastruttura di cui è stato eseguito il deployment tra GKE Standard e Autopilot per soddisfare le esigenze di architettura di ogni applicazione.
Questa pagina mostra queste funzionalità tramite diverse topologie di deployment. Scopri come eseguire la migrazione di un'applicazione di cui è stato eseguito il deployment in un singolo cluster GKE a un deployment multi-cluster nei cluster GKE Standard e Autopilot. Utilizza Servizi multi-cluster GKE per il traffico est-ovest e gateway multi-cluster per abilitare il networking nord-sud multi-cluster.
Questa pagina è rivolta agli architetti cloud e ai team operativi che utilizzano o prevedono di utilizzare GKE per eseguire il deployment di servizi su più cluster Kubernetes. Prima di leggere questa pagina, assicurati di conoscere Kubernetes.
GKE Standard e GKE Autopilot
GKE offre un deployment Kubernetes gestito con una un set di caratteristiche che include un piano di controllo per l'alta disponibilità. GKE possono essere avviati rapidamente e scalare fino a 15.000 nodi. Con GKE Pilota automatico cluster, Google gestisce l'infrastruttura, compresi il piano di controllo tra i nodi. Se invece vuoi configurare e gestire i nodi, GKE fornisce Modalità Standard.
Per ulteriori informazioni sulle differenze tra le modalità, consulta Scegliere una modalità di funzionamento del cluster.
Servizi multi-cluster e gateway multi-cluster
Kubernetes può essere eseguito utilizzando un unico piano di controllo in zone cloud diverse per fornire resilienza e una maggiore disponibilità per i tuoi servizi.
GKE fa un ulteriore passo in questa
GKE
Servizi multi-cluster
(MCS) che fornisce un meccanismo di rilevamento e Service Discovery tra cluster.
I servizi che utilizzano questa funzionalità sono rilevabili e accessibili tra i cluster con un indirizzo IP virtuale, che corrisponde al comportamento di un servizio ClusterIP accessibile in un cluster. Questo approccio offre i seguenti vantaggi:
- I servizi possono essere bilanciati su più cluster nella stessa regione o in regioni diverse (traffico est-ovest).
- Sono possibili opzioni di alta disponibilità dei servizi tra regioni.
- È possibile eseguire il deployment dei carichi di lavoro stateful e stateless e gestirli in cluster.
- I servizi condivisi sono disponibili in tutti i cluster.
Per scoprire di più su come eseguire il deployment di MCS, consulta Configurazione di servizi multi-cluster.
GKE fornisce un'implementazione dell'API Kubernetes Gateway che utilizza Controller gateway GKE. Gateway consente a GKE di eseguire il deployment di bilanciatori del carico Google Cloud per fornire il routing del traffico in entrata (da nord a 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 del carico bilanciatori che instradano il traffico a servizi di cui è stato eseguito il deployment cluster GKE.
Il seguente diagramma mostra come, quando combini MCS e MCG, puoi gestire gli aspetti complementari del deployment del servizio e dell'instradamento del traffico di un singolo piano di controllo:
Per saperne di più, consulta Eseguire il deployment di gateway multi-cluster.
Panoramica della migrazione
Le funzionalità di networking multi-cluster GKE sono vantaggiosi per i carichi di lavoro vari profili. Ad esempio, potresti avere componenti senza stato con traffico picchiettato che vuoi spostare in Autopilot a causa del suo modello di costo più efficiente.
In alternativa, ti consigliamo di posizionare i frontend dell'applicazione più vicino agli utenti. Questo approccio offre una latenza e una memorizzazione nella cache inferiori che migliorano le prestazioni dell'applicazione e l'esperienza utente. Allo stesso tempo, è possibile che alcuni su cui si basa la tua applicazione e che possono risiedere in una sola posizione. Questa configurazione richiede il bilanciamento del carico multi-cluster nord-sud per inviare il traffico client al cluster corretto in quella località. Hai bisogno anche di est-ovest, il bilanciamento del carico multi-cluster per inviare il traffico tra i cluster e raggiungere componenti stateful,
Questa pagina 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. Inizia con una versione monozona dell'applicazione. Aggiungi poi elementi di alta disponibilità e resilienza utilizzando servizi e gateway multi-cluster e riduci la complessità operativa sfruttando Autopilot.
Deployment iniziale su cluster singolo
Nel diagramma seguente, viene eseguito inizialmente il deployment dell'applicazione Online Boutique
in un singolo cluster GKE Standard denominato
std-west ed è esposto utilizzando un servizio LoadBalancer:
Esegui la migrazione ai servizi multi-cluster
Nel passaggio intermedio successivo, crei altri due cluster e i servizi senza stato vengono di cuipiati in altre regioni. Puoi creare due cluster GKE Autopilot denominati auto-east e auto-central in due regioni distinte dal singolo cluster GKE Standard std-west e registrarli nel parco risorse Google Cloud.
I parchi risorse sono un concetto di Google Cloud per l'organizzazione logica dei cluster e di altre risorse; ti consentono di utilizzare e gestire le funzionalità multi-cluster e di applicare criteri coerenti in tutti i tuoi sistemi.
Esporti cartservice nel cluster std-west nello spazio dei nomi onlineboutique nei nuovi cluster di parchi utilizzando ServiceExport.
Esegui il deployment del servizio frontend di Online Boutique su tutti e tre i cluster e espostolo tramite un servizio ClusterIP. Poi esporti il servizio nel parco utilizzando ServiceExports.
Servizi come il livello middleware di Online Boutique (come
productcatalog, shipping e adservice) viene implementato in tutti e tre
cluster.
Un Pod in esecuzione in qualsiasi cluster del parco risorse può accedere a un Service estratto inviando una richiesta all'URI ClusterSet del servizio. La richiesta
a un endpoint che supporta il servizio.
Il servizio frontend è in grado di utilizzare i servizi middleware (ad esempio productcatalogservice o currencyservice) localmente nello stesso cluster. Questa architettura consente di mantenere le richieste in entrata locali nelle regioni il cui il frontend risponde alla richiesta ed evita una rete tra regioni non necessaria addebiti sul traffico.
Il seguente diagramma illustra i due servizi multi-cluster. Il servizio frontend stateless viene eseguito in tre cluster e il servizio cartservice stateful viene eseguito in un cluster. Il diagramma mostra anche che in questo
passaggio intermedio, il traffico in entrata per il servizio frontend rimane instradato verso
il cluster GKE Standard originale in us-west1
utilizzando un bilanciatore del carico di rete passthrough esterno creato
Servizio LoadBalancer:
Esegui la migrazione a un gateway multi-cluster
Nel passaggio finale, instrada il traffico in entrata per il frontend Servizio proveniente da richieste di client esterni a servizi in più cluster nel un parco risorse utilizzando un gateway multi-cluster.
Un quarto cluster denominato config-central viene aggiunto al parco 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 della boutique online viene inviato a un endpoint funzionante in una delle regioni disponibili. Questo approccio aggiunge elementi di
la disponibilità dell'architettura dell'applicazione Online Boutique.
Nel diagramma seguente, il gateway multicluster 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 su ciascuno dei tre cluster di applicazioni del parco.
Nello stato finale, questo modello "guidato" dimostra un basso accoppiamento tra le parti stateful (cartservice e redis-cart) e stateless di l'applicazione (frontend, emailservice, checkoutservice, recommendationservice, paymentservice, productcatalogservice, currencyservice, shippingservice e adservice). Anche se non rientra nell'ambito di questa pagina, questo approccio ti offre in futuro l'opportunità di aggiungere resilienza e alta disponibilità al livello di servizi stateful.
Obiettivi
- Crea e configura GKE Standard Autopilot.
- Esegui il deployment di Online Boutique su un GKE Standard a livello di zona in un cluster Kubernetes.
- Esporta multi-cluster
Services. - Esegui il deployment dei manifest nei cluster Standard e Autopilot.
- Attiva 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 basata sull'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 di soddisfare i seguenti requisiti:
- Ti consigliamo di usare un nuovo progetto per questa guida, in quanto per eseguire la pulizia consiste nell'eliminare il progetto al termine.
- Questa guida presuppone che tu abbia il ruolo IAM proprietario per progetto Google Cloud. Per la produzione o ambientazioni reali, è meglio di modificare l'ambito delle autorizzazioni in base al privilegio minimo. Per ulteriori informazioni, consulta Utilizzare IAM in modo sicuro e Gestire identità e accessi.
- Acquisisci familiarità con le Negozio online di microservizi dimostrano l'architettura dell'applicazione.
prepara l'ambiente
In questa guida, utilizzi Cloud Shell per inserire comandi. Cloud Shell ti consente di accedere 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 nella console Google Cloud. L'inizializzazione può richiedere diversi minuti, ma la finestra viene visualizzata immediatamente.
In the Google Cloud console, activate 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 i passaggi in questa pagina:
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 componenti di Google Cloud come Cloud DNS, regole firewall e Cloud Service Mesh, pertanto anche queste API devono essere attivate. Per saperne di più, consulta la panoramica di Cloud Service Mesh.
L'output è simile al seguente esempio:
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 i dettagli sulla risoluzione dei problemi relativi ai servizi multicluster.
Crea e configura i cluster GKE
Per dimostrare il pattern multi-cluster in questa guida, vengono utilizzati tre cluster di applicazioni in tre regioni cloud separate e un cluster per ospitare la configurazione per le risorse del gateway. Registra tutti i cluster nel parco risorse associato al tuo progetto. Un progetto Google Cloud può avere associato un solo parco risorse. Questo progetto è noto come host del parco risorse progetto.
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 su GKE Autopilot in modo da non dover usare
--workload-poolquando crei i cluster come fai con di cluster GKE Standard.Attendi che i dati dei cluster STATUS per passare da PROVISIONING a RUNNING. Questa procedura può richiedere fino a 10 minuti. Puoi monitorare l'avanzamento utilizzando un loop di visualizzazione:
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 e interrompere il comando.Aggiungi un'associazione di criteri IAM (Identity and Access Management) per concedere all'host del parco risorse all'account di servizio MCS del progetto 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"Utilizza 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'oggetto MCS del progetto host del parco risorse L'account di servizio Importatore GKE richiede questo ruolo.
L'output è simile al seguente esempio:
- members: - serviceAccount:PROJECT_ID.svc.id.goog[gke-mcs/gke-mcs-importer] role: roles/compute.networkViewer [...]Registra GKE Standard e Autopilot al parco risorse del tuo progetto. Per ulteriori dettagli, consulta la sezione 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 le voci di 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 $PROJECTPer ogni comando, l'output è simile al seguente esempio:
Fetching cluster endpoint and auth data. kubeconfig entry generated for std-west.Rinomina i contesti per i cluster in modo da facilitarne l'utilizzo nel resto di questa pagina:
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, i passaggi rimanenti di questa guida utilizzano i nomi utilizzati in questo passaggio.
Esegui il deployment di Online Boutique su GKE Standard
Nel primo passaggio del deployment di dimostrazione, esegui il deployment dell'insieme completo di servizi dell'applicazione Online Boutique nell'unico 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 al seguente esempio:
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 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 al seguente esempio:
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 visualizza l'IP pubblico. del bilanciatore del carico.Quando
Serviceè pronto, ottieni l'indirizzo IP esterno del carico e utilizzare curl per verificare che il frontend sia pronto. Se questo 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 monozona di Online Boutique in esecuzione in us-west1-a.
Puoi anche utilizzare un browser web per accedere 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:
Esportare cartservice come servizio multi-cluster
In questa sezione, inizierai ad aggiungere elementi di alta disponibilità al un'applicazione. Esporta il backend cartservice come servizio multi-cluster ai 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 in tutti gli altri cluster in
ClusterSet. L'oggettoServiceExportregistra il servizio cartservice. Servizio, con i servizi multi-cluster GKE, per l'esportazione in Tutti i cluster nel parco risorse che presentano lo spazio dei nomi onlineboutique. Per ulteriori dettagli, vedi registrare 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 il pattern multi-cluster
In questa sezione applichi due manifest selezionati per eseguire 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 il deployment del middleware
Services(emailservice, checkoutservice, recommendationservice, paymentservice, productcatalogservice, currencyservice, shippingservice e adservice) in tutte le regioni in cui è in esecuzione un frontend. Se mantieni un locale in una regione per il più a lungo possibile, eviterai inutili per il traffico di rete tra regioni.
Un Pod in esecuzione in qualsiasi cluster del parco risorse può accedere a un Service esportato
inviando una richiesta all'URI ClusterSet per quel 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 servizio
cartservice nello spazio dei nomi onlineboutique inviando una richiesta a
cartservice.onlineboutique.svc.clusterset.local.
Per questo motivo, in ogni manifest, il nome host per cartservice è stato
aggiornato all'URI ClusterSet. Questo passaggio è fondamentale. Se il nome host di questo servizio
non viene aggiornato, il servizio di frontend chiederà a kube-dns cartservice
anziché cartservice.onlineboutique.svc.clusterset.local. Questo comportamento causerebbe errori HTTP Status 500 nei cluster in cui non è disponibile una versione locale di cartservice e i pod frontend non sarebbero in stato di salute.
Imposta una variabile di ambiente per il repository GitHub contenente 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 carichi di lavoro cluster:
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 in tutti e tre i cluster di workload:
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 hai il frontend Deployment, Service e ServiceExport attivo
nei cluster std-west, auto-east e auto-central. Hai anche a disposizione
che eseguono i servizi middleware Online Boutique in ogni cluster. Tuttavia, il traffico esterno viene comunque indirizzato solo al 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 a e bilancia il carico del traffico esterno in tutti e tre i cluster. Per ottenere questa configurazione, utilizza gateway multi-cluster (MCG). Questi passaggi per configurare il gruppo di gateway multi-cluster seguono le indicazioni descritte in modo più dettagliato nell'articolo Attivare i gateway multi-cluster.
In questi passaggi, utilizzerai il cluster config-central per ospitare la configurazione per le risorse del gateway.
Verifica che tutti i cluster siano stati registrati correttamente nel parco risorse:
gcloud container fleet memberships list --project=$PROJECTL'esempio di output 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 della risorsa personalizzata dell'API Gateway nel 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, tra cui le risorse
GatewayClass,GatewayeHTTPRoute. Le definizioni di risorse personalizzate sono gestite dal Network Special Interest Group di Kubernetes. Una volta installato, puoi utilizzare il controller GKE Gateway.Se non l'hai ancora fatto, abilita Ingress multi-cluster per il tuo parco risorse. 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 al seguente esempio:
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 sul cluster config-central:kubectl get gatewayclasses --context=config-centralL'output è simile al seguente esempio:
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 maggiori informazioni informazioni su quando utilizzare quale tipo, consulta Funzionalità 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 èGatewayClassgke-l7-global-external-managed-mc che gestisce il livello 7 esterno Cloud Load Balancing ed espone l'applicazione multi-clusterEsegui il deployment della
HTTPRoutepublic-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 di bilanciamento del carico Cloud di livello 7 esterno ed esposto il frontendServiceImportsupportato dai servizi frontend in esecuzione nei cluster std-west, auto-east e auto-central.Il seguente diagramma mostra come, dopo che il gateway multi-cluster viene di cui è stato eseguito il deployment, il traffico può essere instradato verso qualsiasi cluster multi-cluster frontend Servizi su uno qualsiasi dei tre cluster di applicazioni:
Attendi che il bilanciatore del carico sia pronto con un indirizzo IP esterno provisionato prima di procedere con il passaggio successivo. L'assegnazione dell'indirizzo IP può richiedere fino a 10 minuti. Puoi monitorare l'avanzamento utilizzando un loop di monitoraggio. Il bilanciatore del carico ha un nome nel pattern come 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 il seguente 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 pubblicati 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: L'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 di routing multi-regione dell'applicazione
Una delle potenti funzionalità offerte dai servizi multi-cluster in un gateway multi-cluster è che le richieste esterne vengono instradate dal cluster geografico più vicino.
Per testare il comportamento dell'applicazione in più regioni, genera traffico che ha origine da
le varie regioni in cui è stato eseguito il deployment dei cluster. Crea tre piccoli pod, uno in ciascuno dei cluster di servizio (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'Una volta che 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 controlla 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é si tratta di un cluster Autopilot, potrebbe essere necessario eseguire il provisioning di risorse aggiuntive per pianificare
Pod. Se vedi un output simile nell'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 indirizzato ai pod corrispondenti in località più vicine alla richiesta di origine.
Testa la resilienza multiregionale dell'applicazione
Oltre a un routing efficiente del traffico, l'esecuzione dei servizi in più offre resilienza nel raro, ma ancora possibile, caso un guasto dell'infrastruttura.
Verifica il comportamento eliminando il frontend Deployments in cluster specifici
e riprova a eseguire il comando curl dal client Pod in quelle regioni. Verifica che l'applicazione sia ancora disponibile e controlla la posizione del Pod che risponde alla richiesta.
Esegui il comando curl da client-west
Podnel cluster std-west, e vediamo 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 frontend
Deploymentnel 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 vedere una risposta da uno dei frontendDeploymentsrimanenti situati 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 posizione del
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 di dimostrazione, hai aggiunto elementi di resilienza e distribuzione geografica all'applicazione Online Boutique utilizzando servizi e gateway multi-cluster. Le richieste vengono indirizzate al più vicino regione geografica e anche se i servizi frontend o middleware in una regione problemi, l'utente finale è comunque in grado di utilizzare un'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.
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
Passaggi successivi
- Scopri di più su Gestione dei parchi risorse e multi-cluster Google Cloud.
- Scopri come registrare un cluster, inclusi i cluster GKE Enterprise, in un parco risorse Google Cloud.
- Scopri di più sull'API Kubernetes Gateway e su GKE Gateway.
- Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.