Versione 1.14

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Migrazione basata su Canary alle CA mesh

La migrazione all'autorità di certificazione (Mesh CA) di Anthos Service Mesh da Istio CA (nota anche come Cittadella) richiede la migrazione della root 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, era necessario pianificare il tempo di inattività perché Anthos Service Mesh non era in grado di caricare più certificati radice. Pertanto, durante la migrazione, i nuovi carichi di lavoro di cui viene eseguito il deployment considerano attendibile il nuovo certificato radice, mentre altri considerano attendibile il vecchio certificato radice. I carichi di lavoro che utilizzano certificati firmati da diversi certificati radice non possono eseguire l'autenticazione tra loro. Questo significa che il traffico di TLS TLS (mutual TLS) viene interrotto durante la migrazione. L'intero cluster viene ripristinato completamente solo quando il piano di controllo e tutti i carichi di lavoro in tutti gli spazi dei nomi vengono sottoposti nuovamente a deployment con il certificato di CA CA mesh. Se il tuo mesh ha più cluster con carichi di lavoro che inviano richieste ai carichi di lavoro su un altro cluster, è necessario aggiornare anche tutti i carichi di lavoro su tali cluster.

Segui i passaggi descritti in questa guida per i seguenti casi d'uso:

  • Esegui la migrazione da Istio 1.10 or 1.11 su GKE al piano di controllo nel cluster Anthos Service Mesh1.14.4-asm.0 con Mesh CA.
  • Esegui l'upgrade da Anthos Service Mesh 1.12 or a 1.13 patch release con Istio CA al piano di controllo in-cluster Anthos Service Mesh 1.14.4-asm.0 con Mesh CA.

Limitazioni

  • La CA mesh è supportata solo su GKE.
  • Tutti i cluster GKE devono trovarsi nello stesso progetto Google Cloud.

Prerequisiti

Segui i passaggi descritti in Installare strumenti dipendenti e convalidare il cluster per:

Strumenti obbligatori

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

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

Questo strumento ha le seguenti dipendenze:

  • awk
  • grep
  • istioctl eseguendo asmcli install scarica 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, segui la procedura di migrazione basata sulla revisione (denominata anche "upgrade canary"). Con una migrazione basata sulla revisione, viene eseguito il deployment di una nuova revisione del piano di controllo insieme al piano di controllo esistente. Successivamente, sposti gradualmente i carichi di lavoro nella nuova revisione, che ti consente di monitorare l'effetto della migrazione durante il 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 di Istio.

Di seguito è riportata la struttura della migrazione a Mesh CA:

  1. Distribuisci la radice di attendibilità CA della mesh.

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

    2. Esegui la migrazione dei carichi di lavoro al nuovo piano di controllo (spazio dei nomi per spazio dei nomi) e testa la tua applicazione. Una volta eseguita correttamente la migrazione di tutti i carichi di lavoro nel 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 root di trust CA mesh, puoi eseguire la migrazione a Mesh CA senza tempi di inattività. Anche in questo caso, segui la procedura di migrazione basata sulle revisioni:

    1. Installare una revisione del piano di controllo con CA mesh abilitata.

    2. Esegui la migrazione dei carichi di lavoro alla nuova revisione del piano di controllo, allo spazio dei nomi per spazio dei nomi e testa la tua applicazione. Una volta eseguita la migrazione di tutti i carichi di lavoro nel nuovo piano di controllo, rimuovi quello precedente.

    3. Rimuovi i secret dell'autorità di certificazione nel cluster associato alla CA precedente e riavvia il nuovo piano di controllo.

Distribuisci la radice di trust CA mesh

Prima di poter eseguire la migrazione a Mesh CA, tutti i cluster GKE nel mesh devono avere 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 ai proxy di tutti i carichi di lavoro nel cluster. Al termine del processo, ogni proxy è configurato sia con la vecchia sia con la nuova radice di trust. Con questo schema, quando esegui la migrazione a Mesh CA, i carichi di lavoro che utilizzano CA possono essere autenticati con carichi di lavoro che utilizzano 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 CA CA mesh.

  1. Segui i passaggi descritti in Installare strumenti dipendenti e convalidare il cluster per prepararti a utilizzare uno strumento fornito da Google, asmcli, per installare la nuova revisione del piano di controllo.

  2. Assicurati di avere la versione di asmcli che installa Anthos Service Mesh 1.11 o versioni successive:

    ./asmcli --version
    
  3. Esegui asmcli install. Nel comando seguente, sostituisci i segnaposto con i valori.

     ./asmcli install \
       --fleet_id FLEET_PROJECT_ID \
       --kubeconfig KUBECONFIG_FILE \
       --enable_all \
       --ca citadel \
       --ca_cert CA_CERT_FILE_PATH \
       --ca_key CA_KEY_FILE_PATH \
       --root_cert ROOT_CERT_FILE_PATH \
       --cert_chain CERT_CHAIN_FILE_PATH \
       --option ca-migration-citadel \
       --revision_name REVISION_1 \
       --output_dir DIR_PATH
    
  • --fleet_id L'ID progetto del progetto host del parco risorse.
  • --kubeconfig Il percorso del file kubeconfig Puoi specificare un percorso relativo o un percorso completo. La variabile di ambiente $PWD non funziona qui.
  • --output_dir Includi questa opzione per specificare una directory in cui asmcli scarica il pacchetto anthos-service-mesh ed estrae il file di installazione, che contiene, istioctl, campioni e manifest. In caso contrario, asmcli scarica i file in una directory tmp. Puoi specificare un percorso relativo o un percorso completo. La variabile di ambiente $PWD non funziona qui.
  • --enable_all Consente allo strumento di:
    • Concedi le autorizzazioni IAM richieste.
    • Abilita le API di Google richieste.
    • Imposta un'etichetta sul cluster che identifica il mesh.
    • Registra il cluster nel parco risorse se non è già registrato.

  • -ca citadel Per evitare tempi di inattività, specifica Istio CA (l'opzione citadel corrisponde a CA CA). Non passare a Mesh CA in questo momento.
  • --ca_cert Il certificato intermedio.
  • --ca_key La chiave per il certificato intermedio
  • --root_cert Il certificato radice.
  • --cert_chain La catena di certificati.
  • --option ca-migration-citadel Quando riesegui il deployment dei tuoi carichi di lavoro, questa opzione attiva la nuova radice di attendibilità da distribuire ai proxy sidecar dei carichi di lavoro.
  • REVISION_1: opzione consigliata. Un'etichetta di revisione è una coppia chiave-valore impostata sul piano di controllo. La chiave dell'etichetta di revisione è sempre istio.io/rev. Per impostazione predefinita, lo strumento imposta il valore dell'etichetta di revisione in base alla versione di Anthos Service Mesh, ad esempio: asm-1144-0. Ti consigliamo di includere questa opzione e di sostituire REVISION_1 con un nome che descrive l'installazione, come asm-1144-0-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 (come my-name o abc-123).

Esegui la 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=<var>REVISION_1</var>-distribute-root e riavviare i carichi di lavoro. Quando esegui il test dei carichi di lavoro dopo il riavvio, esegui uno strumento per verificare che il proxy sidecar sia configurato con la radice precedente e nuova per l'affidabilità di 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 strumento di convalida:

    curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/master/scripts/ca-migration/migrate_ca > migrate_ca
    
  3. Imposta il bit eseguibile sullo strumento:

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

    export PATH=ISTIOCTL_PATH:$PATH
    which istioctl
    echo $PATH
    
  5. Ottieni 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, nella colonna REV, prendi nota del valore dell'etichetta di revisione della nuova revisione, che corrisponde all'etichetta di revisione specificata quando hai eseguito asmcli install. In questo esempio, il valore è asm-1144-0-distribute-root.

    2. Al termine del trasferimento dei carichi di lavoro alla nuova revisione, devi eliminare la vecchia revisione di istiod. Osserva il valore nell'etichetta della revisione per la versione precedente di istiod. L'output di esempio mostra una migrazione da Istio, che utilizza la revisione default.

  6. 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 per etichettare.

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

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

  7. Riavvia i pod per attivare la nuova iniezione.

    kubectl rollout restart deployment -n NAMESPACE
    
  8. Testa la tua applicazione per verificare che i carichi di lavoro funzionino correttamente.

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

  10. Verifica che i proxy sidecar per tutti i carichi di lavoro nel cluster siano configurati con i certificati radice precedenti 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]
  11. Se devi eseguire la migrazione dei gateway, segui i passaggi descritti in Upgrade canary (avanzati) per installare nuovi deployment gateway. Tieni presente quanto segue:

    • Utilizza REVISION_1 come etichetta di revisione.
    • Esegui il deployment delle risorse gateway nello stesso spazio dei nomi del gateway dall'installazione precedente per eseguire la migrazione senza tempo di inattività. Assicurati che anche le risorse di servizio che rimandano al gateway precedente includano i deployment più recenti.
    • Non eliminare i deployment del gateway meno recente fino a quando non hai la certezza che l'applicazione funzioni correttamente (dopo il passaggio successivo).
  12. Se l'applicazione funziona come previsto, continua con i passaggi per la transizione alla nuova versione di istiod. Se si è verificato un problema con la tua applicazione, segui i passaggi per eseguire il rollback.

    Completa la transizione

    Se ritieni che l'applicazione funzioni 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 anthos-service-meshGitHub.

    2. Configura il webhook di convalida in modo che utilizzi il nuovo piano di controllo.

      kubectl apply -f asm/istio/istiod-service.yaml
      
    3. Elimina il vecchio istio-ingressgatewaydeployment. Il comando eseguito dipende dalla migrazione da Istio o dall'upgrade da una versione precedente di Anthos Service Mesh:

      Migrazione

      Se hai eseguito la migrazione da Istio, la versione precedente di istio-ingressgateway non ha un'etichetta di revisione.

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

      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 vecchia revisione di istiod. Il comando utilizzato dipende dalla migrazione da Istio o dall'upgrade da una versione precedente di Anthos Service Mesh.

      Migrazione

      Se hai eseguito la migrazione da Istio, la versione precedente di istio-ingressgateway non ha un'etichetta di revisione.

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

      Upgrade

      Se hai eseguito l'upgrade da una versione precedente di Anthos Service Mesh, nel comando seguente, assicurati che OLD_REVISION corrisponda all'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 versione precedente della configurazione 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 della tua applicazione con la nuova versione di istiod, segui questi passaggi per eseguire il rollback alla versione precedente:

    1. Elimina i nuovi deployment del gateway installati nel passaggio 11.

    2. Rietichetta il tuo spazio dei nomi per abilitare l'inserimento automatico con la versione precedente di istiod. Il comando utilizzato dipende dal fatto 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 di revisione nello spazio dei nomi corrisponda all'etichetta di revisione della versione precedente di istiod:

      kubectl get ns NAMESPACE --show-labels
      
    4. Riavvia i pod per attivare la nuova iniezione in modo che i proxy dispongano della versione precedente:

      kubectl rollout restart deployment -n NAMESPACE
      
    5. Rimuovi il nuovo deployment di 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 di IstioOperator.

      kubectl delete IstioOperator installed-state-asm-1144-0-distribute-root -n istio-system
      

      L'output previsto è simile al seguente:

      istiooperator.install.istio.io "installed-state-asm-1144-0-distribute-root" deleted

Migrazione a Mesh CA

Ora che i proxy sidecar per tutti i carichi di lavoro sono configurati sia con la vecchia radice di attendibilità che con la nuova radice di attendibilità per Mesh CA, i passaggi per la migrazione a Mesh CA sono simili a quelli che hai eseguito per la distribuzione della radice di CA della rete mesh:

Installa un nuovo piano di controllo con Mesh CA attivato

asmcli install viene utilizzato per installare una nuova revisione del piano di controllo in cui è abilitata la CA mesh.

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

  2. Esegui asmcli install. Nel comando seguente, sostituisci i segnaposto con i valori.

     ./asmcli install \
       --fleet_id FLEET_PROJECT_ID \
       --kubeconfig KUBECONFIG_FILE \
       --output_dir DIR_PATH \
       --enable_all \
       --ca mesh_ca \
       --root_cert ROOT_CERT_FILE_PATH \
       --cert_chain CERT_CHAIN_FILE_PATH
       --option ca-migration-meshca \
      --revision_name REVISION_2 \
      --output_dir DIR_PATH \
      OVERLAYS
    
      • --fleet_id L'ID progetto del progetto host del parco risorse.
      • --kubeconfig Il percorso del file kubeconfig Puoi specificare un percorso relativo o completo. La variabile di ambiente $PWD non funziona qui.
      • --output_dir includi questa opzione per specificare una directory in cui asmcli scarica il pacchetto anthos-service-mesh ed estrae il file di installazione, che contiene istioctl, esempi e manifest. In caso contrario, asmcli scarica i file in una directory tmp. Puoi specificare un percorso relativo o un percorso completo. La variabile di ambiente $PWD non funziona qui.
      • --enable_all Consente allo strumento di:
        • Concedi le autorizzazioni IAM richieste.
        • Abilita le API di Google richieste.
        • Imposta un'etichetta sul cluster che identifica il mesh.
        • Registra il cluster nel parco risorse se non è già registrato.

      • --ca mesh_ca Ora puoi passare a Mesh CA poiché è stata distribuita la radice di attendibilità CA mesh.
      • REVISION_2 Consigliato. Sostituisci REVISION_2 con un nome che descrive l'installazione, ad esempio asm-1144-0-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 (come my-name o abc-123).
      • --option ca-migration-migration Quando esegui nuovamente il deployment dei tuoi carichi di lavoro, questa opzione configura i proxy in modo che utilizzino la radice di CA CA mesh.

Esegui la 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. Ottieni 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-1144-0-distribute-root-65d884685d-6hrdk      1/1     Running   0          67m   asm-1144-0-distribute-root
    istio-ingressgateway-asm-1144-0-distribute-root65d884685d-94wgz       1/1     Running   0          67m   asm-1144-0-distribute-root
    istio-ingressgateway-asm-1144-0-meshca-ca-migration-8b5fc8767-gk6hb   1/1     Running   0          5s    asm-1144-0-meshca-ca-migration
    istio-ingressgateway-asm-1144-0-meshca-ca-migration-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-1144-0-meshca-ca-migration
    istiod-asm-1144-0-distribute-root-67998f4b55-lrzpz                    1/1     Running   0          68m   asm-1144-0-distribute-root
    istiod-asm-1144-0-distribute-root-67998f4b55-r76kr                    1/1     Running   0          68m   asm-1144-0-distribute-root
    istiod-asm-1144-0-meshca-ca-migration-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-1144-0-meshca-ca-migration
    istiod-asm-1144-0-meshca-ca-migration-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-1144-0-meshca-ca-migration
    1. Nell'output, nella colonna REV, indica il valore dell'etichetta di revisione della nuova versione. In questo esempio, il valore è asm-1144-0-meshca-ca-migration.

    2. Nota anche il valore nell'etichetta di revisione della versione precedente di istiod. È necessario per eliminare la versione precedente di istiod quando hai completato il trasferimento dei carichi di lavoro alla nuova versione. Nell'esempio, il valore dell'etichetta della revisione della revisione precedente è asm-1144-0-distribute-root.

  2. 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
    
  3. Riavvia i pod per attivare la nuova iniezione.

    kubectl rollout restart deployment -n NAMESPACE
    
  4. Testa la tua applicazione per verificare che i carichi di lavoro funzionino correttamente. Assicurati che la comunicazione mTLS funzioni tra i carichi di lavoro nella versione precedente dello spazio dei nomi e i carichi di lavoro nello spazio dei nomi più recente.

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

  6. Segui i passaggi descritti in Upgrade in loco per eseguire l'upgrade dei deployment gateway meno recenti installati nel passaggio 11 della sezione precedente all'ultima revisione REVISION_2.

  7. Se ritieni che l'applicazione funzioni come previsto, continua con i passaggi per la transizione al nuovo piano di controllo. Se si è verificato un problema con la tua applicazione, segui i passaggi per eseguire il rollback.

    Completa la transizione

    Se ritieni che l'applicazione funzioni 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 anthos-service-meshGitHub.

    2. Configura il webhook di convalida in modo che utilizzi il nuovo piano di controllo.

      kubectl apply -f asm/istio/istiod-service.yaml
      
    3. Elimina il vecchio istio-ingressgatewaydeployment. 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. 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 della tua applicazione con la nuova revisione istiod, segui questi passaggi per eseguire il rollback alla revisione precedente:

    1. Segui i passaggi descritti in Upgrade in loco per eseguire il downgrade dei deployment del gateway a cui era stato eseguito l'upgrade nel passaggio 6 di questa sezione alla revisione precedente, REVISION_1.

    2. Rietichetta il tuo spazio dei nomi per abilitare l'iniezione automatica 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 di revisione nello spazio dei nomi corrisponda all'etichetta di revisione della versione precedente di istiod:

      kubectl get ns NAMESPACE --show-labels
      
    4. Riavvia i pod per attivare la nuova iniezione in modo che i proxy dispongano della versione precedente:

      kubectl rollout restart deployment -n NAMESPACE
      
    5. Rimuovi il nuovo deployment di 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 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 dell'autorità di certificazione e riavvia il nuovo piano di controllo

  1. Conserva i secret solo se ne hai 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 dell'autorità di certificazione 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. Ciò assicura che la vecchia radice di attendibilità sia rimossa da tutti i carichi di lavoro in esecuzione nel mesh.

    kubectl rollout restart deployment -n istio-system