Esegui la migrazione al networking multi-cluster con i cluster Autopilot e Standard di Google Kubernetes Engine (GKE)

Prepara l'ambiente

In questa guida utilizzerai Cloud Shell per inserire i comandi. Cloud Shell ti consente di accedere alla riga di comando nella consoleGoogle Cloud e include Google Cloud SDK e altri strumenti, come Google Cloud CLI. Cloud Shell viene visualizzata come finestra nella parte inferiore della consoleGoogle Cloud . L'inizializzazione può richiedere diversi minuti, ma la finestra viene visualizzata immediatamente.

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

2. 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}
   

3. Attiva i servizi richiesti per i passaggi descritti 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 enable
   

   Multi-cluster Services gestisce i componenti Google Cloud come Cloud DNS, le regole firewall e Cloud Service Mesh, quindi anche queste API devono essere abilitate. 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.
   

4. Verifica che i servizi multi-cluster mostrino lo stato ACTIVE:

   gcloud container fleet multi-cluster-services describe
   

   L'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 per la risoluzione dei problemi dei servizi multicluster.

Crea e configura cluster GKE

Per dimostrare il pattern multi-cluster in questa guida, utilizzi tre cluster di applicazioni in tre regioni cloud separate e un cluster per ospitare la configurazione per le risorse Gateway. Registri tutti i cluster nel parco risorse associato al tuo progetto. Un progetto Google Cloud può avere una sola flotta associata. Questo progetto è noto come progetto host del parco risorse.

1. Crea cluster GKE Standard e Autopilot:

   gcloud container clusters create std-west \
       --location 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 \
       --location us-east1 \
       --release-channel regular \
       --async
   
   gcloud container clusters create-auto auto-central \
       --location us-central1 \
       --release-channel regular \
       --async
   
   gcloud container clusters create config-central \
       --location 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 sui cluster GKE Autopilot, quindi non devi utilizzare il flag --workload-pool quando crei questi cluster, come fai con i cluster GKE Standard.

2. Attendi che lo STATO dei cluster passi da PROVISIONING a RUNNING. Questa operazione può richiedere fino a 10 minuti. Puoi monitorare l'avanzamento utilizzando un ciclo di osservazione:

   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: PROVISIONING
   

3. Una volta che tutti i cluster sono nello stato RUNNING, premi CTRL-C per interrompere il comando.

4. Aggiungi un binding dei criteri Identity and Access Management (IAM) che concede all'account di servizio MCS del progetto host del parco risorse il ruolo Utente di rete per il proprio progetto:

   gcloud projects add-iam-policy-binding ${PROJECT} \
       --member "serviceAccount:${PROJECT}.svc.id.goog[gke-mcs/gke-mcs-importer]" \
       --role "roles/compute.networkViewer"
   

   Utilizzi 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, il account di servizio Importer GKE di MCS del progetto host del parco risorse 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
   [...]
   

5. 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.
   

6. Connettiti ai cluster e genera voci kubeconfig:

   gcloud container clusters get-credentials std-west \
       --location us-west1-a --project $PROJECT
   
   gcloud container clusters get-credentials auto-east \
       --location us-east1 --project $PROJECT
   
   gcloud container clusters get-credentials auto-central \
       --location us-central1 --project $PROJECT
   
   gcloud container clusters get-credentials config-central \
       --location us-central1 --project $PROJECT
   

   Per ogni comando, l'output è simile al seguente esempio:

   Fetching cluster endpoint and auth data.
   kubeconfig entry generated for std-west.
   

7. Rinomina i contesti per i cluster in modo che siano più facili da utilizzare 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-central
   

   In 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 dimostrativo, esegui il deployment dell'intero insieme di servizi dell'applicazione Online Boutique nel singolo cluster GKE Standard std-west in us-west1.

1. Crea lo spazio dei nomi onlineboutique su std-west:

   kubectl create namespace onlineboutique --context std-west
   

   L'output è simile al seguente esempio:

   namespace/onlineboutique created
   

2. Clona 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`
   

3. Esegui il deployment di Online Boutique su std-west. Questo processo crea Deployments e Services per tutti i microservizi di Online Boutique e include un servizio di tipo LoadBalancer che espone esternamente il servizio di frontend di Online Boutique:

   cd $WORKDIR
   
   kubectl apply -f kubernetes-manifests.yaml \
       -n onlineboutique --context=std-west
   

4. 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 al seguente esempio:

   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 mostra l'indirizzo IP pubblico del bilanciatore del carico.

5. Quando Service è pronto, recupera l'indirizzo IP esterno del bilanciatore del carico e utilizza curl per verificare che il frontend sia pronto. Se questo comando curl restituisce un errore, attendi qualche istante prima di riprovare:

     curl $(kubectl get svc frontend-external \
         -n onlineboutique --context=std-west \
         -o=jsonpath="{.status.loadBalancer.ingress[0].ip}") | \
           grep -e Cluster -e Zone -e Pod
   

   L'output riuscito del comando curl è simile al seguente esempio:

   <b>Cluster: </b>std-west<br/>
   <b>Zone: </b>us-west1-a<br/>
   <b>Pod: </b>frontend-b7bddcc97-wdjsk
   

Ora hai una versione a zona singola di Online Boutique in esecuzione in us-west1-a. Puoi anche utilizzare un browser web per passare all'IP esterno assegnato al servizio frontend-external LoadBalancer per accedere all'applicazione e osservarne il comportamento. Questo singolo deployment iniziale è mostrato nel seguente diagramma:

Esporta cartservice come servizio multi-cluster

In questa sezione, inizi ad aggiungere elementi di alta disponibilità all'applicazione. Esporta il backend cartservice come servizio multi-cluster nei cluster GKE Autopilot.

1. Crea lo spazio dei nomi onlineboutique nei cluster rimanenti:

   kubectl create namespace onlineboutique --context auto-east
   
   kubectl create namespace onlineboutique --context auto-central
   
   kubectl create namespace onlineboutique --context config-central
   

   Per ogni comando, l'output è simile al seguente esempio:

   namespace/onlineboutique created
   

2. Esporta cartservice dal cluster std-west a tutti gli altri cluster in ClusterSet. L'oggetto ServiceExport registra il servizio cartservice con i servizi multi-cluster GKE per l'esportazione in tutti i cluster del parco risorse in cui è presente lo spazio dei nomi onlineboutique. Per maggiori 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 curati per eseguire il deployment del pattern multicluster. Questi manifest contengono porzioni selezionate del file kubernetes-manifests.yaml che hai applicato in precedenza al cluster std-west:

• Il primo manifest viene utilizzato per il frontend Deployment, Service e ServiceExport.
• 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 a una regione il più a lungo possibile, eviti costi di traffico di rete interregionale non necessari.

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 cartservice, nello spazio dei nomi onlineboutique, effettuando una richiesta a cartservice.onlineboutique.svc.clusterset.local.

Per questo motivo, in ogni manifest, il nome host di cartservice è stato aggiornato al relativo URI ClusterSet. Questo passaggio è fondamentale. Se il nome host di questo servizio non viene aggiornato, il servizio frontend chiederà a kube-dns cartservice anziché cartservice.onlineboutique.svc.clusterset.local. Questo comportamento comporterebbe errori HTTP Status 500 nei cluster in cui non è disponibile una versione locale di cartservice e causerebbe lo stato non integro dei pod frontend.

1. Imposta una variabile di ambiente per il repository GitHub che contiene i manifest:

   export MANIFEST_REPO_PATH=https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/cluster-migration
   

2. Applica i manifest per eseguire il deployment del livello frontend a tutti e tre i cluster del 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-central
   

3. Applica i manifest per eseguire il deployment del livello middleware a tutti e tre i cluster di carichi di lavoro:

   kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-middleware-manifests.yaml \
       -n onlineboutique --context=std-west
   
   kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-middleware-manifests.yaml \
       -n onlineboutique --context=auto-east
   
   kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-middleware-manifests.yaml \
       -n onlineboutique --context=auto-central
   

Ora hai frontend Deployment, Service e ServiceExport attivi nei cluster std-west, auto-east e auto-central. In ogni cluster sono presenti anche servizi middleware Online Boutique in esecuzione in locale. Tuttavia, il traffico esterno viene ancora 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 e bilanci il carico del traffico esterno tra i frontend di tutti e tre i cluster. Per ottenere questa configurazione, utilizza i gateway multicluster (MCG). Questi passaggi per configurare MCG seguono le indicazioni descritte in modo più dettagliato nella sezione Attivazione di gateway multi-cluster.

In questi passaggi, utilizzi il cluster config-central per ospitare la configurazione per le risorse Gateway.

1. 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 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-612f14810012
   

2. Installa la definizione di risorsa personalizzata dell'API Gateway sul cluster config-central:

   kubectl --context=config-central kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v0.5.0" \
       | kubectl apply -f -
   

   Questo passaggio installa le definizioni delle risorse personalizzate dell'API Gateway, incluse le risorse GatewayClass, Gateway e HTTPRoute. Le definizioni di risorse personalizzate sono gestite dal Network Special Interest Group di Kubernetes. Una volta installato, puoi utilizzare il controller GKE Gateway.

3. Se non l'hai ancora fatto, abilita Ingress multi-cluster per il tuo parco risorse. L'attivazione di questa funzionalità attiva 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 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.

4. Verifica che GatewayClasses siano disponibili sul cluster config-central:

   kubectl get gatewayclasses --context=config-central
   

   L'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   16s
   

   Risorse GatewayClass diverse hanno funzionalità diverse. Per saperne di più su quando utilizzare ciascun tipo, consulta Funzionalità di GatewayClass.

5. Esegui il deployment della risorsa gateway external-http in config-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 è di tipo GatewayClass gke-l7-global-external-managed-mc, che gestisce il bilanciamento del carico di livello 7 esterno di Cloud Load Balancing ed espone l'applicazione multicluster

6. Esegui 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 creata una risorsa di Cloud Load Balancing esterno di livello 7 e viene esposto il frontend ServiceImport supportato dai servizi di frontend eseguiti nei cluster std-west, auto-east e auto-central.

   Il seguente diagramma mostra come, dopo il deployment del gateway multi-cluster, il traffico può essere indirizzato a uno qualsiasi dei servizi multi-cluster frontend su uno qualsiasi dei tre cluster di applicazioni:

   

7. Attendi che il bilanciatore del carico sia pronto con un indirizzo IP esterno di cui è stato eseguito il provisioning prima di procedere al passaggio successivo. L'assegnazione dell'indirizzo IP può richiedere fino a 10 minuti. Puoi monitorare i progressi utilizzando un anello per lo smartwatch. Il bilanciatore del carico ha un nome con un 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 al seguente esempio:

   NAME: gkemcg-onlineboutique-external-http-k09mfhk74gop
   REGION:
   IP_ADDRESS: 34.149.29.176
   IP_PROTOCOL: TCP
   TARGET: gkemcg-onlineboutique-external-http-k09mfhk74gop
   

8. Quando 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}')
   

9. 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 il nome host store.example.com al frontend ServiceImport, devi fornire l'intestazione HOST quando 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 Pod
   

   L'output riuscito 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 multiregionale dell'applicazione

Una delle potenti funzionalità ottenute utilizzando i servizi multi-cluster e i gateway multi-cluster è che le richieste esterne vengono indirizzate al cluster geograficamente più vicino.

Per testare il comportamento multiregionale dell'applicazione, genera traffico proveniente dalle varie regioni in cui hai eseguito il deployment dei cluster. Crea tre piccoli pod, uno in ciascuno dei cluster di pubblicazione (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.

1. 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'
   

2. Una volta che i pod sono in esecuzione, utilizza un comando curl per inviare una richiesta all'endpoint del bilanciatore del carico dal client Pod nel cluster std-west e rivedi 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 riuscito 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
   

3. Esegui la stessa richiesta curl dal client Pod nel cluster auto-east e guarda 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 riuscito 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é si tratta di un cluster Autopilot, potrebbe essere necessario eseguire il provisioning di risorse aggiuntive per pianificare Pod. Se vedi un output simile al seguente esempio, attendi un momento e riprova:

    Error from server (BadRequest): pod client-east does not have a host assigned
   

4. 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 riuscito 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 nelle posizioni più vicine all'origine della richiesta.

Testare la resilienza multiregionale dell'applicazione

Oltre al routing efficiente del traffico, l'esecuzione dei servizi in più regioni garantisce la resilienza nel raro, ma comunque possibile, caso di guasto dell'infrastruttura.

Verifica il comportamento eliminando frontend Deployments in cluster specifici e poi riprova il comando curl dal client Pod in queste regioni. Osserva che l'applicazione è ancora disponibile e guarda la posizione di Pod che risponde alla richiesta.

1. Esegui il comando curl da client-west Pod nel 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 Pod
   

   L'output riuscito 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
   

2. Elimina il frontend Deployment nel cluster std-west:

   kubectl delete deploy frontend \
       -n onlineboutique --context=std-west
   

   L'output è simile al seguente esempio:

   deployment.apps "frontend" deleted
   

3. Invia un'altra richiesta da client-west Pod nel cluster std-west. Dovresti vedere una risposta da uno dei frontend Deployments rimanenti 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 Pod
   

   Un output simile al seguente esempio 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 distribuzione geografica all'applicazione Online Boutique utilizzando servizi multi-cluster e gateway multi-cluster. Le richieste vengono instradate alla regione geografica più vicina e, anche se i servizi di frontend o middleware in una regione riscontrano problemi, l'utente finale è comunque in grado di utilizzare l'applicazione.