Configurazione di un mesh multi-cluster su GKE

Questa guida spiega come unire due cluster in un unico mesh di servizi Cloud utilizzando Mesh CA oppure Istio CA, e abilitare il bilanciamento del carico tra cluster. Puoi estendere facilmente questo processo per incorporare un numero qualsiasi di cluster nel tuo mesh.

Una configurazione multi-cluster Cloud Service Mesh può risolvere diverse fasi aziendali cruciali come la scalabilità, la posizione e l'isolamento. Per ulteriori informazioni, consulta Casi d'uso multi-cluster.

Prerequisiti

Questa guida presuppone che tu abbia due o più cluster GKE di Google Cloud che soddisfano i seguenti requisiti:

• Cloud Service Mesh versione 1.11 o successive installata sui cluster che utilizzano asmcli install. Devi avere asmcli, lo strumento istioctl e i sample che asmcli scarica nella directory specificata in --output_dir quando hai eseguito asmcli install. Se devi eseguire la configurazione, segui i passaggi descritti in Installare gli strumenti dipendenti e convalidare il cluster per:

  • Installare gli strumenti richiesti
  • Scarica asmcli
  • Concedi le autorizzazioni di amministratore del cluster
  • Convalidare il progetto e il cluster

• I cluster nel tuo mesh devono avere connettività tra tutti i pod prima di configurare Cloud Service Mesh. Inoltre, se unisci cluster che non fanno parte dello stesso progetto, questi devono essere registrati nello stesso progetto host del parco risorse e devono essere configurati in un VPC condiviso insieme sulla stessa rete. Ti consigliamo inoltre di creare un progetto ospitare il VPC condiviso e due progetti di servizio per la creazione di cluster. Per maggiori informazioni le informazioni, vedi Configurazione di cluster con VPC condiviso

• Se utilizzi Istio CA, utilizza lo stesso certificato radice personalizzato per entrambi i cluster.

• Se Cloud Service Mesh è basato su cluster privati, ti consigliamo creando una singola subnet nello stesso VPC, altrimenti devi assicurarti che:

  1. I piani di controllo possono raggiungere i piani di controllo del cluster privato remoto tramite IP privati del cluster.
  2. Puoi aggiungere gli intervalli IP dei control plane chiamanti alle reti autorizzate dei cluster privati remoti. Per ulteriori informazioni, vedi Configura il rilevamento degli endpoint tra cluster privati.

• Il server API deve essere raggiungibile dalle altre istanze del piano di controllo di Cloud Service Mesh nel mesh multi-cluster.

  • Assicurati che i cluster abbiano accesso globale in un bucket in cui è abilitato il controllo delle versioni.
  • Assicurati che l'indirizzo IP del control plane di Cloud Service Mesh sia stato autorizzato correttamente tramite la lista consentita con la rete autorizzata principale.

Impostazione delle variabili di progetto e cluster

1. Crea le seguenti variabili di ambiente per l'ID progetto, la zona o la regione del cluster, il nome del cluster e il contesto.

   export PROJECT_1=PROJECT_ID_1
   export LOCATION_1=CLUSTER_LOCATION_1
   export CLUSTER_1=CLUSTER_NAME_1
   export CTX_1="gke_${PROJECT_1}_${LOCATION_1}_${CLUSTER_1}"
   
   export PROJECT_2=PROJECT_ID_2
   export LOCATION_2=CLUSTER_LOCATION_2
   export CLUSTER_2=CLUSTER_NAME_2
   export CTX_2="gke_${PROJECT_2}_${LOCATION_2}_${CLUSTER_2}"
   

2. Se si tratta di cluster appena creati, assicurati di recuperare le credenziali per ogni cluster con i seguenti comandi gcloud, altrimenti il relativo context non sarà disponibile per l'utilizzo nei passaggi successivi di questa guida.

   I comandi dipendono dal tipo di cluster, regionale o zonale:

   Regionale

   gcloud container clusters get-credentials ${CLUSTER_1} --region ${LOCATION_1}
   gcloud container clusters get-credentials ${CLUSTER_2} --region ${LOCATION_2}
   

   A livello di zona

   gcloud container clusters get-credentials ${CLUSTER_1} --zone ${LOCATION_1}
   gcloud container clusters get-credentials ${CLUSTER_2} --zone ${LOCATION_2}
   

Crea regola firewall

In alcuni casi, devi creare una regola firewall per consentire l'accesso per via del traffico. Ad esempio, devi creare una regola firewall se:

• Utilizzi sottoreti diverse per i cluster nella tua mesh.
• I pod aprono porte diverse da 443 e 15002.

GKE aggiunge automaticamente regole firewall a ogni nodo per il traffico all'interno della stessa subnet. Se la rete mesh contiene più subnet, devi configurare esplicitamente le regole firewall per consentire il traffico tra subnet. Devi aggiungere una nuova regola firewall per ogni subnet per consentire i blocchi CIDR IP di origine e le porte di destinazione di tutto il trafico in entrata.

Le istruzioni seguenti consentono la comunicazione tra tutti i cluster nel tuo progetto o solo tra $CLUSTER_1 e $CLUSTER_2.

1. Raccogli informazioni sulla rete dei tuoi cluster.

   Tutti i cluster del progetto

   Se i cluster si trovano nello stesso progetto, puoi utilizzare il comando seguente per consentire la comunicazione tra tutti i cluster del progetto. Se ci sono nel progetto che non vuoi esporre, utilizza il comando la scheda Cluster specifici.

   function join_by { local IFS="$1"; shift; echo "$*"; }
   ALL_CLUSTER_CIDRS=$(gcloud container clusters list --project $PROJECT_1 --format='value(clusterIpv4Cidr)' | sort | uniq)
   ALL_CLUSTER_CIDRS=$(join_by , $(echo "${ALL_CLUSTER_CIDRS}"))
   ALL_CLUSTER_NETTAGS=$(gcloud compute instances list --project $PROJECT_1 --format='value(tags.items.[0])' | sort | uniq)
   ALL_CLUSTER_NETTAGS=$(join_by , $(echo "${ALL_CLUSTER_NETTAGS}"))
   

   Cluster specifici

   Il seguente comando consente la comunicazione tra $CLUSTER_1 e $CLUSTER_2 e non espone altri cluster nel tuo progetto.

   function join_by { local IFS="$1"; shift; echo "$*"; }
   ALL_CLUSTER_CIDRS=$(for P in $PROJECT_1 $PROJECT_2; do gcloud --project $P container clusters list --filter="name:($CLUSTER_1,$CLUSTER_2)" --format='value(clusterIpv4Cidr)'; done | sort | uniq)
   ALL_CLUSTER_CIDRS=$(join_by , $(echo "${ALL_CLUSTER_CIDRS}"))
   ALL_CLUSTER_NETTAGS=$(for P in $PROJECT_1 $PROJECT_2; do gcloud --project $P compute instances list  --filter="name:($CLUSTER_1,$CLUSTER_2)" --format='value(tags.items.[0])' ; done | sort | uniq)
   ALL_CLUSTER_NETTAGS=$(join_by , $(echo "${ALL_CLUSTER_NETTAGS}"))
   

2. Crea la regola firewall.

   GKE

   gcloud compute firewall-rules create istio-multicluster-pods \
       --allow=tcp,udp,icmp,esp,ah,sctp \
       --direction=INGRESS \
       --priority=900 \
       --source-ranges="${ALL_CLUSTER_CIDRS}" \
       --target-tags="${ALL_CLUSTER_NETTAGS}" --quiet \
       --network=YOUR_NETWORK
   

   Autopilot

   TAGS=""
   for CLUSTER in ${CLUSTER_1} ${CLUSTER_2}
   do
       TAGS+=$(gcloud compute firewall-rules list --filter="Name:$CLUSTER*" --format="value(targetTags)" | uniq) && TAGS+=","
   done
   TAGS=${TAGS::-1}
   echo "Network tags for pod ranges are $TAGS"
   
   gcloud compute firewall-rules create asm-multicluster-pods \
       --allow=tcp,udp,icmp,esp,ah,sctp \
       --network=gke-cluster-vpc \
       --direction=INGRESS \
       --priority=900 --network=VPC_NAME \
       --source-ranges="${ALL_CLUSTER_CIDRS}" \
       --target-tags=$TAGS
   

Configura il rilevamento degli endpoint

Nota: per ulteriori informazioni sul rilevamento degli endpoint, consulta Rilevamento degli endpoint con più piani di controllo.

I passaggi necessari per configurare il rilevamento degli endpoint dipendono dalla tua preferenza per utilizzare l'API dichiarativa nei cluster in un parco risorse o abilitalo manualmente cluster pubblici o cluster privati.

Avviso: se la rilevazione degli endpoint è abilitata tra i cluster, i servizi inter-cluster non sono in grado di comunicare tra loro senza una configurazione DNS adeguata. Questo perché i servizi GKE dipendono sul nome di dominio completo (FQDN) di ciascun servizio per il routing del traffico. Puoi attivare il proxy DNS per consentire il rilevamento tra cluster. Il proxy DNS acquisisce tutte le richieste DNS e le risolve utilizzando le informazioni del Control Plane.

Abilita il rilevamento degli endpoint tra i cluster con l'API dichiarativa (anteprima)

Anteprima - Enable endpoint discovery

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Puoi attivare il rilevamento degli endpoint nei cluster di un parco applicando la configurazione "multicluster_mode":"connected" nel configmap asm-options. I cluster con questa configurazione abilitata nello stesso parco risorse avranno il rilevamento dei servizi tra cluster abilitato automaticamente tra di loro.

Avviso: non utilizzare questo metodo se i tuoi cluster utilizzano già segreti remote in-cluster esistenti.

Questo metodo è disponibile per le installazioni di Cloud Service Mesh gestite su tutti i canali di rilascio. Prima di procedere, devi avere ha creato una regola firewall.

Per più progetti, devi aggiungere manualmente FLEET_PROJECT_ID.svc.id.goog a trustDomainAliases in meshConfig della revisione se non è già presente.

Attiva

Se il configmap asm-options esiste già nel tuo cluster, abilita il rilevamento degli endpoint per il cluster:

kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"connected"}}'

Se il configmap asm-options non esiste ancora nel tuo cluster, crealo con i dati associati e abilita il rilevamento degli endpoint per il cluster:

kubectl --context ${CTX_1} create configmap asm-options -n istio-system --from-file <(echo '{"data":{"multicluster_mode":"connected"}}')

Disattiva

Disabilita il rilevamento degli endpoint per un cluster:

kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"manual"}}'

Se annulli la registrazione di un cluster dal parco risorse senza disattivare il rilevamento degli endpoint, i secret potrebbero rimanere nel cluster. Devi rimuovere manualmente eventuali elementi i tuoi segreti.

1. Esegui il seguente comando per trovare i secret che richiedono la pulizia:

   kubectl get secrets -n istio-system -l istio.io/owned-by=mesh.googleapis.com,istio/multiCluster=true
   

2. Elimina ogni secret:

   kubectl delete secret SECRET_NAME
   

   Ripeti questo passaggio per ogni segreto rimanente.

Configurare il rilevamento degli endpoint tra i cluster pubblici

Per configurare il rilevamento degli endpoint tra i cluster GKE, esegui asmcli create-mesh. Questo comando:

• Registra tutti i cluster nello stesso parco risorse.
• Configura il mesh in modo che l'identità dei carichi di lavoro del parco risorse sia attendibile.
• Crea secret remoti.

Puoi specificare l'URI per ogni cluster o il percorso del file kubeconfig.

URI cluster

Nel comando seguente, sostituisci FLEET_PROJECT_ID con l'ID del progetto host del parco risorse e l'URI del cluster con il nome, la zona o la regione del cluster e l'ID progetto per ciascun cluster. Questo esempio mostra solo due cluster, ma puoi eseguire il comando per abilitare il rilevamento degli endpoint su cluster aggiuntivi, in base alle numero massimo consentito di cluster che puoi aggiungere al tuo parco risorse.

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    ${PROJECT_1}/${LOCATION_1}/${CLUSTER_1} \
    ${PROJECT_2}/${LOCATION_2}/${CLUSTER_2}

file kubeconfig

Nel comando seguente, sostituisci FLEET_PROJECT_ID con l'ID progetto del progetto host del parco risorse e PATH_TO_KUBECONFIG con il percorso di ciascun file kubeconfig. Questo esempio mostra solo due cluster, ma puoi eseguire il comando per attivare il rilevamento degli endpoint su altri cluster, rispettando il numero massimo consentito di cluster che puoi aggiungere al tuo parco risorse.

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    PATH_TO_KUBECONFIG_1 \
    PATH_TO_KUBECONFIG_2

Configura il rilevamento degli endpoint tra cluster privati

1. Configurare secret remoti per consentire l'accesso del server API al cluster per dal piano di controllo Cloud Service Mesh di un altro cluster. I comandi dipendono Tipo di Cloud Service Mesh (in-cluster o gestito):

   Nota: assicurati di eseguire i seguenti comandi utilizzando istioctl dalla posizione --output_dir specificata durante l'esecuzione di asmcli install, eseguendo i comandi istioctl in un modo ../output_dir/istioctl.

   A. Per Cloud Service Mesh all'interno del cluster, devi configurare gli IP privati anziché quelli pubblici perché questi ultimi non sono accessibili:

   PRIV_IP=`gcloud container clusters describe "${CLUSTER_1}" --project "${PROJECT_1}" \
    --zone "${LOCATION_1}" --format "value(privateClusterConfig.privateEndpoint)"`
   
   ./istioctl x create-remote-secret --context=${CTX_1} --name=${CLUSTER_1} --server=https://${PRIV_IP} > ${CTX_1}.secret
   

   PRIV_IP=`gcloud container clusters describe "${CLUSTER_2}" --project "${PROJECT_2}" \
    --zone "${LOCATION_2}" --format "value(privateClusterConfig.privateEndpoint)"`
   
   ./istioctl x create-remote-secret --context=${CTX_2} --name=${CLUSTER_2} --server=https://${PRIV_IP} > ${CTX_2}.secret
   

   B. Per Managed Cloud Service Mesh:

   PUBLIC_IP=`gcloud container clusters describe "${CLUSTER_1}" --project "${PROJECT_1}" \
    --zone "${LOCATION_1}" --format "value(privateClusterConfig.publicEndpoint)"`
   
   ./istioctl x create-remote-secret --context=${CTX_1} --name=${CLUSTER_1} --server=https://${PUBLIC_IP} > ${CTX_1}.secret
   

   PUBLIC_IP=`gcloud container clusters describe "${CLUSTER_2}" --project "${PROJECT_2}" \
    --zone "${LOCATION_2}" --format "value(privateClusterConfig.publicEndpoint)"`
   
   ./istioctl x create-remote-secret --context=${CTX_2} --name=${CLUSTER_2} --server=https://${PUBLIC_IP} > ${CTX_2}.secret
   

2. Applica i nuovi secret ai cluster:

   kubectl apply -f ${CTX_1}.secret --context=${CTX_2}
   

   kubectl apply -f ${CTX_2}.secret --context=${CTX_1}
   

Configurare le reti autorizzate per i cluster privati

Segui questa sezione solo se al mesh si applicano tutte le seguenti condizioni:

• Stai utilizzando cluster privati.
• I cluster non appartengono alla stessa subnet.
• I cluster hanno abilitato le reti autorizzate.

Quando esegui il deployment di più cluster privati, il control plane di Cloud Service Mesh in ogni cluster deve chiamare il control plane GKE dei cluster remoti. Per consentire il traffico, devi aggiungere l'intervallo di indirizzi dei pod nella di chiamata alle reti autorizzate dei cluster remoti.

1. Ottieni il blocco CIDR IP del pod per ogni cluster:

   POD_IP_CIDR_1=`gcloud container clusters describe ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
     --format "value(ipAllocationPolicy.clusterIpv4CidrBlock)"`
   

   POD_IP_CIDR_2=`gcloud container clusters describe ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
     --format "value(ipAllocationPolicy.clusterIpv4CidrBlock)"`
   

2. Aggiungi i blocchi CIDR degli IP dei pod del cluster Kubernetes ai cluster remoti:

   EXISTING_CIDR_1=`gcloud container clusters describe ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
    --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"`
   gcloud container clusters update ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
   --enable-master-authorized-networks \
   --master-authorized-networks ${POD_IP_CIDR_2},${EXISTING_CIDR_1//;/,}
   

   EXISTING_CIDR_2=`gcloud container clusters describe ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
    --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"`
   gcloud container clusters update ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
   --enable-master-authorized-networks \
   --master-authorized-networks ${POD_IP_CIDR_1},${EXISTING_CIDR_2//;/,}
   

   Per ulteriori informazioni, vedi Creazione di un cluster con reti autorizzate.

3. Verifica che le reti autorizzate siano aggiornate:

   gcloud container clusters describe ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
    --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"
   

   gcloud container clusters describe ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
    --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"
   

Abilita l'accesso globale al piano di controllo

Segui questa sezione solo se al mesh si applicano tutte le seguenti condizioni:

• Stai utilizzando cluster privati.
• Utilizzi regioni diverse per i cluster nel mesh.

Devi abilitare l'accesso globale al piano di controllo per consentire al piano di controllo di Cloud Service Mesh in ciascun cluster di chiamare dal piano di controllo GKE dei cluster remoti.

1. Abilita l'accesso globale al control plane:

   gcloud container clusters update ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
    --enable-master-global-access
   

   gcloud container clusters update ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
    --enable-master-global-access
   

2. Verifica che l'accesso globale al piano di controllo sia abilitato:

   gcloud container clusters describe ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1}
   

   gcloud container clusters describe ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2}
   

   La sezione privateClusterConfig nell'output mostra lo stato di masterGlobalAccessConfig.

Verificare la connettività multicluster

Nota sulla piattaforma: questi passaggi sono applicabili solo se utilizzi un control plane in-cluster. Per Cloud Service Mesh gestito, consulta Eseguire l'iniezione di proxy sidecar o Applicare il data plane gestito.

Questa sezione spiega come eseguire il deployment dei servizi HelloWorld e Sleep di esempio nel tuo ambiente multi-cluster per verificare il funzionamento del bilanciamento del carico tra i cluster.

Nota: questi servizi di esempio si trovano in Directory samples dell'Istio incluso nel tag istioctl (situato in OUTPUT_DIR/istio-${ASM_VERSION%+*}/samples) e non Directory samples scaricata da asmcli (situata in OUTPUT_DIR/samples).

Imposta variabile per la directory di esempio

1. Vai alla posizione in cui è stato scaricato asmcli ed esegui il seguente comando per impostare ASM_VERSION

   export ASM_VERSION="$(./asmcli --version)"
   

2. Imposta una cartella di lavoro per i sample che utilizzi per verificare il funzionamento del bilanciamento del carico tra cluster. I campioni si trovano in nella directory --output_dir specificata nella directory Comando asmcli install. Nel comando seguente, modifica OUTPUT_DIR alla directory specificata in --output_dir.

   export SAMPLES_DIR=OUTPUT_DIR/istio-${ASM_VERSION%+*}
   

Attiva l'iniezione di sidecar

1. Individua il valore dell'etichetta di revisione, che utilizzerai nei passaggi successivi. Il passaggio dipende dal tipo di Cloud Service Mesh (gestito o in cluster).

   Nota: se i tuoi cluster hanno versioni diverse di Cloud Service Mesh, devi eseguire il seguente comando per ogni cluster.

   Gestito

   Utilizza il seguente comando per individuare l'etichetta di revisione, che utilizzerai nei passaggi successivi.

   kubectl get controlplanerevision -n istio-system

   L'output è simile al seguente:

    NAME                RECONCILED   STALLED   AGE
    asm-managed-rapid   True         False     89d
    

   Nell'output, nella colonna NAME, prendi nota del valore dell'etichetta della revisione. In questo esempio, il valore è asm-managed-rapid. Utilizza la il valore della revisione nei passaggi della prossima sezione.

   Nel cluster

   Utilizza il seguente comando per individuare l'etichetta di revisione, che utilizzerai nei passaggi successivi.

   kubectl -n istio-system get pods -l app=istiod --show-labels

   L'output è simile al seguente:

    NAME                                READY   STATUS    RESTARTS   AGE   LABELS
    istiod-asm-173-3-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-173-3,istio=istiod,pod-template-hash=5788d57586
    istiod-asm-173-3-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-173-3,istio=istiod,pod-template-hash=5788d57586
    

   Nell'output, sotto la colonna LABELS, prendi nota del valore del parametro istiod etichetta di revisione, che segue il prefisso istio.io/rev=. In questo esempio, Il valore è asm-173-3. Utilizza il valore della revisione nei passaggi della sezione successiva.

Installa il servizio HelloWorld

Nota: l'esempio del servizio HelloWorld utilizza Docker Hub. In privato cluster, il runtime del container può eseguire il pull delle immagini container da Artifact Registry per impostazione predefinita. Il runtime del container non può estrarre immagini da nessun altro registry di immagini container su internet. Puoi scaricare l'immagine ed eseguirne il push su Artifact Registry o utilizzare Cloud NAT per fornire l'accesso a internet in uscita per determinati nodi privati. Per maggiori informazioni, consulta Eseguire la migrazione dei contenitori esterni e Creare un cluster privato.

1. Crea lo spazio dei nomi di esempio e la definizione del servizio in ogni cluster. Nel comando seguente, sostituisci REVISION con l'etichetta di revisione istiod che hai annotato nel passaggio precedente.

   Importante: se utilizzi il piano di controllo gestito di Cloud Service Mesh, sostituisci REVISION con asm-managed nei seguenti passaggi.

   for CTX in ${CTX_1} ${CTX_2}
   do
       kubectl create --context=${CTX} namespace sample
       kubectl label --context=${CTX} namespace sample \
           istio-injection- istio.io/rev=REVISION --overwrite
   done
   

   dove REVISION è l'etichetta di revisione istiod che hai precedentemente prendere nota.

   L'output è:

   label "istio-injection" not found.
   namespace/sample labeled
   

   Puoi ignorare tranquillamente label "istio-injection" not found.

2. Crea il servizio HelloWorld in entrambi i cluster:

   kubectl create --context=${CTX_1} \
       -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \
       -l service=helloworld -n sample
   

   kubectl create --context=${CTX_2} \
       -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \
       -l service=helloworld -n sample
   

Esegui il deployment di HelloWorld v1 e v2 in ogni cluster

1. Esegui il deployment di HelloWorld v1 in CLUSTER_1 e di v2 su CLUSTER_2, che consentono di verificare in un secondo momento il bilanciamento del carico tra cluster:

   kubectl create --context=${CTX_1} \
     -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \
     -l version=v1 -n sample

   kubectl create --context=${CTX_2} \
     -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \
     -l version=v2 -n sample

2. Verifica che HelloWorld v1 e v2 siano in esecuzione utilizzando i seguenti comandi. Verifica che l'output sia simile a quello mostrato.

   kubectl get pod --context=${CTX_1} -n sample

   NAME                            READY     STATUS    RESTARTS   AGE
   helloworld-v1-86f77cd7bd-cpxhv  2/2       Running   0          40s

   kubectl get pod --context=${CTX_2} -n sample

   NAME                            READY     STATUS    RESTARTS   AGE
   helloworld-v2-758dd55874-6x4t8  2/2       Running   0          40s

esegui il deployment del servizio Sleep

1. Esegui il deployment del servizio Sleep in entrambi i cluster. Questo pod genera traffico di rete artificiale a scopo dimostrativo:

   for CTX in ${CTX_1} ${CTX_2}
   do
       kubectl apply --context=${CTX} \
           -f ${SAMPLES_DIR}/samples/sleep/sleep.yaml -n sample
   done
   

2. Attendi l'avvio del servizio Sleep in ogni cluster. Verifica che l'output sia simile a quello mostrato:

   kubectl get pod --context=${CTX_1} -n sample -l app=sleep

   NAME                             READY   STATUS    RESTARTS   AGE
   sleep-754684654f-n6bzf           2/2     Running   0          5s

   kubectl get pod --context=${CTX_2} -n sample -l app=sleep

   NAME                             READY   STATUS    RESTARTS   AGE
   sleep-754684654f-dzl9j           2/2     Running   0          5s

Verificare il bilanciamento del carico tra cluster

Chiama più volte il servizio HelloWorld e controlla l'output per verificare risposte alternate da v1 a v2:

1. Chiama il servizio HelloWorld:

   kubectl exec --context="${CTX_1}" -n sample -c sleep \
       "$(kubectl get pod --context="${CTX_1}" -n sample -l \
       app=sleep -o jsonpath='{.items[0].metadata.name}')" \
       -- /bin/sh -c 'for i in $(seq 1 20); do curl -sS helloworld.sample:5000/hello; done'
   

   L'output è simile a quello mostrato:

   Hello version: v2, instance: helloworld-v2-758dd55874-6x4t8
   Hello version: v1, instance: helloworld-v1-86f77cd7bd-cpxhv
   ...

2. Chiama di nuovo il servizio HelloWorld:

   kubectl exec --context="${CTX_2}" -n sample -c sleep \
       "$(kubectl get pod --context="${CTX_2}" -n sample -l \
       app=sleep -o jsonpath='{.items[0].metadata.name}')" \
       -- /bin/sh -c 'for i in $(seq 1 20); do curl -sS helloworld.sample:5000/hello; done'
   

   L'output è simile a quello mostrato:

   Hello version: v2, instance: helloworld-v2-758dd55874-6x4t8
   Hello version: v1, instance: helloworld-v1-86f77cd7bd-cpxhv
   ...

Congratulazioni, hai verificato il tuo mesh di servizi Cloud multi-cluster con bilanciamento del carico.

Eliminazione del servizio HelloWorld

Al termine della verifica del bilanciamento del carico, rimuovi HelloWorld e Sleep dal tuo cluster.

kubectl delete ns sample --context ${CTX_1}
kubectl delete ns sample --context ${CTX_2}