Workshop su Anthos Service Mesh: guida del lab

1. WORKSHOP ALPHA

NOTA IMPORTANTE: QUESTO È UN WORKSHOP DELL'ALPHA E È STRETTAMENTE DESTINATO A Svolgere un corso di formazione con istruttore.

Link al codelab del workshop bit.ly/asm-workshop

2. Panoramica

Diagramma dell'architettura

Questo workshop è un'esperienza pratica e immersiva che illustra come configurare servizi distribuiti a livello globale su Google Cloud in produzione. Le tecnologie principali utilizzate sono Google Kubernetes Engine (GKE) per il computing e il mesh di servizi Istio per creare connettività sicura, osservabilità e modellazione del traffico avanzato. Tutte le pratiche e gli strumenti usati in questo workshop sono quelli che useresti in produzione.

Programma

• Modulo 0 - Introduzione e configurazione della piattaforma
• Introduzione e architettura
• Introduzione a Service Mesh e Istio/ASM
• Lab - Configurazione dell'infrastruttura: flusso di lavoro utente
• Break (Pausa)
• QnA
• Modulo 1 - Installa, proteggi e monitora le applicazioni con ASM
• Modello repository: infrastruttura e repository Kubernetes
• Lab: Deployment dell'applicazione di esempio
• Servizi distribuiti e osservabilità
• Pranzo
• Lab: Osservabilità con Stackdriver
• QNA
• Modulo 2 - DevOps - Implementazioni canary, criteri/RBAC
• Rilevamento dei servizi e sicurezza/criteri multi-cluster
• Lab: TLS reciproco
• Deployment canary
• Lab: Deployment canary
• Bilanciamento del carico globale sicuro multi-cluster
• Break (Pausa)
• Lab: Criterio di autorizzazione
• QNA
• Modulo 3 - Infra Ops - Upgrade della piattaforma
• Componenti di base per i servizi distribuiti
• Lab: Scalabilità dell'infrastruttura
• Passaggi successivi

Presentazioni

Le diapositive per questo workshop sono disponibili al seguente link:

Diapositive del workshop sull'ASM

Prerequisiti

Prima di procedere con questo workshop, è necessario quanto segue:

1. Un nodo Organizzazione Google Cloud.
2. Un ID account di fatturazione (l'utente deve essere Amministratore fatturazione per questo account di fatturazione)
3. Ruolo IAM Amministratore organizzazione a livello di organizzazione per il tuo utente

3. Configurazione dell'infrastruttura - Flusso di lavoro dell'amministratore

I passaggi in questa sezione vengono eseguiti da un amministratore che crea il workshop.

Se sei un utente del workshop, passa alla sezione successiva con l'etichetta Infrastructure Setup - User Workflow

Spiegazione dello script del workshop di bootstrap

Per configurare l'ambiente iniziale per il workshop viene utilizzato uno script denominato bootstrap_workshop.sh. Puoi utilizzare questo script per configurare un ambiente singolo per te stesso o più ambienti per più utenti nel caso in cui tu stia organizzando questo workshop come formazione per più utenti.

Lo script del workshop di bootstrap richiede i seguenti input:

• Nome dell'organizzazione (ad esempio yourcompany.com): l'organizzazione in cui crei gli ambienti per il workshop.
• ID fatturazione (ad esempio 12345-12345-12345): questo ID fatturazione viene utilizzato per fatturare tutte le risorse utilizzate durante il workshop.
• Numero officina (ad esempio 01): un numero a due cifre. Questa opzione viene utilizzata se devi tenere più workshop in un solo giorno e vuoi tenerne traccia separatamente. I numeri dei workshop vengono utilizzati anche per ricavare gli ID progetto. Avere numeri di workshop separati ti consente di avere più facilmente ID progetto univoci. Oltre al numero del workshop, per gli ID progetto si utilizza anche la data attuale (nel formato YYMMDD). La combinazione di data e numero del workshop fornisce ID progetto univoci.
• Numero iniziale dell'utente (ad esempio 1): questo numero indica il primo utente del workshop. Ad esempio, se vuoi creare un workshop per 10 utenti, potresti avere come utente iniziale 1 e come utente finale 10.
• Numero utente finale (ad esempio 10): questo numero indica l'ultimo utente del workshop. Ad esempio, se vuoi creare un workshop per 10 utenti, potresti avere come utente iniziale 1 e come utente finale 10. Se stai configurando un singolo ambiente (ad esempio per te), fai in modo che il numero di utente iniziale e quello di utente finale corrispondano. Questo creerà un unico ambiente.

Oltre alla data e al numero del workshop, negli ID progetto sono incorporati anche i numeri di inizio e di utente finale. Gli ID utente (per gli utenti che eseguono il workshop) derivano dal numero dell'utente iniziale e di quello finale. Gli ID utente sono descritti nella sezione User schema and permissions performing the workshop.

• Bucket GCS amministratore (ad esempio my-gcs-bucket-name). Un bucket GCS viene utilizzato per archiviare le informazioni relative al workshop. Queste informazioni vengono utilizzate dallo script cleanup_workshop.sh per eliminare agevolmente tutte le risorse create durante lo script del workshop di bootstrap. Gli amministratori che creano workshop devono disporre delle autorizzazioni di lettura/scrittura per questo bucket.

Lo script del workshop di bootstrap utilizza i valori forniti in precedenza e funge da script wrapper che chiama lo script setup-terraform-admin-project.sh. Lo script setup-terraform-admin-project.sh crea l'ambiente del workshop per un singolo utente.

Autorizzazioni di amministratore necessarie per eseguire il bootstrap del workshop

Ci sono due tipi di utenti in questo workshop. Un ADMIN_USER, che crea ed elimina le risorse per questo workshop. Il secondo è MY_USER, che svolge i passaggi del workshop. MY_USER ha accesso solo alle proprie risorse. ADMIN_USER ha accesso a tutte le configurazioni utente. Se stai creando questa configurazione per te, i valori di ADMIN_USER e MY_USER coincidono. Se sei un insegnante e stai creando questo workshop per più studenti, i tuoi ADMIN_USER e MY_USER saranno diversi.

Per l'ADMIN_USER sono necessarie le seguenti autorizzazioni a livello di organizzazione:

• Proprietario: autorizzazione di proprietario del progetto per tutti i progetti nell'organizzazione.
• Amministratore cartelle: può creare ed eliminare cartelle nell'organizzazione. Ogni utente riceve una singola cartella con tutte le proprie risorse all'interno del progetto.
• Amministratore dell'organizzazione
• Autore progetto: può creare progetti nell'organizzazione.
• Autore eliminazione progetti: può eliminare progetti nell'organizzazione.
• Amministratore IAM progetto - Può creare regole IAM in tutti i progetti dell'organizzazione.

Oltre a questi, ADMIN_USER deve essere anche l'amministratore della fatturazione per l'ID fatturazione utilizzato per il workshop.

Schema e autorizzazioni degli utenti che eseguono il workshop

Se hai intenzione di creare questo workshop per altri utenti della tua organizzazione, devi seguire uno schema di denominazione specifico per MY_USERs. Durante lo script bootstrap_workshop.sh, fornisci un numero di inizio e un numero di utente finale. Questi numeri vengono utilizzati per creare i seguenti nomi utente:

• user<3 digit user number>@<organization_name>

Ad esempio, se esegui lo script del workshop di bootstrap con il numero dell'utente iniziale 1 e il numero dell'utente finale 3, nella tua organizzazione denominata azienda.com, vengono creati gli ambienti del workshop per i seguenti utenti:

• [e-mail]
• [e-mail]
• [e-mail]

A questi nomi utente vengono assegnati ruoli di proprietario del progetto per i progetti specifici creati durante lo script setup_terraform_admin_project.sh. Devi rispettare questo schema di denominazione degli utenti quando utilizzi lo script di bootstrap. Leggi come aggiungere più utenti contemporaneamente in G Suite.

Strumenti richiesti per il workshop

Questo workshop è stato pensato per il bootstrap da Cloud Shell. Per questo workshop sono necessari i seguenti strumenti.

• gcloud (ver >= 270)
• kubectl
• sed (funziona con sed su Cloud Shell/Linux e non su Mac OS)
• git (assicurati di essere aggiornato)
• sudo apt update
• sudo apt install git
• envsubst
• kustomize

Tutti gli strumenti, ad eccezione di kustomize, sono già installati in Cloud Shell per impostazione predefinita. Se kustomize non è installato, installalo usando lo script bash fornito nel link precedente e assicurati che il programma binario kustomize sia nel tuo PATH e conferma eseguendo il comando kustomize in Cloud Shell.

Configura il workshop per te (configurazione utente singolo)

1. Apri Cloud Shell, esegui tutte le azioni seguenti in Cloud Shell. Fai clic sul link di seguito.

CLOUD SHELL

2. Verifica di aver eseguito l'accesso a gcloud con l'utente amministratore previsto.

gcloud config list
 

3. Crea un elemento WORKDIR e clona il repository del workshop.

mkdir asm-workshop
cd asm-workshop
export WORKDIR=`pwd`
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git asm
 

4. Definisci il nome della tua organizzazione, l'ID fatturazione, il numero del workshop e un bucket GCS amministratore da utilizzare per il workshop. Esamina le autorizzazioni richieste per la configurazione del workshop nelle sezioni precedenti.

gcloud organizations list
export ORGANIZATION_NAME=<ORGANIZATION NAME>

gcloud beta billing accounts list
export ADMIN_BILLING_ID=<ADMIN_BILLING ID>

export WORKSHOP_NUMBER=<two digit number for example 01>

export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>
 

5. Esegui lo script bootstrap_workshop.sh. Il completamento di questo script può richiedere alcuni minuti.

cd asm
./scripts/bootstrap_workshop.sh --org-name ${ORGANIZATION_NAME} --billing-id ${ADMIN_BILLING_ID} --workshop-num ${WORKSHOP_NUMBER} --admin-gcs-bucket ${ADMIN_STORAGE_BUCKET} --set-up-for-admin 
 

Tieni presente che non è necessario definire il numero di inizio e di fine dell'utente, in quanto lo stai impostando personalmente.

Una volta completato lo script bootstrap_workshop.sh, viene creata una cartella Google Cloud per ciascun utente all'interno dell'organizzazione. All'interno della cartella, viene creato un progetto terraform admin. Il progetto di amministrazione Terraform viene utilizzato per creare le risorse Google Cloud rimanenti richieste per questo workshop. Abiliterai le API richieste nel progetto Terraform Admin. Utilizzerai Cloud Build per applicare i piani Terraform. Devi assegnare i ruoli IAM appropriati all'account di servizio Cloud Build affinché sia in grado di creare risorse su Google Cloud. Infine, configurerai un backend remoto in un bucket Google Cloud Storage (GCS) per archiviare gli stati Terraform per tutte le risorse Google Cloud.

Per visualizzare le attività Cloud Build nel progetto Terraform Admin, devi disporre dell'ID progetto Terraform. Viene archiviato nel file vars/vars.sh nella directory asm. Questa directory è permanente solo se stai configurando il workshop per te stesso come amministratore.

6. Crea il file delle variabili per impostare le variabili di ambiente

echo "export WORKDIR=$WORKDIR" >> $WORKDIR/asm/vars/vars.sh
source $WORKDIR/asm/vars/vars.sh 
 

Configurare un workshop per più utenti (configurazione multiutente)

7. Apri Cloud Shell, esegui tutte le azioni seguenti in Cloud Shell. Fai clic sul link di seguito.

CLOUD SHELL

8. Verifica di aver eseguito l'accesso a gcloud con l'utente amministratore previsto.

gcloud config list
 

9. Crea un elemento WORKDIR e clona il repository del workshop.

mkdir asm-workshop
cd asm-workshop
export WORKDIR=`pwd`
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git asm
 

10. Definisci il nome della tua organizzazione, l'ID fatturazione, il numero del workshop, il numero di inizio e di fine dell'utente e un bucket GCS amministratore da utilizzare per il workshop. Esamina le autorizzazioni richieste per la configurazione del workshop nelle sezioni precedenti.

gcloud organizations list
export ORGANIZATION_NAME=<ORGANIZATION NAME>

gcloud beta billing accounts list
export ADMIN_BILLING_ID=<BILLING ID>

export WORKSHOP_NUMBER=<two digit number for example 01>

export START_USER_NUMBER=<number for example 1>

export END_USER_NUMBER=<number greater or equal to START_USER_NUM>

export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>
 

11. Esegui lo script bootstrap_workshop.sh. Il completamento di questo script può richiedere alcuni minuti.

cd asm
./scripts/bootstrap_workshop.sh --org-name ${ORGANIZATION_NAME} --billing-id ${ADMIN_BILLING_ID} --workshop-num ${WORKSHOP_NUMBER} --start-user-num ${START_USER_NUMBER} --end-user-num ${END_USER_NUMBER} --admin-gcs-bucket ${ADMIN_STORAGE_BUCKET}
 

12. Recupera il file workshop.txt dal bucket GCS amministratore per recuperare gli ID progetto Terraform.

export WORKSHOP_ID="$(date '+%y%m%d')-${WORKSHOP_NUMBER}"
gsutil cp gs://${ADMIN_STORAGE_BUCKET}/${ORGANIZATION_NAME}/${WORKSHOP_ID}/workshop.txt .
 

4. Configurazione e preparazione del lab

Gli utenti che svolgono il workshop iniziano qui. Esegui tutti i passaggi da una finestra INCOGNITO in Chrome o Firefox.

Scegli il percorso del lab

I lab di questo workshop possono essere svolti in due modi:

• Gli "script interattivi a procedura rapida" modo
• L'opzione "Copia e incolla manualmente ogni istruzione" modo

Il metodo degli script rapidi ti consente di eseguire un singolo script interattivo per ogni lab che ti guida nella procedura, eseguendo automaticamente i comandi per quel lab. I comandi vengono eseguiti in batch con spiegazioni concise di ogni passaggio e dei risultati ottenuti. Dopo ogni batch, ti viene chiesto di passare al batch di comandi successivo. In questo modo, potrai eseguire i lab al tuo ritmo. Gli script veloci sono idempotenti, il che significa che è possibile eseguirli più volte ottenendo lo stesso risultato.

Gli script per i percorsi rapidi vengono visualizzati nella parte superiore di ogni lab in una casella verde, come mostrato di seguito.

TESTO DELLA TRACCIA RAPIDA

${WORKDIR}/asm/fasttrack_scripts/<name_of_script>.sh

Il metodo copia e incolla è il metodo tradizionale di copia e incolla dei singoli blocchi di comandi con le spiegazioni dei comandi. Questo metodo deve essere eseguito una sola volta. Non c'è alcuna garanzia che la nuova esecuzione dei comandi in questo metodo restituisca gli stessi risultati.

Quando esegui i lab, scegli uno di questi due metodi.

Dopo aver scelto un metodo ed eseguito i relativi passaggi, non eseguire i passaggi nell'altro metodo.

Configurazione rapida dello script

Una volta completato lo script della registrazione rapida, hai terminato il lab. Non eseguire i passaggi delle istruzioni del lab Copia e incolla.

Ottieni informazioni utente

Questo workshop viene eseguito utilizzando un account utente temporaneo (o un account del lab) creato dall'amministratore del workshop. L'account del lab è proprietario di tutti i progetti nel workshop. L'amministratore del workshop fornisce le credenziali dell'account del lab (nome utente e password) all'utente che lo esegue. Tutti i progetti dell'utente sono preceduti dal prefisso del nome utente dell'account del lab, ad esempio per l'account del lab [e-mail], l'ID del progetto amministratore Terraform sarà user001-200131-01-tf-abcde e così via per gli altri progetti. Ogni utente deve accedere con l'account del lab fornito dall'amministratore del workshop ed eseguire il workshop utilizzando l'account del lab.

Controlla la tua email aziendale (lo stesso che hai utilizzato per registrarti al workshop). Dovresti aver ricevuto un'email dall'amministratore del workshop con le credenziali del tuo account del lab (ovvero nome utente e password). L'email ha il seguente aspetto.

1. Apri Cloud Shell facendo clic sul link di seguito.

CLOUD SHELL

2. Accedi con le credenziali dell'account del lab (non con il tuo account aziendale o personale). L'account del lab è simile a userXYZ@<workshop_domain>.com.
3. Poiché questo è un nuovo account, ti viene chiesto di accettare i Termini di servizio di Google. Fai clic su Accetta.

4. Nella schermata successiva, seleziona la casella di controllo per accettare i Termini di servizio di Google e fai clic su Start Cloud Shell.

Questo passaggio esegue il provisioning di una piccola VM Debian Linux, che potrai utilizzare per accedere alle risorse Google Cloud. Ogni account riceve una VM Cloud Shell. Accedi con il provisioning dell'account del lab e accedi utilizzando le credenziali dell'account del lab. Oltre a Cloud Shell, viene eseguito anche il provisioning di un editor di codice che semplifica la modifica dei file di configurazione (terraform, YAML e così via). Per impostazione predefinita, la schermata di Cloud Shell è suddivisa nell'ambiente shell di Cloud Shell (in basso) e nell'editor di codice Cloud (in alto). La matita e l'icona del prompt della shell nell'angolo in alto a destra consentono di passare da una all'altra (shell ed editor di codice). Puoi anche trascinare la barra di separazione centrale (verso l'alto o verso il basso) e modificare manualmente le dimensioni di ogni finestra. 5. Crea un WORKDIR per questo workshop. Il WORKDIR è una cartella da cui puoi eseguire tutti i lab di questo workshop. Esegui questi comandi in Cloud Shell per creare WORKDIR.

mkdir -p ${HOME}/asm-workshop
cd ${HOME}/asm-workshop
export WORKDIR=`pwd` 
 

6. Esporta l'utente dell'account del lab come variabile da utilizzare per questo workshop. Si tratta dello stesso account con cui hai eseguito l'accesso a Cloud Shell.

export MY_USER=<LAB ACCOUNT EMAIL PROVIDED BY THE WORKSHOP ADMIN>
# For example export MY_USER=[e-mail] 
 

Nota: se sei un amministratore e hai configurato il workshop per te stesso utilizzando il comando "-sufa" o "–setup-for-admin" quindi imposta MY_USER sull'email dell'account Google Cloud usato per creare i progetti del workshop.

7. Fai clic sulle variabili WORKDIR e MY_USER per assicurarti che entrambe siano impostate correttamente eseguendo i comandi seguenti.

echo "WORKDIR set to ${WORKDIR}" && echo "MY_USER set to ${MY_USER}"
 

8. Clona il repository del workshop.

git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git ${WORKDIR}/asm
 

5. Configurazione dell'infrastruttura - Flusso di lavoro dell'utente

Obiettivo: verificare l'infrastruttura e l'installazione di Istio

• Installazione di strumenti di officina
• Clona il repository del workshop
• Verifica l'installazione di Infrastructure
• Verifica l'installazione di k8s-repo
• Verifica l'installazione di Istio

TESTO DELLA TRACCIA RAPIDA

Se scegli questo metodo, esegui lo script seguente per completare il lab.

${WORKDIR}/asm/fasttrack_scripts/infrastructure-setup-user-workflow.sh

Al termine dello script, genera il tuo bashrc per aggiornare le variabili nella sessione di Cloud Shell.

source ${HOME}/.bashrc

Istruzioni del lab sul metodo di copia e incolla

IMPORTANTE: se hai già completato lo script della procedura rapida per questo lab, non utilizzare il metodo di copia e incolla riportato di seguito**.**

Ottieni informazioni utente

L’amministratore che configura il workshop deve fornire il nome utente e la password all’utente. Tutti i progetti dell'utente saranno preceduti dal prefisso del nome utente, ad esempio per l'utente [e-mail], l'ID progetto amministratore Terraform sarà user001-200131-01-tf-abcde e così via per gli altri progetti. Ogni utente può accedere solo al proprio ambiente di workshop.

Strumenti richiesti per il workshop

Questo workshop è stato pensato per il bootstrap da Cloud Shell. Per questo workshop sono necessari i seguenti strumenti.

Tutti gli strumenti, tranne kustomize e pv, sono già installati per impostazione predefinita in Cloud Shell. Di seguito troverai le istruzioni per installarli entrambi.

• gcloud (ver >= 270)
• kubectl
• sed (funziona con sed su Cloud Shell/Linux e non su Mac OS)
• git (assicurati di essere aggiornato)
• sudo apt update
• sudo apt install git
• envsubst
• kustomize
• pv

Accedi al progetto amministratore Terraform

Una volta completato lo script bootstrap_workshop.sh, viene creata una cartella Google Cloud per ciascun utente all'interno dell'organizzazione. All'interno della cartella, viene creato un progetto terraform admin. Il progetto di amministrazione Terraform viene utilizzato per creare le risorse Google Cloud rimanenti richieste per questo workshop. Lo script setup-terraform-admin-project.sh abilita le API richieste nel progetto Terraform Admin. Cloud Build è utilizzato per applicare i piani Terraform. Tramite lo script, assegni i ruoli IAM appropriati all'account di servizio Cloud Build affinché sia in grado di creare risorse su Google Cloud. Infine, un backend remoto è configurato in un bucket Google Cloud Storage (GCS) per archiviare gli stati Terraform per tutte le risorse Google Cloud.

Per visualizzare le attività Cloud Build nel progetto Terraform Admin, devi disporre dell'ID progetto Terraform. Viene archiviato nel bucket GCS dell'amministratore specificato nello script di bootstrap. Se esegui lo script di bootstrap per più utenti, tutti gli ID progetto amministratore Terraform si trovano nel bucket GCS.

Questo workshop è destinato a essere eseguito in Cloud Shell e nella console Cloud. Dato che accederai con nome utente e password separati, esegui i seguenti passaggi in una finestra di INCOGNITO.

1. Apri Cloud Shell (se non è già aperto dalla sezione Configurazione e preparazione del lab) facendo clic sul link di seguito.

CLOUD SHELL

2. Installa kustomize (se non è già installato) nella cartella $HOME/bin e aggiungi la cartella $HOME/bin a $PATH.

mkdir -p $HOME/bin
cd $HOME/bin
curl -s "https://raw.githubusercontent.com/\
kubernetes-sigs/kustomize/master/hack/install_kustomize.sh"  | bash
cd $HOME
export PATH=$PATH:${HOME}/bin
echo "export PATH=$PATH:$HOME/bin" >> $HOME/.bashrc
 

3. Installa pv e spostalo in $HOME/bin/pv.

sudo apt-get update && sudo apt-get -y install pv
sudo mv /usr/bin/pv ${HOME}/bin/pv
 

4. Aggiorna il prompt bash.

cp $WORKDIR/asm/scripts/krompt.bash $HOME/.krompt.bash
echo "export PATH=\$PATH:\$HOME/bin" >> $HOME/.asm-workshop.bash
echo "source $HOME/.krompt.bash" >> $HOME/.asm-workshop.bash

alias asm-init='source $HOME/.asm-workshop.bash' >> $HOME/.bashrc
echo "source $HOME/.asm-workshop.bash" >> $HOME/.bashrc
source $HOME/.bashrc
 

5. Verifica di aver eseguito l'accesso a gcloud con l'account utente previsto.

echo "Check logged in user output from the next command is $MY_USER"
gcloud config list account --format=json | jq -r .core.account
 

6. Esegui il comando seguente per recuperare l'ID del progetto amministratore di Terraform:

export TF_ADMIN=$(gcloud projects list | grep tf- | awk '{ print $1 }')
echo $TF_ADMIN
 

7. Tutte le risorse associate al workshop vengono archiviate come variabili in un file vars.sh archiviato in un bucket GCS nel progetto amministratore Terraform. Recupera il file vars.sh per il tuo progetto amministratore Terraform.

mkdir $WORKDIR/asm/vars
gsutil cp gs://$TF_ADMIN/vars/vars.sh $WORKDIR/asm/vars/vars.sh
echo "export WORKDIR=$WORKDIR" >> $WORKDIR/asm/vars/vars.sh
 

8. Fai clic sul link visualizzato per aprire la pagina Cloud Build del progetto amministratore Terraform e verificare che la build sia stata completata correttamente.

source $WORKDIR/asm/vars/vars.sh
echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_ADMIN}"
 

Se accedi a Cloud Console per la prima volta, accetta i Termini di servizio di Google.

9. Ora che stai visualizzando la pagina Cloud Build, fai clic sul link History nel menu di navigazione a sinistra e fai clic sull'ultima build per visualizzare i dettagli dell'applicazione iniziale di Terraform. Le seguenti risorse vengono create come parte dello script Terraform. Puoi anche fare riferimento al diagramma dell'architettura riportato sopra.

• 4 progetti Google Cloud nell'organizzazione. L'account di fatturazione fornito è associato a ogni progetto.
• Un progetto è il network host project per il VPC condiviso. Non vengono create altre risorse in questo progetto.
• Un progetto è il ops project utilizzato per i cluster GKE del piano di controllo Istio.
• Due progetti rappresentano due diversi team di sviluppo che lavorano sui rispettivi servizi.
• Vengono creati due cluster GKE in ciascuno dei tre progetti ops, dev1 e dev2.
• Viene creato un repository CSR denominato k8s-repo che contiene sei cartelle per i file manifest di Kubernetes. Una cartella per cluster GKE. Questo repository viene utilizzato per eseguire il deployment dei manifest Kubernetes nei cluster in modo GitOps.
• Viene creato un trigger di Cloud Build in modo che ogni volta che è presente un commit nel ramo master di k8s-repo, esegua il deployment dei manifest Kubernetes nei cluster GKE dalle rispettive cartelle.

Lo script Terraform richiede 40-50 minuti.

10. Una volta completata la build in terraform admin project, verrà avviata un'altra build nel progetto Ops. Fai clic sul link visualizzato per aprire la pagina Cloud Build per ops project e verificare che Cloud Build k8s-repo sia stato completato correttamente.

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
 

Nota: questa build deve essere completata prima di poter verificare l'installazione di Istio.

Verifica installazione

11. Crea file kubeconfig per tutti i cluster. Esegui lo script seguente.

$WORKDIR/asm/scripts/setup-gke-vars-kubeconfig.sh
 

Questo script crea un nuovo file kubeconfig nella cartella gke denominata kubemesh.

12. Modifica la variabile KUBECONFIG in modo che punti al nuovo file kubeconfig.

source $WORKDIR/asm/vars/vars.sh
export KUBECONFIG=$WORKDIR/asm/gke/kubemesh
 

13. Aggiungi vars.sh e KUBECONFIG var al file .bashrc in Cloud Shell, in modo che venga recuperato ogni volta che Cloud Shell viene riavviato.

echo "source ${WORKDIR}/asm/vars/vars.sh" >> $HOME/.bashrc
echo "export KUBECONFIG=${WORKDIR}/asm/gke/kubemesh" >> $HOME/.bashrc
 

14. Elenca i contesti del cluster. Dovresti vedere sei cluster.

kubectl config view -ojson | jq -r '.clusters[].name'
 

    `Output (do not copy)`

gke_tf05-01-ops_us-central1_gke-asm-2-r2-prod
gke_tf05-01-ops_us-west1_gke-asm-1-r1-prod
gke_tf05-02-dev1_us-west1-a_gke-1-apps-r1a-prod
gke_tf05-02-dev1_us-west1-b_gke-2-apps-r1b-prod
gke_tf05-03-dev2_us-central1-a_gke-3-apps-r2a-prod
gke_tf05-03-dev2_us-central1-b_gke-4-apps-r2b-prod

Verifica l'installazione di Istio

15. Assicurati che Istio sia installato su entrambi i cluster controllando che tutti i pod siano in esecuzione e che i job siano stati completati.

kubectl --context ${OPS_GKE_1} get pods -n istio-system
kubectl --context ${OPS_GKE_2} get pods -n istio-system
 

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
grafana-5f798469fd-z9f98                  1/1     Running   0          6m21s
istio-citadel-568747d88-qdw64             1/1     Running   0          6m26s
istio-egressgateway-8f454cf58-ckw7n       1/1     Running   0          6m25s
istio-galley-6b9495645d-m996v             2/2     Running   0          6m25s
istio-ingressgateway-5df799fdbd-8nqhj     1/1     Running   0          2m57s
istio-pilot-67fd786f65-nwmcb              2/2     Running   0          6m24s
istio-policy-74cf89cb66-4wrpl             2/2     Running   1          6m25s
istio-sidecar-injector-759bf6b4bc-mw4vf   1/1     Running   0          6m25s
istio-telemetry-77b6dfb4ff-zqxzz          2/2     Running   1          6m24s
istio-tracing-cd67ddf8-n4d7k              1/1     Running   0          6m25s
istiocoredns-5f7546c6f4-g7b5c             2/2     Running   0          6m39s
kiali-7964898d8c-5twln                    1/1     Running   0          6m23s
prometheus-586d4445c7-xhn8d               1/1     Running   0          6m25s

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
grafana-5f798469fd-2s8k4                  1/1     Running   0          59m
istio-citadel-568747d88-87kdj             1/1     Running   0          59m
istio-egressgateway-8f454cf58-zj9fs       1/1     Running   0          60m
istio-galley-6b9495645d-qfdr6             2/2     Running   0          59m
istio-ingressgateway-5df799fdbd-2c9rc     1/1     Running   0          60m
istio-pilot-67fd786f65-nzhx4              2/2     Running   0          59m
istio-policy-74cf89cb66-4bc7f             2/2     Running   3          59m
istio-sidecar-injector-759bf6b4bc-grk24   1/1     Running   0          59m
istio-telemetry-77b6dfb4ff-6zr94          2/2     Running   4          60m
istio-tracing-cd67ddf8-grs9g              1/1     Running   0          60m
istiocoredns-5f7546c6f4-gxd66             2/2     Running   0          60m
kiali-7964898d8c-nhn52                    1/1     Running   0          59m
prometheus-586d4445c7-xr44v               1/1     Running   0          59m

16. Assicurati che Istio sia installato su entrambi i cluster dev1. Nei cluster dev1 vengono eseguiti solo Citadel, sidecar-injector e coredns. Condividono un piano di controllo Istio in esecuzione nel cluster ops-1.

kubectl --context ${DEV1_GKE_1} get pods -n istio-system
kubectl --context ${DEV1_GKE_2} get pods -n istio-system
 

17. Assicurati che Istio sia installato su entrambi i cluster dev2. Nei cluster dev2 vengono eseguiti solo Citadel, sidecar-injector e coredns. Condividono un piano di controllo Istio in esecuzione nel cluster ops-2.

kubectl --context ${DEV2_GKE_1} get pods -n istio-system
kubectl --context ${DEV2_GKE_2} get pods -n istio-system
 

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
istio-citadel-568747d88-4lj9b             1/1     Running   0          66s
istio-sidecar-injector-759bf6b4bc-ks5br   1/1     Running   0          66s
istiocoredns-5f7546c6f4-qbsqm             2/2     Running   0          78s

Verifica il rilevamento dei servizi per i piani di controllo condivisi

18. Facoltativamente, verifica che sia stato eseguito il deployment dei secret.

kubectl --context ${OPS_GKE_1} get secrets -l istio/multiCluster=true -n istio-system
kubectl --context ${OPS_GKE_2} get secrets -l istio/multiCluster=true -n istio-system
 

    `Output (do not copy)`

For OPS_GKE_1:
NAME                  TYPE     DATA   AGE
gke-1-apps-r1a-prod   Opaque   1      8m7s
gke-2-apps-r1b-prod   Opaque   1      8m7s
gke-3-apps-r2a-prod   Opaque   1      44s
gke-4-apps-r2b-prod   Opaque   1      43s

For OPS_GKE_2:
NAME                  TYPE     DATA   AGE
gke-1-apps-r1a-prod   Opaque   1      40s
gke-2-apps-r1b-prod   Opaque   1      40s
gke-3-apps-r2a-prod   Opaque   1      8m4s
gke-4-apps-r2b-prod   Opaque   1      8m4s

In questo workshop utilizzerai un singolo VPC condiviso in cui vengono creati tutti i cluster GKE. Per scoprire i servizi nei vari cluster, utilizza i file kubeconfig (per ciascuno dei cluster di applicazioni) creati come secret nei cluster delle operazioni. Il progetto pilota utilizza questi segreti per scoprire i servizi eseguendo una query sul server API Kube dei cluster di applicazioni (autenticati tramite i secret in alto). Puoi notare che entrambi i cluster delle operazioni possono autenticarsi in tutti i cluster di app utilizzando secret creati da kubeconfig. I cluster operativi possono rilevare servizi automaticamente utilizzando i file kubeconfig come metodo secret. Ciò richiede che il progetto pilota nei cluster operativi abbia accesso al server API Kube di tutti gli altri cluster. Se il progetto pilota non riesce a raggiungere i server API Kube, dovrai aggiungere manualmente i servizi remoti come ServiceEntries. Puoi considerare le ServiceEntries come voci DNS del tuo registro dei servizi. Le voci di servizio definiscono un servizio utilizzando un nome DNS completo ( FQDN) e un indirizzo IP al quale può essere raggiunto. Per ulteriori informazioni, consulta la documentazione di Istio Multicluster.

6. Spiegazione del repository dell'infrastruttura

Infrastruttura Cloud Build

Le risorse Google Cloud per il workshop sono create utilizzando Cloud Build e un repository CSR infrastructure. Hai appena eseguito uno script di bootstrap (all'indirizzo scripts/bootstrap_workshop.sh) dal tuo terminale locale. Lo script di bootstrap crea una cartella Google Cloud, un progetto amministratore Terraform e le autorizzazioni IAM appropriate per l'account di servizio Cloud Build. Il progetto amministratore Terraform viene utilizzato per archiviare stati Terraform, log e script vari. Contiene i repository CSR infrastructure e k8s_repo. Questi repository sono spiegati in dettaglio nella sezione successiva. Nessun'altra risorsa del workshop viene creata nel progetto per amministratori Terraform. L'account di servizio Cloud Build nel progetto amministratore Terraform viene utilizzato per creare risorse per il workshop.

Un file cloudbuild.yaml situato nella cartella infrastructure viene utilizzato per creare le risorse Google Cloud per il workshop. Viene creata un'immagine builder personalizzata con tutti gli strumenti necessari per creare risorse Google Cloud. Questi strumenti includono gcloud SDK, Terraform e altre utilità come python, git, jq e così via. L'immagine del generatore personalizzato esegue terraform plan e apply per ogni risorsa. I file Terraform di ogni risorsa si trovano in cartelle separate (per i dettagli vedi la sezione successiva). Le risorse vengono create una alla volta e nell'ordine tipico (ad esempio, un progetto Google Cloud viene creato prima delle risorse nel progetto). Per ulteriori dettagli, esamina il file cloudbuild.yaml.

Cloud Build viene attivato ogni volta che è presente un commit al repository infrastructure. Qualsiasi modifica apportata all'infrastruttura viene archiviata come Infrastructure as Code (IaC) e impegnata nel repository. Lo stato del workshop viene sempre archiviato in questo repository.

Struttura delle cartelle: team, ambienti e risorse

Il repository dell'infrastruttura configura le risorse dell'infrastruttura Google Cloud per il workshop. È strutturato in cartelle e sottocartelle. Le cartelle di base all'interno del repository rappresentano i team proprietari di risorse Google Cloud specifiche. Il livello di cartelle successivo rappresenta il environment specifico per il team (ad esempio, sviluppo, fase, produzione). Il livello successivo di cartelle all'interno dell'ambiente rappresenta resource specifico (ad esempio host_project, gke_clusters e così via). Gli script e i file Terraform richiesti sono presenti all'interno delle cartelle delle risorse.

In questo workshop vengono rappresentati i quattro tipi di team seguenti:

1. infrastruttura - rappresenta il team dell'infrastruttura cloud. Sono responsabili della creazione delle risorse Google Cloud per tutti gli altri team. Per le risorse viene usato il progetto amministratore Terraform. Il repository dell'infrastruttura stesso si trova nel progetto amministratore Terraform, nonché i file di stato di Terraform (spiegati di seguito). Queste risorse vengono create da uno script bash durante il processo di bootstrap (per maggiori dettagli, vedi Modulo 0 - Flusso di lavoro dell'amministratore).
2. network: rappresenta il team di networking. Sono responsabili delle risorse VPC e di networking. Sono proprietari delle seguenti risorse Google Cloud.
3. host project: rappresenta il progetto host del VPC condiviso.
4. shared VPC: rappresenta il VPC condiviso, le subnet, gli intervalli IP secondari, le route e le regole firewall.
5. ops: rappresenta il team Operations/devops. Sono proprietari delle seguenti risorse.
6. ops project: rappresenta un progetto per tutte le risorse operative.
7. gke clusters: un cluster GKE delle operazioni per regione. Il piano di controllo Istio viene installato in ciascuno dei cluster GKE delle operazioni.
8. k8s-repo: un repository CSR che contiene i manifest GKE per tutti i cluster GKE.
9. apps: rappresenta i team delle applicazioni. Questo workshop simula due team: app1 e app2. Sono proprietari delle seguenti risorse.
10. app projects - ogni team addetto all'app riceve un insieme di progetti. Ciò consente loro di controllare la fatturazione e IAM per il loro progetto specifico.
11. gke clusters: i cluster di applicazioni in cui vengono eseguiti i container/pod di applicazioni.
12. gce instances: facoltativamente, se dispongono di applicazioni in esecuzione su istanze GCE. In questo workshop, app1 ha un paio di istanze GCE in cui viene eseguita parte dell'applicazione.

In questo workshop, la stessa app (app negozio Hipster) rappresenta sia app1 che app2.

Provider, stati e output - Backend e stati condivisi

I fornitori google e google-beta si trovano presso gcp/[environment]/gcp/provider.tf. Il file provider.tf ha un collegamento simbolico in ogni cartella delle risorse. In questo modo puoi modificare il provider in un'unica posizione anziché gestirli individualmente per ogni risorsa.

Ogni risorsa contiene un file backend.tf che definisce la posizione del file tfstate della risorsa. Questo file backend.tf viene generato da un modello (disponibile all'indirizzo templates/backend.tf_tmpl) utilizzando uno script (disponibile in scripts/setup_terraform_admin_project), quindi inserito nella rispettiva cartella delle risorse. I bucket Google Cloud Storage (GCS) vengono utilizzati per i backend. Il nome della cartella del bucket GCS corrisponde al nome della risorsa. Tutti i backend delle risorse si trovano nel progetto amministratore Terraform.

Le risorse con valori interdipendenti contengono un file output.tf. I valori di output richiesti vengono archiviati nel file tfstate definito nel backend per quella determinata risorsa. Ad esempio, per creare un cluster GKE in un progetto, devi conoscere l'ID progetto. L'ID progetto viene fornito tramite output.tf nel file tfstate, che può essere utilizzato tramite un'origine dati terraform_remote_state nella risorsa del cluster GKE.

Il file shared_state è un'origine dati terraform_remote_state che punta al file tfstate di una risorsa. Nelle cartelle delle risorse che richiedono output da altre risorse sono presenti uno o più file shared_state_[resource_name].tf. Ad esempio, nella cartella delle risorse ops_gke sono presenti file shared_state dalle risorse ops_project e shared_vpc, perché sono necessari l'ID progetto e i dettagli del VPC per creare cluster GKE nel progetto operazioni. I file shared_state vengono generati da un modello (disponibile all'indirizzo templates/shared_state.tf_tmpl) utilizzando uno script (disponibile all'indirizzo scripts/setup_terraform_admin_project). Tutte le risorse I file shared_state vengono inseriti nella cartella gcp/[environment]/shared_states. I file shared_state richiesti sono collegati tramite simboli nelle rispettive cartelle delle risorse. Se posizioni tutti i file shared_state in una cartella e li colleghi alle cartelle delle risorse appropriate, è facile gestire tutti i file di stato in un'unica posizione.

Variabili

Tutti i valori delle risorse vengono archiviati come variabili di ambiente. Queste variabili sono archiviate (come istruzioni di esportazione) in un file denominato vars.sh situato in un bucket GCS nel progetto amministratore Terraform. Questo file contiene l'ID organizzazione, l'account di fatturazione, gli ID progetto, i dettagli del cluster GKE e così via. Puoi scaricare l'vars.sh e recuperarlo da qualsiasi terminale per ottenere i valori della configurazione.

Le variabili Terraform sono archiviate in vars.sh come TF_VAR_[variable name]. Queste variabili vengono utilizzate per generare un file variables.tfvars nella rispettiva cartella delle risorse. Il file variables.tfvars contiene tutte le variabili con i relativi valori. Il file variables.tfvars viene generato da un file modello nella stessa cartella utilizzando uno script (disponibile nella pagina scripts/setup_terraform_admin_project).

Spiegazione del repository K8s

k8s_repo è un repository CSR (separato dal repository dell'infrastruttura) situato nel progetto di amministrazione Terraform. Viene utilizzato per archiviare e applicare manifest GKE a tutti i cluster GKE. L'elemento k8s_repo viene creato dall'infrastruttura Cloud Build (vedi la sezione precedente per i dettagli). Durante il processo iniziale dell'infrastruttura Cloud Build, vengono creati un totale di sei cluster GKE. In k8s_repo, vengono create sei cartelle. Ogni cartella (nome corrispondente al nome del cluster GKE) corrisponde a un cluster GKE contenente i rispettivi file manifest delle risorse. Analogamente alla creazione dell'infrastruttura, Cloud Build viene utilizzato per applicare i manifest Kubernetes a tutti i cluster GKE utilizzando k8s_repo. Cloud Build viene attivato ogni volta che viene eseguito un commit nel repository k8s_repo. Come per l'infrastruttura, tutti i manifest di Kubernetes sono archiviati come codice nel repository k8s_repo e lo stato di ogni cluster GKE è sempre archiviato nella rispettiva cartella.

Nell'ambito della build iniziale dell'infrastruttura, viene creato k8s_repo e Istio installato su tutti i cluster.

Progetti, cluster GKE e spazi dei nomi

Le risorse di questo workshop sono suddivise in diversi progetti Google Cloud. I progetti devono corrispondere alla struttura organizzativa (o team) della tua azienda. I team (nella tua organizzazione) responsabili di diversi progetti/prodotti/risorse utilizzano progetti Google Cloud diversi. La presenza di progetti separati consente di creare set separati di autorizzazioni IAM e di gestire la fatturazione a livello di progetto. Inoltre, le quote vengono gestite anche a livello di progetto.

In questo workshop sono rappresentati cinque team, ognuno con il proprio progetto.

1. Il team dell'infrastruttura che crea risorse Google Cloud utilizza Terraform admin project. Gestisce l'infrastruttura come codice in un repository CSR (denominato infrastructure) e archiviano tutte le informazioni sullo stato di Terraform relative alle risorse create in Google Cloud nei bucket GCS. Controllano l'accesso al repository CSR e ai bucket GCS dello stato di Terraform.
2. Il team di rete che crea il VPC condiviso utilizza host project. Questo progetto contiene il VPC, le subnet, le route e le regole firewall. Un VPC condiviso consente di gestire centralmente il networking per le risorse Google Cloud. Tutti i progetti hanno utilizzato questo singolo VPC condiviso per il networking.
3. Il team operativo/piattaforma che crea i cluster GKE e i piani di controllo ASM/Istio utilizzano ops project. Gestiscono il ciclo di vita dei cluster GKE e del mesh di servizi. Sono responsabili del rafforzamento dei cluster, della gestione della resilienza e della scalabilità della piattaforma Kubernetes. In questo workshop, utilizzerai il metodo gitops per eseguire il deployment delle risorse in Kubernetes. Nel progetto operazioni esiste un repository CSR (denominato k8s_repo).
4. Infine, i team dev1 e dev2 (rappresentano due team di sviluppo) che creano applicazioni utilizzano i propri dev1 e dev2 projects. Si tratta delle applicazioni e dei servizi che offri ai tuoi clienti. che si basano sulla piattaforma gestita dal team operativo. Le risorse (deployment, servizi e così via) vengono inviate tramite push a k8s_repo, di cui viene eseguito il deployment nei cluster appropriati. È importante notare che questo workshop non è incentrato sulle best practice e sugli strumenti di CI/CD. Puoi usare Cloud Build per automatizzare il deployment delle risorse Kubernetes direttamente nei cluster GKE. In scenari di produzione reali, utilizzeresti una soluzione CI/CD adeguata per eseguire il deployment delle applicazioni sui cluster GKE.

In questo workshop sono presenti due tipi di cluster GKE.

1. Cluster operazioni: utilizzati dal team operativo per eseguire gli strumenti DevOps. In questo workshop, viene eseguito il piano di controllo ASM/Istio per gestire il mesh di servizi.
2. Cluster di applicazioni (app): utilizzati dai team di sviluppo per eseguire le applicazioni. In questo workshop viene utilizzata l'app Hipster Shop.

La separazione degli strumenti operativi/di amministrazione dai cluster che eseguono l'applicazione consente di gestire il ciclo di vita di ogni risorsa in modo indipendente. I due tipi di cluster esistono anche in diversi progetti relativi al team o al prodotto che li utilizza, il che rende anche più facile la gestione delle autorizzazioni IAM.

Ci sono in totale sei cluster GKE. Nel progetto Ops vengono creati due cluster operativi a livello di regione. Il piano di controllo ASM/Istio è installato su entrambi i cluster operativi. Ogni cluster operativo si trova in una regione diversa. Inoltre, esistono quattro cluster di applicazioni a livello di zona. Vengono creati nei propri progetti. Questo workshop simula due team di sviluppo, ognuno con i propri progetti. Ogni progetto contiene due cluster di app. I cluster di app sono cluster a livello di zona in zone diverse. I quattro cluster di app si trovano in due regioni e quattro zone. In questo modo ottieni la ridondanza a livello di regione e zona.

Il deployment dell'applicazione utilizzata in questo workshop, l'app Hipster Shop, è stato eseguito in tutti e quattro i cluster di app. Ogni microservizio risiede nel proprio spazio dei nomi in ogni cluster di app. Il deployment dei deployment dell'app Hipster Shop (pod) non viene eseguito nei cluster operativi. Tuttavia, gli spazi dei nomi e le risorse del servizio per tutti i microservizi vengono creati anche nei cluster operativi. Il piano di controllo ASM/Istio utilizza i registri di servizi Kubernetes per il rilevamento dei servizi. In assenza di Services (nei cluster delle operazioni), dovrai creare manualmente ServiceEntries per ogni servizio in esecuzione nel cluster dell'app.

In questo workshop eseguirai il deployment di un'applicazione di microservizi a 10 livelli. L'applicazione è un'app di e-commerce basata sul web chiamata " Hipster Shop" dove gli utenti possono sfogliare gli articoli, aggiungerli al carrello e acquistarli.

manifest di Kubernetes e k8s_repo

Utilizzerai k8s_repo per aggiungere risorse Kubernetes a tutti i cluster GKE. Per farlo, copia i manifest di Kubernetes ed esegui il commit nell'k8s_repo. Tutti i commit in k8s_repo attivano un job Cloud Build che esegue il deployment dei manifest di Kubernetes nel rispettivo cluster. Il manifest di ogni cluster si trova in una cartella separata denominata con lo stesso nome del cluster.

I sei nomi di cluster sono:

1. gke-asm-1-r1-prod: il cluster di operazioni a livello di regione nella regione 1
2. gke-asm-2-r2-prod: il cluster di operazioni a livello di regione nella regione 2
3. gke-1-apps-r1a-prod: il cluster dell'app nella zona 1 della regione a
4. gke-2-apps-r1b-prod: il cluster dell'app nella zona b della regione 1
5. gke-3-apps-r2a-prod: il cluster dell'app nella zona 2 della regione a
6. gke-4-apps-r2b-prod: il cluster dell'app nella zona b della regione 2

k8s_repo ha cartelle corrispondenti a questi cluster. Tutti i manifest inseriti in queste cartelle vengono applicati al cluster GKE corrispondente. Per facilitare la gestione, i manifest per ogni cluster vengono inseriti in sottocartelle (all'interno della cartella principale del cluster). In questo workshop, utilizzerai Kustomize per tenere traccia delle risorse di cui viene eseguito il deployment. Per ulteriori dettagli, consulta la documentazione ufficiale di Kustomize.

7. Esegui il deployment dell'app di esempio

Obiettivo: eseguire il deployment dell'app Negozio Hipster su cluster di app

• k8s-repo (clone)
• Copia i manifest del negozio Hipster in tutti i cluster di app
• Crea l'app Services per il negozio Hipster nei cluster operativi
• Configura loadgenerators nei cluster operativi per testare la connettività globale
• Verifica la connettività sicura all'app Hipster Shop

TESTO DELLA TRACCIA RAPIDA

Se scegli questo metodo, esegui lo script seguente per completare il lab.

${WORKDIR}/asm/fasttrack_scripts/deploy-sample-app.sh

Istruzioni del lab sul metodo di copia e incolla

Se hai già completato lo script della procedura rapida per questo lab, non utilizzare il metodo di copia e incolla riportato di seguito**.**

Clona il repository di origine del progetto Ops

Come parte della build iniziale dell'infrastruttura Terraform, k8s-repo è già stato creato nel progetto Ops.

1. Crea una directory vuota per il repository Git:

mkdir $WORKDIR/k8s-repo
 

2. Inizia il repository Git, aggiungi remote ed esegui il pull del master dal repository remoto:

cd $WORKDIR/k8s-repo
git init && git remote add origin \
https://source.developers.google.com/p/$TF_VAR_ops_project_name/r/k8s-repo
 

3. Imposta la configurazione locale Git locale.

git config --local user.email $MY_USER
git config --local user.name "K8s repo user"
git config --local \
credential.'https://source.developers.google.com'.helper gcloud.sh
git pull origin master

Copia manifest, esegui il commit ed esegui il push

4. Copia gli spazi dei nomi e i servizi Hipster Shop nel repository di origine per tutti i cluster.

cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/.

cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/.
 

5. Copia la cartella dell'app kustomization.yaml in tutti i cluster.

cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/
 

6. Copia i Deployments, RBAC e PodSecurityPolicy di origine nel repository di origine per i cluster delle app.

cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/

cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/

7. Rimuovi il deployment di cartservice, rbac e podsecuritypolicy da tutti i cluster di sviluppo tranne uno. Hipstershop non è stato creato per il deployment multi-cluster, quindi per evitare risultati incoerenti, utilizziamo un solo carrelloservice.

rm $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/deployments/app-cart-service.yaml
rm $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/podsecuritypolicies/cart-psp.yaml
rm $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/rbac/cart-rbac.yaml

rm $WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/deployments/app-cart-service.yaml
rm $WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/podsecuritypolicies/cart-psp.yaml
rm $WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/rbac/cart-rbac.yaml

rm $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/deployments/app-cart-service.yaml
rm $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/podsecuritypolicies/cart-psp.yaml
rm $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/rbac/cart-rbac.yaml
 

8. Aggiungi il deployment di cartservice, rbac e podsecuritypolicy a kustomization.yaml solo nel primo cluster di sviluppo.

cd ${WORKDIR}/k8s-repo/${DEV1_GKE_1_CLUSTER}/app
cd deployments && kustomize edit add resource app-cart-service.yaml
cd ../podsecuritypolicies && kustomize edit add resource cart-psp.yaml
cd ../rbac && kustomize edit add resource cart-rbac.yaml
cd ${WORKDIR}/asm
 

9. Rimuovi podsecuritypolicies, deployment e directory Rbac dai cluster operativi kustomization.yaml

sed -i -e '/- deployments\//d' -e '/- podsecuritypolicies\//d' \
  -e '/- rbac\//d' \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/kustomization.yaml
sed -i -e '/- deployments\//d' -e '/- podsecuritypolicies\//d' \
  -e '/- rbac\//d' \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/kustomization.yaml

10. Sostituisci il valore di PROJECT_ID nei manifest RBAC.

sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev1_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV1_GKE_1_CLUSTER}/app/rbac/*
sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev1_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV1_GKE_2_CLUSTER}/app/rbac/*
sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev2_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV2_GKE_1_CLUSTER}/app/rbac/*
sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev2_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV2_GKE_2_CLUSTER}/app/rbac/*
  

11. Copia i manifest IngressGateway e VirtualService nel repository di origine per i cluster delle operazioni.

cp -r $WORKDIR/asm/k8s_manifests/prod/app-ingress/* \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-ingress/
cp -r $WORKDIR/asm/k8s_manifests/prod/app-ingress/* \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-ingress/
 

12. Copia le risorse di Config Connector in uno dei cluster in ogni progetto.

cp -r $WORKDIR/asm/k8s_manifests/prod/app-cnrm/* \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-cnrm/
cp -r $WORKDIR/asm/k8s_manifests/prod/app-cnrm/* \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app-cnrm/
cp -r $WORKDIR/asm/k8s_manifests/prod/app-cnrm/* \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app-cnrm/
 

13. Sostituisci il PROJECT_ID nei manifest di Config Connector.

sed -i 's/${PROJECT_ID}/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-cnrm/*
sed -i 's/${PROJECT_ID}/'$TF_VAR_dev1_project_name'/g' \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app-cnrm/*
sed -i 's/${PROJECT_ID}/'$TF_VAR_dev2_project_name'/g' \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app-cnrm/*
 

14. Copia i manifest loadgenerator (Deployment, PodSecurityPolicy e RBAC) nei cluster operativi. L'app Hipster Shop è esposta utilizzando un bilanciatore del carico Google Cloud (GCLB) globale. GCLB riceve il traffico client (destinato a frontend) e lo invia all'istanza più vicina del servizio. L'inserimento di loadgenerator su entrambi i cluster delle operazioni garantirà l'invio del traffico a entrambi i gateway Istio Ingress in esecuzione nei cluster delle operazioni. Il bilanciamento del carico è spiegato in dettaglio nella sezione seguente.

cp -r $WORKDIR/asm/k8s_manifests/prod/app-loadgenerator/. \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-loadgenerator/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app-loadgenerator/. \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-loadgenerator/. 
 

15. Sostituisci l'ID progetto Ops nei manifest loadgenerator per entrambi i cluster operativi.

sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g'  \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-loadgenerator/loadgenerator-deployment.yaml
sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-loadgenerator/loadgenerator-rbac.yaml
sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-loadgenerator/loadgenerator-deployment.yaml
sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-loadgenerator/loadgenerator-rbac.yaml
 

16. Aggiungi le risorse loadgenerator a kustomization.yaml per entrambi i cluster operativi.

cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-loadgenerator/
kustomize edit add resource loadgenerator-psp.yaml
kustomize edit add resource loadgenerator-rbac.yaml
kustomize edit add resource loadgenerator-deployment.yaml

cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-loadgenerator/
kustomize edit add resource loadgenerator-psp.yaml
kustomize edit add resource loadgenerator-rbac.yaml
kustomize edit add resource loadgenerator-deployment.yaml
 

17. Sottoscrivi k8s-repo.

cd $WORKDIR/k8s-repo
git add . && git commit -am "create app namespaces and install hipster shop"
git push --set-upstream origin master 
 

18. Visualizza lo stato del progetto Ops Cloud Build in una scheda aperta in precedenza o facendo clic sul seguente link:

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
  

Verifica il deployment dell'applicazione

19. Verifica che i pod in tutti gli spazi dei nomi delle applicazioni, ad eccezione del carrello, siano in stato In esecuzione in tutti i cluster dev.

for ns in ad checkout currency email frontend payment product-catalog recommendation shipping; do
  kubectl --context $DEV1_GKE_1 get pods -n $ns;
  kubectl --context $DEV1_GKE_2 get pods -n $ns;
  kubectl --context $DEV2_GKE_1 get pods -n $ns;
  kubectl --context $DEV2_GKE_2 get pods -n $ns;
done;
 

Output (do not copy)

NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-pvc6s   2/2     Running   0          13m
NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-xlkl9   2/2     Running   0          13m
NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-zdjkg   2/2     Running   0          115s
NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-l748q   2/2     Running   0          82s

NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-gk92n   2/2     Running   0          13m
NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-rvzk9   2/2     Running   0          13m
NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-mt925   2/2     Running   0          117s
NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-klqn7   2/2     Running   0          84s

NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-kkq7d   2/2     Running   0          13m
NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-lwskf   2/2     Running   0          13m
NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-zz7xs   2/2     Running   0          118s
NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-2vtw5   2/2     Running   0          85s

NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-df8ml   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-bdcvg   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-jqf28   2/2     Running   0          117s
NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-95x2m   2/2     Running   0          86s

NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-q5g9p   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-n6lp8   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-gf9xl   2/2     Running   0          119s
NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-v7cbr   2/2     Running   0          86s

NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-2ltrk   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-dqd55   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-jghcl   2/2     Running   0          119s
NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-kkspz   2/2     Running   0          87s

NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-qqd9n   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-xczg5   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-wfgfr   2/2     Running   0          2m
NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-r6t8v   2/2     Running   0          88s

20. Verifica che i pod nello spazio dei nomi del carrello siano in stato In esecuzione solo nel primo cluster dev.

kubectl --context $DEV1_GKE_1 get pods -n cart;
 

Output (do not copy)

NAME                           READY   STATUS    RESTARTS   AGE
cartservice-659c9749b4-vqnrd   2/2     Running   0          17m

Accedi all'app Hipster Shop

Bilanciamento del carico globale

Ora hai eseguito il deployment dell'app Hipster Shop in tutti e quattro i cluster di app. Questi cluster si trovano in due regioni e quattro zone. I clienti possono accedere all'app Hipster Shop tramite il servizio frontend. Il servizio frontend viene eseguito su tutti e quattro i cluster dell'app. Per ricevere il traffico client verso tutte e quattro le istanze del servizio frontend viene utilizzato un bilanciatore del carico Google Cloud ( GCLB).

I gateway Istio Ingress vengono eseguiti solo nei cluster operativi e fungono da bilanciatore del carico a livello di regione per i due cluster di applicazioni a livello di zona all'interno della regione. GCLB utilizza i due gateway in entrata Istio (in esecuzione nei due cluster delle operazioni) come backend al servizio frontend globale. I gateway Istio Ingress ricevono il traffico client da GCLB e quindi lo inviano ai pod di frontend in esecuzione nei cluster dell'applicazione.

In alternativa, puoi inserire gateway Istio Ingress direttamente sui cluster delle applicazioni e il GCLB può utilizzarli come backend.

Controller GKE Autoneg

Il servizio Kubernetes del gateway Istio Ingress si registra come backend del GCLB utilizzando i gruppi di endpoint di rete (NEG). I NEG consentono il bilanciamento del carico nativo del container tramite GCLB. I NEG vengono creati tramite un'annotazione speciale su un servizio Kubernetes, in modo che possano registrarsi nel controller NEG. Il controller Autoneg è un controller GKE speciale che automatizza la creazione di NEG e assegnarli come backend a un GCLB utilizzando le annotazioni dei servizi. Il deployment dei piani di controllo Istio, inclusi i gateway in entrata Istio, viene eseguito durante l'infrastruttura iniziale di Terraform Cloud Build. La configurazione di GCLB e della negazione automatica viene eseguita nell'ambito dell'infrastruttura Terraform iniziale in Cloud Build.

Proteggi il traffico in entrata utilizzando Cloud Endpoints e i certificati gestiti

I certificati gestiti da Google Cloud vengono utilizzati per proteggere il traffico client al servizio GCLB frontend. GCLB utilizza certificati gestiti per il servizio frontend globale e il certificato viene terminato a GCLB. In questo workshop, utilizzerai Cloud Endpoints come dominio per il certificato gestito. In alternativa, puoi utilizzare il tuo dominio e un nome DNS per frontend per creare certificati gestiti da Google Cloud.

21. Per accedere al negozio Hipster, fai clic sull'output del link del seguente comando.

echo "https://frontend.endpoints.$TF_VAR_ops_project_name.cloud.goog" 
 

22. Puoi verificare che il certificato sia valido facendo clic sul simbolo del lucchetto nella barra degli URL della scheda di Chrome.

Verifica del bilanciamento del carico globale

Nell'ambito del deployment dell'applicazione, è stato eseguito il deployment dei generatori di carico in entrambi i cluster operativi che generano traffico di prova verso il link Cloud Endpoints di GCLB Hipster Shop. Verifica che il GCLB stia ricevendo traffico e inviando a entrambi i gateway Istio Ingress.

23. Scarica il GCLB > Monitoraggio per il progetto operativo in cui è stato creato il GCLB del negozio Hipster.

echo "https://console.cloud.google.com/net-services/loadbalancing/details/http/istio-ingressgateway?project=$TF_VAR_ops_project_name&cloudshell=false&tab=monitoring&duration=PT1H" 
 

24. Passa da Tutti i backend a istio-ingressgateway dal menu a discesa Backend, come mostrato di seguito.

25. Nota il traffico verso istio-ingressgateways.

Vengono creati tre NEG per istio-ingressgateway. Poiché i cluster operativi sono cluster a livello di regione, viene creato un NEG per ogni zona della regione. I pod istio-ingressgateway, tuttavia, vengono eseguiti in una singola zona per regione. Il traffico viene mostrato ai pod istio-ingressgateway.

I generatori di carico sono in esecuzione in entrambi i cluster operativi, simulando il traffico client dalle due regioni in cui si trovano. Il carico generato nella regione 1 del cluster di operazioni viene inviato a istio-ingressgateway nella regione 2. Allo stesso modo, il carico generato nella regione 2 del cluster operativo viene inviato a istio-ingressgateway nella regione 2.

8. Osservabilità con Stackdriver

Obiettivo: connettere la telemetria Istio a Stackdriver ed eseguire la convalida.

• Installa istio-telemetry risorse
• Crea/aggiorna le dashboard dei servizi Istio
• Visualizza log dei container
• Visualizza il tracciamento distribuito in Stackdriver

TESTO DELLA TRACCIA RAPIDA

Se scegli questo metodo, esegui lo script seguente per completare il lab.

${WORKDIR}/asm/fasttrack_scripts/observability-with-stackdriver.sh

Istruzioni del lab sul metodo di copia e incolla

Se hai già completato lo script della procedura rapida per questo lab, non utilizzare il metodo di copia e incolla riportato di seguito**.**

Una delle funzionalità principali di Istio è l'osservabilità integrata ("o11y"). Ciò significa che anche con container black-box e non instrumentati, gli operatori possono comunque osservare il traffico in entrata e in uscita da questi container, fornendo servizi ai clienti. Questa osservazione prende la forma di diversi metodi: metriche, log e tracce.

In Hipster Shop verrà utilizzato anche il sistema integrato di generazione del carico. L'osservabilità non funziona molto bene in un sistema statico senza traffico, quindi la generazione del carico ci aiuta a capire come funziona. Il carico è già in esecuzione, ora potremo solo vederlo.

1. Installare il file di configurazione da istio a Stackdriver.

cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/istio-telemetry
kustomize edit add resource istio-telemetry.yaml

cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/istio-telemetry
kustomize edit add resource istio-telemetry.yaml
 

2. Esegui il commit in k8s-repo.

cd $WORKDIR/k8s-repo
git add . && git commit -am "Install istio to stackdriver configuration"
git push 
 

3. Visualizza lo stato del progetto Ops Cloud Build in una scheda aperta in precedenza o facendo clic sul seguente link:

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
 

4. Verifica l'integrazione di Istio → Stackdriver Scarica il CRD del gestore di Stackdriver.

kubectl --context $OPS_GKE_1 get handler -n istio-system
 

L'output dovrebbe mostrare un gestore denominato stackdriver:

NAME            AGE
kubernetesenv   12d
prometheus      12d
stackdriver     69s      # <== NEW!

5. Verifica che l'esportazione delle metriche Istio in Stackdriver funzioni correttamente. Fai clic sull'output del link da questo comando:

echo "https://console.cloud.google.com/monitoring/metrics-explorer?cloudshell=false&project=$TF_VAR_ops_project_name"
 

Ti verrà chiesto di creare una nuova area di lavoro, denominata in base al progetto Ops. Devi solo scegliere OK. Se viene richiesto di utilizzare la nuova UI, chiudi semplicemente la finestra di dialogo.

In Esplora metriche, nella sezione "Trovare tipo di risorsa e metrica" digita "istio" per vedere le opzioni, ad esempio "Server Request Count" (Conteggio richieste server) nel "Container Kubernetes" un tipo di risorsa. Questo ci mostra che le metriche fluiscono dal mesh in Stackdriver.

Per visualizzare le righe seguenti, dovrai utilizzare l'etichetta Raggruppa per destination_service_name.

Visualizzazione delle metriche con le dashboard:

Ora che le nostre metriche si trovano nel sistema Stackdriver APM, vogliamo trovare un modo per visualizzarle. In questa sezione installeremo una dashboard predefinita che mostra i tre dei quattro " Indicatori aurei" delle metriche: Traffico (Richieste al secondo), Latenza (in questo caso, 99° e 50° percentile) ed Errori (in questo esempio stiamo escludendo la Saturazione).

Il proxy Envoy di Istio fornisce diverse metriche, ma queste sono un buon set per iniziare. (l'elenco completo è disponibile qui). Tieni presente che ogni metrica ha un insieme di etichette che possono essere utilizzate per l'applicazione di filtri e l'aggregazione, ad esempio: destination_service, source_workload_namespace, response_code, istio_tcp_received_bytes_total e così via.

6. Ora aggiungiamo la dashboard delle metriche preimpostate. Useremo direttamente l'API Dashboard. Si tratta di un'operazione che normalmente non svolgeresti generando manualmente le chiamate API, in un sistema di automazione o nella creazione manuale della dashboard nell'interfaccia utente web. Questo ci consentirà di iniziare rapidamente:

sed -i 's/OPS_PROJECT/'${TF_VAR_ops_project_name}'/g' \
$WORKDIR/asm/k8s_manifests/prod/app-telemetry/services-dashboard.json
OAUTH_TOKEN=$(gcloud auth application-default print-access-token)
curl -X POST -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json" \
https://monitoring.googleapis.com/v1/projects/$TF_VAR_ops_project_name/dashboards \
 -d @$WORKDIR/asm/k8s_manifests/prod/app-telemetry/services-dashboard.json
 

7. Vai al link di output riportato di seguito per visualizzare la "Dashboard dei servizi" appena aggiunta.

echo "https://console.cloud.google.com/monitoring/dashboards/custom/servicesdash?cloudshell=false&project=$TF_VAR_ops_project_name"
 
 

Potremmo modificare la dashboard in loco utilizzando la UX, ma nel nostro caso aggiungeremo rapidamente un nuovo grafico utilizzando l'API. A questo scopo, devi scaricare la versione più recente della dashboard, applicare le modifiche ed eseguire il push utilizzando il metodo HTTP PATCH.

8. Puoi ottenere una dashboard esistente eseguendo una query sull'API Monitoring. Scarica la dashboard esistente appena aggiunta:

curl -X GET -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json" \
https://monitoring.googleapis.com/v1/projects/$TF_VAR_ops_project_name/dashboards/servicesdash > /tmp/services-dashboard.json
 

9. Aggiungi un nuovo grafico: (50° %ile latenza): [ Riferimento API] Ora possiamo aggiungere un nuovo widget grafico nel codice alla nostra dashboard. Questa modifica può essere esaminata dai peer e registrata nel controllo della versione. Ecco un widget da aggiungere che mostra una latenza del 50% (latenza mediana).

Prova a modificare la dashboard appena creata, aggiungendo una nuova stanza:

NEW_CHART=${WORKDIR}/asm/k8s_manifests/prod/app-telemetry/new-chart.json
jq --argjson newChart "$(<$NEW_CHART)" '.gridLayout.widgets += [$newChart]' /tmp/services-dashboard.json > /tmp/patched-services-dashboard.json
 

10. Aggiorna la dashboard dei servizi esistenti:

curl -X PATCH -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json" \
https://monitoring.googleapis.com/v1/projects/$TF_VAR_ops_project_name/dashboards/servicesdash \
 -d @/tmp/patched-services-dashboard.json
 

11. Per visualizzare la dashboard aggiornata, vai al seguente link di output:

echo "https://console.cloud.google.com/monitoring/dashboards/custom/servicesdash?cloudshell=false&project=$TF_VAR_ops_project_name"
 

12. Esegui semplici analisi dei log.

Istio fornisce un set di log strutturati per tutto il traffico di rete in-mesh e li carica su Stackdriver Logging per consentire l'analisi tra cluster in un unico potente strumento. I log sono annotati con metadati a livello di servizio come cluster, container, app, connection_id e così via.

Un esempio di voce di log (in questo caso, il log di accesso del proxy Envoy) potrebbe avere il seguente aspetto (tagliato):

*** DO NOT PASTE *** 
 logName: "projects/PROJECTNAME-11932-01-ops/logs/server-tcp-accesslog-stackdriver.instance.istio-system" 
labels: {
  connection_id: "fbb46826-96fd-476c-ac98-68a9bd6e585d-1517191"   
  destination_app: "redis-cart"   
  destination_ip: "10.16.1.7"   
  destination_name: "redis-cart-6448dcbdcc-cj52v"   
  destination_namespace: "cart"   
  destination_owner: "kubernetes://apis/apps/v1/namespaces/cart/deployments/redis-cart"   
  destination_workload: "redis-cart"   
  source_ip: "10.16.2.8"   
  total_received_bytes: "539"   
  total_sent_bytes: "569" 
...  
 }

Visualizza i log qui:

echo "https://console.cloud.google.com/logs/viewer?cloudshell=false&project=$TF_VAR_ops_project_name"
 

Puoi visualizzare i log del piano di controllo di Istio selezionando Risorsa > Container Kubernetes e ricerca "pilot" -

Qui possiamo vedere il piano di controllo Istio che esegue il push della configurazione del proxy ai proxy sidecar per ogni servizio app di esempio. "CDS" "LDS" e "RDS" rappresentano API Envoy diverse ( ulteriori informazioni).

Oltre ai log di Istio, puoi trovare anche i log dei container e i log dell'infrastruttura o di altri servizi Google Cloud, il tutto nella stessa interfaccia. Ecco alcune query sui log di esempio per GKE. Il visualizzatore log consente anche di creare metriche dai log (ad es. "conteggia ogni errore che corrisponde a una stringa") che possono essere utilizzate in una dashboard o come parte di un avviso. I log possono anche essere trasmessi in flusso ad altri strumenti di analisi come BigQuery.

Alcuni filtri di esempio per il negozio hipster:

resource.type="k8s_container" labels.destination_app="productcatalogservice"

resource.type="k8s_container" resource.labels.namespace_name="cart"

13. Dai un'occhiata alle tracce distribuite.

Ora che stai utilizzando un sistema distribuito, per il debug serve un nuovo strumento: Distributed Tracciamento. Questo strumento ti consente di scoprire statistiche sull'interazione dei servizi (ad esempio scoprire gli eventi lenti periferici nell'immagine seguente), nonché di analizzare campioni non elaborati per esaminare i dettagli di ciò che sta realmente accadendo.

La Visualizzazione cronologia mostra tutte le richieste nel tempo, rappresentate da un grafico in base alla loro latenza o al tempo trascorso tra le richieste iniziali, tramite lo stack Hipster, per rispondere all'utente finale. Più sono alti i punti, più lenta (e meno felice) sarà l'esperienza dell'utente.

Puoi fare clic su un punto per trovare la visualizzazione a cascata dettagliata di tale richiesta. Questa capacità di trovare i dettagli non elaborati di una richiesta specifica (non solo le statistiche aggregate) è fondamentale per comprendere l'interazione tra i servizi, soprattutto quando si cercano interazioni rare ma non ottimali tra i servizi.

La vista a cascata dovrebbe essere familiare a chiunque abbia utilizzato un debugger, ma in questo caso, invece di mostrare il tempo trascorso in diversi processi di una singola applicazione, mostra il tempo trascorso attraverso il nostro mesh, tra servizi, in esecuzione in container separati.

Qui puoi trovare le tue tracce:

echo "https://console.cloud.google.com/traces/overview?cloudshell=false&project=$TF_VAR_ops_project_name"
 

Uno screenshot di esempio dello strumento:

9. Autenticazione TLS reciproca

Obiettivo: proteggere la connettività tra microservizi (AuthN).

• Attiva mTLS a livello di rete mesh
• Verifica mTLS esaminando i log

TESTO DELLA TRACCIA RAPIDA

Se scegli questo metodo, esegui lo script seguente per completare il lab.

${WORKDIR}/asm/fasttrack_scripts/mutual-tls.sh

Istruzioni del lab sul metodo di copia e incolla

Se hai già completato lo script della procedura rapida per questo lab, non utilizzare il metodo di copia e incolla riportato di seguito**.**

Ora che le nostre app sono installate e Observability è configurato, possiamo iniziare a proteggere le connessioni tra i servizi e assicurarci che continui a funzionare.

Ad esempio, nella dashboard di Kiali possiamo vedere che i nostri servizi non utilizzano MTLS (nessuna icona "lucchetto"). Ma il traffico è scorrevole e il sistema funziona bene. La nostra dashboard delle metriche auree di StackDriver ci dà la certezza che tutto funzioni correttamente.

1. Controlla MeshPolicy nei cluster operativi. Tieni presente che mTLS è PERMISSIVE e consente il traffico sia criptato che non mTLS.

kubectl --context $OPS_GKE_1 get MeshPolicy -o json | jq '.items[].spec'
kubectl --context $OPS_GKE_2 get MeshPolicy -o json | jq '.items[].spec'
 

    `Output (do not copy)`

{
  "peers": [
    {
      "mtls": {
        "mode": "PERMISSIVE"
      }
    }
  ]
}

Istio viene configurato su tutti i cluster utilizzando l'operatore Istio, che utilizza la risorsa personalizzata (RP) IstioControlPlane. Configureremo mTLS in tutti i cluster aggiornando la RP IstioControlPlane e aggiornando il k8s-repo. Impostazione globale > mTLS > enabled: true nella CR IstioControlPlane genera le due modifiche seguenti al piano di controllo Istio:

• MeshPolicy è impostato per attivare il mesh mTLS a livello di rete per tutti i servizi in esecuzione in tutti i cluster.
• Viene creata una regola di destinazione per consentire il traffico ISTIO_MUTUAL tra i servizi in esecuzione in tutti i cluster.

2. Applicheremo una patch kustomize alla RP di istioControlPlane per abilitare a livello di cluster mTLS. Copia la patch nella directory pertinente per tutti i cluster e aggiungi una patch kustomize.

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-replicated.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-replicated.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml
 

3. Esegui il commit in k8s-repo.

cd $WORKDIR/k8s-repo
git add . && git commit -am "turn mTLS on"
git push
 

4. Visualizza lo stato del progetto Ops Cloud Build in una scheda aperta in precedenza o facendo clic sul seguente link:

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"

 

Verifica mTLS

5. Controlla di nuovo MeshPolicy nei cluster operativi. Tieni presente che mTLS non è più PERMISSIVE e consentirà solo il traffico mTLS.

kubectl --context $OPS_GKE_1 get MeshPolicy -o json | jq .items[].spec
kubectl --context $OPS_GKE_2 get MeshPolicy -o json | jq .items[].spec
 

Output (non copiare):

{
  "peers": [
    {
      "mtls": {}
    }
  ]
}

6. Descrivi la destinationRule creata dal controller dell'operatore Istio.

kubectl --context $OPS_GKE_1 get DestinationRule default -n istio-system -o json | jq '.spec'
kubectl --context $OPS_GKE_2 get DestinationRule default -n istio-system -o json | jq '.spec'

Output (non copiare):

{
    host: '*.local',
    trafficPolicy: {
      tls: {
        mode: ISTIO_MUTUAL
      }
   }
}

Possiamo anche osservare il passaggio da HTTP a HTTPS nei log.

Possiamo visualizzare questo particolare campo dai log nell'interfaccia utente facendo clic su una voce di log e quindi sul valore del campo da visualizzare. Nel nostro caso, fai clic su "http" accanto a "protocollo:

Si tratta di un ottimo modo per visualizzare il cambiamento.

10. Deployment canary

Obiettivo: implementare una nuova versione del servizio frontend.

• Implementazione del servizio frontend-v2 (nuova versione di produzione) in una regione
• Usa DestinationRules e VirtualServices per indirizzare lentamente il traffico verso frontend-v2
• Verifica la pipeline di deployment di GitOps ispezionando una serie di commit in k8s-repo

TESTO DELLA TRACCIA RAPIDA

Se scegli questo metodo, esegui lo script seguente per completare il lab.

${WORKDIR}/asm/fasttrack_scripts/canary-deployments.sh

Istruzioni del lab sul metodo di copia e incolla

Se hai già completato lo script della procedura rapida per questo lab, non utilizzare il metodo di copia e incolla riportato di seguito**.**

Un deployment canary è un'implementazione progressiva di un nuovo servizio. In un deployment canary, invii una quantità crescente di traffico alla nuova versione, continuando a inviare la percentuale rimanente alla versione attuale. Un modello comune è eseguire un'analisi canary in ogni fase della suddivisione del traffico e confrontare gli "indicatori aurei" della nuova versione (latenza, tasso di errore, saturazione) rispetto a una base di riferimento. Questo contribuisce a evitare interruzioni e a garantire la stabilità della nuova versione "v2" in ogni fase della suddivisione del traffico.

In questa sezione imparerai a utilizzare i criteri di traffico di Cloud Build e Istio per creare un deployment canary di base per una nuova versione del servizio frontend.

Per prima cosa, eseguiremo la pipeline canary nella regione DEV1 (us-west1) e implementeremo il frontend v2 su entrambi i cluster nella regione. In secondo luogo, eseguiremo la pipeline canary nella regione DEV2 (us-central) ed eseguiremo il deployment della versione v2 su entrambi i cluster nella regione. L'esecuzione della pipeline sulle regioni in ordine, anziché in parallelo in tutte le regioni, consente di evitare interruzioni globali causate da una configurazione errata o da bug nell'app v2 stessa.

Nota: attiveremo manualmente la pipeline canary in entrambe le regioni, ma in produzione userai un trigger automatico, ad esempio basato su un nuovo tag immagine Docker inviato a un registro.

1. Da Cloud Shell, definisci alcune variabili env per semplificare l'esecuzione del resto dei comandi.

CANARY_DIR="$WORKDIR/asm/k8s_manifests/prod/app-canary/"
K8S_REPO="$WORKDIR/k8s-repo"
 

2. Esegui lo script repo_setup.sh per copiare i manifest di riferimento in k8s-repo.

$CANARY_DIR/repo-setup.sh 
 

Vengono copiati i seguenti manifest:

• Deployment di frontend-v2
• Patch frontend-v1 (per includere l'etichetta "v1" e un'immagine con un endpoint "/version")
• respy, un piccolo pod che stamperà la distribuzione delle risposte HTTP e ci aiuterà a visualizzare il deployment canary in tempo reale.
• DestinationRule del frontend Istio: suddivide il servizio Kubernetes frontend in due sottoinsiemi, v1 e v2, in base alla "versione" etichetta deployment
• Istio VirtualService frontend: instrada il 100% del traffico al frontend v1. Questa operazione sostituisce il comportamento round-robin predefinito del servizio Kubernetes, che invia immediatamente il 50% di tutto il traffico regionale Dev1 al frontend v2.

3. Esegui il commit delle modifiche in k8s_repo:

cd $K8S_REPO 
git add . && git commit -am "frontend canary setup"
git push
 

4. Visualizza lo stato del progetto Ops Cloud Build in una scheda aperta in precedenza o facendo clic sul seguente link:

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}" 
 

5. Vai a Cloud Build nella console per il progetto OPS1. Attendi il completamento della pipeline Cloud Build, quindi inserisci i pod nello spazio dei nomi frontend in entrambi i cluster DEV1. Dovresti visualizzare quanto segue:

watch -n 1 kubectl --context $DEV1_GKE_1 get pods -n frontend 
 

Output (do not copy)

NAME                           READY   STATUS    RESTARTS   AGE
frontend-578b5c5db6-h9567      2/2     Running   0          59m
frontend-v2-54b74fc75b-fbxhc   2/2     Running   0          2m26s
respy-5f4664b5f6-ff22r         2/2     Running   0          2m26s

Nota: Ctrl-C per uscire dai comandi dell'orologio

Utilizzeremo tmux per dividere la finestra di Cloudshell in due riquadri:

• Nel riquadro inferiore verrà eseguito il comando watch per osservare la distribuzione della risposta HTTP per il servizio frontend.
• Nel riquadro superiore verrà eseguito lo script effettivo della pipeline canary.

6. Esegui il comando per dividere la finestra di Cloud Shell ed eseguire il comando watch nel riquadro inferiore.

RESPY_POD=$(kubectl --context $DEV1_GKE_1 get pod \
-n frontend -l app=respy -o jsonpath='{..metadata.name}')
export TMUX_SESSION=$(tmux display-message -p '#S')
tmux split-window -d -t $TMUX_SESSION:0 -p33 \
-v "export KUBECONFIG=$WORKDIR/asm/gke/kubemesh; \
kubectl --context $DEV1_GKE_1 exec -n frontend -it \
$RESPY_POD -c respy /bin/sh -- -c 'watch -n 1 ./respy \
--u http://frontend:80/version --c 10 --n 500'; sleep 2"
 

Output (non copiare)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 100.0%            |
|          |                   |
+----------+-------------------+

Possiamo vedere che tutto il traffico viene indirizzato al deployment frontend v1, definito nel nuovo VirtualService.

7. Eseguire la pipeline canary nella regione Dev1. Forniamo uno script che aggiorna le percentuali di traffico frontend-v2 in VirtualService (aggiornando i pesi al 20%, 50%, 80% e 100%). Tra un aggiornamento e l'altro, lo script attende il completamento della pipeline di Cloud Build. Esegui lo script di deployment canary per la regione Dev1. Nota: il completamento di questo script richiede circa 10 minuti.

K8S_REPO=$K8S_REPO CANARY_DIR=$CANARY_DIR \
OPS_DIR=$OPS_GKE_1_CLUSTER OPS_CONTEXT=$OPS_GKE_1 \
${CANARY_DIR}/auto-canary.sh
 

Puoi vedere la suddivisione del traffico in tempo reale nella finestra inferiore dove stai eseguendo il comando respy. Ad esempio, alla soglia del 20% :

Output (non copiare)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 79.4%             |
|          |                   |
| v2       | 20.6%             |
|          |                   |
+----------+-------------------+

8. Una volta completata l'implementazione Dev2 per frontend-v2, dovresti vedere un messaggio di operazione riuscita alla fine dello script:

    Output (do not copy) 
   

✅ 100% successfully deployed
🌈 frontend-v2 Canary Complete for gke-asm-1-r1-prod

9. E tutto il traffico frontend da un pod Dev2 deve essere indirizzato a frontend-v2:

    Output (do not copy) 
   

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v2       | 100.0%            |
|          |                   |
+----------+-------------------+

10. Chiudi il riquadro diviso.

tmux respawn-pane -t ${TMUX_SESSION}:0.1 -k 'exit'
 

11. Vai ai repository di codice sorgente Cloud al collegamento generato.

echo https://source.developers.google.com/p/$TF_VAR_ops_project_name/r/k8s-repo

Dovresti vedere un commit separato per ogni percentuale di traffico, con l'impegno più recente in cima all'elenco:

Ora ripeterai la stessa procedura per la regione Dev2. Tieni presente che la regione Dev2 è ancora "bloccata" sulla versione 1. Questo perché nello script repo_setup di riferimento abbiamo eseguito il push di un servizio VirtualService per inviare esplicitamente tutto il traffico alla versione 1. In questo modo, siamo riusciti a eseguire in sicurezza una versione canary regionale su Dev1 e ad assicurarci che funzioni correttamente prima di implementare la nuova versione a livello globale.

12. Esegui il comando per dividere la finestra di Cloud Shell ed eseguire il comando watch nel riquadro inferiore.

RESPY_POD=$(kubectl --context $DEV2_GKE_1 get pod \
-n frontend -l app=respy -o jsonpath='{..metadata.name}')
export TMUX_SESSION=$(tmux display-message -p '#S')
tmux split-window -d -t $TMUX_SESSION:0 -p33 \
-v "export KUBECONFIG=$WORKDIR/asm/gke/kubemesh; \
kubectl --context $DEV2_GKE_1 exec -n frontend -it \
$RESPY_POD -c respy /bin/sh -- -c 'watch -n 1 ./respy \
--u http://frontend:80/version --c 10 --n 500'; sleep 2"
 

Output (non copiare)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 100.0%            |
|          |                   |
+----------+-------------------+

Possiamo vedere che tutto il traffico viene indirizzato al deployment frontend v1, definito nel nuovo VirtualService.

13. Eseguire la pipeline canary nella regione Dev2. Forniamo uno script che aggiorna le percentuali di traffico frontend-v2 in VirtualService (aggiornando i pesi al 20%, 50%, 80% e 100%). Tra un aggiornamento e l'altro, lo script attende il completamento della pipeline di Cloud Build. Esegui lo script di deployment canary per la regione Dev1. Nota: il completamento di questo script richiede circa 10 minuti.

K8S_REPO=$K8S_REPO CANARY_DIR=$CANARY_DIR \
OPS_DIR=$OPS_GKE_2_CLUSTER OPS_CONTEXT=$OPS_GKE_2 \
${CANARY_DIR}/auto-canary.sh
 

Output (non copiare)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 100.0%            |
|          |                   |
+----------+-------------------+

14. Dal pod Respy nella versione Dev2, il traffico proveniente dai pod Dev2 passa progressivamente dalla versione 1 alla 2 del frontend. Una volta completato lo script, dovresti vedere:

Output (non copiare)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v2       | 100.0%            |
|          |                   |
+----------+-------------------+

15. Chiudi il riquadro diviso.

tmux respawn-pane -t ${TMUX_SESSION}:0.1 -k 'exit'

Questa sezione ha introdotto come utilizzare Istio per i deployment canary a livello di regione. In produzione, invece di uno script manuale, potresti attivare automaticamente questo script canary come pipeline di Cloud Build, utilizzando un trigger come il push di una nuova immagine con tag in un Container Registry. Potresti anche voler aggiungere l'analisi canary tra un passaggio e l'altro, analizzando la latenza e il tasso di errore della versione 2 a fronte di una soglia di sicurezza predefinita, prima di inviare più traffico.

11. Criteri di autorizzazione

Obiettivo: configurare RBAC tra microservizi (AuthZ).

• Crea AuthorizationPolicy per NEGARE l'accesso a un microservizio
• Crea AuthorizationPolicy per CONSENTIRE l'accesso specifico a un microservizio

TESTO DELLA TRACCIA RAPIDA

Se scegli questo metodo, esegui lo script seguente per completare il lab.

${WORKDIR}/asm/fasttrack_scripts/authorization-policy.sh

Istruzioni del lab sul metodo di copia e incolla

Se hai già completato lo script della procedura rapida per questo lab, non utilizzare il metodo di copia e incolla riportato di seguito**.**

A differenza di un'applicazione monolitica che potrebbe essere eseguita in un'unica posizione, le app di microservizi distribuite a livello globale effettuano chiamate oltre i confini della rete. Ciò significa più punti di ingresso nelle applicazioni e maggiori opportunità di attacco dannoso. Inoltre, poiché i pod Kubernetes hanno IP temporanei, le regole firewall tradizionali basate su IP non sono più adeguate a proteggere l'accesso tra carichi di lavoro. In un'architettura di microservizi, è necessario un nuovo approccio alla sicurezza. Basandosi sui componenti di base per la sicurezza di Kubernetes come gli account di servizio, Istio fornisce un insieme flessibile di criteri di sicurezza per le tue applicazioni.

I criteri Istio coprono sia l'autenticazione che l'autorizzazione. L'autenticazione verifica l'identità (il server è chi dice di essere?) e l'autorizzazione verifica le autorizzazioni (il client è autorizzato a farlo?). Abbiamo trattato l'autenticazione Istio nella sezione TLS reciproca del modulo 1 (MeshPolicy). In questa sezione imparerai come utilizzare i criteri di autorizzazione Istio per controllare l'accesso a uno dei nostri carichi di lavoro applicativi, currencyservice.

Come prima cosa, eseguiremo il deployment di un AuthorizationPolicy in tutti e quattro i cluster di sviluppo, chiudendo l'accesso a currencyservice e attivando un errore nel frontend. Quindi, consentiremo solo al servizio frontend di accedere al servizio currencyservice.

1. Controlla i contenuti di currency-deny-all.yaml. Questo criterio utilizza i selettori delle etichette del deployment per limitare l'accesso al servizio currencyservice. Nota che non è presente alcun campo spec. Ciò significa che questo criterio negherà ogni accesso al servizio selezionato.

cat $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-deny-all.yaml
 

Output (non copiare)

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "currency-policy"
  namespace: currency
spec:
  selector:
    matchLabels:
      app: currencyservice

2. Copia il criterio della valuta in k8s-repo per i cluster operativi in entrambe le regioni.

cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-deny-all.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization/currency-policy.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization
kustomize edit add resource currency-policy.yaml
cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-deny-all.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization/currency-policy.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization
kustomize edit add resource currency-policy.yaml

3. Esegui il push delle modifiche.

cd $WORKDIR/k8s-repo 
git add . && git commit -am "AuthorizationPolicy - currency: deny all"
git push 

4. Controlla lo stato del progetto Ops Cloud Build in una scheda aperta in precedenza o facendo clic sul link seguente:

echo https://console.cloud.google.com/cloud-build/builds?project=$TF_VAR_ops_project_name 
 

5. Al termine della creazione, prova a raggiungere il frontend hipstershop in un browser al seguente link:

echo "https://frontend.endpoints.$TF_VAR_ops_project_name.cloud.goog" 
 

Dovresti visualizzare un errore di autorizzazione da currencyservice:

6. Analizziamo l'applicazione di questo criterio di autorizzazione da parte del servizio di valute. Innanzitutto, abilita i log a livello di traccia sul proxy Envoy per uno dei pod di valuta, poiché le chiamate di autorizzazione bloccate non vengono registrate per impostazione predefinita.

CURRENCY_POD=$(kubectl --context $DEV1_GKE_2 get pod -n currency | grep currency| awk '{ print $1 }')
kubectl --context $DEV1_GKE_2 exec -it $CURRENCY_POD -n \
currency -c istio-proxy -- curl -X POST \
"http://localhost:15000/logging?level=trace"
 

7. Recupera i log di autorizzazione (RBAC) dal proxy sidecar del servizio di valute. Dovresti visualizzare un messaggio di errore "applicazione negata" che indica che il servizio currencyservice è impostato per bloccare tutte le richieste in entrata.

kubectl --context $DEV1_GKE_2 logs -n currency $CURRENCY_POD \
-c istio-proxy | grep -m 3 rbac
 

Output (non copiare)

[Envoy (Epoch 0)] [2020-01-30 00:45:50.815][22][debug][rbac] [external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:67] checking request: remoteAddress: 10.16.5.15:37310, localAddress: 10.16.3.8:7000, ssl: uriSanPeerCertificate: spiffe://cluster.local/ns/frontend/sa/frontend, subjectPeerCertificate: , headers: ':method', 'POST'
[Envoy (Epoch 0)] [2020-01-30 00:45:50.815][22][debug][rbac] [external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:118] enforced denied
[Envoy (Epoch 0)] [2020-01-30 00:45:50.815][22][debug][http] [external/envoy/source/common/http/conn_manager_impl.cc:1354] [C115][S17310331589050212978] Sending local reply with details rbac_access_denied

8. Ora consentiamo al frontend, ma non agli altri servizi di backend, di accedere a currencyservice. Apri currency-allow-frontend.yaml e controllane i contenuti. Tieni presente che abbiamo aggiunto la seguente regola:

cat ${WORKDIR}/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend.yaml

Output (non copiare)

rules:
 - from:
   - source:
       principals: ["cluster.local/ns/frontend/sa/frontend"]

Qui stiamo autorizzando un source.principal (client) specifico ad accedere al servizio di valuta. Questa risorsa source.principal è definita da un account di servizio Kubernetes. In questo caso, l'account di servizio che stiamo autorizzando è l'account di servizio frontend nello spazio dei nomi frontend.

Nota:quando utilizzi gli account di servizio Kubernetes in Istio AuthorizationPolicy, devi prima abilitare TLS reciprocamente a livello di cluster, come abbiamo fatto nel modulo 1. Questo serve a garantire che le credenziali dell'account di servizio vengano montate nelle richieste.

9. Copia le norme aggiornate relative alla valuta

cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization/currency-policy.yaml
cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization/currency-policy.yaml
 

10. Esegui il push delle modifiche.

cd $WORKDIR/k8s-repo
git add . && git commit -am "AuthorizationPolicy - currency: allow frontend"
git push
 

11. Visualizza lo stato del progetto Ops Cloud Build in una scheda aperta in precedenza o facendo clic sul seguente link:

echo https://console.cloud.google.com/cloud-build/builds?project=$TF_VAR_ops_project_name

12. Al termine della creazione, apri di nuovo il frontend Hipstershop. Questa volta non dovresti vedere errori nella home page perché il frontend è esplicitamente autorizzato ad accedere al servizio attuale.
13. Ora prova a eseguire un pagamento, aggiungendo articoli al carrello e facendo clic su "Effettua ordine". Questa volta, dovresti visualizzare un errore di conversione del prezzo dal servizio di valuta, in quanto abbiamo autorizzato solo il frontend e il servizio di pagamento non è ancora in grado di accedere al servizio di valuta.

14. Infine, consentiamo al servizio di pagamento di accedere alla valuta aggiungendo un'altra regola al nostro AuthorizationPolicy del servizio currencyservice. Tieni presente che stiamo offrendo l'accesso alla valuta solo ai due servizi che devono accedervi: frontend e checkout. Gli altri backend continueranno a essere bloccati.
15. Apri currency-allow-frontend-checkout.yaml e controllane i contenuti. Tieni presente che l'elenco delle regole funziona come valuta OR logico accetterà solo le richieste da carichi di lavoro con uno di questi due account di servizio.

cat ${WORKDIR}/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend-checkout.yaml
 

Output (non copiare)

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "currency-policy"
  namespace: currency
spec:
  selector:
    matchLabels:
      app: currencyservice
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/frontend/sa/frontend"]
  - from:
    - source:
        principals: ["cluster.local/ns/checkout/sa/checkout"]

16. Copia il criterio di autorizzazione finale in k8s-repo.

cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend-checkout.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization/currency-policy.yaml
cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend-checkout.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization/currency-policy.yaml
 

17. Esegui il push delle modifiche

cd $WORKDIR/k8s-repo 
git add . && git commit -am "AuthorizationPolicy - currency: allow frontend and checkout"
git push
 

18. Visualizza lo stato del progetto Ops Cloud Build in una scheda aperta in precedenza o facendo clic sul seguente link:

echo https://console.cloud.google.com/cloud-build/builds?project=$TF_VAR_ops_project_name
 

19. Al termine della build, prova a eseguire un pagamento: dovrebbe funzionare.

Questa sezione illustra come utilizzare i criteri di autorizzazione Istio per applicare un controllo granulare degli accessi a livello di servizio. In produzione, potresti creare un criterio AuthorizationPolicy per ogni servizio e, ad esempio, utilizzare un criterio allow-all per consentire a tutti i carichi di lavoro nello stesso spazio dei nomi di accedere l'uno all'altro.

12. Scalabilità dell'infrastruttura

Obiettivo: scalare l'infrastruttura aggiungendo nuova regione, progetto e cluster.

• Clona il repository infrastructure
• Aggiorna i file Terraform per creare nuove risorse
• Due subnet nella nuova regione (una per il progetto operativo e una per il nuovo progetto)
• Nuovo cluster operativo in una nuova regione (nella nuova subnet)
• Nuovo piano di controllo Istio per la nuova regione
• 2 cluster di app nel nuovo progetto nella nuova regione
• Esegui il commit in infrastructure repository
• Verifica installazione

TESTO DELLA TRACCIA RAPIDA

Se scegli questo metodo, esegui lo script seguente per completare il lab.

${WORKDIR}/asm/fasttrack_scripts/infrastructure-scaling.sh

Istruzioni del lab sul metodo di copia e incolla

Se hai già completato lo script della procedura rapida per questo lab, non utilizzare il metodo di copia e incolla riportato di seguito**.**

Esistono diversi modi per scalare una piattaforma. Puoi aumentare il calcolo aggiungendo nodi ai cluster esistenti. Puoi aggiungere altri cluster in una regione. In alternativa, puoi aggiungere altre regioni alla piattaforma. La decisione su quale aspetto della piattaforma scalare dipende dai requisiti. Ad esempio, se hai cluster in tutte e tre le zone di una regione, potrebbe essere sufficiente aggiungere altri nodi (o pool di nodi) al cluster esistente. Tuttavia, se hai cluster in due o tre zone in una singola regione, l'aggiunta di un nuovo cluster nella terza zona ti dà scalabilità e un dominio di errore aggiuntivo (ovvero una nuova zona). Un altro motivo per aggiungere un nuovo cluster in una regione potrebbe essere la necessità di creare un cluster con singolo tenant, per motivi normativi o di conformità (ad esempio PCI o un cluster di database che ospita informazioni PII). Con l'espansione della tua attività e dei tuoi servizi, l'aggiunta di nuove regioni diventa inevitabile per fornire servizi più vicini ai clienti.

La piattaforma attuale è composta da due regioni e cluster in due zone per regione. Puoi scalare la piattaforma in due modi:

• In verticale: all'interno di ogni regione aggiungendo più risorse di calcolo. Per farlo, devi aggiungere più nodi (o pool di nodi) ai cluster esistenti o aggiungere nuovi cluster all'interno della regione. Questa operazione viene eseguita tramite il repository infrastructure. Il percorso più semplice consiste nell'aggiungere nodi ai cluster esistenti. Non è necessaria alcuna configurazione aggiuntiva. L'aggiunta di nuovi cluster può richiedere subnet aggiuntive (e intervalli secondari), l'aggiunta di regole firewall appropriate, l'aggiunta di nuovi cluster al piano di controllo del mesh di servizi ASM/Istio a livello di regione e il deployment di risorse delle applicazioni nei nuovi cluster.
• Orizzontalmente: aggiungendo altre regioni. La piattaforma attuale fornisce un modello regionale. Si tratta di un cluster di operazioni regionali in cui risiede il controllo ASM/Istio e di due (o più) cluster di applicazioni a livello di zona in cui viene eseguito il deployment delle risorse dell'applicazione.

In questo workshop, scalerai la piattaforma "orizzontalmente" poiché include anche i passaggi verticali del caso d'uso. Per scalare la piattaforma in orizzontale, aggiungi una nuova regione (r3) alla piattaforma, devi aggiungere le seguenti risorse:

1. Le subnet nel progetto host hanno condiviso il VPC nella regione r3 per le nuove operazioni e i cluster di applicazioni.
2. Cluster di operazioni regionali nella regione r3 in cui si trova il piano di controllo ASM/Istio.
3. Due cluster di applicazioni a livello di zona in due zone nella regione r3.
4. Esegui l'aggiornamento a k8s-repo:
5. Esegui il deployment delle risorse del piano di controllo ASM/Istio nel cluster delle operazioni nella regione r3.
6. Esegui il deployment delle risorse del piano di controllo condivise di ASM/Istio nei cluster dell'app nella regione r3.
7. Anche se non è necessario creare un nuovo progetto, i passaggi nel workshop mostrano l'aggiunta di un nuovo progetto dev3 per coprire il caso d'uso di aggiunta di un nuovo team alla piattaforma.

Il repository dell'infrastruttura viene utilizzato per aggiungere nuove risorse indicate sopra.

1. In Cloud Shell, vai a WORKDIR e clona il repository infrastructure.

mkdir -p $WORKDIR/infra-repo
cd $WORKDIR/infra-repo
git init && git remote add origin https://source.developers.google.com/p/${TF_ADMIN}/r/infrastructure
git config --local user.email ${MY_USER}
git config --local user.name "infra repo user"
git config --local credential.'https://source.developers.google.com'.helper gcloud.sh
git pull origin master

2. Clona il ramo del repository di origine del workshop add-proj nella directory add-proj-repo.

cd $WORKDIR
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git add-proj-repo -b add-proj

 

3. Copia i file dal ramo add-proj nel repository del workshop di origine. Il ramo add-proj contiene le modifiche per questa sezione.

cp -r $WORKDIR/add-proj-repo/infrastructure/* $WORKDIR/infra-repo/
 

4. Sostituisci la directory infrastructure nella directory del repository add-proj con un collegamento simbolico alla directory infra-repo per consentire l'esecuzione degli script sul ramo.

rm -rf $WORKDIR/add-proj-repo/infrastructure
ln -s $WORKDIR/infra-repo $WORKDIR/add-proj-repo/infrastructure
 

5. Esegui lo script add-project.sh per copiare gli stati e le variabili condivisi nella nuova struttura di directory del progetto.

$WORKDIR/add-proj-repo/scripts/add-project.sh app3 $WORKDIR/asm $WORKDIR/infra-repo

6. Esegui il commit delle modifiche ed eseguine il push per creare un nuovo progetto

cd $WORKDIR/infra-repo
git add .
git status
git commit -m "add new project" && git push origin master
 

7. Il commit attiva il repository infrastructure per il deployment dell'infrastruttura con le nuove risorse. Visualizza l'avanzamento di Cloud Build facendo clic sull'output del link seguente e andando alla build più recente in alto.

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_ADMIN}"
 

Questo passaggio richiede 25-30 minuti. È il momento ideale per una pausa caffè.

L'ultimo passaggio di infrastructure Cloud Build crea nuove risorse Kubernetes in k8s-repo. Questo attiva Cloud Build in k8s-repo (nel progetto Ops). Le nuove risorse Kubernetes riguardano i tre nuovi cluster aggiunti nel passaggio precedente. Le risorse del piano di controllo ASM/Istio e del piano di controllo condivise vengono aggiunte ai nuovi cluster con Cloud Build k8s-repo.

8. Al termine dell'infrastruttura Cloud Build, vai all'ultima esecuzione di Cloud Build k8s-repo facendo clic sul seguente link di output.

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
 

9. Esegui lo script seguente per aggiungere i nuovi cluster ai file vars e kubeconfig.

$WORKDIR/add-proj-repo/scripts/setup-gke-vars-kubeconfig-add-proj.sh $WORKDIR/asm
 

10. Modifica la variabile KUBECONFIG in modo che punti al nuovo file kubeconfig.

source $WORKDIR/asm/vars/vars.sh
export KUBECONFIG=$WORKDIR/asm/gke/kubemesh
 

11. Elenca i contesti del cluster. Dovresti vedere otto cluster.

kubectl config view -ojson | jq -r '.clusters[].name'
 

    `Output (do not copy)`

gke_user001-200204-05-dev1-49tqc4_us-west1-a_gke-1-apps-r1a-prod
gke_user001-200204-05-dev1-49tqc4_us-west1-b_gke-2-apps-r1b-prod
gke_user001-200204-05-dev2-49tqc4_us-central1-a_gke-3-apps-r2a-prod
gke_user001-200204-05-dev2-49tqc4_us-central1-b_gke-4-apps-r2b-prod
gke_user001-200204-05-dev3-49tqc4_us-east1-b_gke-5-apps-r3b-prod
gke_user001-200204-05-dev3-49tqc4_us-east1-c_gke-6-apps-r3c-prod
gke_user001-200204-05-ops-49tqc4_us-central1_gke-asm-2-r2-prod
gke_user001-200204-05-ops-49tqc4_us-east1_gke-asm-3-r3-prod
gke_user001-200204-05-ops-49tqc4_us-west1_gke-asm-1-r1-prod

Verifica l'installazione di Istio

12. Assicurati che Istio sia installato sul nuovo cluster delle operazioni controllando che tutti i pod siano in esecuzione e che i job siano stati completati.

kubectl --context $OPS_GKE_3 get pods -n istio-system
 

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
grafana-5f798469fd-72g6w                  1/1     Running   0          5h12m
istio-citadel-7d8595845-hmmvj             1/1     Running   0          5h12m
istio-egressgateway-779b87c464-rw8bg      1/1     Running   0          5h12m
istio-galley-844ddfc788-zzpkl             2/2     Running   0          5h12m
istio-ingressgateway-59ccd6574b-xfj98     1/1     Running   0          5h12m
istio-pilot-7c8989f5cf-5plsg              2/2     Running   0          5h12m
istio-policy-6674bc7678-2shrk             2/2     Running   3          5h12m
istio-sidecar-injector-7795bb5888-kbl5p   1/1     Running   0          5h12m
istio-telemetry-5fd7cbbb47-c4q7b          2/2     Running   2          5h12m
istio-tracing-cd67ddf8-2qwkd              1/1     Running   0          5h12m
istiocoredns-5f7546c6f4-qhj9k             2/2     Running   0          5h12m
kiali-7964898d8c-l74ww                    1/1     Running   0          5h12m
prometheus-586d4445c7-x9ln6               1/1     Running   0          5h12m

13. Assicurati che Istio sia installato su entrambi i cluster dev3. Nei cluster dev3 vengono eseguiti solo Citadel, sidecar-injector e coredns. Condividono un piano di controllo Istio in esecuzione nel cluster ops-3.

kubectl --context $DEV3_GKE_1 get pods -n istio-system
kubectl --context $DEV3_GKE_2 get pods -n istio-system
 

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
istio-citadel-568747d88-4lj9b             1/1     Running   0          66s
istio-sidecar-injector-759bf6b4bc-ks5br   1/1     Running   0          66s
istiocoredns-5f7546c6f4-qbsqm             2/2     Running   0          78s

Verifica il rilevamento dei servizi per i piani di controllo condivisi

14. Verifica che il deployment dei secret sia stato eseguito in tutti i cluster operativi per tutti e sei i cluster delle applicazioni.

kubectl --context $OPS_GKE_1 get secrets -l istio/multiCluster=true -n istio-system
kubectl --context $OPS_GKE_2 get secrets -l istio/multiCluster=true -n istio-system
kubectl --context $OPS_GKE_3 get secrets -l istio/multiCluster=true -n istio-system
 

    `Output (do not copy)`

NAME                  TYPE     DATA   AGE
gke-1-apps-r1a-prod   Opaque   1      14h
gke-2-apps-r1b-prod   Opaque   1      14h
gke-3-apps-r2a-prod   Opaque   1      14h
gke-4-apps-r2b-prod   Opaque   1      14h
gke-5-apps-r3b-prod   Opaque   1      5h12m
gke-6-apps-r3c-prod   Opaque   1      5h12m

13. Interruttore di sicurezza

Obiettivo: implementare un interruttore di sicurezza per il servizio di spedizione.

• Crea un DestinationRule per il servizio shipping per implementare un interruttore di sicurezza
• Usa fortio (un'utilità per la generazione di carichi) per convalidare l'interruttore di sicurezza per il servizio shipping con l'intervento forzato del circuito

Istruzioni per il Fast Track Script Lab

Fast Track Script Lab sarà disponibile a breve.

Istruzioni del lab sul metodo di copia e incolla

Ora che abbiamo appreso alcune strategie di base per il monitoraggio e la risoluzione dei problemi per i servizi abilitati per Istio, diamo un'occhiata a come Istio aiuta a migliorare la resilienza dei tuoi servizi, riducendo la quantità di operazioni di risoluzione dei problemi da eseguire in primo luogo.

Un'architettura di microservizi introduce il rischio di errori a cascata, in cui l'errore di un servizio può propagarsi alle sue dipendenze e alle dipendenze di queste dipendenze, causando un "effetto a onde" che potrebbe interessare gli utenti finali. Istio fornisce un criterio del traffico per interruttore di sicurezza per aiutarti a isolare i servizi, proteggendo quelli downstream (lato client) dall'attesa dei servizi non funzionanti e proteggendo quelli upstream (lato server) da un flusso improvviso di traffico downstream quando tornano online. In generale, l'uso di interruttori di sicurezza può aiutarti a evitare che tutti i tuoi servizi non vadano a buon fine sugli SLO a causa di un solo servizio di backend in attesa.

Il pattern dell'interruttore di sicurezza è chiamato per un interruttore elettrico che può "scattare" quando passa troppa elettricità, proteggendo i dispositivi dal sovraccarico. In una configurazione di Istio, significa che Envoy è l'interruttore di sicurezza, che tiene traccia del numero di richieste in attesa per un servizio. In questo stato chiuso predefinito, le richieste passano per Envoy senza interruzioni.

Tuttavia, quando il numero di richieste in attesa supera la soglia definita, l'interruttore di sicurezza interviene (si apre) e Envoy restituisce immediatamente un errore. In questo modo il server ha un guasto veloce per il client e il codice dell'applicazione del server non riceverà la richiesta del client in caso di sovraccarico.

Dopodiché, dopo il timeout definito, Envoy passa a uno stato semiaperto, dove il server può iniziare a ricevere di nuovo le richieste in prova e, se riesce a rispondere correttamente alle richieste, l'interruttore di sicurezza si chiude di nuovo e le richieste al server iniziano di nuovo a scorrere.

Questo diagramma riassume il pattern con interruttore di sicurezza Istio. I rettangoli blu rappresentano Envoy, il cerchio blu rappresenta il client e i cerchi bianchi rappresentano il contenitore del server:

Puoi definire i criteri degli interruttori di sicurezza utilizzando Istio destinationRules. In questa sezione, applicheremo la seguente norma per imporre un interruttore di sicurezza per il servizio di spedizione:

Output (do not copy)

apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
  name: "shippingservice-shipping-destrule"
  namespace: "shipping"
spec:
  host: "shippingservice.shipping.svc.cluster.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutiveErrors: 1
      interval: 1s
      baseEjectionTime: 10s
      maxEjectionPercent: 100

Qui sono presenti due campi destinationRule. connectionPool definisce il numero di connessioni consentite da questo servizio. Il campo outlierDetection consente di configurare il modo in cui Envoy determinerà la soglia alla quale aprire l'interruttore di sicurezza. Qui, ogni secondo (intervallo), Envoy conterà il numero di errori ricevuti dal contenitore del server. Se viene superata la soglia consecutiveErrors, l'interruttore di sicurezza Envoy si apre e il 100% dei pod del catalogo dei prodotti viene protetto per 10 secondi dalle richieste dei nuovi client. Quando l'interruttore di sicurezza Envoy è aperto (ossia attivo), i client ricevono errori 503 (Servizio non disponibile). Vediamo come funziona.

1. Imposta le variabili di ambiente per k8s-repo e asm dir in modo da semplificare i comandi.

export K8S_REPO="${WORKDIR}/k8s-repo"
export ASM="${WORKDIR}/asm" 
 

2. Aggiorna k8s-repo

cd $WORKDIR/k8s-repo
git pull
cd $WORKDIR

3. Aggiorna il servizio di spedizione destinationRule su entrambi i cluster Ops.

cp $ASM/k8s_manifests/prod/istio-networking/app-shipping-circuit-breaker.yaml ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml
cp $ASM/k8s_manifests/prod/istio-networking/app-shipping-circuit-breaker.yaml ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml

cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit add resource app-shipping-circuit-breaker.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit add resource app-shipping-circuit-breaker.yaml
 

4. Copia un pod del generatore di carico Fortio nel cluster GKE_1 nella regione Dev1. Questo è il pod client che utilizzeremo per eseguire il "trip" l'interruttore di sicurezza per il servizio di spedizione.

cp $ASM/k8s_manifests/prod/app/deployments/app-fortio.yaml ${K8S_REPO}/${DEV1_GKE_1_CLUSTER}/app/deployments/
cd ${K8S_REPO}/${DEV1_GKE_1_CLUSTER}/app/deployments; kustomize edit add resource app-fortio.yaml
 

5. Esegui il commit delle modifiche.

cd $K8S_REPO 
git add . && git commit -am "Circuit Breaker: shippingservice"
git push
cd $ASM
 

6. Attendi il completamento di Cloud Build.
7. Tornando a Cloud Shell, utilizza il pod fortio per inviare traffico gRPC a shippingservice con 1 connessione simultanea, 1000 richieste in totale. Questo non attiverà l'interruttore di sicurezza perché non abbiamo ancora superato le impostazioni di connectionPool.

FORTIO_POD=$(kubectl --context ${DEV1_GKE_1} get pod -n shipping | grep fortio | awk '{ print $1 }')

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c fortio /usr/bin/fortio -- load -grpc -c 1 -n 1000 -qps 0 shippingservice.shipping.svc.cluster.local:50051 
 

Output (non copiare)

Health SERVING : 1000
All done 1000 calls (plus 0 warmup) 4.968 ms avg, 201.2 qps

8. Ora esegui di nuovo fortio, aumentando il numero di connessioni simultanee a 2, ma mantenendo costante il numero di richieste. Dovremmo vedere che fino a due terzi delle richieste restituiscono un "overflow" perché è stato scattato l'interruttore di sicurezza: nel criterio che abbiamo definito, è consentita una sola connessione in parallelo in un intervallo di 1 secondo.

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c fortio /usr/bin/fortio -- load -grpc -c 2 -n 1000 -qps 0 shippingservice.shipping.svc.cluster.local:50051 
 

Output (non copiare)

18:46:16 W grpcrunner.go:107> Error making grpc call: rpc error: code = Unavailable desc = upstream connect error or disconnect/reset before headers. reset reason: overflow
...

Health ERROR : 625
Health SERVING : 375
All done 1000 calls (plus 0 warmup) 12.118 ms avg, 96.1 qps

9. Envoy tiene traccia del numero di connessioni interrotte quando l'interruttore di sicurezza è attivo con la metrica upstream_rq_pending_overflow. Troviamo questo nel pod fortio:

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c istio-proxy  -- sh -c 'curl localhost:15000/stats' | grep shipping | grep pending
 

Output (non copiare)

cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.circuit_breakers.default.rq_pending_open: 0
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.circuit_breakers.high.rq_pending_open: 0
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_active: 0
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_failure_eject: 9
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_overflow: 565
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_total: 1433

10. Esegui la pulizia rimuovendo il criterio dell'interruttore di sicurezza da entrambe le regioni.

kubectl --context ${OPS_GKE_1} delete destinationrule shippingservice-circuit-breaker -n shipping 
rm ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml
cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit remove resource app-shipping-circuit-breaker.yaml
 

kubectl --context ${OPS_GKE_2} delete destinationrule shippingservice-circuit-breaker -n shipping 
rm ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit remove resource app-shipping-circuit-breaker.yaml
cd $K8S_REPO; git add .; git commit -m "Circuit Breaker: cleanup"; git push origin master
 

Questa sezione ha illustrato come configurare un criterio per un singolo interruttore di sicurezza per un servizio. Una best practice consiste nel configurare un interruttore di sicurezza per qualsiasi servizio upstream (backend) che potrebbe bloccarsi. L'applicazione dei criteri per gli interruttori di sicurezza Istio aiuta a isolare i microservizi, a creare una tolleranza di errore nell'architettura e a ridurre il rischio di errori a cascata sotto carico elevato.

14. Fault Injection

Obiettivo: testare la resilienza del servizio di suggerimenti introducendo ritardi (prima che venga trasferito in produzione).

• Crea un VirtualService per il servizio recommendation per introdurre un ritardo di 5 secondi
• Testa il ritardo utilizzando il generatore di carico fortio
• Rimuovi il ritardo in VirtualService ed esegui la convalida

Istruzioni per il Fast Track Script Lab

Fast Track Script Lab sarà disponibile a breve.

Istruzioni del lab sul metodo di copia e incolla

L'aggiunta di criteri per l'interruttore di sicurezza ai servizi è un modo per creare resilienza rispetto ai servizi in produzione. Tuttavia, l'interruzione di un circuito provoca guasti, potenzialmente errori rivolti agli utenti, il che non è l'ideale. Per prevenire questi casi di errore e prevedere meglio il modo in cui i servizi downstream potrebbero rispondere quando i backend restituiscono errori, puoi adottare i test del caos in un ambiente di gestione temporanea. Il test del caos consiste nel danneggiare deliberatamente i servizi, allo scopo di analizzare i punti deboli del sistema e migliorare la tolleranza agli errori. Puoi anche utilizzare i test caos per identificare modi per mitigare gli errori rivolti agli utenti in caso di errore dei backend, ad esempio visualizzando un risultato memorizzato nella cache in un frontend.

L'utilizzo di Istio per fault injection è utile perché puoi usare le immagini di release di produzione e aggiungere l'errore a livello di rete, invece di modificare il codice sorgente. In produzione, potresti utilizzare uno strumento di test del caos completo per testare la resilienza a livello di Kubernetes/compute oltre che a livello di rete.

Puoi utilizzare Istio per i test sul caos applicando un servizio VirtualService con l'errore "fault" . Istio supporta due tipi di errori: degli errori di ritardo (inject un timeout) e degli errori di interruzione (inserisci errori HTTP). In questo esempio, inseriremo un errore di ritardo di 5 secondi nel servizio suggerimenti. Ma questa volta invece di usare un interruttore di sicurezza per "fail fast" rispetto a questo servizio in attesa, costringeremo i servizi downstream a sopportare il timeout completo.

11. Vai alla directory di fault injection.

export K8S_REPO="${WORKDIR}/k8s-repo"
export ASM="${WORKDIR}/asm/" 
cd $ASM
 

12. Apri k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml per esaminarne i contenuti. Tieni presente che Istio ha un'opzione per inserire l'errore in una percentuale delle richieste: qui introdurremo un timeout in tutte le richieste di Recommendationsservice.

Output (non copiare)

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: recommendation-delay-fault
spec:
  hosts:
  - recommendationservice.recommendation.svc.cluster.local
  http:
  - route:
    - destination:
        host: recommendationservice.recommendation.svc.cluster.local
    fault:
      delay:
        percentage:
          value: 100
        fixedDelay: 5s

13. Copia il componente VirtualService in k8s_repo. Inseriremo l'errore a livello globale in entrambe le regioni.

cp $ASM/k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit add resource app-recommendation-vs-fault.yaml

cp $ASM/k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit add resource app-recommendation-vs-fault.yaml
 

14. Esegui il push delle modifiche

cd $K8S_REPO 
git add . && git commit -am "Fault Injection: recommendationservice"
git push
cd $ASM
 

15. Attendi il completamento di Cloud Build.
16. Esegui il deployment nel pod fortio di cui è stato eseguito il deployment nella sezione dell'interruttore di sicurezza e invia del traffico a Recommendationsservice.

FORTIO_POD=$(kubectl --context ${DEV1_GKE_1} get pod -n shipping | grep fortio | awk '{ print $1 }')

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c fortio /usr/bin/fortio -- load -grpc -c 100 -n 100 -qps 0 recommendationservice.recommendation.svc.cluster.local:8080
 

    Once the fortio command is complete, you should see responses averaging 5s:

Output (non copiare)

Ended after 5.181367359s : 100 calls. qps=19.3
Aggregated Function Time : count 100 avg 5.0996506 +/- 0.03831 min 5.040237641 max 5.177559818 sum 509.965055

17. Un altro modo per vedere il guasto che abbiamo inserito in azione è aprire il frontend in un browser web e fare clic su un prodotto. Il caricamento di una pagina di prodotto dovrebbe richiedere 5 secondi in più, poiché recupera i consigli visualizzati in fondo alla pagina.
18. Esegui la pulizia rimuovendo il servizio di fault injection da entrambi i cluster Ops.

kubectl --context ${OPS_GKE_1} delete virtualservice recommendation-delay-fault -n recommendation 
rm ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit remove resource app-recommendation-vs-fault.yaml

kubectl --context ${OPS_GKE_2} delete virtualservice recommendation-delay-fault -n recommendation 
rm ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit remove resource app-recommendation-vs-fault.yaml
 

19. Esegui il push delle modifiche:

cd $K8S_REPO 
git add . && git commit -am "Fault Injection cleanup / restore"
git push
cd $ASM
 

15. Monitoraggio del piano di controllo Istio

ASM installa quattro importanti componenti del piano di controllo: Pilota, Mixer, Galleria e Citadel. Ciascuno invia le proprie metriche di monitoraggio pertinenti a Prometheus e ASM include dashboard Grafana che consentono agli operatori di visualizzare questi dati di monitoraggio e valutare l'integrità e le prestazioni del piano di controllo.

Visualizzazione delle dashboard

20. Esegui il port forwarding del servizio Grafana installato con Istio

kubectl --context ${OPS_GKE_1} -n istio-system port-forward svc/grafana 3000:3000 >> /dev/null
 

21. Apri Grafana nel browser.
22. Fai clic su "Anteprima web" nell'angolo in alto a destra della finestra di Cloud Shell
23. Fai clic su Anteprima sulla porta 3000. Nota: se la porta non è 3000, fai clic su Modifica porta e seleziona la porta 3000.
24. Nel browser si aprirà una scheda con un URL simile a " BASE_URL/?orgId=1&authuser=0&environment_id=default"
25. Visualizza le dashboard disponibili
26. Modifica l'URL in " BASE_URL/dashboard"
27. Fai clic su "istio" cartella per visualizzare le dashboard disponibili
28. Fai clic su una di queste dashboard per visualizzare il rendimento del componente in questione. Nelle sezioni seguenti esamineremo le metriche importanti per ogni componente.

Monitoraggio pilota

Progetto pilota è il componente del piano di controllo che distribuisce la configurazione di networking e criteri al piano dati (i proxy Envoy). Il progetto pilota tende a scalare in base al numero di carichi di lavoro e di deployment, ma non necessariamente alla quantità di traffico verso questi carichi di lavoro. Un progetto pilota in stato non integro può:

• consumano più risorse del necessario (CPU e/o RAM)
• causano ritardi nell'invio di informazioni di configurazione aggiornate a Envoy

Nota: se il progetto pilota non è attivo o se si verificano ritardi, i carichi di lavoro gestiscono comunque il traffico.

23. Passa a " BASE_URL/dashboard/db/istio-pilot-dashboard" nel browser per visualizzare le metriche del progetto pilota.

Metriche monitorate importanti

Utilizzo delle risorse

Utilizza la pagina Prestazioni e scalabilità di Istio come guida per i valori di utilizzo accettabili. Contatta l'assistenza Google Cloud se riscontri un utilizzo delle risorse notevolmente maggiore rispetto a questo.

Informazioni push sul progetto pilota

Questa sezione monitora i push della configurazione dei piloti ai proxy Envoy.

• Invii pilota mostra il tipo di configurazione trasferita in un dato momento.
• ADS Monitoring mostra il numero di servizi virtuali, servizi ed endpoint connessi nel sistema.
• I cluster senza endpoint noti mostrano gli endpoint che sono stati configurati, ma non hanno istanze in esecuzione (che potrebbe indicare servizi esterni, come *.googleapis.com).
• La scheda Errori del programma pilota mostra il numero di errori riscontrati nel tempo.
• Conflitti mostra il numero di conflitti che sono configurazioni ambigue sui listener.

Se sono presenti errori o conflitti, significa che la tua configurazione di uno o più servizi non è valida o è incoerente. Per informazioni, consulta Risoluzione dei problemi del piano dati.

Informazioni sull'inviato

Questa sezione contiene informazioni sui proxy Envoy che contattano il piano di controllo. Contatta l'assistenza Google Cloud se si verificano ripetuti errori di connessione XDS.

Mixer di monitoraggio

Mixer è il componente che incana la telemetria dai proxy Envoy ai backend di telemetria (in genere Prometheus, Stackdriver e così via). In questa capacità, non si trova nel piano dati. Il deployment viene eseguito come due job Kubernetes (chiamati Mixer) distribuiti con due diversi nomi di servizio (istio-telemetry e istio-policy).

Mixer può essere utilizzato anche per l'integrazione con i sistemi di criteri. In questa capacità, Mixer interessa invece il piano dati, poiché i criteri vengono controllati per Mixer che non riesce a bloccare l'accesso ai tuoi servizi.

Il mixer tende a crescere in base al volume di traffico.

24. Passa a " BASE_URL/dashboard/db/istio-mixer-dashboard" nel browser per visualizzare le metriche del Mixer.

Importanti metriche monitorate

Utilizzo delle risorse

Utilizza la pagina Prestazioni e scalabilità di Istio come guida per i valori di utilizzo accettabili. Contatta l'assistenza Google Cloud se riscontri un utilizzo delle risorse notevolmente maggiore rispetto a questo.

Panoramica del mixer

• Durata della risposta è una metrica importante. Anche se i report sulla telemetria di Mixer non si trovano nel percorso dei dati, se queste latenze sono elevate rallenterà sicuramente le prestazioni del proxy sidecar. Il 90° percentile deve essere espresso in millisecondi a singola cifra e il 99° percentile deve essere inferiore a 100 ms.

• Durata di invio dell'adattatore indica la latenza che il Mixer sta riscontrando negli adattatori di chiamata (attraverso i quali invia informazioni ai sistemi di telemetria e logging). In questo caso, la latenza elevata influisce sulle prestazioni sul mesh. Anche in questo caso, le latenze p90 dovrebbero essere inferiori a 10 ms.

Galleria di monitoraggio

La galleria è il componente di convalida, importazione, elaborazione e distribuzione della configurazione di Istio. Trasmette la configurazione dal server API di Kubernetes al progetto pilota. Come il progetto pilota, tende a scalare in base al numero di servizi ed endpoint nel sistema.

25. Passa a " BASE_URL/dashboard/db/istio-galley-dashboard" nel browser per visualizzare le metriche della galleria.

Importanti metriche monitorate

Convalida delle risorse

La metrica più importante da seguire, che indica il numero di risorse di vari tipi, come regole di destinazione, gateway e voci di servizio, che superano la convalida o non superano la convalida.

Client connessi

Indica quanti client sono connessi a Galley. in genere è 3 (pilota, istio-telemetria, istio-policy) e verrà scalato man mano che i componenti verranno scalati.

16. Risoluzione dei problemi di Istio

Risoluzione dei problemi del piano dati

Se la dashboard del progetto pilota indica che esistono problemi di configurazione, devi esaminare i log di PIlot o utilizzare istioctl per individuare eventuali problemi di configurazione.

Per esaminare i log del progetto pilota, esegui il rilevamento del comando kubectl -n istio-system logs istio-pilot-69db46c598-45m44, sostituendo istio-pilot-... con l'identificatore del pod per l'istanza del progetto pilota di cui vuoi risolvere i problemi.

Nel log risultante, cerca un messaggio Stato push. Ad esempio:

2019-11-07T01:16:20.451967Z        info        ads        Push Status: {
    "ProxyStatus": {
        "pilot_conflict_outbound_listener_tcp_over_current_tcp": {
            "0.0.0.0:443": {
                "proxy": "cartservice-7555f749f-k44dg.hipster",
                "message": "Listener=0.0.0.0:443 AcceptedTCP=accounts.google.com,*.googleapis.com RejectedTCP=edition.cnn.com TCPServices=2"
            }
        },
        "pilot_duplicate_envoy_clusters": {
            "outbound|15443|httpbin|istio-egressgateway.istio-system.svc.cluster.local": {
                "proxy": "sleep-6c66c7765d-9r85f.default",
                "message": "Duplicate cluster outbound|15443|httpbin|istio-egressgateway.istio-system.svc.cluster.local found while pushing CDS"
            },
            "outbound|443|httpbin|istio-egressgateway.istio-system.svc.cluster.local": {
                "proxy": "sleep-6c66c7765d-9r85f.default",
                "message": "Duplicate cluster outbound|443|httpbin|istio-egressgateway.istio-system.svc.cluster.local found while pushing CDS"
            },
            "outbound|80|httpbin|istio-egressgateway.istio-system.svc.cluster.local": {
                "proxy": "sleep-6c66c7765d-9r85f.default",
                "message": "Duplicate cluster outbound|80|httpbin|istio-egressgateway.istio-system.svc.cluster.local found while pushing CDS"
            }
        },
        "pilot_eds_no_instances": {
            "outbound_.80_._.frontend-external.hipster.svc.cluster.local": {},
            "outbound|443||*.googleapis.com": {},
            "outbound|443||accounts.google.com": {},
            "outbound|443||metadata.google.internal": {},
            "outbound|80||*.googleapis.com": {},
            "outbound|80||accounts.google.com": {},
            "outbound|80||frontend-external.hipster.svc.cluster.local": {},
            "outbound|80||metadata.google.internal": {}
        },
        "pilot_no_ip": {
            "loadgenerator-778c8489d6-bc65d.hipster": {
                "proxy": "loadgenerator-778c8489d6-bc65d.hipster"
            }
        }
    },
    "Version": "o1HFhx32U4s="
}

Lo stato del push indicherà gli eventuali problemi che si sono verificati durante il tentativo di eseguire il push della configurazione ai proxy Envoy; in questo caso, vediamo diversi "Cluster duplicati" che indicano destinazioni upstream duplicate.

Per assistenza nella diagnosi dei problemi, contatta l'Assistenza Google Cloud in caso di problemi.

Individuazione degli errori di configurazione

Per utilizzare istioctl per analizzare la configurazione, esegui istioctl experimental analyze -k --context $OPS_GKE_1. Verrà eseguita un'analisi della configurazione nel sistema e verranno indicati eventuali problemi insieme alle modifiche suggerite. Consulta la documentazione per un elenco completo degli errori di configurazione che questo comando è in grado di rilevare.

17. Esegui la pulizia

I seguenti passaggi vengono eseguiti da un amministratore al termine del workshop.

Un amministratore esegue lo script cleanup_workshop.sh per eliminare le risorse create dallo script bootstrap_workshop.sh. Per eseguire lo script di pulizia, sono necessarie le seguenti informazioni.

• Nome dell'organizzazione, ad esempio yourcompany.com
• ID workshop, nel formato YYMMDD-NN, ad esempio 200131-01
• Bucket GCS amministratore, definito nello script di bootstrap.

13. Apri Cloud Shell, esegui tutte le azioni seguenti in Cloud Shell. Fai clic sul link di seguito.

CLOUD SHELL

14. Verifica di aver eseguito l'accesso a gcloud con l'utente amministratore previsto.

gcloud config list
 

15. Vai alla cartella asm.

cd ${WORKDIR}/asm
 

16. Definisci il nome della tua organizzazione e l'ID workshop da eliminare.

export ORGANIZATION_NAME=<ORGANIZATION NAME>
export ASM_WORKSHOP_ID=<WORKSHOP ID>
export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>
 

17. Esegui lo script di pulizia come segue.

./scripts/cleanup_workshop.sh --workshop-id ${ASM_WORKSHOP_ID} --admin-gcs-bucket ${ADMIN_STORAGE_BUCKET} --org-name ${ORGANIZATION_NAME}