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

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

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

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

1. 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 \
       --async
   

   La 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-pool quando crei questi cluster, come accade per i cluster GKE Standard.

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

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

4. 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
   [...]
   

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 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 $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 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-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 di dimostrazione, esegui il deployment dell'insieme completo di servizi dell'applicazione Online Boutique nell'unico 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 frontend di Online Boutique:

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

4. Attendi che il servizio LoadBalancer riceva 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. 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 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 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.

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

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

   namespace/onlineboutique created
   

2. Esporta cartservice dal cluster std-west in 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 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, 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 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.

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

2. Applica 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-central
   

3. Applica 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.

1. Verifica che tutti i cluster siano stati registrati correttamente nel parco risorse:

   gcloud container fleet memberships list --project=$PROJECT
   

   L'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-612f14810012
   

2. Installa 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, 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à 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=$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 ulteriori informazioni su quando utilizzare un tipo o l'altro, 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 Cloud Load Balancing esterno di livello 7 ed espone l'applicazione multi-cluster

6. Esegui 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-central
   

   Quando esegui il deployment della risorsa HTTPRoute, viene creata una risorsa di Cloud Load Balancing di livello 7 esterno ed esposto il frontend ServiceImport supportato 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:

   

7. 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-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, viene restituito il contenuto HTML visualizzato 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 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.

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

3. Esegui la stessa richiesta curl dal client Pod nel 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 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é 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 assigned
   

4. Esegui 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 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.

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

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 visualizzare 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 in 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-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 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.