Migrazione da Istio

Questa pagina spiega come eseguire lo script per eseguire la migrazione da Istio 1.7 or 1.8 ad Anthos Service Mesh 1.8.6 su un cluster GKE per un mesh contenente uno o più cluster nello stesso progetto Google Cloud.

Per una rete mesh multi-cluster in cui i cluster si trovano in progetti diversi, consulta Installazione e migrazione di più cluster/più progetti per GKE.

Questa pagina consente di eseguire la migrazione da Istio ad Anthos Service Mesh. Per informazioni sull'esecuzione dello script per le nuove installazioni e gli upgrade, consulta quanto segue:

• Installazione di Anthos Service Mesh
• Upgrade alla versione più recente

Prima di iniziare

Prima di iniziare la migrazione, assicurati di avere:

• Requisiti esaminati
• Scegliere un'autorità di certificazione
• Hai registrato il cluster
• Ha installato gli strumenti richiesti
• Hai scaricato lo script

Lo script richiede che tu disponga delle autorizzazioni richieste o che includa i flag --enable_all o --enable_gcp_iam_roles per consentire allo script di abilitare l'autorizzazione per te. Analogamente, per consentire allo script di abilitare le API richieste e aggiornare il cluster, specifica il flag --enable_all o i flag di abilitazione più granulari.

Preparazione per una migrazione

Assicurati di consultare la Preparazione per la migrazione da Istio.

Se hai personalizzato l'installazione precedente, avrai bisogno delle stesse personalizzazioni quando esegui l'upgrade a una nuova versione di Anthos Service Mesh o esegui la migrazione da Istio. Se hai personalizzato l'installazione aggiungendo il flag --set values a istioctl install, devi aggiungere queste impostazioni a un file YAML IstioOperator, chiamato file di overlay. Puoi specificare il file dell'overlay utilizzando l'opzione --custom_overlay con il nome del file quando esegui lo script. Lo script passa il file dell'overlay a istioctl install.

Attenzione: l'omissione del file overlay determina l'installazione corretta. Tuttavia, il mesh di servizi ha una configurazione diversa da quella prevista perché i valori omessi vengono reimpostati sui valori predefiniti quando viene eseguito nuovamente il deployment del piano di controllo e del gateway in entrata.

Lo script segue il processo di upgrade di revisione (indicato come upgrade "canary" nella documentazione di Istio). Con un upgrade basato su revisioni, lo script installa una nuova revisione del piano di controllo insieme a quello esistente. Durante l'installazione della nuova versione, lo script include un'etichetta revision che identifica il nuovo piano di controllo.

Successivamente, potrai eseguire la migrazione alla nuova versione impostando la stessa etichetta revision sui carichi di lavoro ed eseguendo un riavvio in sequenza per inserire nuovamente i proxy in modo che utilizzino la nuova versione e configurazione di Anthos Service Mesh. Con questo approccio, puoi monitorare l'effetto dell'upgrade su una piccola percentuale dei carichi di lavoro. Dopo aver testato l'applicazione, puoi eseguire la migrazione di tutto il traffico alla nuova versione. Questo approccio è molto più sicuro rispetto all'upgrade in loco in cui i nuovi componenti del piano di controllo sostituiscono la versione precedente.

Importante: quando esegui lo script, devi includere --option revisioned-istio- ingressgateway come mostrato in tutti gli esempi. Con questa opzione, lo script crea un deployment istio-ingressgateway sottoposto a revisione. Questo consente di decidere quando passare alla nuova versione. Se non includi questa opzione, lo script esegue un upgrade in loco di istio-ingressgateway.

Migrazione ad Anthos Service Mesh

1. Imposta le opzioni e specifica i flag per eseguire lo script. Includi sempre le seguenti opzioni: project_id, cluster_name, cluster_location e mode.

   La seguente sezione fornisce esempi tipici per l'esecuzione dello script. Guarda la barra di navigazione sulla destra per un elenco di esempi. Per una descrizione completa degli argomenti dello script, consulta Opzioni e flag.

2. Per completare la configurazione di Anthos Service Mesh, devi abilitare l'inserimento automatico di file collaterali e eseguire il deployment o rieseguire il deployment dei carichi di lavoro.

Esempi

Questa sezione mostra esempi di esecuzione dello script per una migrazione con alcuni argomenti aggiuntivi che potrebbero esserti utili. Guarda la barra di navigazione a destra per consultare un elenco di esempi.

Solo convalida

L'esempio seguente mostra l'esecuzione dello script con l'opzione --only_validate. Con questa opzione, lo script non apporta alcuna modifica al progetto o al cluster e non installa Anthos Service Mesh. Quando specifichi --only_validate,lo script non riesce se includi uno dei flag --enable_*.

Lo script verifica che:

• Il tuo ambiente dispone degli strumenti necessari.
• Hai l'autorizzazione richiesta per il progetto specificato.
• Il cluster soddisfa i requisiti minimi.
• Nel progetto sono abilitate tutte le API di Google richieste.

Per impostazione predefinita, lo script scarica ed estrae il file di installazione e scarica il pacchetto di configurazione asm da GitHub a una directory temporanea. Prima di uscire, lo script genera un messaggio che fornisce il nome della directory temporanea. Puoi specificare una directory esistente per i download con l'opzione --output_dir DIR_PATH. L'opzione --output_dir semplifica l'utilizzo dello strumento a riga di comando istioctl, se necessario. Inoltre, i file di configurazione per abilitare le funzionalità facoltative sono inclusi nella directory asm/istio/options.

Esegui questo comando per convalidare la configurazione e scaricare il file di installazione e il pacchetto asm nella directory OUTPUT_DIR:

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode migrate \
  --ca citadel \
  --output_dir DIR_PATH \
  --only_validate

In caso di esito positivo, lo script restituisce quanto segue:

./install_asm \
install_asm: Setting up necessary files...
install_asm: Creating temp directory...
install_asm: Generating a new kubeconfig...
install_asm: Checking installation tool dependencies...
install_asm: Downloading ASM..
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 57.0M  100 57.0M    0     0  30.6M      0  0:00:01  0:00:01 --:--:-- 30.6M
install_asm: Downloading ASM kpt package...
fetching package /asm from https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages to asm
install_asm: Checking for project PROJECT_ID...
install_asm: Confirming cluster information...
install_asm: Confirming node pool requirements...
install_asm: Fetching/writing GCP credentials to kubeconfig file...
Fetching cluster endpoint and auth data.
kubeconfig entry generated for cluster-1.
install_asm: Checking Istio installations...
install_asm: Checking required APIs...
install_asm: Successfully validated all requirements to install ASM from this computer.

Se uno dei test non supera la convalida, lo script restituisce un messaggio di errore. Ad esempio, se nel progetto non sono abilitate tutte le API di Google obbligatorie, verrà visualizzato il seguente errore:

ERROR: One or more APIs are not enabled. Please enable them and retry, or run
the script with the '--enable_gcp_apis' flag to allow the script to enable them
on your behalf.

Se hai ricevuto un messaggio di errore relativo alla necessità di eseguire lo script con un flag di abilitazione, puoi includere il flag specifico del messaggio di errore o il flag --enable_all quando esegui lo script senza --only_validate. Se preferisci, puoi aggiornare autonomamente il progetto e il cluster prima di eseguire lo script come descritto nelle sezioni Configurazione del progetto e Configurazione del cluster della Guida all'installazione per più progetti.

Migrazione da Istio con Citadel

Se stai eseguendo la migrazione da Istio con Citadel come CA, puoi continuare a utilizzare Citadel dopo la migrazione ad Anthos Service Mesh. Il seguente comando esegue lo script per una migrazione e abilita Citadel come CA. Questa migrazione esegue il deployment solo del piano di controllo. Non modifica la CA radice e non disturba i carichi di lavoro esistenti.

Attenzione: se hai personalizzato l'installazione precedente, devi specificare il file di configurazione IstioOperator utilizzando l'opzione --custom_overlay. Se il file di configurazione viene omesso, Anthos Service Mesh ripristina i valori predefiniti.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode migrate \
  --ca citadel \
  --option revisioned-istio-ingressgateway \
  --enable_all

Migrazione con un file di overlay

Un file overlay è un file YAML contenente una risorsa IstioOperator personalizzata (CR) che passi a install_asm per configurare il piano di controllo. Puoi eseguire l'override della configurazione predefinita del piano di controllo e abilitare una funzionalità facoltativa passando il file YAML a install_asm. Puoi aggiungere più overlay: ogni file di overlay sostituisce la configurazione dei livelli precedenti.

Se specifichi più di una RP in un file YAML, install_asm suddivide il file in più file YAML temporanei, uno per ogni RP. Lo script suddivide le risposte predefinite in file separati perché istioctl install applica solo la prima RP in un file YAML contenente più di una RP.

L'esempio seguente esegue una migrazione e include un file di overlay per personalizzare la configurazione del piano di controllo. Nel comando seguente, cambia OVERLAY_FILE nel nome del file YAML.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode migrate \
  --ca citadel \
  --enable_all \
  --option revisioned-istio-ingressgateway \
  --custom_overlay OVERLAY_FILE

Migrazione con un'opzione

L'esempio seguente esegue una migrazione e include il file egressgateways.yaml del pacchetto asm, che consente un gateway in uscita. Tieni presente che non includi l'estensione .yaml. Lo script recupera il file per te, così non devi prima scaricare il pacchetto asm.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode migrate \
  --ca citadel \
  --enable_all \
  --option revisioned-istio-ingressgateway \
  --option egressgateways

Puoi utilizzare --option per abilitare una funzionalità facoltativa. Se devi apportare modifiche a uno dei file nella directory asm/istio/options del pacchetto asm, scarica il pacchetto asm, apporta le modifiche e includi il file utilizzando --custom_overlay.

Per scaricare il pacchetto asm nella directory di lavoro corrente in modo da poter apportare modifiche ai file:

kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.8-asm asm

Se hai eseguito l'esempio Solo convalida in cui hai specificato l'opzione --output_dir, i file di configurazione si troveranno nella directory di output specificata in asm/istio/options.

Deployment e nuovo deployment dei carichi di lavoro

L'installazione non è completa finché non abiliti l'iniezione automatica del proxy sidecar (inserimento automatica). Le migrazioni da Istio OSS e dagli upgrade seguono il processo di upgrade basato su revisioni (indicati come "upgrade canary" nella documentazione di Istio). Con un upgrade basato su revisione, la nuova versione del piano di controllo viene installata insieme al piano di controllo esistente. Puoi quindi spostare alcuni dei tuoi carichi di lavoro alla nuova versione, in modo da monitorare l'effetto dell'upgrade con una piccola percentuale dei carichi di lavoro prima di eseguire la migrazione di tutto il traffico alla nuova versione.

Lo script imposta un'etichetta di revisione nel formato istio.io/rev=asm-186-8 su istiod. Per abilitare l'inserimento automatico, aggiungi un'etichetta di revisione corrispondente agli spazi dei nomi. L'etichetta di revisione viene utilizzata dal webhook dell'iniettore sidecar per associare i file collaterali inseriti a una determinata revisione istiod. Dopo aver aggiunto l'etichetta, riavvia i pod nello spazio dei nomi per consentire l'inserimento dei file collaterali.

Lo script crea anche un deployment istio-ingressgateway revisionato. In questo modo puoi decidere quando passare alla nuova versione.

1. Recupera l'etichetta di revisione che si trova su istiod e istio-ingressgateway.

   kubectl get pod -n istio-system -L istio.io/rev
   

   L'output del comando è simile al seguente.

   NAME                                             READY   STATUS    RESTARTS   AGE   REV
   istio-ingressgateway-65d884685d-6hrdk            1/1     Running   0          67m
   istio-ingressgateway-65d884685d-94wgz            1/1     Running   0          67m
   istio-ingressgateway-asm-182-2-8b5fc8767-gk6hb   1/1     Running   0          5s    asm-186-8
   istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-186-8
   istiod-asm-176-1-67998f4b55-lrzpz                1/1     Running   0          68m   asm-178-10
   istiod-asm-176-1-67998f4b55-r76kr                1/1     Running   0          68m   asm-178-10
   istiod-asm-182-2-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-186-8
   istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-186-8

   1. Tieni presente se hai sia la vecchia che la nuova versione dell'istio-ingressgateway.

      • Se hai incluso l'opzione revisioned-istio-ingressgateway durante l'upgrade, è stato eseguito un upgrade canary di istio-ingressgateway. In questo caso, l'output mostra sia la versione precedente che quella nuova di istio-ingressgateway.

      • Se non hai incluso revisioned-istio-ingressgateway durante l'upgrade, è stato eseguito un upgrade in loco di istio-ingressgateway. In questo caso, l'output mostra solo la nuova versione.

   2. Nell'output, sotto la colonna REV, prendi nota del valore dell'etichetta di revisione per la nuova versione. In questo esempio, il valore è asm-186-8.

   3. Nota anche il valore nell'etichetta di revisione per la vecchia versione di istiod. Questa operazione ti consente di eliminare la versione precedente di istiod quando hai finito di spostare i carichi di lavoro alla nuova versione. Nell'output di esempio, il valore dell'etichetta di revisione per la versione precedente è asm-178-10.

2. Se hai sia la versione precedente che quella nuova di istio-ingressgateway, trasferisci il istio-ingressgateway alla nuova revisione. Nel seguente comando, modifica REVISION con il valore che corrisponde all'etichetta di revisione della nuova versione.

   kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION"}]'

   Output previsto: service/istio-ingressgateway patched

3. Aggiungi l'etichetta di revisione a uno spazio dei nomi e rimuovi l'etichetta istio-injection (se esistente). Nel comando seguente, imposta REVISION sul valore che corrisponde alla nuova revisione di istiod.

   kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite

   Se vedi "istio-injection not found" nell'output, puoi ignorarlo. Ciò significa che in precedenza lo spazio dei nomi non aveva l'etichetta istio-injection. Poiché l'inserimento automatica non riesce se uno spazio dei nomi contiene sia l'etichetta istio-injection sia l'etichetta di revisione, tutti i comandi kubectl label nella documentazione di Anthos Service Mesh comprendono la rimozione dell'etichetta istio-injection.

4. Riavvia i pod per attivare la reinserimento.

   kubectl rollout restart deployment -n NAMESPACE

5. Verifica che i pod siano configurati in modo da puntare alla nuova versione di istiod.

   kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION

6. Testa l'applicazione per verificare che i carichi di lavoro funzionino correttamente.

7. Se disponi di carichi di lavoro in altri spazi dei nomi, ripeti i passaggi per etichettare lo spazio dei nomi e riavviare i pod.

8. Se sei soddisfatto del funzionamento previsto dell'applicazione, continua con i passaggi per la transizione alla nuova versione di istiod. Se si verifica un problema con l'applicazione, segui la procedura per eseguire il rollback.

9. Esegui di nuovo il comando seguente per confermare se disponi sia della versione precedente che di quella nuova di istio-ingressgateway o solo della nuova versione. Questo determina la modalità di gestione della transizione alla nuova versione di istio-ingressgateway o del rollback alla versione precedente.

   kubectl get pod -n istio-system -L istio.io/rev
   

   Attenzione: non eseguire comandi che eliminano il deployment istio-ingressgateway se hai solo la nuova versione di istio-ingressgateway. In questo modo, impedisci al traffico di accedere al tuo mesh di servizi.

   Completa la transizione

   Se l'applicazione funziona come previsto, rimuovi il piano di controllo precedente per completare la transizione alla nuova versione.

   1. Passa alla directory in cui si trovano i file del repository GitHub di anthos-service-mesh.

   2. Configura il webhook di convalida per utilizzare il nuovo piano di controllo.

      kubectl apply -f asm/istio/istiod-service.yaml
      

   3. Se hai sia la versione precedente che quella nuova di istio-ingressgateway, elimina il deployment di istio-ingressgateway precedente. Il comando da eseguire dipende dalla migrazione da Istio o da una versione precedente di Anthos Service Mesh:

      Esegui migrazione

      Se hai eseguito la migrazione da Istio, il vecchio istio-ingressgateway non avrà un'etichetta di revisione.

      kubectl delete deploy/istio-ingressgateway -n istio-system
      

      Esegui l'upgrade

      Se hai eseguito l'upgrade da una versione precedente di Anthos Service Mesh, nel comando seguente sostituisci OLD_REVISION con l'etichetta di revisione della versione precedente di istio-ingressgateway.

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
      

   4. Elimina la versione precedente di istiod. Il comando da utilizzare varia a seconda che tu stia eseguendo la migrazione da Istio o da una versione precedente di Anthos Service Mesh.

      Esegui migrazione

      Se hai eseguito la migrazione da Istio, il vecchio istiod non avrà un'etichetta di revisione.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
      

      Esegui l'upgrade

      Se hai eseguito l'upgrade da una versione precedente di Anthos Service Mesh, assicurati che OLD_REVISION corrisponda all'etichetta di revisione della versione precedente di istiod nel comando seguente.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
      

   5. Rimuovi la versione precedente della configurazione di IstioOperator.

      kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
      

      L'output previsto è simile al seguente:

      istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted

   Esegui il rollback

   Se hai riscontrato un problema durante il test dell'applicazione con la nuova versione di istiod, segui questi passaggi per ripristinare la versione precedente:

   1. Torna alla versione precedente di istio-ingressgateway. Il comando da utilizzare varia a seconda che tu abbia sia la versione precedente che quella nuova di istio-ingressgateway o solo la nuova versione.

      • Se hai sia la versione precedente che quella nuova di istio-ingressgateway, esegui il comando kubectl patch service e sostituisci OLD_REVISION con la vecchia revisione.

        kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "OLD_REVISION"}]'
        

      • Se hai solo la nuova versione di istio-ingressgateway, esegui il comando kubectl rollout undo.

        kubectl -n istio-system rollout undo deploy istio-ingressgateway
        

   2. Rietichetta lo spazio dei nomi per abilitare l'inserimento automatico con la versione precedente di istiod. Il comando da utilizzare varia a seconda che tu abbia utilizzato un'etichetta di revisione o istio-injection=enabled con la versione precedente.

      • Se hai utilizzato un'etichetta di revisione per l'inserimento automatico:

        kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
        

      • Se utilizzavi istio-injection=enabled:

        kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
        

      Output previsto:

      namespace/NAMESPACE labeled

   3. Conferma che l'etichetta della revisione nello spazio dei nomi corrisponda all'etichetta della revisione della versione precedente di istiod:

      kubectl get ns NAMESPACE --show-labels
      

   4. Riavvia i pod per attivare la reiniezione in modo che i proxy abbiano la versione precedente:

      kubectl rollout restart deployment -n NAMESPACE
      

   5. Se hai sia la versione precedente che quella nuova di istio-ingressgateway, rimuovi il nuovo deployment di istio-ingressgateway. Assicurati che il valore di REVISION nel comando seguente sia corretto.

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION -n istio-system --ignore-not-found=true
      

   6. Rimuovi la nuova versione di istiod. Assicurati che il valore di REVISION nel seguente comando sia corretto.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true
      

   7. Rimuovi la nuova versione della configurazione IstioOperator.

      kubectl delete IstioOperator installed-state-REVISION -n istio-system
      

      L'output previsto è simile al seguente:

      istiooperator.install.istio.io "installed-state-REVISION" deleted

   8. Se non hai incluso il flag --disable_canonical_service, lo script abilitava il controller del servizio canonico. Ti consigliamo di lasciarlo abilitato, ma se devi disabilitarlo, consulta Attivazione e disattivazione del controller del servizio canonico.

Visualizzazione delle dashboard di Anthos Service Mesh

Dopo aver eseguito il deployment dei carichi di lavoro nel tuo cluster con i proxy sidecar inseriti, puoi esplorare le pagine Anthos Service Mesh nella console Google Cloud per vedere tutte le funzionalità di osservabilità offerte da Anthos Service Mesh. Tieni presente che sono necessari circa uno o due minuti per la visualizzazione dei dati di telemetria nella console Google Cloud dopo il deployment dei carichi di lavoro.

L'accesso ad Anthos Service Mesh nella console Google Cloud è controllato da Identity and Access Management (IAM). Per accedere alle pagine di Anthos Service Mesh, un Proprietario progetto deve concedere agli utenti il ruolo Editor di progetto o Visualizzatore oppure i ruoli più restrittivi descritti in Controllare l'accesso ad Anthos Service Mesh nella console Google Cloud.

1. Nella console Google Cloud, vai ad Anthos Service Mesh.

   Vai ad Anthos Service Mesh

2. Seleziona il progetto Google Cloud dall'elenco a discesa nella barra dei menu.

3. Se disponi di più mesh di servizi, selezionalo dall'elenco a discesa Mesh di servizi.

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

Oltre alle pagine Anthos Service Mesh, le metriche relative ai tuoi servizi (ad esempio il numero di richieste ricevute da un determinato servizio) vengono inviate a Cloud Monitoring, dove vengono visualizzate in Metrics Explorer.

Per visualizzare le metriche:

1. Nella console Google Cloud, vai alla pagina Monitoring:

   Vai a Monitoring

2. Seleziona Risorse > Metrics Explorer.

Per un elenco completo delle metriche, consulta la pagina relativa alle metriche Istio nella documentazione di Cloud Monitoring.

Passaggi successivi

• Esegui il deployment dell'applicazione di esempio di Boutique Online
• Aggiungi cluster ad Anthos Service Mesh