Esegui il deployment della migrazione con l'espansione del mesh Istio

Last reviewed 2023-11-02 UTC

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:

Architettura che utilizza un mesh di servizi per instradare il traffico ai microservizi in esecuzione nell'ambiente legacy 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 microservizi details, ratings e reviews per completare la pagina delle informazioni sul libro
  • details: fornisce informazioni sui libri
  • reviews: contiene recensioni di libri
  • ratings: 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. I nuovi utenti di Google Cloud possono essere idonei a una prova senza costi aggiuntivi.

prepara l'ambiente

Esegui la maggior parte dei passaggi per questo deployment in Cloud Shell.

  1. Nella console Google Cloud, attiva Cloud Shell.

    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.

  2. 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.

  3. Cambia la directory di lavoro nella directory ${HOME}:

    cd "${HOME}"
    
  4. 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
    
  5. 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.

  6. 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.

  1. In Cloud Shell, modifica la directory di lavoro nella directory del repository:

    cd "${DEPLOYMENT_DIRECTORY_PATH}"
    
  2. 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.
  3. Cambia la directory di lavoro nella directory terraform:

    cd "${DEPLOYMENT_DIRECTORY_PATH}"/terraform
    
  4. Applica le modifiche con Terraform:

    terraform apply
    
  5. 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:
  • 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:

Architettura di destinazione per l'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.

  1. In Cloud Shell, modifica la directory di lavoro nella directory del repository:

    cd "${DEPLOYMENT_DIRECTORY_PATH}"
    
  2. 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:

Ambiente di destinazione con Istio installato.

Nel diagramma, Istio espone il carico di lavoro in esecuzione in Compute Engine.

Installa Istio

  1. In Cloud Shell, modifica la directory di lavoro nella directory del repository:

    cd "${DEPLOYMENT_DIRECTORY_PATH}"
    
  2. 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.

  1. In Cloud Shell, modifica la directory di lavoro nella directory del repository:

    cd "${DEPLOYMENT_DIRECTORY_PATH}"
    
  2. 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.

  1. In Cloud Shell, modifica la directory di lavoro nella directory del repository:

    cd "${DEPLOYMENT_DIRECTORY_PATH}"
    
  2. 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"
    
  3. Lo script workloads.sh:

    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.

  1. 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.

  2. 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.

  3. 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 microservizio productpage in esecuzione sull'istanza Compute Engine con l'etichetta della versione compute-engine e al servizio kiali per visualizzare il mesh di servizi.

    Gli altri servizi non vengono visualizzati nel grafico (details, reviews e ratings) perché il microservizio productpage eseguito in Compute Engine si connette direttamente agli altri microservizi in esecuzione in Compute Engine. Il microservizio productpage 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.

    La dashboard di Kiali mostra come viene indirizzato il traffico.

    Il diagramma nella dashboard di Kiali mostra che il traffico viene instradato ai servizi in esecuzione in Compute Engine.

  4. 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:

Architettura di destinazione con traffico instradato a istanze di microservizi in Compute Engine e GKE.

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:

  1. In Cloud Shell, modifica la directory di lavoro nella directory del repository:

    cd "${DEPLOYMENT_DIRECTORY_PATH}"
    
  2. 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:

    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.

  1. 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
    
  2. 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
    [...]
    
  3. 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 o v3.

    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.

    La dashboard di Kiali mostra come viene indirizzato il traffico.

    Il diagramma nella dashboard di Kiali mostra il traffico instradato ai servizi in esecuzione in Compute Engine e ai servizi in esecuzione su GKE.

  4. 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:

Architettura di destinazione con traffico instradato al cluster GKE.

  1. In Cloud Shell, modifica la directory di lavoro nella directory del repository:

    cd "${DEPLOYMENT_DIRECTORY_PATH}"
    
  2. 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 riferimenti WorkloadEntry 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.

  1. 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
    
  2. 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
    [...]
    
  3. 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:

    La dashboard di Kiali mostra come viene indirizzato il traffico.

    Il diagramma sulla dashboard Kiali mostra il traffico instradato ai servizi in esecuzione in GKE.

  4. 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:

Ambiente di origine senza istanze di carichi di lavoro in esecuzione in Compute Engine.

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:

  1. In Cloud Shell, modifica la directory di lavoro nella directory del repository:

    cd "${DEPLOYMENT_DIRECTORY_PATH}"
    
  2. 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

  1. Nella console Google Cloud, vai alla pagina Gestisci risorse.

    Vai a Gestisci risorse

  2. Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
  3. Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Elimina le singole risorse

  1. In Cloud Shell, modifica la directory di lavoro nella directory del repository:

    cd "${DEPLOYMENT_DIRECTORY_PATH}"/terraform
    
  2. Elimina le risorse di cui hai eseguito il provisioning:

    terraform destroy -auto-approve
    

Passaggi successivi