Questo documento descrive come inizializzare e configurare un mesh di servizi per supportare la migrazione funzionalità per funzionalità da un data center on-premise a Google Cloud. Si presume che tu conosca l'architettura di riferimento associata. È destinato ad amministratori, sviluppatori e ingegneri che vogliono utilizzare un mesh di servizi che instrada in modo dinamico il traffico all'ambiente di origine o a Google Cloud.
Questa guida al deployment ha lo scopo di aiutarti a eseguire la migrazione da un ambiente non Google Cloud (ad esempio on-premise o un altro cloud provider) a Google Cloud. Queste migrazioni presentano un livello di complessità di rete perché è necessario configurare un canale di comunicazione sicuro tra l'ambiente non Google Cloud e l'ambiente Google Cloud.
Architettura
Il seguente diagramma mostra come utilizzare un mesh di servizi per instradare il traffico ai microservizi in esecuzione nell'ambiente di origine o a Google Cloud:
Nel diagramma, il gateway Istio fornisce un mesh di servizi che collega i microservizi di un'applicazione. Google Kubernetes Engine (GKE) agisce come container per definire i confini di ciascun microservizio. Per ulteriori informazioni, consulta Supportare la migrazione con l'espansione della rete mesh Istio.
In questo deployment, utilizzerai il seguente software:
- Ubuntu Server e Container-Optimized OS: sistemi operativi utilizzati in questo deployment.
- Docker Engine: piattaforma per eseguire carichi di lavoro containerizzati.
- Docker Compose: uno strumento per definire ed eseguire le app Docker.
- Istio: un mesh di servizi open source.
- Kiali: uno strumento per visualizzare i mesh di servizi Istio.
- Envoy: un proxy sidecar utilizzato da Istio per includere i servizi nel mesh.
Il carico di lavoro di esempio
In questo deployment, utilizzerai l'app Bookinfo, che è un'app di microservizi poliglotta a quattro livelli che mostra informazioni sui libri. Questa app è progettata per essere eseguita su Kubernetes, ma puoi eseguirne il deployment su un'istanza di Compute Engine utilizzando Docker e Docker Compose. Con Docker Compose, descrivi le app multi-container utilizzando descriptors YAML. Puoi quindi avviare l'app eseguendo un singolo comando.
Sebbene questo carico di lavoro di esempio sia già containerizzato, questo approccio si applica anche ai servizi non containerizzati. In questi casi, puoi aggiungere una fase di modernizzazione in cui containerizzare i servizi di cui intendi eseguire la migrazione.
L'app Bookinfo ha quattro componenti di microservizi:
productpage
: chiama i microservizidetails
,ratings
ereviews
per completare la pagina delle informazioni sul librodetails
: fornisce informazioni sui librireviews
: contiene recensioni di libriratings
: restituisce informazioni sul ranking del libro da aggiungere alla recensione di un libro.
Per dimostrare Istio e le sue funzionalità, gli autori e i gestori dell'app Bookinfo hanno implementato più versioni di alcuni di questi componenti. In questo deployment, esegui il deployment di una sola versione di ogni componente.
Obiettivi
- Inizializza un ambiente che simula il data center on-premise.
- Esegui il deployment e il test dei carichi di lavoro di esempio nel data center on-premise.
- Configurare l'ambiente di destinazione su Google Cloud.
- Esegui la migrazione del carico di lavoro dal data center on-premise all'ambiente di destinazione.
- Testa i carichi di lavoro in esecuzione nell'ambiente di destinazione.
- Ritirare il data center on-premise.
Costi
In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:
Per generare una stima dei costi in base all'utilizzo previsto,
utilizza il Calcolatore prezzi.
prepara l'ambiente
Esegui la maggior parte dei passaggi per questo deployment in Cloud Shell.
-
Nella console Google Cloud, attiva Cloud Shell.
Nella parte inferiore della console Google Cloud viene avviata una sessione di Cloud Shell che mostra un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installato e con valori già impostati per il progetto attuale. L'inizializzazione della sessione può richiedere alcuni secondi.
In Cloud Shell, controlla la quantità di spazio libero a tua disposizione:
df -h
Per completare questo deployment, sono necessari circa 200 MB di spazio libero.
Cambia la directory di lavoro nella directory
${HOME}
:cd "${HOME}"
Clona il repository Git, che contiene gli script e i file manifest di cui eseguire il deployment e configurare il carico di lavoro di esempio:
git clone https://github.com/GoogleCloudPlatform/solutions-istio-mesh-expansion-migration
Esegui l'autenticazione con le Credenziali predefinite dell'applicazione (ADC):
gcloud auth application-default login
L'output mostra il percorso del file
Application Default Credentials
:Credentials saved to file: [/tmp/tmp.T5Qae7XwAO/application_default_credentials.json]
Prendi nota del percorso del file
Application Default Credentials
. Queste credenziali verranno utilizzate da qualsiasi libreria che richiede l'ADC.Inizializza le variabili di ambiente:
APPLICATION_DEFAULT_CREDENTIALS_PATH=APPLICATION_DEFAULT_CREDENTIALS_PATH BILLING_ACCOUNT_ID=BILLING_ACCOUNT_ID DEFAULT_FOLDER=DEFAULT_FOLDER DEFAULT_PROJECT=DEFAULT_PROJECT DEFAULT_REGION=DEFAULT_REGION DEFAULT_ZONE=DEFAULT_ZONE GKE_CLUSTER_NAME=istio-migration DEPLOYMENT_DIRECTORY_PATH="$(pwd)"/solutions-istio-mesh-expansion-migration ORGANIZATION_ID=ORGANIZATION_ID
Sostituisci quanto segue:
APPLICATION_DEFAULT_CREDENTIALS_PATH
: il percorso al file ADC del passaggio precedente.BILLING_ACCOUNT_ID
: l'ID dell'account di fatturazione da utilizzare.DEFAULT_FOLDER
: l'ID della cartella Google Cloud in cui creare il progetto Google Cloud. Se vuoi che Terraform crei il progetto Google Cloud direttamente nell'organizzazione Google Cloud, lascia la stringa vuota.DEFAULT_PROJECT
: l'ID del progetto Google Cloud per eseguire il provisioning delle risorse per completare questo deployment. Terraform crea questo progetto per te quando esegue il provisioning dell'ambiente.DEFAULT_REGION
: l'area geografica predefinita in cui viene eseguito il provisioning delle risorse.DEFAULT_ZONE
: la zona predefinita in cui viene eseguito il provisioning delle risorse.ORGANIZATION_ID
: l'ID della tua organizzazione Google Cloud.
Esegui il provisioning degli ambienti
In questa sezione eseguirai il provisioning dei seguenti ambienti per questo deployment:
- Un ambiente che simula il data center on-premise di origine.
- Un ambiente che simula la destinazione della migrazione.
In questo deployment, entrambi gli ambienti vengono eseguiti in Google Cloud. Questo approccio contribuisce a semplificare il processo di configurazione in quanto prevede una sola fase di bootstrap. Il provisioning automatico degli ambienti di origine e di destinazione viene eseguito utilizzando Terraform.
In Cloud Shell, modifica la directory di lavoro nella directory del repository:
cd "${DEPLOYMENT_DIRECTORY_PATH}"
Inizializza la configurazione del backend Terraform:
scripts/init.sh \ --application-credentials "${APPLICATION_DEFAULT_CREDENTIALS_PATH}" \ --billing-account-id "${BILLING_ACCOUNT_ID}" \ --default-folder "${DEFAULT_FOLDER}" \ --default-project "${DEFAULT_PROJECT}" \ --default-region "${DEFAULT_REGION}" \ --default-zone "${DEFAULT_ZONE}" \ --organization-id "${ORGANIZATION_ID}"
Lo script
init.sh
:- Genera i descrittori per configurare il backend Terraform.
- Inizializza la directory di lavoro Terraform.
Cambia la directory di lavoro nella directory
terraform
:cd "${DEPLOYMENT_DIRECTORY_PATH}"/terraform
Applica le modifiche con Terraform:
terraform apply
Quando richiesto, esamina le modifiche proposte e conferma inserendo
yes
.L'output è simile al seguente:
Apply complete! Resources: 27 added, 0 changed, 0 destroyed
Applicando le modifiche proposte con Terraform, automatizzi le seguenti attività:
- Creazione di regole firewall per consentire l'accesso esterno ai microservizi e alle comunicazioni tra database e nodi.
- Creazione e abilitazione di un account di servizio per le istanze di Compute Engine da utilizzare. Ti consigliamo di limitare l'account di servizio ai soli ruoli e autorizzazioni di accesso necessari per eseguire l'app. Per questo deployment, l'account di servizio per le istanze di Compute Engine richiede solo il ruolo Visualizzatore Compute (
roles/compute.viewer
). Questo ruolo fornisce l'accesso di sola lettura alle risorse Compute Engine. - Provisioning e configurazione di un'istanza Compute Engine per ospitare i carichi di lavoro di cui eseguire la migrazione come ambiente di origine. Quando configuri l'istanza Compute Engine, fornisci uno script di avvio che installa Docker, Docker Compose e Dnsmasq.
- Creazione e abilitazione di un account di servizio per il cluster GKE in modo da ospitare i carichi di lavoro come ambiente di destinazione. In questo deployment, creerai un account di servizio utilizzato dai nodi del cluster GKE. Ti consigliamo di limitare l'account di servizio ai soli ruoli e autorizzazioni di accesso necessari per eseguire l'app. Per questo deployment, i ruoli richiesti per l'account di servizio per i nodi dei cluster GKE sono i seguenti:
- Visualizzatore Monitoring (
roles/monitoring.viewer
) - Writer metriche Monitoring
(
roles/monitoring.metricWriter
) - Writer log
(
roles/logging.logWriter
), come descritto in Rafforzamento della sicurezza del cluster
- Visualizzatore Monitoring (
- Provisioning e configurazione di un cluster GKE per ospitare i carichi di lavoro come ambiente di destinazione. Per eseguire il provisioning dei cluster GKE, Terraform utilizza il modulo Terraform kubernetes-engine.
Esegui il deployment del carico di lavoro nell'ambiente di origine
In questo deployment, eseguirai il deployment dell'app Istio Bookinfo come carico di lavoro di cui eseguire la migrazione. Il seguente diagramma mostra l'architettura dell'ambiente di origine:
Nel diagramma, i client accedono al carico di lavoro di esempio in esecuzione su Compute Engine. Per ridurre la complessità in questo esempio, i client si connettono direttamente a una singola istanza Compute Engine. In un ambiente di produzione, è improbabile che questa connessione diretta sia necessaria perché è necessario un livello di bilanciamento del carico per eseguire più istanze di un carico di lavoro.
In Cloud Shell, modifica la directory di lavoro nella directory del repository:
cd "${DEPLOYMENT_DIRECTORY_PATH}"
Esegui il deployment dei carichi di lavoro nelle istanze di Compute Engine:
scripts/workloads.sh \ --deploy-with "COMPOSE" \ --default-project "${DEFAULT_PROJECT}" \ --default-region "${DEFAULT_REGION}" \ --default-zone "${DEFAULT_ZONE}"
Lo script
workloads.sh
:- Configura il progetto, la regione e la zona predefiniti.
- Copia i descrittori Docker Compose nelle istanze di Compute Engine.
- Esegue il deployment del carico di lavoro di esempio utilizzando Docker Compose.
Se non hai già creato un file di chiavi SSH per l'autenticazione con le istanze di Compute Engine, gcloud CLI ti chiede di generarne uno.
Nell'output, vedrai una conferma del deployment e di come puoi accedervi. L'output è simile al seguente:
You can access the workload by loading http://COMPUTE_ENGINE_PRODUCTPAGE_EXTERNAL_IP:9080/productpage
Nell'output,
COMPUTE_ENGINE_PRODUCTPAGE_EXTERNAL_IP
è l'indirizzo IP in cui viene gestito il carico di lavoro. Prendi nota dell'indirizzo IP, perché lo utilizzerai in un passaggio successivo.
Testa il deployment nell'ambiente di origine
Apri un browser e vai al seguente URL, dove
COMPUTE_ENGINE_PRODUCTPAGE_EXTERNAL_IP
è l'indirizzo IP del passaggio precedente:http://COMPUTE_ENGINE_PRODUCTPAGE_EXTERNAL_IP:9080/productpage
Viene visualizzata una pagina Bookinfo con dettagli sui libri e valutazioni pertinenti.
Configura Istio
In questa sezione configurerai l'ambiente di destinazione in Google Cloud installando Istio, quindi utilizzerai Istio per esporre il carico di lavoro di esempio. Il seguente diagramma mostra l'architettura dell'ambiente di destinazione:
Nel diagramma, Istio espone il carico di lavoro in esecuzione in Compute Engine.
Installa Istio
In Cloud Shell, modifica la directory di lavoro nella directory del repository:
cd "${DEPLOYMENT_DIRECTORY_PATH}"
Installa Istio:
scripts/install-istio.sh \ --cluster-name "${GKE_CLUSTER_NAME}" \ --google-cloud-project "${DEFAULT_PROJECT}" \ --cluster-region "${DEFAULT_REGION}"
Lo script
install-istio.sh
:- Scarica la distribuzione Istio.
- Installa Istio nel cluster GKE dell'ambiente di destinazione.
- Esegue il deployment di un gateway per esporre i servizi nel mesh di servizi.
- Configura Istio per consentire l'espansione del mesh di servizi nelle istanze di Compute Engine che simulano l'ambiente di origine.
- Installa strumenti di monitoraggio e visualizzazione del mesh di servizi, come Kiali.
Al termine dell'esecuzione di questo comando, la console mostra una conferma dell'installazione. L'output è simile al seguente:
✔ Istio core installed ✔ Istiod installed ✔ Ingress gateways installed ✔ Egress gateways installed ✔ Installation complete
Configura l'espansione del mesh Istio
In questa sezione collegherai l'istanza Compute Engine, che simula l'ambiente di origine, al mesh di servizi. Il mesh di servizi gestisce la connessione dei microservizi nell'ambiente legacy di cui verrà eseguita la migrazione all'ambiente di destinazione. In questa fase, il mesh di servizi è vuoto, in attesa della registrazione dei servizi. Il mesh di servizi non riceve ancora traffico di produzione.
In Cloud Shell, modifica la directory di lavoro nella directory del repository:
cd "${DEPLOYMENT_DIRECTORY_PATH}"
Installa e configura Istio sull'istanza Compute Engine:
scripts/compute-engine-mesh-expansion-setup.sh \ --default-project "${DEFAULT_PROJECT}" \ --default-region "${DEFAULT_REGION}" \ --default-zone "${DEFAULT_ZONE}"
Lo script
compute-engine-mesh-expansion-setup.sh
:- Installa Istio sull'ambiente di origine delle istanze di Compute Engine.
- Avvia il servizio Istio sulle istanze di Compute Engine.
Esponi il carico di lavoro
In questa sezione registri i carichi di lavoro in esecuzione nell'istanza di Compute Engine e simula l'ambiente di origine sul mesh di servizi Istio.
Lo script workloads.sh
che esegui in questa sezione configura le regole di routing per suddividere il traffico di produzione tra i servizi in esecuzione nell'ambiente legacy e quelli in esecuzione nell'ambiente di destinazione, utilizzando il mesh di servizi. Poiché il routing del traffico all'interno del mesh di servizi è trasparente per i client, i client non sanno se la configurazione del routing è cambiata.
In Cloud Shell, modifica la directory di lavoro nella directory del repository:
cd "${DEPLOYMENT_DIRECTORY_PATH}"
Esponi i carichi di lavoro:
scripts/workloads.sh \ --default-project "${DEFAULT_PROJECT}" \ --default-region "${DEFAULT_REGION}" \ --default-zone "${DEFAULT_ZONE}" \ --expose-with "ISTIO_COMPUTE_ENGINE"
Lo script
workloads.sh
:- Configura il progetto, la regione e la zona predefiniti.
- Attiva l'inserimento automatico del file collaterale per evitare modifiche manuali ai descrittori di deployment.
- Registra nel mesh i carichi di lavoro in esecuzione nell'istanza di Compute Engine configurando gli endpoint
WorkloadEntry
e i servizi corrispondenti. - Esegue il deployment dell'elemento
ServiceEntries
per consentire il traffico al server di metadati di Compute Engine e alle API Cloud. - Esegue il deployment dei servizi virtuali per instradare il traffico dal gateway Istio all'istanza
productpage
in esecuzione nell'istanza di Compute Engine.
Nell'output, vedrai una conferma del deployment e di come puoi accedervi. L'output è simile al seguente:
You can access the workload by loading http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
Nell'output,
ISTIO_INGRESS_GATEWAY_EXTERNAL_IP
è l'indirizzo IP in cui viene gestito il carico di lavoro. Prendi nota dell'indirizzo IP perché lo userai in un passaggio successivo.
Testa l'espansione del mesh Istio
In questa sezione testerai il carico di lavoro di esempio in esecuzione nell'istanza di Compute Engine che hai utilizzato Istio per l'esposizione.
Apri un browser e vai al seguente URL, dove
ISTIO_INGRESS_GATEWAY_EXTERNAL_IP
è l'indirizzo IP del passaggio precedente:http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
Il punto di ingresso dell'ambiente di origine (che si connette all'istanza di Compute Engine) è ancora disponibile in questa fase. Quando esegui la migrazione di un ambiente di produzione, ti consigliamo di reindirizzare gradualmente il traffico all'ambiente di destinazione aggiornando la configurazione del livello di bilanciamento del carico.
Visualizza il mesh di servizi
In questa sezione utilizzerai Kiali per mostrare una rappresentazione visiva della rete mesh di servizi.
Apri un browser e vai al seguente URL, dove
ISTIO_INGRESS_GATEWAY_EXTERNAL_IP
è l'indirizzo IP del passaggio precedente:http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/kiali/console/graph/namespaces/?edges=requestDistribution&graphType=versionedApp&namespaces=default%2Cistio-system&idleNodes=false&duration=60&refresh=15000&operationNodes=false&idleEdges=false&injectServiceNodes=true&layout=dagre
Viene visualizzata la dashboard dei servizi Kiali.
In Cloud Shell, esegui più volte una richiesta per la pagina principale del carico di lavoro di esempio:
ISTIO_INGRESS_GATEWAY_EXTERNAL_IP="$(kubectl get svc istio-ingressgateway -n istio-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}')" for i in {1..10000}; do curl -s -o /dev/null -w "$(date --iso-8601=ns) - %{http_code}\n" http://"${ISTIO_INGRESS_GATEWAY_EXTERNAL_IP}"/productpage; done
La richiesta genera traffico verso l'app Bookinfo. L'output mostra un elenco dei timestamp per ogni richiesta HTTP al servizio
productpage
e il codice di ritorno HTTP di ogni richiesta (200
in questo caso).L'output è simile al seguente:
2021-06-09T10:16:15,355323181+00:00 - 200 2021-06-09T10:16:15,355323182+00:00 - 200 2021-06-09T10:16:15,355323183+00:00 - 200 [...]
Poiché la richiesta richiede del tempo per essere completata, puoi lasciarla in esecuzione e andare al passaggio successivo.
Nella dashboard del servizio Kiali è presente un diagramma del mesh attuale, con il traffico instradato ai servizi in esecuzione in Compute Engine. Tutto il traffico viene instradato dal
istio-ingressgateway
al microservizioproductpage
in esecuzione sull'istanza Compute Engine con l'etichetta della versionecompute-engine
e al serviziokiali
per visualizzare il mesh di servizi.Gli altri servizi non vengono visualizzati nel grafico (
details
,reviews
eratings
) perché il microservizioproductpage
eseguito in Compute Engine si connette direttamente agli altri microservizi in esecuzione in Compute Engine. Il microservizioproductpage
non passa tramite il mesh di servizi.Se vuoi che tutto il traffico passi attraverso il mesh di servizi, devi riconfigurare i carichi di lavoro in esecuzione in Compute Engine in modo che puntino ai servizi nel mesh di servizi, anziché connetterti direttamente a questi servizi.
Se non vedi il seguente diagramma sulla dashboard di Kiali, aggiorna la pagina.
Il diagramma nella dashboard di Kiali mostra che il traffico viene instradato ai servizi in esecuzione in Compute Engine.
In Cloud Shell, per interrompere il comando di generazione del traffico, premi
Control+C
.
Esegui la migrazione del carico di lavoro
In questa sezione eseguirai la migrazione dei componenti del carico di lavoro di esempio dalle istanze di Compute Engine al cluster GKE. Per ogni microservizio del carico di lavoro di esempio:
- Eseguire il deployment di un'istanza del microservizio nel cluster GKE.
- Avvia il routing del traffico alle istanze di microservizi in esecuzione in Compute Engine e in GKE.
Il seguente diagramma mostra l'architettura del sistema per questa sezione:
Nel diagramma, Cloud Load Balancing instrada il traffico al gateway Istio, quindi Istio lo instrada ai servizi in esecuzione su Compute Engine o ai servizi in esecuzione su GKE.
Per eseguire la migrazione dei componenti del carico di lavoro di esempio:
In Cloud Shell, modifica la directory di lavoro nella directory del repository:
cd "${DEPLOYMENT_DIRECTORY_PATH}"
Esegui il deployment dei carichi di lavoro nell'ambiente di destinazione:
scripts/workloads.sh \ --default-project "${DEFAULT_PROJECT}" \ --default-region "${DEFAULT_REGION}" \ --default-zone "${DEFAULT_ZONE}" \ --deploy-with "GKE"
Lo script
workloads.sh
:- Attiva l'inserimento automatico del file collaterale per evitare modifiche manuali ai descrittori di deployment.
- Esegue il deployment di ServiceAccounts e dei Deployment per eseguire i carichi di lavoro di esempio nel cluster GKE.
Vedrai una conferma del deployment e ti verrà spiegato come puoi accedervi. L'output è simile al seguente:
You can access the workload by loading http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
Il mesh di servizi instrada il traffico sia ai carichi di lavoro di esempio in esecuzione nelle istanze di Compute Engine sia a quelli in esecuzione nel cluster GKE.
Testa il carico di lavoro in esecuzione in Compute Engine e GKE
In questa sezione testerai il carico di lavoro di esempio di cui hai eseguito il deployment in Compute Engine e GKE.
Apri un browser e vai al seguente URL, dove
ISTIO_INGRESS_GATEWAY_EXTERNAL_IP
è l'indirizzo IP del passaggio precedente:http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
Viene visualizzata una pagina Bookinfo con informazioni sui libri e valutazioni pertinenti.
Poiché hai eseguito il deployment della stessa versione del carico di lavoro di esempio in Compute Engine e nel cluster GKE, l'output è lo stesso del test precedente.
Visualizza il mesh di servizi
In questa sezione utilizzerai Kiali per mostrare una rappresentazione visiva della rete mesh di servizi.
Apri un browser e vai al seguente URL, dove
ISTIO_INGRESS_GATEWAY_EXTERNAL_IP
è l'indirizzo IP del passaggio precedente:http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/kiali/console/graph/namespaces/?edges=requestDistribution&graphType=versionedApp&namespaces=default%2Cistio-system&idleNodes=false&duration=60&refresh=15000&operationNodes=false&idleEdges=false&injectServiceNodes=true&layout=dagre
In Cloud Shell, esegui più volte una richiesta per la pagina principale del carico di lavoro di esempio:
ISTIO_INGRESS_GATEWAY_EXTERNAL_IP="$(kubectl get svc istio-ingressgateway -n istio-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}')" for i in {1..10000}; do curl -s -o /dev/null -w "$(date --iso-8601=ns) - %{http_code}\n" http://"${ISTIO_INGRESS_GATEWAY_EXTERNAL_IP}"/productpage; done
Il comando genera traffico verso l'app Bookinfo. L'output previsto è un elenco delle date delle richieste HTTP al servizio
productpage
e il codice di ritorno HTTP di ogni richiesta (200 OK
in questo caso). L'output è simile al seguente:2021-06-09T10:16:15,355323181+00:00 - 200 2021-06-09T10:16:15,355323182+00:00 - 200 2021-06-09T10:16:15,355323183+00:00 - 200 [...]
Nella dashboard dei servizi Kiali è visualizzato un diagramma del mesh attuale, con il traffico instradato a servizi in esecuzione in Compute Engine e GKE.
Ogni istanza di un microservizio ha un'etichetta per spiegare la sua revisione:
- Le istanze in esecuzione in Compute Engine hanno un'etichetta
compute-engine
. - Le istanze in esecuzione in GKE hanno una stringa in più, ad esempio
v1
ov3
.
Le istanze in esecuzione in Compute Engine si connettono direttamente alle altre istanze in Compute Engine senza passare attraverso il mesh di servizi. Pertanto, non vedrai il traffico che passa dalle istanze in esecuzione in Compute Engine ad altre istanze.
Se non vedi il seguente diagramma sulla dashboard di Kiali, aggiorna la pagina.
Il diagramma nella dashboard di Kiali mostra il traffico instradato ai servizi in esecuzione in Compute Engine e ai servizi in esecuzione su GKE.
- Le istanze in esecuzione in Compute Engine hanno un'etichetta
In Cloud Shell, per interrompere il comando di generazione del traffico, premi
Control+C
.
Instrada il traffico solo al cluster GKE
In questa sezione instradarai il traffico alle istanze di servizio dei carichi di lavoro in esecuzione solo nel cluster GKE. Per ogni servizio del carico di lavoro di esempio, elimini il riferimento WorkloadEntry
che punta al servizio in esecuzione in Compute Engine. L'eliminazione fa sì che il servizio selezioni solo le istanze di microservizi in esecuzione nel cluster GKE e il traffico viene instradato solo al cluster GKE. Il seguente diagramma mostra l'architettura
del sistema per questa sezione:
In Cloud Shell, modifica la directory di lavoro nella directory del repository:
cd "${DEPLOYMENT_DIRECTORY_PATH}"
Esponi i carichi di lavoro solo nell'ambiente di destinazione:
scripts/workloads.sh \ --default-project "${DEFAULT_PROJECT}" \ --default-region "${DEFAULT_REGION}" \ --default-zone "${DEFAULT_ZONE}" \ --expose-with "GKE_ONLY"
Lo script
workloads.sh
elimina i riferimentiWorkloadEntry
che rimandano alle istanze dei microservizi in esecuzione in Compute Engine dal cluster GKE.Viene visualizzata una conferma del deployment e viene visualizzata una conferma per l'accesso. L'output è simile al seguente:
You can access the workload by loading http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
La voce di servizio utilizza workloadSelector
per selezionare automaticamente il carico di lavoro di esempio in esecuzione nel cluster GKE.
Testa il carico di lavoro in esecuzione in GKE
Apri un browser e vai al seguente URL, dove
ISTIO_INGRESS_GATEWAY_EXTERNAL_IP
è l'indirizzo IP del passaggio precedente:http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
Viene visualizzata una pagina Bookinfo con informazioni sui libri e valutazioni pertinenti.
Visualizza il mesh di servizi
In questa sezione utilizzerai Kiali per mostrare una rappresentazione visiva della rete mesh di servizi.
Apri un browser e vai al seguente URL, dove
ISTIO_INGRESS_GATEWAY_EXTERNAL_IP
è l'indirizzo IP del passaggio precedente:http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/kiali/console/graph/namespaces/?edges=requestDistribution&graphType=versionedApp&namespaces=default%2Cistio-system&idleNodes=false&duration=60&refresh=15000&operationNodes=false&idleEdges=false&injectServiceNodes=true&layout=dagre
In Cloud Shell, esegui più volte una richiesta per la pagina principale del carico di lavoro di esempio:
ISTIO_INGRESS_GATEWAY_EXTERNAL_IP="$(kubectl get svc istio-ingressgateway -n istio-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}')" for i in {1..10000}; do curl -s -o /dev/null -w "$(date --iso-8601=ns) - %{http_code}\n" http://"${ISTIO_INGRESS_GATEWAY_EXTERNAL_IP}"/productpage; done
Questo comando genera traffico verso l'app Bookinfo. L'output previsto è un elenco delle date delle richieste HTTP al servizio
productpage
e il codice di ritorno HTTP di ogni richiesta (200 OK
in questo caso). L'output è simile al seguente:2021-06-09T10:16:15,355323181+00:00 - 200 2021-06-09T10:16:15,355323182+00:00 - 200 2021-06-09T10:16:15,355323183+00:00 - 200 [...]
La dashboard dei servizi Kiali mostra un diagramma del mesh attuale con il traffico instradato a servizi in esecuzione su GKE. Hai eseguito il deployment di due istanze di ogni microservizio: una viene eseguita nell'istanza di Compute Engine e l'altra nel cluster GKE. Tuttavia, poiché hai rimosso i riferimenti
WorkloadEntry
che puntano alle istanze dei microservizi in esecuzione in Compute Engine, i servizi selezionano solo le istanze dei microservizi in esecuzione nel cluster GKE.Se non vedi il seguente diagramma sulla dashboard di Kiali, aggiorna la pagina:
Il diagramma sulla dashboard Kiali mostra il traffico instradato ai servizi in esecuzione in GKE.
In Cloud Shell, per interrompere il comando di generazione del traffico, premi
Control+C
.
Ritira l'ambiente di origine
Poiché ora tutto il traffico è instradato al cluster GKE, puoi arrestare le istanze del carico di lavoro in esecuzione in Compute Engine.
Durante una migrazione in produzione, tieni il data center di origine pronto per la tua strategia di rollback. Ti consigliamo di iniziare a ritirare il data center di origine solo quando hai la certezza che la nuova soluzione funzioni come previsto e che tutti i meccanismi di backup e di tolleranza degli errori siano attivi.
Il seguente diagramma mostra l'architettura del sistema per questa sezione:
Nel diagramma, Istio instrada il traffico ai servizi in esecuzione solo in GKE e i carichi di lavoro in esecuzione in Compute Engine vengono ritirati.
Per ritirare l'ambiente di origine:
In Cloud Shell, modifica la directory di lavoro nella directory del repository:
cd "${DEPLOYMENT_DIRECTORY_PATH}"
Esponi i carichi di lavoro solo nell'ambiente di destinazione:
scripts/workloads.sh \ --default-project "${DEFAULT_PROJECT}" \ --default-region "${DEFAULT_REGION}" \ --default-zone "${DEFAULT_ZONE}" \ --deploy-with "GKE_ONLY"
Lo script
workloads.sh
arresta i container in esecuzione nelle istanze di Compute Engine.
Esegui la pulizia
Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo deployment, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.
Elimina il progetto
- Nella console Google Cloud, vai alla pagina Gestisci risorse.
- Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
- Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.
Elimina le singole risorse
In Cloud Shell, modifica la directory di lavoro nella directory del repository:
cd "${DEPLOYMENT_DIRECTORY_PATH}"/terraform
Elimina le risorse di cui hai eseguito il provisioning:
terraform destroy -auto-approve
Passaggi successivi
- Scopri di più su GKE.
- Scopri di più su Istio.
- Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.