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.
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 fornisce la modalità Standard. Per ulteriori informazioni sulle differenze tra le modalità, consulta Scegliere una modalità di funzionamento del cluster.
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.
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 passo avanti e offre servizi multi-cluster (MCS) che forniscono 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.
- I carichi di lavoro con stato e senza stato possono essere distribuiti e gestiti in cluster distinti.
- I servizi condivisi sono disponibili in tutti i cluster.
Per scoprire 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 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 fornisce inoltre gateway multicluster (MCG) che estendono il controller del gateway GKE per eseguire il provisioning di bilanciatori del carico che indirizzano il traffico ai servizi di cui è stato eseguito il deployment su diversi cluster GKE.
Il seguente diagramma mostra come, combinando MCS e MCG, puoi gestire gli aspetti complementari del deployment dei servizi e del routing del traffico da un unico control plane:
Per saperne di più, consulta Eseguire il deployment di gateway multi-cluster.
Panoramica della migrazione
Le funzionalità di networking multi-cluster di GKE sono vantaggiose per i carichi di lavoro di 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, potresti avere alcuni componenti con stato su cui si basa la tua applicazione che possono trovarsi solo in una posizione. Questa configurazione richiede il bilanciamento del carico multi-cluster nord-sud per inviare il traffico client al cluster corretto in quella località. Inoltre, è necessario il bilanciamento del carico tra più cluster da est a ovest per inviare traffico tra i cluster in modo da raggiungere i 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 di una singola zona. 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 con un solo cluster
Nel seguente diagramma, l'applicazione Online Boutique viene inizialmente dispiattata su un singolo cluster GKE in modalità standard denominato std-west ed è esposta 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.
Anche servizi come il livello middleware della Boutique online (come
productcatalog, shipping e adservice) vengono di'altra parte implementati in tutti e tre
i 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 viene indirizzata 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 arrivo locali nelle regioni il cui frontend risponde alla richiesta ed evita costi di traffico di rete interregionale non necessari.
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 indirizzato al
cluster GKE Standard originale in us-west1
utilizzando un bilanciatore del carico di rete passthrough esterno creato dal servizio frontend-externalLoadBalancer:
Esegui la migrazione a Gateway multi-cluster
Nel passaggio finale, indirizzi il traffico in entrata per il servizio frontend dalle richieste dei client esterni ai servizi in più cluster del fleet 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 alta disponibilità all'architettura dell'applicazione Online Boutique.
Nel seguente diagramma, 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 risorse.
Nello stato finale, questo pattern opinato mostra un basso accoppiamento tra le parti con stato (cartservice e redis-cart) e senza stato dell'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 i cluster GKE Standard e Autopilot.
- Esegui il deployment di Online Boutique in un cluster GKE Standard di zona.
- Esporta
Servicesmulti-cluster. - Esegui il deployment dei manifest nei cluster Standard e Autopilot.
- Attiva e configura i gateway multi-cluster.
- Verifica il comportamento delle applicazioni multiregione.
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 di soddisfare i seguenti requisiti:
- Ti consigliamo di utilizzare un nuovo progetto per questa guida, in quanto il modo più semplice per eseguire la pulizia è eliminare il progetto al termine.
- Questa guida presuppone che tu disponga del ruolo Proprietario IAM per il tuo progetto Google Cloud. Per le impostazioni di produzione o reali, è buona prassi limitare l'ambito delle autorizzazioni al privilegio minimo. Per ulteriori informazioni, consulta Utilizzare IAM in modo sicuro e Gestire identità e accessi.
- Acquisisci familiarità con l'architettura dell'applicazione demo di microservizi di Online Boutique.
Prepara l'ambiente
In questa guida utilizzerai Cloud Shell per inserire i 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 della 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 l'ID del tuo progetto:
export PROJECT=PROJECT_ID gcloud config set project ${PROJECT}Attiva 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 ACTIVE:
gcloud container fleet multi-cluster-services describeL'output è simile al seguente esempio:
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, utilizzerai tre cluster di applicazioni in tre regioni cloud distinte e un cluster per ospitare la configurazione per le risorse 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 progetto di hosting 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 nei cluster GKE Autopilot, quindi non devi utilizzare il flag
--workload-poolquando crei questi cluster, come accade per i cluster GKE Standard.Attendi che lo STATUS dei cluster passi da PROVISIONING a RUNNING. Questa operazione 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 al seguente esempio:
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 RUNNING, premi
CTRL-Cper interrompere il comando.Aggiungi un'associazione di criteri Identity and Access Management (IAM) che conceda all'account di servizio MCS del progetto di 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"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'account di servizio MCS Importer GKE del progetto host del parco 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 i cluster GKE Standard e Autopilot nel 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}Per ogni comando, l'output è simile al seguente esempio:
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 configura 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
LoadBalancerriceva 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 mostra l'indirizzo IP pubblico del bilanciatore del carico.Una volta che
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 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à all'applicazione. Esporti il backend cartservice come servizio multi-cluster nei cluster GKE Autopilot.
Crea lo spazio dei nomi onlineboutique sugli altri cluster:
kubectl create namespace onlineboutique --context auto-east kubectl create namespace onlineboutique --context auto-central kubectl create namespace onlineboutique --context config-centralPer ogni comando, l'output è simile al seguente esempio:
namespace/onlineboutique createdEsporta cartservice dal cluster std-west in tutti gli altri cluster in
ClusterSet. L'oggettoServiceExportregistra il servizio cartservice con i servizi multi-cluster GKE per l'esportazione in tutti i cluster del parco risorse che dispongono dello spazio dei nomi onlineboutique. Per maggiori 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 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 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 il più a lungo possibile, eviti costi non necessari per il traffico di rete interregionale.
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 al relativo URI ClusterSet. Questo passaggio è fondamentale. Se questo nome host del servizio
non viene aggiornato, il servizio frontend chiederà a kube-dns cartservice instead of 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 frontend in tutti e tre i cluster di workload:
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 i frontend Deployment, Service e ServiceExport attivi
nei cluster std-west, auto-east e auto-central. Inoltre, in ogni cluster sono in esecuzione i servizi middleware di Online Boutique. Tuttavia, il traffico esterno viene comunque indirizzato solo al Service in esecuzione nel cluster iniziale in us-west1, come mostrato nel seguente diagramma:
Attivare e configurare i gateway multi-cluster
In questa sezione, indirizzi il traffico verso i frontend e bilanci il traffico esterno tra i frontend in tutti e tre i cluster. Per ottenere questa configurazione, utilizza i gateway multicluster (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 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à comporta anche l'attivazione del controller di 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 ulteriori informazioni su quando utilizzare un tipo o l'altro, consulta Funzionalità di GatewayClass.Esegui il deployment della risorsa gateway
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 è di tipoGatewayClassgke-l7-global-external-managed-mc che gestisce Cloud Load Balancing esterno di livello 7 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 Cloud Load Balancing 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 il deployment del gateway multi-cluster, il traffico può essere indirizzato a uno dei servizi frontend multi-cluster su uno 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 al seguente esempio:
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, viene restituito il contenuto HTML visualizzato 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 di routing multi-regione dell'applicazione
Una delle funzionalità avanzate ottenute utilizzando i servizi e i gateway multi-cluster è che le richieste esterne vengono indirizzate al cluster geograficamente più vicino.
Per testare il comportamento multi-regione dell'applicazione, genera traffico proveniente dalle varie regioni in cui hai implementato i 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 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 visualizzi un output simile al seguente esempio, attendi un istante e riprova:Error from server (BadRequest): pod client-east does not have a host assignedEsegui 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 nelle località più vicine all'origine della richiesta.
Testare la resilienza multi-regione dell'applicazione
Oltre a un routing del traffico efficiente, l'esecuzione dei servizi in più regioni garantisce la resilienza nel raro, ma ancora possibile, caso di guasto dell'infrastruttura.
Testa il comportamento eliminando il frontend Deployments in cluster specifici
e poi 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 verifica che il risultato provenga 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 al seguente esempio:
deployment.apps "frontend" deletedInvia un'altra richiesta da client-west
Podnel cluster std-west. Dovresti visualizzare 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 al seguente esempio indica la posizione del
Podin buono stato 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 i risultati in alternanza.
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 instradate alla regione geografica più vicina e, anche se i servizi frontend o middleware di 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.
- 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ù sulla gestione dei parchi risorse e dei multi-cluster di 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.