Migrazione basata su canary all'autorità di certificazione Cloud Service Mesh

La migrazione all'autorità di certificazione Cloud Service Mesh da Istio CA (nota anche come Citadel) richiede la migrazione della radice di attendibilità. Prima di Cloud Service Mesh 1.10, se volevi eseguire la migrazione da Istio su Google Kubernetes Engine (GKE) a Cloud Service Mesh con l'autorità di certificazione Cloud Service Mesh, dovevi pianificare un periodo di inattività perché Cloud Service Mesh non era in grado di caricare più certificati root. Pertanto, durante la migrazione, i workload appena implementati considerano attendibile il nuovo certificato radice, mentre altri considerano attendibile il vecchio certificato radice. I workload che utilizzano certificati firmati da certificati radice diversi non possono autenticarsi a vicenda. Ciò significa che il traffico TLS reciproco (mTLS) viene interrotto durante la migrazione. L'intero cluster viene ripristinato completamente solo quando il control plane e tutti i workload in tutti gli spazi dei nomi vengono ridistribuiti con il certificato dell'autorità di certificazione Cloud Service Mesh. Se la tua mesh ha più cluster con workload che inviano richieste ad altri workload su un altro cluster, anche tutti i workload su questi cluster devono essere aggiornati.

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

  • Esegui la migrazione da Istio su GKE al control plane in-cluster di Cloud Service Mesh 1.19.10-asm.9 con l'autorità di certificazione Cloud Service Mesh.
  • Esegui l'upgrade da Cloud Service Mesh 1.15 o una release con patch 1.16 con Istio CA al control plane in-cluster di Cloud Service Mesh 1.19.10-asm.9 con l'autorità di certificazione Cloud Service Mesh.

Limitazioni

  • Tutti i cluster GKE devono trovarsi nello stesso Google Cloud progetto.

Prerequisiti

Segui i passaggi descritti in Installa gli strumenti dipendenti e convalida il cluster per:

Strumenti richiesti

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 l'autorità di certificazione Cloud Service Mesh.
  • Il certificato mTLS del workload emesso da Istio CA e dall'autorità di certificazione Cloud Service Mesh.
  • I domini attendibili configurati da Istio CA e dall'autorità di certificazione Cloud Service Mesh.

Questo strumento ha le seguenti dipendenze:

  • awk
  • grep
  • istioctl L'esecuzione di asmcli install scarica la versione di istioctl che corrisponde alla versione di Cloud Service Mesh che stai installando.
  • jq
  • kubectl
  • openssl

Panoramica della migrazione

Per eseguire la migrazione all'autorità di certificazione Cloud Service Mesh, segui la procedura di migrazione basata sulle revisioni (nota anche come "aggiornamento canary"). Con una migrazione basata sulla revisione, viene eseguito il deployment di una nuova revisione del control plane insieme a quello esistente. Poi sposta gradualmente i carichi di lavoro nella nuova revisione, il 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 workload che utilizzano l'autorità di certificazione Cloud Service Mesh e i workload che utilizzano Istio CA.

Di seguito è riportato un riepilogo della migrazione all'autorità di certificazione Cloud Service Mesh:

  1. Distribuisci la radice di attendibilità dell'autorità di certificazione Cloud Service Mesh.

    1. Installa una nuova revisione del control plane che utilizza Istio CA con un'opzione che distribuirà la radice di attendibilità dell'autorità di certificazione Cloud Service Mesh.

    2. Esegui la migrazione dei workload al nuovo control plane, spazio dei nomi per spazio dei nomi, e testa l'applicazione. Quando tutti i workload sono stati migrati correttamente al nuovo control plane, rimuovi quello precedente.

  2. Esegui la migrazione all'autorità di certificazione Cloud Service Mesh. Ora che tutti i proxy sidecar sono configurati con la vecchia radice di attendibilità e la radice di attendibilità dell'autorità di certificazione Cloud Service Mesh, puoi eseguire la migrazione all'autorità di certificazione Cloud Service Mesh senza tempi di inattività. Anche in questo caso, segui la procedura di migrazione basata sulle revisioni:

    1. Installa una revisione del control plane con l'autorità di certificazione Cloud Service Mesh abilitata.

    2. Esegui la migrazione dei workload alla nuova revisione del control plane, spazio dei nomi per spazio dei nomi, e testa l'applicazione. Quando tutti i workload sono stati migrati correttamente al nuovo control plane, rimuovi quello precedente.

    3. Rimuovi i secret CA nel cluster associati alla vecchia CA e riavvia il nuovo control plane.

Distribuire la radice di attendibilità dell'autorità di certificazione Cloud Service Mesh

Prima di poter eseguire la migrazione all'autorità di certificazione Cloud Service Mesh, tutti i cluster GKE nel mesh devono avere Cloud Service Mesh 1.10 o versioni successive e tutti i cluster devono essere configurati con un'opzione del control plane che attivi la radice di attendibilità per l'autorità di certificazione Cloud Service Mesh da distribuire ai proxy di tutti i carichi di lavoro sul cluster. Al termine della procedura, ogni proxy viene configurato con la radice di attendibilità precedente e quella nuova. Con questo schema, quando esegui la migrazione all'autorità di certificazione Cloud Service Mesh, i workload che utilizzano l'autorità di certificazione Cloud Service Mesh potranno autenticarsi con i workload che utilizzano la vecchia CA.

Installa una nuova revisione del control plane

Installa una revisione del control plane con un'opzione che distribuisce la radice di attendibilità dell'autorità di certificazione Cloud Service Mesh.

  1. Segui i passaggi descritti in Installa strumenti dipendenti e convalida il cluster per prepararti a utilizzare uno strumento fornito da Google, asmcli, per installare la nuova revisione del control plane.

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

    ./asmcli --version

  3. Esegui asmcli install. Nel comando seguente, sostituisci i segnaposto con i tuoi 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, 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 nel cluster un'etichetta 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 Istio CA). Non passare all'autorità di certificazione Cloud Service Mesh in questo momento.
  • --ca_cert Il certificato intermedio.
  • --ca_key La chiave del certificato intermedio
  • --root_cert Il certificato radice.
  • --cert_chain La catena di certificati.
  • --option ca-migration-citadel Quando riesegui il deployment dei workload, questa opzione attiva la distribuzione della nuova radice di attendibilità ai proxy sidecar dei workload.
  • REVISION_1: consigliato. Un'etichetta di revisione è una coppia chiave-valore impostata sul control plane. La chiave di etichetta di revisione è sempre istio.io/rev. Per impostazione predefinita, lo strumento imposta il valore dell'etichetta di revisione in base alla versione di Cloud Service Mesh, ad esempio: asm-11910-9. Ti consigliamo di includere questa opzione e sostituire REVISION_1 con un nome che descriva l'installazione, ad esempio asm-11910-9-distribute-root. Il nome deve essere un'etichetta DNS-1035 e deve essere composto da caratteri alfanumerici minuscoli o -, iniziare con un carattere alfabetico e terminare con un carattere alfanumerico (ad esempio my-name o abc-123).

Esegui la migrazione dei workload al nuovo control plane

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 workload. Quando testi i tuoi workload dopo averli riavviati, esegui uno strumento per verificare che il proxy sidecar sia configurato con la radice di attendibilità precedente e quella nuova per l'autorità di certificazione Cloud Service Mesh.

  1. Imposta il contesto attuale 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 collegamento simbolico a istioctl nella directory che hai specificato per --output_dir. Assicurati che la directory si trovi all'inizio del percorso. Nel comando seguente, sostituisci ISTIOCTL_PATH con la directory che contiene istioctl scaricato dallo strumento.

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

  5. Ottieni l'etichetta di revisione presente 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, annota il valore dell'etichetta di revisione per la nuova revisione, che corrisponde all'etichetta di revisione che hai specificato quando hai eseguito asmcli install. In questo esempio, il valore è asm-11910-9-distribute-root.

    2. Devi eliminare la vecchia revisione di istiod quando hai finito 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. Aggiungi l'etichetta di revisione a uno spazio dei nomi e rimuovi l'etichetta istio-injection (se esiste). 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 nell'output vedi "istio-injection not found", puoi ignorarlo. Ciò significa che lo spazio dei nomi non aveva in precedenza l'etichetta istio-injection. Poiché il comportamento dell'inserimento automatico non è definito quando uno spazio dei nomi ha sia l'etichetta istio-injection sia quella di revisione, tutti i comandi kubectl label nella documentazione di Cloud Service Mesh assicurano esplicitamente che ne venga impostata solo una.

  7. Riavvia i pod per attivare la reiniezione.

    kubectl rollout restart deployment -n NAMESPACE

  8. Testa l'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 riavvia i pod.

  10. Verifica che i proxy sidecar per tutti i workload sul 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 (avanzato) per installare nuove implementazioni del gateway. Tieni presente quanto segue:

    • Utilizza REVISION_1 come etichetta della revisione.
    • Per eseguire la migrazione senza tempi di inattività, esegui il deployment delle risorse del gateway nello stesso spazio dei nomi del gateway dell'installazione precedente. Assicurati che le risorse di servizio che puntano al gateway precedente includano ora anche i deployment più recenti.
    • Non eliminare le implementazioni del gateway precedenti finché non avrai la certezza che la tua applicazione funzioni correttamente (dopo il passaggio successivo).

  12. Se ritieni che la tua applicazione funzioni come previsto, continua con i passaggi per la transizione alla nuova versione di istiod. Se si verifica un problema con l'applicazione, segui i passaggi per eseguire il rollback.

    Completa la transizione

    Se ritieni che la tua applicazione funzioni come previsto, rimuovi il control plane precedente per completare la transizione alla nuova versione.

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

    2. Configura il webhook di convalida in modo che utilizzi il nuovo control plane.

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

    3. Elimina il vecchio deployment istio-ingressgateway. Il comando che esegui dipende dal fatto che tu stia eseguendo la migrazione da Istio o l'upgrade da una versione precedente di Cloud Service Mesh:

      Esegui la migrazione

      Se hai eseguito la migrazione da Istio, il vecchio istio-ingressgateway non ha 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 Cloud Service Mesh, nel comando seguente sostituisci OLD_REVISION con l'etichetta di revisione per la 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 che utilizzi dipende dal fatto che tu stia eseguendo la migrazione da Istio o l'upgrade da una versione precedente di Cloud Service Mesh.

      Esegui la migrazione

      Se hai eseguito la migrazione da Istio, il vecchio istio-ingressgateway non ha 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 Cloud Service Mesh, nel comando seguente assicurati che OLD_REVISION corrisponda all'etichetta della 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 dell'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 lo spazio dei nomi per abilitare l'inserimento automatico con la versione precedente di istiod. Il comando che utilizzi 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 hai utilizzato istio-injection=enabled:

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

      Output previsto:

      namespace/NAMESPACE labeled

    3. Verifica che l'etichetta di revisione nello spazio dei nomi corrisponda a quella nella versione precedente di istiod:

      kubectl get ns NAMESPACE --show-labels

    4. Riavvia i pod per attivare il reinserimento in modo che i proxy abbiano la 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 IstioOperator.

      kubectl delete IstioOperator installed-state-asm-11910-9-distribute-root -n istio-system

      L'output previsto è simile al seguente:

      istiooperator.install.istio.io "installed-state-asm-11910-9-distribute-root" deleted

Esegui la migrazione all'autorità di certificazione Cloud Service Mesh

Ora che i proxy sidecar per tutti i workload sono configurati sia con la vecchia radice di attendibilità sia con la nuova radice di attendibilità per l'autorità di certificazione Cloud Service Mesh, i passaggi per eseguire la migrazione all'autorità di certificazione Cloud Service Mesh sono simili a quelli eseguiti per distribuire la radice di attendibilità dell'autorità di certificazione Cloud Service Mesh:

Installa un nuovo control plane con l'autorità di certificazione Cloud Service Mesh abilitata

Utilizzi asmcli install per installare una nuova revisione del control plane con la CA Mesh abilitata.

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

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

     ./asmcli install \
   --fleet_id FLEET_PROJECT_ID \
   --kubeconfig KUBECONFIG_FILE \
   --output_dir DIR_PATH \
   --enable_all \
   --ca mesh_ca \
   --option ca-migration-meshca \
  --revision_name REVISION_2 \
  OVERLAYS
      • --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, 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 nel cluster un'etichetta che identifica il mesh.
        • Registra il cluster nel parco risorse, se non è già registrato.
      • --ca mesh_ca Ora puoi passare all'autorità di certificazione Cloud Service Mesh, poiché la radice di attendibilità dell'autorità di certificazione Cloud Service Mesh è stata distribuita.
      • REVISION_2 Consigliata. Sostituisci REVISION_2 con un nome che descriva l'installazione, ad esempio asm-11910-9-meshca-ca-migration. Il nome deve essere un'etichetta DNS-1035 e deve essere composto da caratteri alfanumerici minuscoli o -, iniziare con un carattere alfabetico e terminare con un carattere alfanumerico (ad esempio my-name o abc-123).
      • --option ca-migration-migration Quando [riesegui il deployment dei tuoi carichi di lavoro](/service-mesh/docs/unified-install/install-anthos-service-mesh#deploy_and_redeploy_workloads), questa opzione configura i proxy in modo che utilizzino la radice di attendibilità dell'autorità di certificazione Cloud Service Mesh.

Esegui la migrazione dei workload al nuovo control plane

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

  1. Ottieni l'etichetta di revisione presente 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-11910-9-distribute-root-65d884685d-6hrdk      1/1     Running   0          67m   asm-11910-9-distribute-root
istio-ingressgateway-asm-11910-9-distribute-root65d884685d-94wgz       1/1     Running   0          67m   asm-11910-9-distribute-root
istio-ingressgateway-asm-11910-9-meshca-ca-migration-8b5fc8767-gk6hb   1/1     Running   0          5s    asm-11910-9-meshca-ca-migration
istio-ingressgateway-asm-11910-9-meshca-ca-migration-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-11910-9-meshca-ca-migration
istiod-asm-11910-9-distribute-root-67998f4b55-lrzpz                    1/1     Running   0          68m   asm-11910-9-distribute-root
istiod-asm-11910-9-distribute-root-67998f4b55-r76kr                    1/1     Running   0          68m   asm-11910-9-distribute-root
istiod-asm-11910-9-meshca-ca-migration-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-11910-9-meshca-ca-migration
istiod-asm-11910-9-meshca-ca-migration-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-11910-9-meshca-ca-migration

    1. Nell'output, nella colonna REV, annota il valore dell'etichetta di revisione per la nuova versione. In questo esempio, il valore è asm-11910-9-meshca-ca-migration.

    2. Prendi nota anche del valore nell'etichetta di revisione per la versione precedente di istiod. Ti serve per eliminare la versione precedente di istiod al termine del trasferimento dei carichi di lavoro alla nuova versione. Nell'esempio, il valore dell'etichetta di revisione per la revisione precedente è asm-11910-9-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 reiniezione.

    kubectl rollout restart deployment -n NAMESPACE

  4. Testa l'applicazione per verificare che i carichi di lavoro funzionino correttamente. Assicurati che la comunicazione mTLS funzioni tra i workload nello spazio dei nomi precedente e i workload 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 riavvia i pod.

  6. Segui i passaggi descritti nella sezione Upgrade sul posto per eseguire l'upgrade delle implementazioni del gateway precedenti installate nel passaggio 11 della sezione precedente all' ultima revisione REVISION_2.

  7. Se ritieni che la tua applicazione funzioni come previsto, continua con i passaggi per la transizione al nuovo control plane. Se si verifica un problema con l'applicazione, segui i passaggi per eseguire il rollback.

    Completa la transizione

    Se ritieni che la tua applicazione funzioni come previsto, rimuovi il control plane precedente per completare la transizione alla nuova versione.

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

    2. Configura il webhook di convalida in modo che utilizzi il nuovo control plane.

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

    3. Elimina il vecchio deployment istio-ingressgateway. 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 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 vecchia 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 revisione istiod, segui questi passaggi per eseguire il rollback alla revisione precedente:

    1. Segui i passaggi descritti nella sezione Upgrade sul posto per eseguire il downgrade dei deployment del gateway di cui è stato eseguito l'upgrade in precedenza nel passaggio 6 di questa sezione alla revisione precedente REVISION_1.

    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. Verifica che l'etichetta di revisione nello spazio dei nomi corrisponda a quella nella versione precedente di istiod:

      kubectl get ns NAMESPACE --show-labels

    4. Riavvia i pod per attivare il reinserimento in modo che i proxy abbiano la 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 della 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 della CA e riavvia il nuovo control plane

  1. Conserva i segreti nel caso in cui ti servissero:

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

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

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

  3. Riavvia il control plane appena installato. In questo modo, la vecchia radice di attendibilità viene pulita da tutti i carichi di lavoro in esecuzione nella mesh.

    kubectl rollout restart deployment -n istio-system