Migrazione da Istio

Questa pagina spiega come eseguire lo script per eseguire la migrazione da Istio ad Anthos Service Mesh 1.10.6 su un cluster GKE per un mesh contenente uno o più cluster nello stesso progetto Google Cloud. Se hai Istio 1.6 o versioni precedenti, devi eseguire l'upgrade prima di eseguire la migrazione ad Anthos Service Mesh. Se hai Istio 1.7 o versioni successive, potresti essere in grado di utilizzare Migrazione da Istio 1.7 o versioni successive ad Anthos Service Mesh e Mesh CA. Se devi eseguire l'upgrade, vai alla pagina Esegui l'upgrade di Istio nella versione applicabile di Istio. Tieni presente che l'upgrade di Istio in più di una versione secondaria (ad esempio da 1.6.x a 1.8.x) in un solo passaggio non è ufficialmente testato né consigliato.

Prima di iniziare

Prima di iniziare la migrazione, assicurati di avere:

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.

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.

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, mode e ca. Per ca hai le seguenti opzioni:

    • --ca mesh_ca: specifica questa opzione quando vuoi eseguire la migrazione all'autorità di certificazione Anthos Service Mesh (Mesh CA).

    • --ca citadel: specifica questa opzione quando vuoi continuare a utilizzare la CA di Istio.

    Per saperne di più, consulta Scegliere un'autorità di certificazione.

    Nota: puoi utilizzare --mode install per una migrazione da Istio. Quando utilizzi --mode install anziché --mode migrate, install_asm consente la migrazione, indipendentemente dalla versione del piano di controllo sul cluster. Il flag migrate consente solo una migrazione dalla versione secondaria precedente o da una versione patch precedente.

    La seguente sezione fornisce esempi tipici per l'esecuzione dello script. 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 da Istio con alcuni argomenti aggiuntivi che potrebbero esserti utili. Guarda la barra di navigazione a destra per 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 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 install \
  --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, hai a disposizione le seguenti opzioni:

  • Includi il flag specifico del messaggio di errore o il flag --enable_all quando esegui lo script per eseguire l'installazione effettiva (ovvero, senza --only_validate).

  • Se preferisci, puoi aggiornare il progetto e il cluster prima di eseguire lo script come descritto in Configurazione per l'installazione di Anthos Service Mesh su GKE.

Tieni presente che install_asm non consente alcun flag di abilitazione con --only_validate.

Migrazione a Mesh CA senza tempi di inattività

La migrazione all'autorità di certificazione Anthos Service Mesh (Mesh CA) dalla CA di Istio richiede la migrazione della radice di attendibilità. Durante la migrazione, alcuni carichi di lavoro utilizzano il certificato radice precedente, mentre altri utilizzano il nuovo certificato radice di Mesh CA. I carichi di lavoro che utilizzano certificati firmati da certificati radice diversi non possono autenticarsi tra loro. L'intero cluster esegue il recupero completo solo quando viene eseguito nuovamente il deployment del piano di controllo e di tutti i carichi di lavoro in tutti gli spazi dei nomi con il nuovo certificato CA radice.

Se puoi pianificare i tempi di inattività, questo è il modo più semplice per eseguire la migrazione ad Anthos Service Mesh con Mesh CA. L'esempio seguente mostra le opzioni della riga di comando tipiche per eseguire la migrazione a Mesh CA.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca mesh_ca \
  --output_dir OUTPUT_DIRECTORY
  --enable_all

Migrazione a Mesh CA con tempi di inattività minimi o nulli

Se non riesci a pianificare il tempo di inattività per la migrazione a Mesh CA, esiste ancora un percorso di migrazione a Mesh CA, ma sono necessari passaggi aggiuntivi. Per maggiori dettagli, consulta Migrazione a Mesh CA.

È in corso la migrazione, ma si continua a utilizzare la CA Istio

Se hai bisogno di una CA personalizzata, puoi continuare a utilizzare la CA di Istio dopo la migrazione ad Anthos Service Mesh. Il seguente comando esegue lo script per una migrazione e abilita la CA di Istio. (L'opzione --ca citadel si chiama "cittadella" perché era il nome del componente CA prima che tutti i componenti Istio fossero incorporati in istiod). Questa migrazione esegue il deployment solo del piano di controllo e del gateway in entrata. Non modifica la CA radice e non disturba i carichi di lavoro esistenti.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca citadel \
  --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 install \
  --ca citadel \
  --enable_all \
  --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 install \
  --ca citadel \
  --enable_all \
  --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.10-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-1106-2 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.

  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-1106-2
istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-1106-2
istiod-asm-176-1-67998f4b55-lrzpz                1/1     Running   0          68m   asm-198-3
istiod-asm-176-1-67998f4b55-r76kr                1/1     Running   0          68m   asm-198-3
istiod-asm-182-2-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-1106-2
istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-1106-2

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

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

  2. Passa alla nuova revisione di istio-ingressgateway. 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.

    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. Elimina il vecchio istio-ingressgatewaydeployment. Il comando da eseguire 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 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 istio-ingressgateway 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. Nel comando seguente, sostituisci OLD_REVISION con la revisione precedente.

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

    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. Rimuovi il nuovo deployment istio-ingressgateway. Assicurati che il valore di REVISION nel seguente comando 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