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

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 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: chiama details, ratings e reviews microservizi per compilare la pagina delle informazioni sul libro
  • details: fornisce informazioni sui libri
  • reviews: contiene recensioni dei libri
  • ratings: 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. I nuovi utenti di Google Cloud potrebbero essere idonei per una prova gratuita.

prepara l'ambiente

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

  1. In the Google Cloud console, activate Cloud Shell.

    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.

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

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

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

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

  1. In Cloud Shell, imposta la directory di lavoro sulla 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 esegue le seguenti operazioni:

    • Genera i descrittori per configurare Backend Terraform.
    • Inizializza la directory di lavoro di 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 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:
  • 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:

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

  1. In Cloud Shell, cambia la directory di lavoro nel repository directory:

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

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, cambia la directory di lavoro nel repository directory:

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

  1. In Cloud Shell, cambia la directory di lavoro nel repository directory:

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

  1. In Cloud Shell, cambia la directory di lavoro nel repository directory:

    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 esegue le seguenti operazioni:

    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.

  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 del servizio 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 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 caso 200).

    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.

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

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

    La dashboard Kiali mostra come viene indirizzato il traffico.

    Il diagramma nella dashboard di Kiali mostra che il traffico viene indirizzato e i 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 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:

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

  1. In Cloud Shell, cambia la directory di lavoro nel repository directory:

    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 esegue le seguenti operazioni:

    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.

  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 delle date delle richieste HTTP al servizio productpage e Codice restituito HTTP di ogni richiesta (in questo caso 200 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
    [...]
    
  3. 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 o v3.

    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.

    La dashboard Kiali mostra come viene indirizzato il traffico.

    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.

  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, 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:

Architettura di destinazione con traffico indirizzato al cluster GKE.

  1. In Cloud Shell, cambia la directory di lavoro nel repository directory:

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

  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 HTTP restituito di ogni richiesta (in questo caso 200 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
    [...]
    
  3. 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:

    La dashboard Kiali mostra come viene indirizzato il traffico.

    Il diagramma nella dashboard di Kiali mostra il traffico indirizzato a in esecuzione su GKE.

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

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

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:

  1. In Cloud Shell, cambia la directory di lavoro nel repository directory:

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

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

Elimina le singole risorse

  1. In Cloud Shell, imposta la directory di lavoro sulla directory del repository:

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

    terraform destroy -auto-approve
    

Passaggi successivi