Migrazione da Istio 1.7 o versioni successive ad Anthos Service Mesh e Mesh CA

Questo documento descrive come gli amministratori di Google Kubernetes Engine (GKE) possono installare Anthos Service Mesh ed eseguire la migrazione dei carichi di lavoro attualmente in esecuzione con un mesh di servizi Istio. La configurazione di Anthos Service Mesh di cui è stato eseguito il deployment include Cloud Monitoring per la telemetria e l'autorità di certificazione Anthos Service Mesh (Mesh CA) per la gestione gestita dei certificati mesh ad alta disponibilità. Gateway, servizi virtuali e altre configurazioni di mesh che definiscono la tua topologia mesh vengono conservati nella migrazione.

Questa procedura riguarda un'installazione a cluster singolo. Per l'installazione di un mesh multi-cluster, consulta Configurare un mesh multi-cluster su GKE, che include la procedura per aggiungere cluster ad Anthos Service Mesh dopo l'installazione.

Per completare i passaggi in questo documento, devi utilizzare Istio 1.7 o versioni successive con un cluster GKE. Anthos Service Mesh non supporta Helm per l'installazione o la configurazione. Consigliamo agli amministratori di mesh di utilizzare l'API IstioOperator per le configurazioni mesh. Questo processo potrebbe comportare tempi di inattività per l'applicazione durante il cambio di autorità di certificazione, pertanto ti consigliamo di eseguire questa procedura durante un periodo di manutenzione pianificato.

Anthos Service Mesh utilizza le stesse API Istio e Envoy per configurare il tuo mesh, perciò non sono necessarie modifiche alle risorse esistenti.

Dopo la migrazione, alcune differenze di implementazione sono le seguenti:

  • Il piano di controllo Istio viene sostituito con un piano di controllo Anthos Service Mesh.

  • L'autorità di certificazione Citadel viene rimossa e i certificati vengono gestiti da un servizio Mesh CA di Google Cloud.

  • La Telemetria viene inviata a Cloud Logging e Cloud Monitoring. Dashboard e gestione degli SLO sono disponibili nella console Google Cloud.

  • Se disponi di una risorsa IstioOperator personalizzata, lo script può prenderla come input.

  • Viene eseguita la migrazione della tua installazione open source di Istio (versione 1.7 o successive) ad Anthos Service Mesh versione 1.10 con Mesh CA. Se hai una versione diversa di Istio o hai bisogno di una versione diversa di Anthos Service Mesh, oppure vuoi eseguire il deployment di Anthos Service Mesh con un piano di controllo gestito da Google, consulta Preparazione per la migrazione da Istio.

Prerequisiti

Per completare questa guida sono necessari i seguenti prerequisiti:

  • Hai un cluster GKE su cui è installato Istio versione 1.7 o successiva. Se non hai un cluster GKE o vuoi prima testare questa guida su un nuovo cluster (di test), segui i passaggi nell'appendice per creare un nuovo cluster GKE con Istio versione 1.7 o successiva di cui è stato eseguito il deployment con un'applicazione di test.

  • Utilizza Cloud Shell per eseguire i passaggi di questa guida perché questa guida viene testata su Cloud Shell.

Obiettivi

In questa guida, sceglierai un percorso di migrazione. Puoi scegliere tra un percorso in un solo passaggio o una migrazione con script passo passo.

Per ulteriori informazioni, vedi Scegliere un percorso di migrazione.

Per ricevere le risposte alle domande frequenti su questa migrazione, consulta le Domande frequenti sulla migrazione da Istio 1.7 o versioni successive ad Anthos Service Mesh e Mesh CA.

Prima di iniziare

Per questa guida, devi disporre dell'accesso amministrativo a un cluster GKE con Istio installato. Per osservare il comportamento dell'applicazione durante il processo di migrazione, ti consigliamo di eseguire prima questa procedura con un cluster in un ambiente di sviluppo o di gestione temporanea.

Anthos Service Mesh prevede i seguenti requisiti. Puoi eseguirle manualmente o consentire agli strumenti forniti di abilitare le dipendenze per conto tuo durante il processo di pre-installazione.

  1. Abilita le seguenti API Google Cloud:

    • container.googleapis.com
    • meshca.googleapis.com
    • meshconfig.googleapis.com
    • gkehub.googleapis.com
    • stackdriver.googleapis.com

  2. Abilita Workload Identity e Stackdriver per il cluster GKE.

  3. Etichetta il cluster per abilitare l'interfaccia utente del servizio.

  4. Ottieni i diritti di amministratore sul cluster Kubernetes.

  5. Registra il cluster in un parco risorse.

  6. Attiva la funzionalità servicemesh nel parco risorse.

Configura l'ambiente

Per configurare l'ambiente, segui questi passaggi:

  1. Nella console Google Cloud, attiva Cloud Shell.

    Attiva Cloud Shell

    Nella parte inferiore della pagina della console Google Cloud, viene avviata una sessione Cloud Shell che mostra un prompt della riga di comando. Cloud Shell è un ambiente shell in cui è già installato Google Cloud CLI e con valori già impostati per il progetto attuale. L'inizializzazione della sessione può richiedere alcuni secondi.

  2. Crea le variabili di ambiente utilizzate in questa guida:

    export PROJECT_ID=PROJECT_ID
gcloud config set project ${PROJECT_ID}
export PROJECT_NUM=$(gcloud projects describe ${PROJECT_ID} --format='value(projectNumber)')
export CLUSTER_NAME=GKE_CLUSTER_NAME
export CLUSTER_LOCATION=GKE_CLUSTER_REGION_OR_ZONE

  3. Crea una cartella WORKDIR:

    mkdir -p migrate-to-asm-working-dir && cd migrate-to-asm-working-dir && export WORKDIR=`pwd`

  4. Crea un file KUBECONFIG per questa guida:

    touch asm-kubeconfig && export KUBECONFIG=`pwd`/asm-kubeconfig

  5. Connettiti al tuo cluster GKE:

    Cluster di zona

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
   --zone ${CLUSTER_LOCATION}

    Cluster a livello di regione

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
   --region ${CLUSTER_LOCATION}

  6. Scarica lo script di migrazione:

    curl -LO https://storage.googleapis.com/csm-artifacts/asm/migrate-to-asm
chmod +x ./migrate-to-asm

Scegli un percorso di migrazione

Puoi scegliere uno dei due percorsi di cui eseguire la migrazione ad Anthos Service Mesh. Scegli solo una di queste due strategie, quindi vai alla sezione corrispondente:

  • Migrazione in un solo passaggio ad Anthos Service Mesh. Come suggerisce il nome, puoi eseguire tutti i passaggi richiesti per migrare ad Anthos Service Mesh utilizzando un singolo comando. Questo può essere utile se hai molti cluster e hai bisogno di un modo rapido e semplice per eseguirne l'upgrade ad Anthos Service Mesh. Tuttavia, questo metodo potrebbe causare tempi di inattività delle applicazioni.

  • Migrazione passo passo ad Anthos Service Mesh. Questo metodo ti offre un maggiore controllo su ogni passaggio e ti aiuta a capire esattamente cosa è necessario per eseguire la migrazione ad Anthos Service Mesh.

Migrazione in un solo passaggio ad Anthos Service Mesh

In questa sezione eseguirai la migrazione dell'installazione attuale di Istio versione 1.7 (o successiva) ad Anthos Service Mesh versione 1.10. Questa sezione ti consente di eseguire la migrazione eseguendo un singolo passaggio. Se vuoi eseguire la migrazione eseguendo una serie di passaggi, consulta la sezione Migrazione passo passo ad Anthos Service Mesh.

Per eseguire la migrazione ad Anthos Service Mesh, esegui questo comando. Con qualsiasi comando, puoi utilizzare il flag --dry-run per stampare i comandi invece di eseguirli oppure puoi usare il flag --verbose per stampare i comandi mentre lo script li esegue. Se hai già configurato le dipendenze, come indicato nella sezione Prima di iniziare, puoi omettere il flag --enable-dependencies.

Nessuna risorsa personalizzata

Non utilizzare una risorsa IstioOperator personalizzata:

./migrate-to-asm migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID \
    --enable-dependencies \
    --verbose

Utilizza risorsa personalizzata

Utilizza una risorsa IstioOperator personalizzata:

export ISTIO_OPERATOR_FILEPATH=PATH_OF_ISTIO_OPERATOR_YAML_FILE

./migrate-to-asm migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID \
    --enable-dependencies \
    --custom_overlay ${ISTIO_OPERATOR_FILEPATH} \
    --verbose

Questo comando esegue i seguenti passaggi:

  • Assicurati che la versione di Istio sia 1.7 o successiva.
  • Abilita Workload Identity sul cluster. Workload Identity è obbligatorio per Mesh CA. Non è necessario abilitare il server metadati GKE sui pool di nodi esistenti.
  • Abilita le API richieste per Anthos Service Mesh.
  • Registra il cluster in un parco risorse.
  • Aggiorna il cluster con le etichette richieste.
  • Valuta se un piano di controllo gestito da Google è migliore per il cluster specificato.
  • Esegue il deployment di Anthos Service Mesh con la configurazione ottimale del piano di controllo.
  • Rietichetta tutti gli spazi dei nomi abilitati per Istio con l'etichetta Anthos Service Mesh richiesta.
  • Riavvio dei carichi di lavoro in tutti gli spazi dei nomi abilitati per Anthos Service Mesh in modo che i carichi di lavoro ricevano i nuovi proxy Anthos Service Mesh.
  • Rimuove il piano di controllo Istio.

Migrazione passo passo ad Anthos Service Mesh

In questa sezione eseguirai la migrazione dell'installazione di Istio versione 1.7 (o successive) ad Anthos Service Mesh versione 1.10. Questa sezione ti consente di eseguire la migrazione eseguendo una serie di passaggi. Se vuoi eseguire la migrazione in un solo passaggio, consulta la sezione Migrazione in un solo passaggio ad Anthos Service Mesh.

Per eseguire la migrazione ad Anthos Service Mesh sono necessari i seguenti passaggi:

  1. Esegui un passaggio di pre-migrazione per convalidare e preparare il cluster e l'ambiente per la migrazione ad Anthos Service Mesh.
  2. Installa Anthos Service Mesh come piano di controllo canary insieme a un piano di controllo Istio esistente e prepara i carichi di lavoro.
  3. Testa i carichi di lavoro su Anthos Service Mesh e rietichetta gli spazi dei nomi per l'inserimento collaterale di Anthos Service Mesh.
  4. Accedi alle dashboard di Anthos Service Mesh e controllale.
  5. Esegui la pulizia degli artefatti Istio o esegui il rollback a una versione di Istio esistente.

Esegui il passaggio di pre-migrazione

Il passaggio di pre-migrazione esegue le seguenti azioni:

  • Convalida che le informazioni sul progetto e sul cluster sono corrette e che la versione di Istio installata è compatibile con la migrazione.

  • Esegue il backup della configurazione del gateway predefinito e delle etichette del mesh di servizi Istio attuale.

  • Se viene utilizzato il flag --enable-dependencies, abilita le dipendenze per tuo conto, altrimenti verifica che le dipendenze siano abilitate.

Lo script di pre-migrazione crea una nuova cartella (o sovrascrive una cartella esistente) denominata configuration_backup nella directory corrente.

Per eseguire il passaggio di pre-migrazione, esegui questo comando:

Dipendenze

Abilita le dipendenze:

./migrate-to-asm pre-migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID \
    --enable-dependencies

Nessuna dipendenza

Non abilitare le dipendenze:

./migrate-to-asm pre-migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID

L'output è simile al seguente:

    migrate-to-asm: Checking installation tool dependencies...
    migrate-to-asm: Checking for $PROJECT_ID...
    migrate-to-asm: Confirming cluster information for $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
    migrate-to-asm: Confirming node pool requirements for $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
    migrate-to-asm: Checking existing Istio version(s)...
    migrate-to-asm:   1.9.5
    migrate-to-asm: No version issues found.
    migrate-to-asm: Enabling required APIs...
    migrate-to-asm:
    migrate-to-asm: APIs enabled.
    migrate-to-asm: Enabling the service mesh feature...
    migrate-to-asm:
    migrate-to-asm: The service mesh feature is already enabled.
    migrate-to-asm: Enabling Stackdriver on $LOCATION/$CLUSTER_NAME...
    Updating $CLUSTER_NAME...
    .........................done.
    Updated [https://container.googleapis.com/v1/projects/$PROJECT_ID/zones/$LOCATION/clusters/$CLUSTER_NAME].
    To inspect the contents of your cluster, go to: https://console.cloud.google.com/kubernetes/workload_/gcloud/$LOCATION/$CLUSTER_NAME?project=$PROJECT_ID
    migrate-to-asm:
    migrate-to-asm: Stackdriver enabled.
    migrate-to-asm: Querying for core/account...
    migrate-to-asm: Binding user@example.com to cluster admin role...
    migrate-to-asm:
    migrate-to-asm:
    migrate-to-asm: Successfully bound to cluster admin role.
    migrate-to-asm: Initializing meshconfig API...
      % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                     Dload  Upload   Total   Spent    Left  Speed
    100     3    0     3    0     0      6      0 --:--:-- --:--:-- --:--:--     6
    migrate-to-asm:
    migrate-to-asm: Finished pre-migration!

Installa Anthos Service Mesh e prepara i carichi di lavoro

Questo passaggio comporta quanto segue:

  • Verifica la presenza della cartella configuration_backup e, se non è presente, viene interrotta per garantire che lo strumento di pre-migrazione abbia funzionato correttamente.
  • Installa e configura un piano di controllo Anthos Service Mesh basato sull'analisi della configurazione di cluster e mesh.
  • Utilizza la risorsa IstioOperator personalizzata, se ne viene fornita una. Se hai gateway personalizzati o più gateway che hai configurato utilizzando una risorsa IstioOperator, utilizza la stessa risorsa in questo passaggio.

Per saltare l'analisi e forzare lo strumento a installare un piano di controllo non gestito in esecuzione con le risorse del tuo cluster, aggiungi il flag --no-mcp al comando.

Quando installi Anthos Service Mesh, puoi scegliere uno dei tre percorsi seguenti:

  • Opzione 1: senza una risorsa IstioOperator personalizzata. Puoi installare Anthos Service Mesh senza una risorsa personalizzata. Utilizzando questa opzione, viene installata la configurazione predefinita di Istio e viene aggiornato quello predefinito di istio-ingressgateway.

  • Opzione 2: con un'opzione di --no-gateways. Quando installi Anthos Service Mesh senza una risorsa IstioOperator personalizzata, puoi anche utilizzare l'opzione --no-gateways per non aggiornare il valore predefinito di istio-ingressgateway. Se utilizzi questa opzione, devi eseguire manualmente l'upgrade dei gateway dopo l'installazione.

  • Opzione 3: con una risorsa IstioOperator personalizzata. Puoi installare Anthos Service Mesh con una risorsa IstioOperator personalizzata. Se hai eseguito il deployment di Istio utilizzando una risorsa IstioOperator personalizzata, ti consigliamo di utilizzare la stessa risorsa IstioOperator durante l'installazione di Anthos Service Mesh.

Per installare Anthos Service Mesh, esegui uno dei seguenti comandi:

Opzione 1

Esegui l'upgrade del valore predefinito di istio-ingressgateway:

 ./migrate-to-asm install-asm \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID

Opzione 2

Non eseguire l'upgrade del valore predefinito di istio-ingressgateway:

 ./migrate-to-asm install-asm \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID \
     --no-gateways

Opzione 3

Esegui l'upgrade dei gateway attivi con una risorsa IstioOperator personalizzata:

 export ISTIO_OPERATOR_FILEPATH=PATH_OF_ISTIO_OPERATOR_YAML_FILE

 ./migrate-to-asm install-asm \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID \
     --custom-overlay ${ISTIO_OPERATOR_FILEPATH}

L'output è simile al seguente:

 migrate-to-asm: Checking installation tool dependencies...
 migrate-to-asm: Checking for $PROJECT_ID...
 migrate-to-asm: Fetching/writing Google Cloud credentials to kubeconfig file...
 Fetching cluster endpoint and auth data.
 kubeconfig entry generated for $CLUSTER_NAME.
 migrate-to-asm:
 migrate-to-asm: Verifying connectivity (20s)...
 migrate-to-asm: kubeconfig set to $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
 migrate-to-asm: Configuring kpt package...
 asm/
 set 20 field(s) of setter "gcloud.container.cluster" to value "$CLUSTER_NAME"
 asm/
 set 28 field(s) of setter "gcloud.core.project" to value "$PROJECT_ID"
 asm/
 set 2 field(s) of setter "gcloud.project.projectNumber" to value "42"
 asm/
 set 5 field(s) of setter "gcloud.project.environProjectNumber" to value "42"
 asm/
 set 20 field(s) of setter "gcloud.compute.location" to value "$LOCATION"
 asm/
 set 1 field(s) of setter "gcloud.compute.network" to value "$PROJECT_ID-default"
 asm/
 set 6 field(s) of setter "anthos.servicemesh.rev" to value "asm-1102-2"
 asm/
 set 5 field(s) of setter "anthos.servicemesh.tag" to value "1.10.2-asm.2"
 asm/
 set 4 field(s) of setter "anthos.servicemesh.hubTrustDomain" to value "$PROJECT_ID.svc.id.goog"
 asm/
 set 2 field(s) of setter "anthos.servicemesh.hub-idp-url" to value "https://container.googleapis.com/v1/projects/$PROJECT_ID/locations/$LOCATION/clusters/$CLUSTER_NAME"
 asm/
 set 4 field(s) of setter "anthos.servicemesh.trustDomainAliases" to value "$PROJECT_ID.svc.id.goog"
 migrate-to-asm: Configured.
 migrate-to-asm: Installing Anthos Service Mesh control plane...
 migrate-to-asm:
 - Processing resources for Istio core.
 ✔ Istio core installed
 - Processing resources for Istiod.
 - Processing resources for Istiod. Waiting for Deployment/istio-system/istiod-asm-1102-2
 ✔ Istiod installed
 - Processing resources for CNI, Ingress gateways.
 - Processing resources for CNI, Ingress gateways. Waiting for Deployment/istio-system/istio-ingressgateway
 ✔ CNI installed
 - Processing resources for Ingress gateways. Waiting for Deployment/istio-system/istio-ingressgateway
 ✔ Ingress gateways installed
 - Pruning removed resources
 migrate-to-asm:
 migrate-to-asm:
 namespace/asm-system created
 customresourcedefinition.apiextensions.k8s.io/canonicalservices.anthos.cloud.google.com configured
 role.rbac.authorization.k8s.io/canonical-service-leader-election-role created
 clusterrole.rbac.authorization.k8s.io/canonical-service-manager-role configured
 clusterrole.rbac.authorization.k8s.io/canonical-service-metrics-reader unchanged
 serviceaccount/canonical-service-account created
 rolebinding.rbac.authorization.k8s.io/canonical-service-leader-election-rolebinding created
 clusterrolebinding.rbac.authorization.k8s.io/canonical-service-manager-rolebinding unchanged
 clusterrolebinding.rbac.authorization.k8s.io/canonical-service-proxy-rolebinding unchanged
 service/canonical-service-controller-manager-metrics-service created
 deployment.apps/canonical-service-controller-manager created
 deployment.apps/canonical-service-controller-manager condition met
 migrate-to-asm:
 migrate-to-asm:
 migrate-to-asm: *******
 migrate-to-asm: Control plane installation complete!

Reinserisci i carichi di lavoro e controlla il comportamento dell'applicazione

Il piano di controllo Anthos Service Mesh è ora pronto per gestire i carichi di lavoro, ma il piano di controllo Istio esistente sta ancora gestendo i carichi di lavoro esistenti. Per eseguire la migrazione di questi carichi di lavoro, devi rietichettare gli spazi dei nomi Kubernetes attualmente etichettati per l'inserimento di Istio, con l'etichetta di revisione di Anthos Service Mesh. Devi quindi riavviare i carichi di lavoro in questi spazi dei nomi. Puoi eseguire questa operazione manualmente (vedi la nota nel passaggio 1) o in un solo passaggio utilizzando lo strumento.

Il passaggio di rietichettatura permette di:

  • Trova tutti gli spazi dei nomi che attualmente utilizzano un'etichetta di inserimento Istio.
  • Questi spazi dei nomi vengono etichettati di nuovo con istio.io/rev=asm-1102-2.
  • Riavvia i carichi di lavoro nello spazio dei nomi.

Per inserire nuovamente i carichi di lavoro:

  1. Rietichetta tutti gli spazi dei nomi abilitati per Istio e riavvia i carichi di lavoro eseguendo questo comando:

     ./migrate-to-asm relabel \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID

    L'output è simile al seguente:

    migrate-to-asm: Checking installation tool dependencies...
migrate-to-asm: Checking for $PROJECT_ID...
migrate-to-asm: Fetching/writing Google Cloud credentials to kubeconfig file...
Fetching cluster endpoint and auth data.
kubeconfig entry generated for $CLUSTER_NAME.
migrate-to-asm:
migrate-to-asm: Verifying connectivity (20s)...
migrate-to-asm: kubeconfig set to $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
******
migrate-to-asm: Installation of Anthos Service Mesh has completed. Migration will continue
migrate-to-asm: by relabeling and restarting workloads in the following namespaces:
migrate-to-asm:     namespace/default
migrate-to-asm:
Continue with migration? (Y/n)Y
migrate-to-asm: Relabeling namespace/default...
namespace/default labeled
migrate-to-asm: Restarting workloads in namespace/default and waiting for them to become available (max 5 min)...
deployment.apps/frontend restarted
deployment.apps/backend restarted
deployment.apps/frontend condition met
deployment.apps/backend condition met
migrate-to-asm: *******
migrate-to-asm: Finished restarting workloads!

  2. Attendi il riavvio di tutti i deployment, quindi controlla la versione del piano dati eseguendo questo comando:

    istioctl version

    L'output è simile al seguente:

    client version: 1.8.0
pilot version: 1.9.5
istiod version: 1.10.2-asm.2
data plane version: 1.10.2-asm.2 (14 proxies)

  3. Verifica che le applicazioni funzionino correttamente dopo il riavvio.

Accedi alle dashboard di Anthos Service Mesh

In questa sezione, vai alle dashboard di Anthos Service Mesh e assicurati di ricevere i segnali finali per tutti i servizi. Dovresti anche riuscire a vedere la topologia della tua applicazione.

  1. Nella console Google Cloud, vai alla pagina Anthos Service Mesh.

    Vai ad Anthos Service Mesh

  2. Dovresti essere in grado di visualizzare le metriche e la topologia dei tuoi servizi.

Per scoprire di più sulle dashboard di Anthos Service Mesh, consulta Esplorazione di Anthos Service Mesh nella console Google Cloud.

Finalizza la migrazione

Prima di finalizzare la migrazione, assicurati che tutte le applicazioni funzionino correttamente. Dopo aver finalizzato la migrazione, non puoi eseguire il rollback alla versione esistente di Istio. Il completamento della migrazione prevede i seguenti passaggi:

  • Convalida che tutti i proxy in esecuzione nel cluster utilizzano Anthos Service Mesh.
  • Rimuove i componenti Istio inutilizzati dal cluster. Questo passaggio è irreversibile.

Per finalizzare la migrazione ad Anthos Service Mesh, esegui questo comando:

 ./migrate-to-asm finalize \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID
L'output è simile al seguente: 
migrate-to-asm: Checking installation tool dependencies...
migrate-to-asm: Checking for asm-scriptaro-oss...
migrate-to-asm: All proxies running Anthos Service Mesh!
Remove previous control plane resources? (Y/n)
migrate-to-asm: ****
migrate-to-asm: Previous Istio control plane has been removed.

Esegui il rollback a una versione di Istio esistente

Esegui il passaggio di rollback per rietichettare gli spazi dei nomi con la precedente etichetta di inserimento Istio, riavvia i carichi di lavoro ed esegui il rollback delle modifiche al gateway. In seguito, lo strumento rimuove tutti i componenti Anthos Service Mesh di cui è stato eseguito il deployment nel cluster.

Dovrai ripristinare manualmente tutte le dipendenze attivate dal passaggio di pre-migrazione.

Per eseguire il rollback a Istio, esegui questo comando:

 ./migrate-to-asm rollback \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID
L'output è simile al seguente: 
migrate-to-asm: Checking installation tool dependencies...
migrate-to-asm: Checking for $PROJECT_ID...
******
migrate-to-asm: Rolling back migration by relabeling and restarting workloads
migrate-to-asm: in the following namespaces:
migrate-to-asm:     namespace/default
migrate-to-asm:
Continue with rollback? (Y/n)
migrate-to-asm: Relabeling namespace/default...
namespace/default labeled
migrate-to-asm: Restarting workloads in namespace/default and waiting for them to become available (max 5 min)...
deployment.apps/frontend restarted
deployment.apps/backend restarted
deployment.apps/frontend condition met
deployment.apps/backend condition met
migrate-to-asm: *******
migrate-to-asm: Finished restarting workloads!
service/istio-ingressgateway configured
deployment.apps/istio-ingressgateway configured
There are still 14 proxies pointing to the control plane revision asm-1102-2
istio-ingressgateway-66c85975d-2gt8c.istio-system
istio-ingressgateway-66c85975d-jdd96.istio-system
...
frontend-685dcb78d6-9l45j.default
If you proceed with the uninstall, these proxies will become detached from any control plane and will not function correctly.

Removed HorizontalPodAutoscaler:istio-system:istio-ingressgateway.
Removed HorizontalPodAutoscaler:istio-system:istiod-asm-1102-2.
...
Removed ClusterRoleBinding::mdp-controller.
✔ Uninstall complete
namespace "asm-system" deleted
migrate-to-asm: ****
migrate-to-asm: Anthos Service Mesh has been uninstalled from the cluster.

Appendice

Crea un cluster GKE con Istio installato

In questa sezione eseguirai il deployment di un cluster GKE con Istio abilitato. Puoi utilizzare un cluster GKE privato o non privato. I cluster GKE privati devono avere un endpoint GKE pubblico. Dovrai anche verificare l'installazione di Istio.

Se hai già un cluster GKE, puoi saltare il passaggio di creazione e assicurarti di avere accesso al cluster che utilizza il file KUBECONFIG. Il contesto utilizzato in questa guida è definito nella variabile ${CLUSTER_1_CTX}. Puoi impostare il contesto del tuo cluster su questa variabile.

  1. Crea le variabili di ambiente utilizzate in questa guida:

    # Enter your project ID
export PROJECT_ID=PROJECT_ID
gcloud config set project ${PROJECT_ID}
export PROJECT_NUM=$(gcloud projects describe ${PROJECT_ID} --format='value(projectNumber)')
export CLUSTER_NAME=GKE_CLUSTER_NAME
export CLUSTER_LOCATION=GKE_CLUSTER_REGION_OR_ZONE
export CLUSTER_CTX=gke_${PROJECT_ID}_${CLUSTER_LOCATION}_${CLUSTER_NAME}
export ISTIO_VERSION=ISTIO_VERSION # Must be versions 1.7 through 1.10 and must be of the form major.minor.patch, for example 1.7.4 or 1.9.5

  2. Crea un cluster GKE con Istio abilitato (questo è un cluster privato). Puoi eseguire questi passaggi anche con un cluster GKE non privato.

    Cluster di zona

    gcloud container clusters create ${CLUSTER_NAME} \
    --project ${PROJECT_ID} \
    --zone ${CLUSTER_LOCATION} \
    --machine-type "e2-standard-4" \
    --num-nodes "4" --min-nodes "2" --max-nodes "5" \
    --enable-ip-alias --enable-autoscaling

    Cluster a livello di regione

    gcloud container clusters create ${CLUSTER_NAME} \
    --project ${PROJECT_ID} \
    --region ${CLUSTER_LOCATION} \
    --machine-type "e2-standard-4" \
    --num-nodes "4" --min-nodes "2" --max-nodes "5" \
    --enable-ip-alias --enable-autoscaling

  3. Conferma che il cluster sia RUNNING:

     gcloud container clusters list

    L'output è simile al seguente:

    NAME      LOCATION    MASTER_VERSION    MASTER_IP      MACHINE_TYPE   NODE_VERSION      NUM_NODES  STATUS
gke-east  us-east1-b  1.19.10-gke.1600  34.73.171.206  e2-standard-4  1.19.10-gke.1600  4          RUNNING

  4. Connettiti al cluster:

    Cluster di zona

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
    --zone ${CLUSTER_LOCATION}

    Cluster a livello di regione

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
    --region ${CLUSTER_LOCATION}

Ricordati di annullare l'impostazione della variabile KUBECONFIG alla fine.

Installa Istio

In questa sezione eseguirai il deployment di Istio versione 1.7 nel cluster GKE.

  1. Scarica Istio:

    curl -L https://istio.io/downloadIstio | ISTIO_VERSION=${ISTIO_VERSION} TARGET_ARCH=x86_64 sh -

  2. Installa Istio utilizzando lo strumento a riga di comando istioctl. Scegli un'opzione tra le seguenti:

    • Opzione 1: senza una risorsa IstioOperator personalizzata

    • Opzione 2: con una risorsa IstioOperator personalizzata

    Opzione 1

    Senza una risorsa IstioOperator personalizzata:

    ./istio-${ISTIO_VERSION}/bin/istioctl install --set profile=default -y

    L'output è simile al seguente:

    ✔ Istio core installed
✔ Istiod installed
✔ Ingress gateways installed
✔ Installation complete

    Opzione 2

    Con una risorsa IstioOperator personalizzata:

    cat <<EOF > istio-operator.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
 name: istio-operator
spec:
 components:
   base:
     enabled: true
   ingressGateways:
   - enabled: true
     k8s:
       env:
       - name: TERMINATION_DRAIN_DURATION_SECONDS
         value: "10"
       hpaSpec:
         maxReplicas: 10
         metrics:
         - resource:
             name: cpu
             targetAverageUtilization: 80
           type: Resource
         minReplicas: 2
       resources:
         limits:
           cpu: "4"
           memory: 8Gi
         requests:
           cpu: "2"
           memory: 4Gi
       service:
         ports:
         - name: status-port
           port: 15021
           targetPort: 15021
         - name: http2
           port: 80
           targetPort: 8080
         - name: https
           port: 443
           targetPort: 8443
         - name: tls
           port: 15443
           targetPort: 15443
     name: istio-ingressgateway
   - enabled: true
     k8s:
       env:
       - name: TERMINATION_DRAIN_DURATION_SECONDS
         value: "10"
       hpaSpec:
         maxReplicas: 10
         minReplicas: 2
       resources:
         limits:
           cpu: "4"
           memory: 8Gi
         requests:
           cpu: "2"
           memory: 4Gi
       service:
         ports:
         - name: status-port
           port: 15021
           targetPort: 15021
         - name: http2
           port: 80
           targetPort: 8080
         - name: https
           port: 443
           targetPort: 8443
         - name: tls
           port: 15443
           targetPort: 15443
     label:
       istio: istio-api-ingressgateway
     name: istio-api-ingressgateway
 meshConfig:
   defaultConfig:
     tracing:
       sampling: 1
       zipkin:
         address: jaeger-collector.observability.svc.cluster.local:9411
   enableTracing: true
EOF

./istio-${ISTIO_VERSION}/bin/istioctl install -f istio-operator.yaml -y

    L'output è simile al seguente:

    ✔ Istio core installed
✔ Istiod installed
✔ Ingress gateways installed
✔ Installation complete

  3. Assicurati che venga eseguito il deployment dei servizi e dei pod Istio e che siano in esecuzione:

    kubectl --context=${CLUSTER_CTX} -n istio-system get services,pods

    L'output è simile al seguente:

    Opzione 1

    Senza una risorsa IstioOperator personalizzata:

    NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP         PORT(S)                                                      AGE
service/istio-ingressgateway   LoadBalancer   10.64.5.113    <pending>           15021:31285/TCP,80:31740/TCP,443:30753/TCP,15443:31246/TCP   33s
service/istiod                 ClusterIP      10.64.15.184   <none>              15010/TCP,15012/TCP,443/TCP,15014/TCP,853/TCP                45s

NAME                                        READY   STATUS    RESTARTS   AGE
pod/istio-ingressgateway-6f44d6745b-22q9h   1/1     Running   0          34s
pod/istiod-b89f5cc6-nhsrc                   1/1     Running   0          48s

    Opzione 2

    Con una risorsa IstioOperator personalizzata:

    NAME                               TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)                                                      AGE
service/istio-api-ingressgateway   LoadBalancer   10.100.0.84    104.196.26.108   15021:32489/TCP,80:30083/TCP,443:30565/TCP,15443:30705/TCP   76s
service/istio-ingressgateway       LoadBalancer   10.100.3.221   34.139.111.125   15021:30966/TCP,80:31557/TCP,443:31016/TCP,15443:31574/TCP   75s
service/istiod                     ClusterIP      10.100.13.72   <none>           15010/TCP,15012/TCP,443/TCP,15014/TCP                        86s

NAME                                            READY   STATUS    RESTARTS   AGE
pod/istio-api-ingressgateway-79978ddc65-hslbv   1/1     Running   0          61s
pod/istio-api-ingressgateway-79978ddc65-z92w8   1/1     Running   0          77s
pod/istio-ingressgateway-fb47c4859-pkdn7        1/1     Running   0          60s
pod/istio-ingressgateway-fb47c4859-t2pfq        1/1     Running   0          77s
pod/istiod-9445656d7-fxk9j                      1/1     Running   0          89s

Implementa Boutique online

In questa sezione eseguirai il deployment nel cluster GKE di un'applicazione di esempio basata su microservizi, basata Online. Il deployment di Online Boutique viene eseguito in uno spazio dei nomi abilitato per Istio. verificherai che l'applicazione funzioni e che Istio inserisca i proxy sidecar in ogni pod.

Se hai già cluster con applicazioni, puoi saltare la creazione di un nuovo spazio dei nomi e il deployment di Online Boutique. Puoi seguire la stessa procedura per tutti gli spazi dei nomi nella sezione Installa Anthos Service Mesh e prepara i carichi di lavoro.

  1. Esegui il deployment di Online Boutique nel cluster GKE:

    kpt pkg get \
https://github.com/GoogleCloudPlatform/microservices-demo.git/release \
online-boutique

kubectl --context=${CLUSTER_CTX} create namespace online-boutique
kubectl --context=${CLUSTER_CTX} label namespace online-boutique istio-injection=enabled

kubectl --context=${CLUSTER_CTX} -n online-boutique apply -f online-boutique

  2. Attendi che tutti i deployment siano pronti:

    kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment adservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment checkoutservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment currencyservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment emailservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment frontend
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment paymentservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment productcatalogservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment shippingservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment cartservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment loadgenerator
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment recommendationservice

  3. Assicurati che ci siano due container per pod: il container dell'applicazione e il proxy sidecar Istio che Istio inserisce automaticamente nel pod:

    kubectl --context=${CLUSTER_CTX} -n online-boutique get pods

    L'output è simile al seguente:

    NAME                                     READY   STATUS    RESTARTS   AGE
adservice-7cbc9bd9-t92k4                 2/2     Running   0          3m21s
cartservice-d7db78c66-5qfmt              2/2     Running   1          3m23s
checkoutservice-784bfc794f-j8rl5         2/2     Running   0          3m26s
currencyservice-5898885559-lkwg4         2/2     Running   0          3m23s
emailservice-6bd8b47657-llvgv            2/2     Running   0          3m27s
frontend-764c5c755f-9wf97                2/2     Running   0          3m25s
loadgenerator-84cbcd768c-5pdbr           2/2     Running   3          3m23s
paymentservice-6c676df669-s779c          2/2     Running   0          3m25s
productcatalogservice-7fcf4f8cc-hvf5x    2/2     Running   0          3m24s
recommendationservice-79f5f4bbf5-6st24   2/2     Running   0          3m26s
redis-cart-74594bd569-pfhkz              2/2     Running   0          3m22s
shippingservice-b5879cdbf-5z7m5          2/2     Running   0          3m22s

  4. Puoi anche controllare la versione del proxy Envoy del file sidecar da uno qualsiasi dei pod per confermare che sia stato eseguito il deployment dei proxy Envoy versione 1.4 di Istio:

    export FRONTEND_POD=$(kubectl get pod -n online-boutique -l app=frontend --context=${CLUSTER_CTX} -o jsonpath='{.items[0].metadata.name}')
kubectl --context=${CLUSTER_CTX} get pods ${FRONTEND_POD} -n online-boutique -o json | jq '.status.containerStatuses[].image'

    L'output è simile al seguente:

    "docker.io/istio/proxyv2:1.7.4"
"gcr.io/google-samples/microservices-demo/frontend:v0.3.4"

  5. Accedi all'applicazione passando all'indirizzo IP dell'indirizzo IP del servizio istio-ingressgateway:

    kubectl --context=${CLUSTER_CTX} -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

Passaggi successivi