Migrazione a Mesh CA

La migrazione all'autorità di certificazione Anthos Service Mesh (Mesh CA) da Istio CA (nota anche come Citadel) richiede la migrazione della radice di attendibilità. Prima di Anthos Service Mesh 1.10, se volevi eseguire la migrazione da Istio su Google Kubernetes Engine (GKE) ad Anthos Service Mesh con Mesh CA, dovevi pianificare il tempo di inattività perché Anthos Service Mesh non era in grado di caricare più certificati radice. Pertanto, durante la migrazione, i carichi di lavoro di cui è stato appena eseguito il deployment considerano attendibili il nuovo certificato radice, mentre altri considerano attendibile il certificato radice precedente. I carichi di lavoro che utilizzano certificati firmati da certificati radice diversi non possono autenticarsi tra loro. Ciò significa che il traffico TLS reciproca (mTLS) viene interrotto durante la migrazione. L'intero cluster viene eseguito completamente 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 certificato di Mesh CA. Se la tua rete mesh ha più cluster con carichi di lavoro che inviano richieste ai carichi di lavoro su un altro cluster, anche tutti i carichi di lavoro su tali cluster dovranno essere aggiornati.

Questa pagina descrive come eseguire la migrazione da Istio CA a Mesh CA con tempi di inattività minimi o nulli. Segui i passaggi descritti in questa guida per i seguenti casi d'uso:

• Esegui la migrazione da Istio su GKE al piano di controllo nel cluster Anthos Service Mesh 1.10.6-asm.2 con Mesh CA.
• Esegui l'upgrade da Anthos Service Mesh 1.9 or a 1.10 patch release con Istio CA al piano di controllo in-cluster Anthos Service Mesh 1.10.6-asm.2 con Mesh CA.

Limitazioni

• Mesh CA è supportato solo su GKE.
• Tutti i cluster GKE devono essere nello stesso progetto Google Cloud.

Prerequisiti

Questa guida presuppone che tu disponga di:

• Un progetto Google Cloud
• Un account di fatturazione Cloud
• Gli strumenti necessari per eseguire lo script install_asm
• Per un mesh multi-cluster utilizzando la CA Istio, deve essere impostato lo stesso certificato radice su ogni cluster

Strumenti obbligatori

Durante la migrazione, esegui uno script fornito da Google, migrate_ca, per convalidare quanto segue per ogni pod nel cluster:

• Il certificato radice per la CA Istio e la CA mesh.
• Il certificato mTLS del carico di lavoro emesso dalla CA Istio e dalla CA Mesh.
• I domini di attendibilità configurati da Istio CA e Mesh CA.

Questo script ha le seguenti dipendenze:

• awk
• grep
• istioctl Quando esegui lo script install_asm, viene scaricata la versione di istioctl che corrisponde alla versione di Anthos Service Mesh che stai installando.
• jq
• kubectl
• openssl

Panoramica della migrazione

Per eseguire la migrazione a Mesh CA, devi seguire il processo di migrazione basato sulla revisione (chiamato anche "upgrade canary"). Con una migrazione basata sulla revisione, viene eseguito il deployment di una nuova revisione del piano di controllo insieme a quello esistente. Puoi quindi spostare gradualmente i carichi di lavoro alla nuova revisione, per monitorare l'effetto della migrazione durante l'intero processo. Durante il processo di migrazione, l'autenticazione e l'autorizzazione sono completamente funzionali tra i carichi di lavoro che utilizzano la CA Mesh e i carichi di lavoro che utilizzano la CA Istio.

Di seguito è riportato uno schema della migrazione a Mesh CA:

1. Distribuisci la radice di attendibilità di Mesh CA.

   1. Installa una nuova revisione del piano di controllo con un'opzione che distribuirà la radice di attendibilità della CA Mesh.

   2. Esegui la migrazione dei carichi di lavoro nel nuovo piano di controllo, lo spazio dei nomi per spazio dei nomi e testa l'applicazione. Una volta eseguita correttamente la migrazione di tutti i carichi di lavoro al nuovo piano di controllo, rimuovi quello precedente.

2. Esegui la migrazione a Mesh CA. Ora che tutti i proxy sidecar sono configurati con la radice di attendibilità precedente e la radice di attendibilità Mesh CA, puoi eseguire la migrazione a Mesh CA senza tempi di inattività. Anche in questo caso, segui il processo di migrazione basato sulle revisioni:

   1. Installa una revisione del piano di controllo con Mesh CA abilitato.

   2. Esegui la migrazione dei carichi di lavoro alla nuova revisione del piano di controllo, lo spazio dei nomi per spazio dei nomi e testa l'applicazione. Una volta eseguita correttamente la migrazione di tutti i carichi di lavoro al nuovo piano di controllo, rimuovi quello precedente.

   3. Rimuovi i secret CA nel cluster associati alla vecchia CA e riavvia il nuovo piano di controllo.

Distribuisci la radice di attendibilità di Mesh CA

Prima di poter eseguire la migrazione a Mesh CA, tutti i cluster GKE nel mesh devono disporre di Anthos Service Mesh 1.10 o versioni successive e tutti i cluster devono essere configurati con un'opzione del piano di controllo che attivi la radice di attendibilità per Mesh CA da distribuire sui proxy di tutti i carichi di lavoro sul cluster. Al termine del processo, ogni proxy viene configurato con la radice precedente e quella nuova di trust. Con questo schema, quando esegui la migrazione a Mesh CA, i carichi di lavoro che utilizzano Mesh CA potranno eseguire l'autenticazione con i carichi di lavoro utilizzando la CA precedente.

Installa una nuova revisione del piano di controllo

Installa una revisione del piano di controllo con un'opzione che distribuisce la radice di attendibilità della CA mesh.

1. Segui i passaggi in Installazione di Anthos Service Mesh su GKE per prepararti a utilizzare uno script fornito da Google, install_asm, e installare la nuova revisione del piano di controllo.

2. Assicurati di disporre della versione di install_asm che installa Anthos Service Mesh 1.10 o versioni successive:

   ./install_asm --version
   

3. Esegui install_asm. Nel comando seguente, sostituisci i segnaposto con i tuoi valori.

   • PROJECT_ID: campo obbligatorio. L'ID del progetto in cui è stato creato il cluster.

   • CLUSTER_NAME: campo obbligatorio. Il nome del cluster.

   • CLUSTER_LOCATION: campo obbligatorio. La zona o l'area geografica in cui si trova il cluster.

   • REVISION_1: consigliato. Un'etichetta di revisione è una coppia chiave-valore impostata sul piano di controllo. La chiave dell'etichetta della revisione è sempre istio.io/rev. Per impostazione predefinita, lo script imposta il valore dell'etichetta di revisione in base alla versione di Anthos Service Mesh, ad esempio: asm-1106-2. Ti consigliamo di includere questa opzione e di sostituire REVISION_1 con un nome che descriva l'installazione, ad esempio asm-1106-2-distribute-root. Il nome deve essere un'etichetta DNS-1035 e deve contenere caratteri alfanumerici minuscoli o -, iniziare con un carattere alfabetico e terminare con un carattere alfanumerico (ad esempio my-name' o abc-123). L'espressione regolare utilizzata per la convalida è: '[a-z]([-a-z0-9]*[a-z0-9])?')

   • DIR_PATH : campo obbligatorio. Un percorso relativo a una directory in cui lo script scarica il pacchetto anthos-service-mesh e il file di installazione di Anthos Service Mesh, che contiene istioctl, esempi e manifest.

   • OVERLAYS: facoltativo. Se vuoi abilitare le funzionalità facoltative, includi --custom_overlay con il nome del file di overlay per ogni funzionalità. Se non abiliti le funzionalità facoltative, elimina questa riga e la barra rovesciata nella riga precedente.

     ./install_asm \
       --project_id  PROJECT_ID \
       --cluster_name CLUSTER_NAME \
       --cluster_location CLUSTER_LOCATION \
       --mode install \
       --ca citadel \
       --enable_all \
       --option ca-migration-citadel \
       --revision_name REVISION_1  \
       --output_dir DIR_PATH \
       OVERLAYS
     

   Gli argomenti della riga di comando seguenti sono obbligatori:

   • --ca citadel: per evitare tempi di inattività, specifica la CA Istio (l'opzione citadel corrisponde alla CA Istio). Non passare a Mesh CA in questo momento.

   • --option ca-migration-citadel: quando riesegui il deployment dei carichi di lavoro, questa opzione attiva la distribuzione della nuova radice di attendibilità ai proxy collaterali dei carichi di lavoro.

Migrazione dei carichi di lavoro al nuovo piano di controllo

Per completare la distribuzione della nuova radice di attendibilità, devi etichettare gli spazi dei nomi con l'etichetta di revisione istio.io/rev=asm-1106-2-distribute-root e riavviare i carichi di lavoro. Quando testi i carichi di lavoro dopo averli riavviati, esegui uno script per verificare che il proxy sidecar sia configurato con la radice di attendibilità precedente e nuova per Mesh CA.

1. Imposta il contesto corrente per kubectl. Nel comando seguente, modifica --region in --zone se hai un cluster a zona singola.

   gcloud container clusters get-credentials CLUSTER_NAME \
       --project=PROJECT_ID \
       --region=CLUSTER_LOCATION
   

2. Scarica lo script di convalida:

   curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/release-1.10-asm/scripts/ca-migration/migrate_ca > migrate_ca
   

3. Imposta il bit eseguibile nello script:

   chmod +x migrate_ca
   

4. Lo script migrate_ca chiama istioctl, che dipende dalla versione. Lo script install_asm aggiunge un link simbolico a istioctl nella directory specificata per --output_dir. Assicurati che la directory si trovi all'inizio del percorso. Nel seguente comando, sostituisci ISTIOCTL_PATH con la directory che contiene istioctl scaricata dallo script.

   export PATH=ISTIOCTL_PATH:$PATH
   which istioctl
   echo $PATH
   

5. 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 è simile al seguente:

   NAME                                                             READY   STATUS    RESTARTS   AGE   REV
   istio-ingressgateway-5fd454f8ff-t7w9x                            1/1     Running   0          36m   default
   istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-z2s9p   1/1     Running   0          18m   asm-195-2-distribute-root
   istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-zr2cs   1/1     Running   0          18m   asm-195-2-distribute-root
   istiod-68bc495f77-shl2h                                          1/1     Running   0          36m   default
   istiod-asm-195-2-distribute-root-6f764dbb7c-g9f8c                1/1     Running   0          18m   asm-195-2-distribute-root
   istiod-asm-195-2-distribute-root-6f764dbb7c-z7z9s                1/1     Running   0          18m   asm-195-2-distribute-root

   1. Nell'output, sotto la colonna REV, prendi nota del valore dell'etichetta di revisione per la nuova revisione, che corrisponde all'etichetta di revisione che hai specificato quando hai eseguito install_asm. In questo esempio, il valore è asm-1106-2-distribute-root.

   2. Devi eliminare la vecchia revisione di istiod quando finisci di spostare i carichi di lavoro nella nuova revisione. Prendi nota del valore nell'etichetta di revisione per la vecchia revisione istiod. L'output di esempio mostra una migrazione da Istio, che utilizza la revisione default.

6. Passa alla nuova revisione di istio-ingressgateway. Nel seguente comando, assicurati che REVISION_1 corrisponda al valore dell'etichetta di revisione della nuova revisione.

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

   Output previsto:

   service/istio-ingressgateway patched

7. Aggiungi l'etichetta di revisione a uno spazio dei nomi e rimuovi l'etichetta istio-injection (se esistente). Nel comando seguente, sostituisci NAMESPACE con lo spazio dei nomi da etichettare.

   kubectl label namespace NAMESPACE istio.io/rev=REVISION_1 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.

8. Riavvia i pod per attivare la reinserimento.

   kubectl rollout restart deployment -n NAMESPACE
   

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

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

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

12. Verifica che i proxy sidecar per tutti i carichi di lavoro nel cluster siano configurati con i certificati radice vecchi e nuovi:

    ./migrate_ca check-root-cert
    

    Output previsto:

    Namespace: foo
    httpbin-66cdbdb6c5-pmzps.foo trusts [CITADEL MESHCA]
    sleep-64d7d56698-6tmjm.foo trusts [CITADEL MESHCA]

13. 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 revisione 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-ingressgatewqy. 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.

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

    6. Rimuovi la nuova revisione di istiod.

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

    7. Rimuovi la nuova configurazione IstioOperator.

       kubectl delete IstioOperator installed-state-asm-1106-2-distribute-root -n istio-system
       

       L'output previsto è simile al seguente:

       istiooperator.install.istio.io "installed-state-asm-1106-2-distribute-root" deleted

Migrazione a Mesh CA

Ora che i proxy sidecar per tutti i carichi di lavoro sono configurati con la vecchia radice di attendibilità e la nuova radice di attendibilità per Mesh CA, i passaggi per eseguire la migrazione a mesh CA sono simili a quelli eseguiti per distribuire la radice di attendibilità di Mesh CA:

Installa un nuovo piano di controllo con Mesh CA abilitato

Utilizza install_asm per installare una nuova revisione del piano di controllo con CA mesh abilitata.

1. Se hai personalizzato l'installazione precedente, devi specificare gli stessi file di overlay quando esegui install_asm.

2. Esegui install_asm. Nel comando seguente, sostituisci i segnaposto con i tuoi valori.

   • PROJECT_ID: campo obbligatorio. L'ID del progetto in cui è stato creato il cluster.

   • CLUSTER_NAME: campo obbligatorio. Il nome del cluster.

   • CLUSTER_LOCATION: campo obbligatorio. La zona o l'area geografica in cui si trova il cluster.

   • REVISION_2: consigliato. Sostituisci REVISION_2 con un nome che descrive l'installazione, ad esempio asm-1106-2-meshca-ca-migration. Il nome deve essere un'etichetta DNS-1035 e deve contenere caratteri alfanumerici minuscoli o -, iniziare con un carattere alfabetico e terminare con un carattere alfanumerico (ad esempio my-name' o abc-123). L'espressione regolare utilizzata per la convalida è: '[a-z]([-a-z0-9]*[a-z0-9])?')

   • DIR_PATH : campo obbligatorio. Un percorso relativo a una directory in cui lo script scarica il pacchetto anthos-service-mesh e il file di installazione di Anthos Service Mesh, che contiene istioctl, esempi e manifest.

   • OVERLAYS: facoltativo. Se vuoi abilitare le funzionalità facoltative, includi --custom_overlay con il nome del file di overlay per ogni funzionalità. Se non abiliti le funzionalità facoltative, elimina questa riga e la barra rovesciata nella riga precedente.

   ./install_asm \
     --project_id  PROJECT_ID \
     --cluster_name CLUSTER_NAME \
     --cluster_location CLUSTER_LOCATION \
     --mode install \
     --ca mesh_ca \
     --enable_all \
     --option ca-migration-meshca \
     --revision_name REVISION_2 \
     --output_dir DIR_PATH \
     OVERLAYS
   

   Gli argomenti della riga di comando seguenti sono obbligatori:

   • --ca mesh_ca: ora puoi passare a Mesh CA poiché la radice di attendibilità di Mesh CA è stata distribuita.

   • --option ca-migration-migration: quando riesegui il deployment dei carichi di lavoro, questa opzione configura i proxy in modo che utilizzino la radice di attendibilità Mesh CA.

Migrazione dei carichi di lavoro al nuovo piano di controllo

Per completare l'installazione, devi etichettare gli spazi dei nomi con la nuova etichetta di revisione e riavviare i carichi di lavoro.

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 è simile al seguente:

   NAME                                                                          READY   STATUS    RESTARTS   AGE   REV
   istio-ingressgateway-asm-1106-2-distribute-root-65d884685d-6hrdk      1/1     Running   0          67m   asm-1106-2-distribute-root
   istio-ingressgateway-asm-1106-2-distribute-root65d884685d-94wgz       1/1     Running   0          67m   asm-1106-2-distribute-root
   istio-ingressgateway-asm-1106-2-meshca-ca-migration-8b5fc8767-gk6hb   1/1     Running   0          5s    asm-1106-2-meshca-ca-migration
   istio-ingressgateway-asm-1106-2-meshca-ca-migration-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-1106-2-meshca-ca-migration
   istiod-asm-1106-2-distribute-root-67998f4b55-lrzpz                    1/1     Running   0          68m   asm-1106-2-distribute-root
   istiod-asm-1106-2-distribute-root-67998f4b55-r76kr                    1/1     Running   0          68m   asm-1106-2-distribute-root
   istiod-asm-1106-2-meshca-ca-migration-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-1106-2-meshca-ca-migration
   istiod-asm-1106-2-meshca-ca-migration-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-1106-2-meshca-ca-migration

   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-meshca-ca-migration.

   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'esempio, il valore dell'etichetta di revisione per la revisione precedente è "asm-1106-2-distribute-root".

2. Passa alla nuova revisione di istio-ingressgateway. Nel seguente comando, modifica REVISION_2 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_2"}]'

   Output previsto:

   service/istio-ingressgateway patched

3. Aggiungi la nuova etichetta di revisione a uno spazio dei nomi Nel comando seguente, sostituisci NAMESPACE con lo spazio dei nomi da etichettare.

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

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_2
   

6. Testa l'applicazione per verificare che i carichi di lavoro funzionino correttamente. Assicurati che la comunicazione mTLS funzioni tra i carichi di lavoro dello spazio dei nomi precedente e quelli dello spazio dei nomi più recente.

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 l'applicazione funziona come previsto, continua con i passaggi per la transizione al nuovo piano di controllo. 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. Nel seguente comando, 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 revisione istiod precedente. Nel comando seguente, sostituisci OLD_REVISION con l'etichetta di revisione della versione precedente di istiod.

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

   5. Rimuovi la configurazione IstioOperator precedente.

      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 revisione istiod, segui questi passaggi per eseguire il rollback alla revisione precedente:

   1. Torna ai istio-ingressgatewqy precedenti. 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 revisione istiod precedente.

      kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --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.

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

   6. Rimuovi la nuova versione di istiod. Assicurati che l'etichetta di revisione nel comando seguente corrisponda alla tua revisione.

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

   7. Rimuovi la nuova versione della configurazione IstioOperator.

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

      L'output previsto è simile al seguente:

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

Rimuovi i secret CA e riavvia il nuovo piano di controllo

1. Conserva i secret solo nel caso in cui ne avessi bisogno:

   kubectl get secret/cacerts -n istio-system -o yaml > save_file_1
   kubectl get secret/istio-ca-secret -n istio-system -o yaml > save_file_2
   

2. Rimuovi i secret CA nel cluster associato alla CA precedente:

    kubectl delete secret cacerts istio-ca-secret -n istio-system --ignore-not-found
   

3. Riavvia il piano di controllo appena installato. In questo modo puoi rimuovere la radice di attendibilità precedente da tutti i carichi di lavoro in esecuzione nel mesh.

   kubectl rollout restart deployment -n istio-system