Questo documento descrive come inizializzare e configurare un mesh di servizi per supportare la migrazione graduale di tutte le funzionalità da un data center on-premise a Google Cloud. Si presume che tu abbia familiarità con l'architettura di riferimento associata. È destinata ad amministratori, sviluppatori e ingegneri che vogliono utilizzare una mesh di servizi che instrada dinamicamente il traffico all'ambiente di origine oppure a Google Cloud.
Questa guida all'implementazione ha lo scopo di aiutarti a eseguire la migrazione da un ambiente non Google Cloud (ad esempio on-premise o un altro cloud a Google Cloud. Queste migrazioni hanno un livello di rete perché devi configurare canale di comunicazione sicuro tra l'ambiente non Google Cloud e Google Cloud completamente gestito di 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 Google Cloud:
Nel diagramma, il gateway Istio fornisce un mesh di servizi che collega di un'applicazione. Google Kubernetes Engine (GKE) funge da container per e definire i confini di ogni microservizio. Per ulteriori informazioni, vedi Supporta la migrazione con l'espansione del mesh Istio.
In questo deployment, utilizzerai il software seguente:
- Ubuntu Server e Container-Optimized OS: sistemi operativi utilizzati in questo deployment.
- Docker Engine: Piattaforma per l'esecuzione di 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.
Carico di lavoro di esempio
In questo deployment, utilizzerai Informazioni sul libro un'app di 4 livelli, poliglotta di microservizi che mostra informazioni su libri. Questa app è progettata per su Kubernetes, ma ne esegui il deployment su un'istanza Compute Engine utilizzando Docker e Docker Compose. Con Docker Compose, descrivi le app multi-container usando YAML descrittori. Puoi quindi avviare l'app eseguendo un singolo comando.
Sebbene il carico di lavoro di esempio sia già containerizzato, questo approccio si applica ai servizi non containerizzati. In questi casi, puoi aggiungere fase di modernizzazione in cui containerizza i servizi di cui intendi eseguire la migrazione.
L'app Bookinfo ha quattro componenti di microservizi:
productpage
: chiamadetails
,ratings
ereviews
microservizi per compilare la pagina delle informazioni sul librodetails
: fornisce informazioni sui librireviews
: contiene recensioni dei libriratings
: restituisce informazioni sul ranking del libro da allegare alla recensione di un libro
Per dimostrare Istio e le sue funzionalità, gli autori e i gestori del servizio L'app Bookinfo ha implementato più versioni di alcuni di questi componenti. Nel questo deployment, eseguirai il deployment di una sola versione di ogni componente.
Obiettivi
- Inizializzare un ambiente che simula il data center on-premise.
- Esegui il deployment e il test di 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 alla destinazione completamente gestito di Google Cloud.
- Testa i carichi di lavoro in esecuzione nell'ambiente di destinazione.
- Ritira il data center on-premise.
Costi
In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:
Per generare una stima dei costi basata sull'utilizzo previsto,
utilizza il Calcolatore prezzi.
prepara l'ambiente
Esegui la maggior parte dei passaggi per questo deployment in Cloud Shell.
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
In Cloud Shell, controlla la quantità di spazio libero a tua disposizione:
df -h
Per completare questo deployment, devi disporre di 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 il 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
Autenticazione con 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 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 del file ADC del passaggio precedente.BILLING_ACCOUNT_ID
: l'ID dell'account di fatturazione da utilizzare.DEFAULT_FOLDER
: l'ID del Google Cloud cartella in cui creare il progetto Google Cloud. Se vuoi che Terraform creare il progetto Google Cloud direttamente all'interno organizzazione, lascia questa stringa vuota.DEFAULT_PROJECT
: l'ID di il progetto Google Cloud per eseguire il provisioning delle risorse e deployment continuo. Terraform crea questo progetto per te quando esegue il provisioning dell'ambiente.DEFAULT_REGION
: il valore predefinito regione in cui viene eseguito il provisioning delle risorse.DEFAULT_ZONE
: il valore predefinito zona in cui viene eseguito il provisioning delle risorse.ORGANIZATION_ID
: l'ID di la tua Google Cloud organizzazione.
Esegui il provisioning degli ambienti
In questa sezione eseguirai il provisioning dei seguenti ambienti 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 semplifica il processo di configurazione perché c'è un solo bootstrap durante la fase di sviluppo. Esegui automaticamente il provisioning degli ambienti di origine e di destinazione utilizzando con Terraform.
In Cloud Shell, imposta la directory di lavoro sulla 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
esegue le seguenti operazioni:- Genera i descrittori per configurare Backend Terraform.
- Inizializza la directory di lavoro di Terraform.
Cambia la directory di lavoro nella directory
terraform
:cd "${DEPLOYMENT_DIRECTORY_PATH}"/terraform
Applica le modifiche con Terraform:
terraform apply
Quando ti viene 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 quanto segue attività:
- Creazione di regole firewall di consentire l'accesso esterno ai microservizi e al database per le comunicazioni tra nodi.
- Creazione e abilitazione di un account di servizio
utilizzabili dalle istanze Compute Engine. Ti consigliamo di limitare
l'account di servizio solo ai ruoli e alle autorizzazioni di accesso necessari per eseguire l'app. Per questo deployment, l'account di servizio per le istanze Compute Engine richiede solo il
ruolo Visualizzatore Compute
(
roles/compute.viewer
). Questo ruolo fornisce l'accesso in sola lettura alle risorse di Compute Engine. - Provisioning e configurazione di un'istanza Compute Engine per l'hosting dei carichi di lavoro da migrare, come ambiente di origine. Quando configuri Compute Engine, devi fornire uno script di avvio che installa Docker, Docker Compose Dnsmasq.
- Creazione e abilitazione di un account di servizio per GKE
per ospitare i carichi di lavoro come ambiente di destinazione. In questo deployment,
crei un account di servizio che il cluster GKE
possono essere usati dai nodi. Ti consigliamo di limitare l'account di servizio solo
i ruoli e le autorizzazioni di accesso necessari per eseguire l'app. Per
i ruoli richiesti per l'account di servizio
I nodi dei cluster GKE sono i seguenti:
- Visualizzatore Monitoring
(
roles/monitoring.viewer
) - Autore delle metriche di 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 l'hosting per gestire 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 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 in Compute Engine. Per ridurre la complessità in questo esempio, i client entrano in contatto direttamente a una singola istanza Compute Engine. In un ambiente di produzione, questa connessione diretta è improbabile perché è necessario un livello di bilanciamento del carico per eseguire più istanze di un carico di lavoro.
In Cloud Shell, cambia la directory di lavoro nel repository directory:
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
esegue le seguenti operazioni:- Configura il progetto, la regione e la zona predefiniti.
- Copia i descrittori di Docker Compose nella di Compute Engine.
- Esegue il deployment del carico di lavoro di esempio utilizzando Docker Compose.
Se non hai creato in precedenza un file di chiave SSH per l'autenticazione Compute Engine, gcloud CLI ti chiede di generarne uno.
Nell'output vedrai una conferma del deployment e di come per 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 dove viene gestito il carico di lavoro. Prendi nota dell'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 i dettagli dei libri e le valutazioni pertinenti.
Configura Istio
In questa sezione configurerai l'ambiente di destinazione in Google Cloud installa Istio per poi utilizzare Istio per esporre il carico di lavoro di esempio. La 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, cambia la directory di lavoro nel repository directory:
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
esegue le seguenti operazioni:- Scarica la distribuzione Istio.
- Installa Istio nell'ambiente di destinazione cluster GKE.
- Esegue il deployment di un gateway per esporre i servizi nel mesh di servizi.
- Configura Istio per consentire espansione del mesh di servizi alle istanze Compute Engine che simulano l'origine completamente gestito di Google Cloud.
- Installa strumenti di monitoraggio e visualizzazione del mesh di servizi, come Kiali.
Al termine dell'esecuzione, 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, connetterai l'istanza Compute Engine che simula dall'ambiente di origine al mesh di servizi. Il mesh di servizi gestisce la connessione i microservizi nell'ambiente legacy di cui verrà eseguita la migrazione nella destinazione completamente gestito di Google Cloud. In questa fase, il mesh di servizi è vuoto, in attesa che i servizi la registrazione. Il mesh di servizi non riceve ancora traffico di produzione.
In Cloud Shell, cambia la directory di lavoro nel repository directory:
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
esegue le seguenti operazioni:- Installa Istio nell'ambiente di origine Compute Engine 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 Compute Engine e simula l'ambiente di origine Mesh di servizi Istio.
Lo script workloads.sh
eseguito in questa sezione configura le regole di routing per suddividere il traffico di produzione tra i servizi in esecuzione nell'ambiente precedente e quelli in esecuzione nell'ambiente di destinazione utilizzando il service mesh. Poiché
che il routing del traffico all'interno del mesh di servizi sia trasparente per i client
che la configurazione del routing è cambiata.
In Cloud Shell, cambia la directory di lavoro nel repository directory:
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
esegue le seguenti operazioni:- Configura il progetto, la regione e la zona predefiniti.
- Consente di eseguire l'iniezione automatica di sidecar per evitare modifiche manuali ai descrittori di deployment.
- Registra i carichi di lavoro in esecuzione in Compute Engine
alla rete mesh, configurando
WorkloadEntry
e i servizi corrispondenti. - Esegue il deployment di
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 Compute Engine.
Nell'output vedrai una conferma del deployment e di come per 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 dove viene gestito il carico di lavoro. Prendi nota dell'indirizzo IP, poiché lo userai in un passaggio successivo.
Testa l'espansione del mesh Istio
In questa sezione testerai il carico di lavoro di esempio in esecuzione Istanza Compute Engine che hai utilizzato Istio per esporre.
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 a Compute Engine) ) è ancora disponibile in questa fase. Quando esegui la migrazione di un modello ti consigliamo di reindirizzare gradualmente il traffico allo di Google Cloud mediante l'aggiornamento della configurazione del livello di bilanciamento del carico.
Visualizza il mesh di servizi
In questa sezione utilizzerai Kiali per mostrare una rappresentazione visiva del servizio in mesh.
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 del servizio 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 all'app Bookinfo. L'output mostra un elenco dei timestamp per ogni richiesta HTTP al servizio
productpage
e il codice HTTP restituito di ogni richiesta (in questo caso200
).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 [...]
Il completamento della richiesta richiede tempo, quindi puoi lasciarla in esecuzione e procedere al passaggio successivo.
Nella dashboard dei servizi Kiali puoi vedere un diagramma del mesh attuale, con traffico indirizzato a servizi in esecuzione in Compute Engine. Tutto il traffico viene indirizzato dal
istio-ingressgateway
alproductpage
microservizio in esecuzione sull'istanza Compute Engine con l'etichetta della versionecompute-engine
e al serviziokiali
per visualizzare il service mesh.Non vedi gli altri servizi nel grafico (
details
,reviews
eratings
) perché il microservizioproductpage
in esecuzione Compute Engine si connette direttamente agli altri microservizi in esecuzione in Compute Engine. Il microservizioproductpage
non passa per il mesh di servizi.Se vuoi che tutto il traffico passi attraverso il mesh di servizi, devi riconfigurare i carichi di lavoro in esecuzione su Compute Engine perché puntino nel mesh di servizi, invece di connettervi direttamente.
Se non vedi il seguente diagramma sul cruscotto Kiali, aggiorna il .
Il diagramma nella dashboard di Kiali mostra che il traffico viene indirizzato e i 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 dalla di Compute Engine al cluster GKE. Per ogni microservizio del carico di lavoro di esempio, esegui queste operazioni:
- Esegui il deployment di un'istanza del microservizio in GKE in un cluster Kubernetes.
- Inizia a instradare il traffico sia alle istanze di microservizi in esecuzione in Compute Engine sia a quelle in esecuzione in GKE.
Il seguente diagramma mostra l'architettura del sistema per questa sezione:
Nel diagramma, Cloud Load Balancing instrada il traffico al gateway Istio Istio instrada il traffico ai servizi in esecuzione in Compute Engine o ai servizi in esecuzione su GKE.
Per eseguire la migrazione dei componenti del carico di lavoro di esempio, segui questi passaggi:
In Cloud Shell, cambia la directory di lavoro nel repository directory:
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
esegue le seguenti operazioni:- Consente di eseguire l'iniezione automatica di sidecar per evitare modifiche manuali ai descrittori di deployment.
- Esegue il deployment ServiceAccounts e ai Deployment per eseguire i carichi di lavoro di esempio nel cluster GKE.
Vedrai una conferma del deployment e il modo in cui puoi accedervi. La è simile al seguente:
You can access the workload by loading http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
Il mesh di servizi instrada il traffico a entrambi i carichi di lavoro di esempio in esecuzione le istanze di Compute Engine e quelle in esecuzione 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 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 sui contenuti pertinenti valutazioni.
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 del servizio in mesh.
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 delle date delle richieste HTTP al servizio
productpage
e Codice restituito HTTP di ogni richiesta (in questo caso200 OK
). 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 puoi vedere un diagramma del mesh attuale, con traffico indirizzato a servizi in esecuzione in Compute Engine e GKE.
Ogni istanza di un microservizio ha un'etichetta che ne spiega la revisione:
- Le istanze in esecuzione in Compute Engine hanno l'etichetta
compute-engine
. - Le istanze in esecuzione su GKE hanno un'offerta
stringa, ad esempio
v1
ov3
.
Le istanze in esecuzione in Compute Engine si connettono direttamente alle altre istanze in Compute Engine senza passare per mesh di servizi. Pertanto, non vedi il traffico che proviene dalla in esecuzione su Compute Engine ad altre istanze.
Se non vedi il seguente diagramma nella dashboard di Kiali, aggiorna la pagina.
Il diagramma nella dashboard di Kiali mostra il traffico indirizzato a da servizi in esecuzione su Compute Engine e da quelli in esecuzione in GKE.
- Le istanze in esecuzione in Compute Engine hanno l'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, instrada il traffico alle istanze di servizio dei carichi di lavoro
in esecuzione solo nel cluster GKE. Per ogni servizio
carico di lavoro di esempio, elimini il riferimento WorkloadEntry
che rimanda al
in esecuzione in Compute Engine. L'eliminazione fa sì che il servizio
e selezionare solo le istanze di microservizi in esecuzione
cluster GKE e il traffico viene instradato solo
cluster GKE. Il seguente diagramma mostra l'architettura
del sistema per questa sezione:
In Cloud Shell, cambia la directory di lavoro nel repository directory:
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 di microservizi in esecuzione in Compute Engine dal cluster GKE.Vedrai una conferma del deployment e del modo in cui puoi accedervi. 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
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 sui contenuti pertinenti valutazioni.
Visualizza il mesh di servizi
In questa sezione utilizzerai Kiali per mostrare una rappresentazione visiva del servizio in mesh.
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 HTTP restituito di ogni richiesta (in questo caso200 OK
). 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 dell'attuale mesh con con il traffico indirizzato a servizi in esecuzione su GKE. Hai eseguito il deployment di due istanze di ciascun microservizio: una viene eseguita nell'istanza Compute Engine e l'altra nel cluster GKE. Tuttavia, poiché hai rimosso
WorkloadEntry
fa riferimento che puntano alle istanze dei microservizi vengono eseguiti in Compute Engine, i servizi selezionano solo il microservizio in esecuzione nel cluster GKE.Se non vedi il seguente diagramma sulla dashboard di Kiali, aggiorna nella pagina:
Il diagramma nella dashboard di Kiali mostra il traffico indirizzato a in esecuzione su GKE.
In Cloud Shell, per interrompere il comando di generazione del traffico, premi
Control+C
.
Ritira l'ambiente di origine
Poiché tutto il traffico viene ora instradato al cluster GKE, puoi arrestare le istanze del carico di lavoro in esecuzione in Compute Engine.
Durante una migrazione in produzione, tieni pronto il data center di origine per la 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 siano in atto meccanismi di backup e tolleranza di errore.
Il seguente diagramma mostra l'architettura del sistema per questa sezione:
Nel diagramma, Istio instrada il traffico ai servizi in esecuzione di GKE e i carichi di lavoro in esecuzione Compute Engine viene ritirato.
Per ritirare l'ambiente di origine:
In Cloud Shell, cambia la directory di lavoro nel repository directory:
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
interrompe i container in esecuzione in di Compute Engine.
Esegui la pulizia
Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse usati in questo deployment, elimina il progetto che contiene le risorse, o mantenere il progetto ed eliminare le singole risorse.
Elimina il progetto
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
Elimina le singole risorse
In Cloud Shell, imposta la directory di lavoro sulla directory del repository:
cd "${DEPLOYMENT_DIRECTORY_PATH}"/terraform
Elimina le risorse di cui hai eseguito il provisioning:
terraform destroy -auto-approve
Passaggi successivi
- Informazioni GKE
- Scopri di più su Istio.
- Per altre architetture di riferimento, diagrammi e best practice, esplora il Centro architetture cloud.