DA MASER A MONFUMO | MOTO GUZZI V85TT | PURE SOUND POV 4K

🏍️ Il mio nuovo canale YouTube: giri in moto in POV, solo audio, tra le Dolomiti in 4K. Niente musica, niente parole — solo il motore e le Alpi. Vieni a fare un giro!

▶ Iscriviti

In questo articolo spiegherò passo dopo passo come ho distribuito un service mesh multi-cluster e multi-regione usando Anthos Service Mesh. Durante la mia proof of concept, ho letto la documentazione su https://cloud.google.com/service-mesh/docs/install, ma nessuna delle guide copriva esattamente i miei requisiti, che sono:

  • Service mesh multi-cluster e multi-regione

  • Piano di controllo Istio gestito da Google (per maggiore resilienza e per minimizzare il mio intervento)

  • Certificati CA gestiti da Google per Istio mTLS

Distribuire i cluster GKE

Distribuisci i due cluster GKE. Li ho chiamati asm-a e asm-b (più facili da ricordare) e li ho distribuiti in due regioni diverse (us-west2-a e us-central1-a). Poiché Anthos Service Mesh richiede nodi con almeno 4 vCPU (e alcuni altri requisiti, vedi la lista completa su: https://cloud.google.com/service-mesh/docs/scripted-install/asm-onboarding), usa almeno le macchine e2-standard-4.

Come preparazione, archivia il Project ID di Google Cloud in una variabile d'ambiente in modo che i comandi successivi possano essere copiati e incollati direttamente.

shell
export PROJECT_ID=$(gcloud info --format='value(config.project)')

Poi, per distribuire i cluster, esegui:

shell
gcloud container clusters create asm-a --zone us-west2-a --machine-type "e2-standard-4" --disk-size "100" --num-nodes "2" --workload-pool=${PROJECT_ID}.svc.id.goog --async
 
gcloud container clusters create asm-b --zone us-central1-a --machine-type "e2-standard-4" --disk-size "100" --num-nodes "2" --workload-pool=${PROJECT_ID}.svc.id.goog --async

I comandi abilitano anche la Workload Identity, su cui puoi leggere di più su: https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity.

Recuperare le credenziali per i cluster

Una volta creati i cluster, recupera le credenziali necessarie per connetterti ad essi tramite kubectl. Usa i seguenti comandi:

shell
gcloud container clusters get-credentials asm-a --zone us-west2-a --project ${PROJECT_ID}
gcloud container clusters get-credentials asm-b --zone us-central1-a --project ${PROJECT_ID}

Cambiare contesto kubectl facilmente con kubectx

kubectx rende semplice passare tra cluster e namespace in kubectl (noto anche come context) creando un alias memorabile per ciascuno di essi (in questo caso, asma e asmb). Scopri di più sullo strumento su: https://github.com/ahmetb/kubectx.

shell
kubectx asma=gke_${PROJECT_ID}_us-west2-a_asm-a
kubectx asmb=gke_${PROJECT_ID}_us-central1-a_asm-b

Impostare il label Mesh ID per i cluster

Imposta il label mesh_id sui cluster prima di installare Anthos Service Mesh, necessario affinché Anthos possa identificare quali cluster appartengono a quale mesh. Il mesh_id è sempre nel formato proj-<numero-progetto>, e il numero di progetto può essere trovato eseguendo:

shell
gcloud projects list

Usa questi comandi per creare il label mesh_id su entrambi i cluster (sostituisci <your-project-number> con il numero di progetto trovato con il comando precedente):

shell
export MESH_ID="proj-<your-project-number>"
gcloud container clusters update asm-a --region us-west2-a --project=${PROJECT_ID} --update-labels=mesh_id=${MESH_ID}
 
gcloud container clusters update asm-b --region us-central1-a --project=${PROJECT_ID} --update-labels=mesh_id=${MESH_ID}

Abilitare StackDriver

Abilita StackDriver sui cluster per poter vedere i log in caso di problemi durante la configurazione!

shell
gcloud container clusters update asm-a --region us-west2-a --project=${PROJECT_ID} --enable-stackdriver-kubernetes
 
gcloud container clusters update asm-b --region us-central1-a --project=${PROJECT_ID} --enable-stackdriver-kubernetes

Creare regole firewall per la comunicazione inter-regione

I cluster si trovano in regioni diverse, quindi è necessario creare una nuova regola firewall per consentire la comunicazione tra di loro e i loro pod. Preparati a un po' di Bash!

shell
ASMA_POD_CIDR=$(gcloud container clusters describe asm-a --zone us-west2-a --format=json | jq -r '.clusterIpv4Cidr')
ASMB_POD_CIDR=$(gcloud container clusters describe asm-b --zone us-central1-a --format=json | jq -r '.clusterIpv4Cidr')
ASMA_PRIMARY_CIDR=$(gcloud compute networks subnets describe default --region=us-west2 --format=json | jq -r '.ipCidrRange')
ASMB_PRIMARY_CIDR=$(gcloud compute networks subnets describe default --region=us-central1 --format=json | jq -r '.ipCidrRange')
ALL_CLUSTER_CIDRS=$ASMA_POD_CIDR,$ASMB_POD_CIDR,$ASMA_PRIMARY_CIDR,$ASMB_PRIMARY_CIDR
 
gcloud compute firewall-rules create asm-multicluster-rule \
    --allow=tcp,udp,icmp,esp,ah,sctp \
    --direction=INGRESS \
    --priority=900 \
    --source-ranges="${ALL_CLUSTER_CIDRS}" \
    --target-tags="${ALL_CLUSTER_NETTAGS}" --quiet

Installare Anthos Service Mesh

Prima di tutto, installa gli strumenti locali richiesti come spiegato qui: https://cloud.google.com/service-mesh/docs/scripted-install/asm-onboarding#installing\_required\_tools.

Lo strumento install_asm installerà Anthos Service Mesh sui cluster. Passa queste opzioni per soddisfare i requisiti iniziali:

  • --managed: Piano di controllo Istio gestito da Google

  • --ca mesh_ca: Certificati CA gestiti da Google per Istio mTLS

  • --enable_registration: registra automaticamente i cluster con Anthos (può essere fatto anche manualmente in seguito)

  • --enable_all: tutte le API Google richieste dall'installazione verranno abilitate automaticamente dallo script

shell
./install_asm --project_id ${PROJECT_ID} --cluster_name asm-a --cluster_location us-west2-a --mode install --managed --ca mesh_ca --output_dir asma --enable_registration --enable_all
 
./install_asm --project_id ${PROJECT_ID} --cluster_name asm-b --cluster_location us-central1-a --mode install --managed --ca mesh_ca --output_dir asmb --enable_registration --enable_all

Configurare la scoperta degli endpoint tra i cluster

La scoperta degli endpoint consente ai cluster di comunicare tra loro, ad esempio abilita la scoperta degli endpoint dei servizi tra i cluster.

Installa gli strumenti locali richiesti come spiegato qui: https://cloud.google.com/service-mesh/docs/downloading-istioctl, poi esegui i seguenti comandi:

shell
istioctl x create-remote-secret --context=asma --name=asm-a| kubectl apply -f - --context=asmb
 
istioctl x create-remote-secret --context=asmb --name=asm-b| kubectl apply -f - --context=asma

Testare il service mesh

Anthos Service Mesh è ora pronto! Distribuiamo un'applicazione di esempio per verificare il traffico cross-cluster e i failover.

Creare il namespace per l'app Hello World

Crea un nuovo namespace su entrambi i cluster e abilita l'iniezione automatica del sidecar Istio per entrambi. Poiché il piano di controllo Istio è gestito da Google, il label istio-injection- istio.io/rev= viene impostato su asm-managed.

shell
kubectl create --context=asma namespace sample
 
kubectl label --context=asma namespace sample istio-injection- istio.io/rev=asm-managed --overwrite
 
kubectl create --context=asmb namespace sample
 
kubectl label --context=asmb namespace sample istio-injection- istio.io/rev=asm-managed --overwrite

Creare il servizio Hello World

Distribuisci i servizi per l'app Hello World su entrambi i cluster con:

shell
kubectl create --context=asma -f https://raw.githubusercontent.com/istio/istio/1.9.5/samples/helloworld/helloworld.yaml -l service=helloworld -n sample
 
kubectl create --context=asmb -f https://raw.githubusercontent.com/istio/istio/1.9.5/samples/helloworld/helloworld.yaml -l service=helloworld -n sample

Creare il deployment Hello World

Distribuisci l'app di esempio Hello World, che fornisce un endpoint che restituirà il numero di versione dell'applicazione (il numero di versione è diverso nei due cluster) e un messaggio Hello World come accompagnamento.

shell
kubectl create --context=asma -f https://raw.githubusercontent.com/istio/istio/1.9.5/samples/helloworld/helloworld.yaml -l version=v1 -n sample
 
kubectl create --context=asmb -f https://raw.githubusercontent.com/istio/istio/1.9.5/samples/helloworld/helloworld.yaml -l version=v2 -n sample

Distribuire il pod Sleep

L'applicazione Sleep simula un'interruzione del servizio. Usiamola per testare la resilienza del service mesh! Per distribuire l'applicazione Sleep, usa:

shell
kubectl apply --context=asma -f https://raw.githubusercontent.com/istio/istio/1.9.5/samples/sleep/sleep.yaml -n sample
 
kubectl apply --context=asmb -f https://raw.githubusercontent.com/istio/istio/1.9.5/samples/sleep/sleep.yaml -n sample

Verificare il traffico cross-cluster

Per verificare che il load balancing cross-cluster funzioni come previsto (in altre parole: il service mesh riesce a sopravvivere a un guasto regionale?), chiama il servizio HelloWorld più volte usando il pod Sleep. Per assicurarti che il load balancing funzioni correttamente, chiama il servizio HelloWorld da tutti i cluster nel tuo deployment.

shell
kubectl exec --context=asma -n sample -c sleep "$(kubectl get pod --context=asma -n sample -l app=sleep -o jsonpath='{.items[0].metadata.name}')" -- curl -sS helloworld.sample:5000/hello
 
kubectl exec --context=asmb -n sample -c sleep "$(kubectl get pod --context=asmb -n sample -l app=sleep -o jsonpath='{.items[0].metadata.name}')" -- curl -sS helloworld.sample:5000/hello

Ripeti questa richiesta più volte e verifica che la versione di HelloWorld alterni tra v1 e v2. Ciò significa che la richiesta viene indirizzata al cluster sano quando l'altro non risponde!

In questo articolo ho spiegato come ho distribuito Anthos Service Mesh su due cluster GKE in regioni diverse, con piano di controllo Istio e certificati CA gestiti da Google. Anthos Service Mesh semplifica la distribuzione di un service mesh multi-cluster perché la maggior parte della complessità di Istio è ora gestita da Google.