Il networking multi-cluster è uno strumento prezioso che consente casi d'uso come disponibilità elevata, vicinanza agli utenti distribuita a livello globale per 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 utilizzarli 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 GKE Standard e Autopilot per soddisfare le esigenze dell'architettura di ogni applicazione.
Questo documento illustra queste funzionalità attraverso diverse topologie di deployment. Imparerai a eseguire il deployment di un'applicazione in un unico cluster GKE ed eseguirne la migrazione a un deployment multi-cluster su GKE standard e Autopilot. Utilizzi GKE Servizi multi-cluster per il traffico da est a ovest Gateway multi-cluster per abilitare il networking nord-sud multi-cluster.
Il documento è rivolto ai cloud architect e ai team operativi che utilizzano o pianificano per il deployment, GKE per eseguire il deployment di servizi in più cluster. In questo documento si presuppone che tu abbia familiarità con Kubernetes
GKE Standard e GKE Autopilot
GKE fornisce un deployment Kubernetes gestito 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à, vedi Scegli una modalità operativa del cluster.
Servizi multi-cluster e gateway multi-cluster
Kubernetes può essere eseguito utilizzando un unico piano di controllo in diverse zone cloud
offrono resilienza e 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 in più cluster
con un IP virtuale, che corrisponde al comportamento di un servizio ClusterIP
accessibili in un cluster. Questo approccio offre i seguenti vantaggi:
- Il bilanciamento del carico dei servizi può avvenire in più cluster nella stessa regione oppure regioni diverse (traffico da est a 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.
- 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. Il gateway consente a GKE di eseguire il deployment dei bilanciatori del carico Google Cloud forniscono 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 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 ulteriori informazioni, vedi 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 stateless del traffico che vuoi spostare ad Autopilot in virtù del suo costo più efficiente model.
In alternativa, potresti voler posizionare i frontend dell'applicazione più vicino agli utenti. Questo fornisce una latenza minore e una memorizzazione nella cache, che migliora l'applicazione le prestazioni 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,
Questo documento utilizza Negozio online i microservizi cloud dimostrano l'applicazione per dimostrare un pattern multi-cluster che può essere utilizzata per migliorare il deployment della demo a zona singola. Inizi con un una versione a zona singola dell'applicazione. Poi aggiungi elementi di alta la disponibilità e la resilienza mediante servizi multi-cluster i gateway e ridurre il lavoro manuale sfruttando Autopilot.
Deployment iniziale su cluster singolo
Nel diagramma seguente, viene eseguito inizialmente il deployment dell'applicazione Online Boutique
in un singolo cluster in modalità GKE Standard denominato
std-west ed è esposto utilizzando un servizio LoadBalancer
:
Esegui la migrazione ai servizi multi-cluster
Nel passaggio intermedio successivo, creerai altre due di cluster e il deployment dei servizi stateless in altre regioni. Tu crea due cluster GKE Autopilot denominati auto-east e auto-central in due regioni distinte dalla singola std-west GKE Standard e registra i cluster il Il parco risorse Google Cloud.
I parchi risorse sono un concetto di Google Cloud per l'organizzazione logica dei cluster e di altri e ti consentono di utilizzare e gestire funzionalità multi-cluster e applicare in modo coerente in tutti i sistemi.
Esporti cartservice nel cluster std-west in onlineboutique
dello spazio dei nomi ai nuovi cluster del parco risorse
ServiceExport.
Esegui il deployment del servizio frontend di Online Boutique su tutti e tre i cluster ed esponi
attraverso una
ClusterIP
completamente gestito di Google Cloud. Quindi esporterai il servizio nel parco risorse utilizzando ServiceExports
.
Servizi come il livello middleware di Online Boutique (come
productcatalog, shipping e adservice) viene implementato in tutti e tre
cluster.
Un Pod
eseguito in qualsiasi cluster nel parco risorse può accedere a un Service
esportato
inviando una richiesta all'URI ClusterSet
di quel servizio. La richiesta
a un endpoint che supporta il servizio.
Il servizio frontend può 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 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. L'architettura
Viene eseguito il deployment del servizio frontend in tre cluster e nel backend stateful
Il deployment di cartservice 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.
Al parco risorse viene aggiunto un quarto cluster denominato config-central per ospitare e gestire
la configurazione
Gateway
e
HTTPRoute
di risorse create come parte di questa configurazione. HTTPRoute
La risorsa mappa il prefisso / al frontend
ServiceImport:
Il traffico per il frontend di Online Boutique viene inviato a un stato integro
in una delle regioni disponibili. Questo approccio aggiunge elementi di
la disponibilità dell'architettura dell'applicazione Online Boutique.
Nel diagramma seguente, il gateway multi-cluster esegue il deployment di una Bilanciatore del carico che instrada il traffico esterno al servizio frontend stateless di cui è stato eseguito il deployment in ciascuno dei tre cluster di applicazioni nel parco risorse.
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). Non rientra nell'ambito di questo documento, questo approccio ti offre l'opportunità futura di aumentare la resilienza e l'alta disponibilità al livello dei 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.
- Abilita e configura i gateway multi-cluster.
- Testa il comportamento delle applicazioni multiregionali.
Costi
In questo documento vengono utilizzati 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 che siano soddisfatti i seguenti requisiti:
- Ti consigliamo di usare un nuovo progetto per questa guida, in quanto per ripulire il progetto 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, vedi Utilizzo sicuro di IAM e Gestire identità e accesso.
- 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 dà accesso alla riga di comando nel 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 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 enable
I servizi multi-cluster gestiscono componenti Google Cloud come Cloud DNS, regole firewall e Cloud Service Mesh, pertanto anche queste API devono abilitare l'accesso privato. Per ulteriori informazioni, vedi 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 describe
L'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, vedi il sezione relativa alla risoluzione dei problemi della documentazione di MCS.
Crea e configura cluster GKE
Per dimostrare il pattern multi-cluster in questa guida, utilizza tre cluster di applicazioni in tre regioni cloud separate e un cluster per ospitare la configurazione per le risorse del gateway. Puoi registrare tutti i cluster con parco risorse associato al tuo progetto. Un progetto Google Cloud può avere solo associati a un'unica flotta. Questo progetto è noto come host del parco risorse progetto.
Crea GKE Standard e Autopilot cluster:
gcloud container clusters create std-west \ --zone us-west1-a \ --num-nodes=6 \ --enable-ip-alias \ --release-channel regular \ --workload-pool=${PROJECT}.svc.id.goog \ --async gcloud container clusters create-auto auto-east \ --region us-east1 \ --release-channel regular \ --async gcloud container clusters create-auto auto-central \ --region us-central1 \ --release-channel regular \ --async gcloud container clusters create config-central \ --region us-central1 \ --num-nodes=1 \ --enable-ip-alias \ --release-channel regular \ --workload-pool=${PROJECT}.svc.id.goog \ --async
La federazione delle identità per i carichi di lavoro per GKE è abilitata per impostazione predefinita su GKE Autopilot in modo da non dover usare
--workload-pool
quando crei i cluster come fai con di cluster GKE Standard.Attendi che i cluster STATUS per passare da PROVISIONING a RUNNING. Questa procedura può richiedere fino a 10 minuti. Puoi monitorare l'avanzamento per usare un cinturino quando prendi una tazza di caffeina o fai un po' di luce esercizi di stretching 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: PROVISIONING
Quando tutti i cluster sono nello stato IN ESECUZIONE, premi
CTRL-C
per 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"
Puoi utilizzare la federazione delle identità per i carichi di lavoro per GKE per concedere al servizio MCS l'accesso in lettura 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 all'esempio seguente:
- 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. Consulta Registrazione di un cluster per ulteriori dettagli. 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 $PROJECT
L'output di ogni comando è simile all'esempio seguente:
Fetching cluster endpoint and auth data. kubeconfig entry generated for std-west.
Rinominare i contesti per i cluster in modo da agevolarne l'utilizzo nel parte restante 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-central
In questa guida, i contesti sono denominati in base alla loro posizione. Sebbene puoi fornire nomi alternativi, i passaggi rimanenti di questa guida utilizzano i nomi utilizzati in questo passaggio.
Esegui il deployment di Boutique online su GKE Standard
Nel primo passaggio del deployment dimostrativo, esegui il deployment dell'intero set dei servizi delle applicazioni Online Boutique al singolo cluster GKE Cluster standard std-west in us-west1.
Crea lo spazio dei nomi onlineboutique su std-west:
kubectl create namespace onlineboutique --context std-west
L'output è simile all'esempio seguente:
namespace/onlineboutique created
Clona 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. Questa procedura crea
Deployments
Services
per tutti i microservizi di Online Boutique e include una LoadBalancer che espone esternamente il servizio frontend di Online Boutique:cd $WORKDIR kubectl apply -f kubernetes-manifests.yaml \ -n onlineboutique --context=std-west
Attendi che il servizio
LoadBalancer
ottenga 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 43s
Quando
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 Pod
L'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 accedere all'IP esterno assegnato al
frontend-external LoadBalancer
Servizio per accedere all'applicazione e osservare
il suo comportamento. Questo singolo deployment iniziale è mostrato nel seguente diagramma:
Esporta 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-central
L'output di ogni comando è simile all'esempio seguente:
namespace/onlineboutique created
Esporta cartservice dal cluster std-west a tutti gli altri cluster in
ClusterSet
. L'oggettoServiceExport
registra 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 pattern multi-cluster
In questa sezione vengono applicati due manifest selezionati per il deployment dell'architettura multi-cluster pattern. Questi manifest contengono parti selezionate kubernetes-manifests.yaml che hai applicato in precedenza a std-west cluster:
- Il primo manifest viene utilizzato per il frontend
Deployment
,Service
eServiceExport
. - 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
eseguito in qualsiasi cluster nel parco risorse può accedere a un Service
esportato
inviando una richiesta all'URI ClusterSet
di quel servizio in formato
SERVICE_NAME.NAMESPACE.svc.clusterset.local
. Ad esempio, il frontend
Deployments
in tutti e tre i cluster di esempio sono in grado di utilizzare
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 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
comporterebbe HTTP Status 500
errori sui cluster in cui una versione locale di
cartservice non è disponibile e causa lo stato non integro dei pod del frontend.
Imposta una variabile di ambiente per il repository GitHub che contiene la classe manifests:
export MANIFEST_REPO_PATH=https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/cluster-migration
Applica 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-central
Applica i manifest per eseguire il deployment del livello middleware a tutti e tre i carichi di lavoro cluster:
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, le sorgenti
il traffico 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 a e bilancia il carico del traffico esterno in tutti e tre i cluster. Per ottenere questa configurazione, utilizza gateway multi-cluster (MCG). Questo documento segue le indicazioni per la configurazione di una rete multicanale come descritto in Abilitazione dei gateway multi-cluster.
In questa guida 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=$PROJECT
L'output di esempio seguente mostra che tutti i cluster sono stati correttamente registrato:
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-612f14810012
Installa la definizione di risorsa personalizzata dell'API Gateway in config-central cluster:
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 Risorse
GatewayClass
,Gateway
eHTTPRoute
. La risorsa personalizzata le definizioni sono gestite dall'amministratore Gruppo di interesse speciale della rete. 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=$PROJECT
L'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
GatewayClasses
siano disponibili nel cluster config-central:kubectl get gatewayclasses --context=config-central
L'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 16s
Risorse
GatewayClass
diverse hanno funzionalità diverse. Per ulteriori informazioni informazioni su quando utilizzare quale tipo, consulta Funzionalità GatewayClass.Esegui il deployment della risorsa gateway di
external-http
inconfig-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-central
Come indicato dal campo
gatewayClassName
, questa risorsa èGatewayClass
gke-l7-global-external-managed-mc che gestisce il livello 7 Cloud Load Balancing esterno ed espone l'applicazione multi-clusterEsegui il deployment di
HTTPRoute
denominato 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-central
Quando esegui il deployment della risorsa
HTTPRoute
, viene creato un livello esterno 7 Cloud Load Balancing ed espone il frontendServiceImport
supportato dai servizi frontend eseguiti nei sistemi 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 IP esterno di cui è stato eseguito il provisioning prima di procedere con il passaggio successivo. L'operazione potrebbe richiedere fino a 10 minuti l'indirizzo IP da assegnare. Puoi monitorare i progressi usando un orologio ciclo. 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-k09mfhk74gop
Quando il bilanciatore del carico è pronto, esegui questo comando Cloud Shell per esportare l'indirizzo IP esterno del bilanciatore del carico creato mediante l'applicazione di external-http-gateway.yaml e Manifest 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
HTTPRoute
per mappare lastore.example.com
per il frontendServiceImport
, devi fornisci l'intestazioneHOST
quando 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 Pod
L'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 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. Creare tre piccoli pod,
uno in ciascuno dei cluster di gestione (std-west, auto-east e
auto-central), che puoi utilizzare per inviare richieste HTTP al bilanciatore del carico
endpoint. 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 al carico endpoint del bilanciatore del carico dal client
Pod
nel cluster std-west ed esaminare 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 Pod
L'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-trzc4
Esegui la stessa richiesta curl dal client
Pod
nel cluster auto-east, e osserveremo 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 Pod
L'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-scdws
Poiché questo è un cluster Autopilot, potrebbe essere necessario eseguire il provisioning del cluster 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 assigned
Esegui il comando curl dal client
Pod
nel 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 Pod
L'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-x2fv4
Questi 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
nelle regioni in questione. Osservazione
che l'applicazione sia ancora disponibile e controlla la posizione del Pod
che risponde alla richiesta.
Esegui il comando curl da client-west
Pod
nel 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 Pod
L'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-trzc4
Elimina il
Deployment
frontend nel cluster std-west:kubectl delete deploy frontend \ -n onlineboutique --context=std-west
L'output è simile all'esempio seguente:
deployment.apps "frontend" deleted
Invia un'altra richiesta da
Pod
client-west nel cluster std-west. Dovresti vedere una risposta da uno deiDeployments
frontend rimanenti situata 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 Pod
Un output simile all'esempio seguente indica la posizione del
Pod
integro che risponde a questa richiesta:<b>Cluster: </b>auto-central<br/> <b>Zone: </b>us-central1-b<br/> <b>Pod: </b>frontend-6784b6df98-x2fv4
o
<b>Cluster: </b>auto-east<br/> <b>Zone: </b>us-east1-d<br/> <b>Pod: </b>frontend-6784b6df98-scdws
Esegui il comando più volte per visualizzare risultati alternati.
Con questo deployment dimostrativo, hai aggiunto elementi di resilienza e la 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.
- 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ù su Gestione dei parchi risorse e multi-cluster Google Cloud.
- Informazioni su come registrare un cluster, inclusi i cluster GKE Enterprise, in un parco risorse Google Cloud.
- Approfondisci API Kubernetes Gateway e ai Gateway GKE.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Centro architetture cloud.