Anthos Service Mesh 1.10 ha raggiunto la fine del ciclo di vita e non è più supportato. Vedi Upgrade dalle versioni precedenti.

Visualizza la documentazione più recente o seleziona un'altra versione disponibile:

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

Questo documento descrive in che modo 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 dei certificati mesh gestiti ad alta disponibilità. Gateway, servizi virtuali e altre configurazioni mesh che definiscono la tua topologia mesh vengono conservati nella migrazione.

Questo processo riguarda l'installazione di un singolo cluster. Per l'installazione di un mesh multi-cluster, consulta la sezione Configurare un mesh multi-cluster su GKE, che include i passaggi su come aggiungere cluster ad Anthos Service Mesh dopo l'installazione.

Per completare i passaggi di 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 mesh di utilizzare l'API IstioOperator per le configurazioni mesh. Questo processo potrebbe comportare un tempo di inattività dell'applicazione durante il passaggio da un'autorità di certificazione a un'altra, pertanto ti consigliamo di eseguire questa procedura durante un periodo di manutenzione pianificata.

Anthos Service Mesh utilizza le stesse API Istio e Envoy per configurare il mesh, così non è necessaria alcuna modifica alle risorse esistenti.

Ecco alcune differenze di implementazione dopo la migrazione:

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

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

  • La telemetria viene inviata a Cloud Logging e Cloud Monitoring. Dashboard e gestione degli SLO sono disponibili in Google Cloud Console.

  • Se hai una risorsa IstioOperator personalizzata, lo script può utilizzarla come input.

  • Viene eseguita la migrazione dell'installazione Istio open source (versione 1.7 o successiva) 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 o vuoi eseguire il deployment di Anthos Service Mesh con un piano di controllo gestito da Google, consulta Preparazione alla migrazione da Istio.

Prerequisiti

Per completare questa guida, sono necessari i seguenti prerequisiti:

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

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

Obiettivi

In questa guida, scegli un percorso di migrazione. Puoi scegliere tra un percorso basato su script o una migrazione passo passo con script.

Per saperne di più, vedi Scegliere un percorso di migrazione.

Per ottenere 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, è necessario l'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 questo processo con un cluster in un ambiente di sviluppo o temporaneo.

Anthos Service Mesh soddisfa i seguenti requisiti. Puoi eseguirli manualmente o consentire agli strumenti forniti di attivare le dipendenze per tuo conto durante il processo di preinstallazione.

  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 tuo cluster GKE.

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

  4. Ottenere i diritti di amministratore del cluster su Kubernetes.

  5. Registra il cluster in un flotte.

  6. Attiva la funzionalità servicemesh sul parco risorse.

Configura l'ambiente

Per configurare l'ambiente:

  1. In Google Cloud Console, attiva Cloud Shell.

    Attiva Cloud Shell

    Nella parte inferiore della pagina della console, viene avviata una sessione Cloud Shell e viene visualizzato un prompt della riga di comando. Cloud Shell è un ambiente shell con l'interfaccia a riga di comando di Google Cloud già installato e con valori già impostati per il progetto corrente. 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 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. Disabilita l'interfaccia a riga di comando gestita modificando il CRD di ControlPlaneRevision e applicando l'etichetta mesh.cloud.google.com/managed-cni-enabled: "false":

    apiVersion: mesh.cloud.google.com/v1beta1
    kind: ControlPlaneRevision
    metadata:
      labels:
        mesh.cloud.google.com/managed-cni-enabled: "false"
    

    Tieni presente che questo passaggio può richiedere fino a cinque minuti prima che il riconciliatore applichi la modifica.

  7. 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 per eseguire la migrazione ad Anthos Service Mesh. Scegli una di queste due strategie e poi prosegui con la sezione che segue:

  • Migrazione in un solo passaggio ad Anthos Service Mesh. Come suggerito dal nome stesso, puoi eseguire tutti i passaggi necessari per eseguire la migrazione 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 un tempo di inattività dell'applicazione.

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

Migrazione in un passaggio ad Anthos Service Mesh

In questa sezione eseguirai la migrazione della tua installazione corrente 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 dettagliata ad Anthos Service Mesh.

Per eseguire la migrazione ad Anthos Service Mesh, esegui il comando seguente. Con qualsiasi comando, puoi utilizzare il flag --dry-run per stampare i comandi anziché eseguirli oppure puoi utilizzare il flag --verbose per stampare i comandi mentre lo script li esegue. Se in precedenza hai 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:

  • Garantisce che la versione di Istio sia la versione 1.7 o successiva.
  • Abilita Workload Identity nel cluster. Workload Identity è obbligatorio per Mesh CA. Non è necessario abilitare il server di metadati GKE sui pool di nodi esistenti.
  • Abilita le API richieste per Anthos Service Mesh.
  • Registra il cluster a 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 obbligatoria Anthos Service Mesh.
  • Riavvia i 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 dettagliata ad Anthos Service Mesh

In questa sezione eseguirai la migrazione dell'installazione di Istio versione 1.7 (o successiva) 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 passaggio ad Anthos Service Mesh.

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

  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 ed etichetta nuovamente gli spazi dei nomi per l'inserimento sidecar di Anthos Service Mesh.
  4. Accedi e analizza le dashboard di Anthos Service Mesh.
  5. Pulire gli artefatti Istio o eseguire il rollback a una versione Istio esistente.

Esegui il passaggio precedente alla migrazione

Il passaggio precedente alla 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.

  • Effettua il backup della configurazione per il gateway predefinito e le etichette per il mesh di servizi Istio attuale.

  • Il flag --enable-dependencies, se utilizzato, 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 migrazione preliminare, esegui il comando seguente:

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 prevede quanto segue:

  • Controlla la presenza della cartella configuration_backup e, se non è presente, interrompe l'esecuzione dello strumento di pre-migrazione.
  • Installa e configura un piano di controllo Anthos Service Mesh in base all'analisi della configurazione del cluster e del mesh.
  • Utilizza la risorsa personalizzata IstioOperator, se disponibile. 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 cluster, aggiungi il flag --no-mcp al comando.

Puoi scegliere uno dei tre percorsi durante l'installazione di Anthos Service Mesh:

  • Opzione 1: senza una risorsa IstioOperator personalizzata. Puoi installare Anthos Service Mesh senza una risorsa personalizzata. L'utilizzo di questa opzione installa la configurazione predefinita di Istio e aggiorna il valore predefinito di istio-ingressgateway.

  • Opzione 2: con un'opzione --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 l'upgrade dei gateway manualmente 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 dell'azione istio-ingressgateway predefinita:

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

Opzione 2

Non eseguire l'upgrade della regola istio-ingressgateway predefinita:

 ./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 implementati 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 carichi di lavoro e verifica il comportamento dell'applicazione

Il piano di controllo Anthos Service Mesh è ora pronto a gestire i carichi di lavoro, ma il piano di controllo Istio esistente gestisce ancora i carichi di lavoro esistenti. Per eseguire la migrazione di tali carichi di lavoro, devi etichettare gli spazi dei nomi Kubernetes attualmente etichettati per Istio injection con l'etichetta di revisione di Anthos Service Mesh. Successivamente, dovrai riavviare i carichi di lavoro in questi spazi dei nomi. Puoi farlo manualmente (vedi la nota nel passaggio 1) o in un passaggio utilizzando lo strumento.

La fase di rietichetta ha le seguenti caratteristiche:

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

Per reinserire i carichi di lavoro, segui questi passaggi:

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

     ./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 il comando seguente:

    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 aurei per tutti i servizi. Dovresti anche essere in grado di visualizzare la topologia della tua applicazione.

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

    Vai ad Anthos Service Mesh

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

Per saperne di più sulle dashboard di Anthos Service Mesh, consulta Esplorazione di Anthos Service Mesh nella console.

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 Istio esistente. Il processo di finalizzazione della migrazione è il seguente:

  • Convalida che tutti i proxy in esecuzione nel cluster utilizzino Anthos Service Mesh.
  • Rimuove i componenti Istio inutilizzati dal cluster. Questa operazione è irreversibile.

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

 ./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 Istio esistente

Esegui il passaggio di rollback per rietichettare gli spazi dei nomi con la precedente etichetta Istio injection, riavviare i carichi di lavoro e eseguire il rollback delle modifiche del gateway. Successivamente, lo strumento rimuove tutti i componenti di Anthos Service Mesh di cui è stato eseguito il deployment nel cluster.

Devi ripristinare manualmente tutte le dipendenze abilitate dal passaggio di pre-migrazione.

Per eseguire il rollback a Istio, esegui il comando seguente:

 ./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. Inoltre, verifichi 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 da questa guida è definito nella variabile ${CLUSTER_1_CTX}. Puoi impostare il contesto del 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 anche eseguire questi passaggi 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}
    

Ricorda 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 una delle seguenti opzioni:

    • 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 il deployment dei servizi e dei pod Istio sia 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
    

Esegui il deployment di Boutique online

In questa sezione eseguirai il deployment nel cluster GKE di un'applicazione di esempio basata su microservizi, chiamata Online Boutique. Il deployment di Online Boutique viene eseguito in uno spazio dei nomi abilitato per Istio. Devi verificare che l'applicazione funzioni e che Istio stia inserendo 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 Boutique online. 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 siano presenti due container per pod: il container dell'applicazione e il proxy collaterale 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 collaterale da uno qualsiasi dei pod per verificare che sia stato eseguito il deployment dei proxy Envoy della 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 andando all'indirizzo IP dell'indirizzo istio-ingressgateway del servizio di emergenza:

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

Passaggi successivi