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

Migrazione all'autorità di certificazione Cloud Service Mesh (autorità di certificazione Cloud Service Mesh) da Istio CA (nota anche come Citadel) richiede la migrazione del componente radice di fiducia. Prima di Cloud Service Mesh 1.10, per eseguire la migrazione da Istio Da Google Kubernetes Engine (GKE) a Cloud Service Mesh con Cloud Service Mesh, devi pianificare tempo di inattività perché Cloud Service Mesh non è stato in grado di caricare più certificati radice. Pertanto, durante la migrazione, i nuovi carichi di lavoro di cui si esegue certificato radice, altri considerano attendibile il vecchio certificato radice. Carichi di lavoro che utilizzano certificati firmati da certificati radice diversi non possono autenticarsi con ciascun e l'altro. Ciò significa che il TLS (mTLS) il traffico viene interrotto durante la migrazione. L'intero cluster esegue il ripristino quando il piano di controllo e tutti i carichi di lavoro in tutti gli spazi dei nomi vengono rieseguito il deployment con il certificato dell'autorità di certificazione Cloud Service Mesh. Se il tuo mesh ha più cluster con carichi di lavoro che inviano richieste a carichi di lavoro su un altro cluster, anche questi cluster devono essere aggiornati.

Segui la procedura descritta in questa guida per i seguenti casi d'uso:

  • Esegui la migrazione da Istio su GKE Piano di controllo nel cluster 1.19.10-asm.9 Cloud Service Mesh con l'autorità di certificazione Cloud Service Mesh.
  • Esegui l'upgrade da Cloud Service Mesh 1.15 o versione di patch 1.16 con Istio CA alla Piano di controllo nel cluster 1.19.10-asm.9 Cloud Service Mesh con l'autorità di certificazione Cloud Service Mesh.

Limitazioni

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

Prerequisiti

Segui i passaggi descritti in Installare gli strumenti dipendenti e convalidare il cluster. a:

Strumenti richiesti

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

  • Il certificato radice per l'autorità di certificazione Istio CA e Cloud Service Mesh.
  • Il certificato mTLS per i carichi di lavoro emesso dalla CA Istio 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 del asmcli install scarica la versione di istioctl che corrisponda 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 le processo di migrazione basato sulle revisioni (anche noto come "upgrade canary"). Con una migrazione basata sulla revisione, Il deployment della revisione del piano di controllo viene eseguito insieme al piano di controllo esistente. Tu quindi trasferire gradualmente i carichi di lavoro alla nuova revisione, in modo da monitorare l'effetto della migrazione attraverso il processo. Durante il processo di migrazione, l'autenticazione e l'autorizzazione sono pienamente funzionanti tra carichi di lavoro l'autorità di certificazione e i carichi di lavoro di Cloud Service Mesh che utilizzano la CA Istio.

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 piano di controllo che utilizza la CA Istio con un che distribuirà la radice di attendibilità dell'autorità di certificazione Cloud Service Mesh.

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

  2. Esegui la migrazione all'autorità di certificazione Cloud Service Mesh. Ora che tutti i proxy sidecar sono configurati radice di attendibilità precedente e 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 il processo di migrazione basato sulla revisione:

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

    2. Esegui la migrazione dei carichi di lavoro alla nuova revisione del piano di controllo, spazio dei nomi per dello spazio dei nomi e testare l'applicazione. Quando tutti i carichi di lavoro hanno esito positivo è stata eseguita la migrazione al nuovo piano di controllo, rimuovi quello precedente.

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

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

Prima di eseguire la migrazione all'autorità di certificazione Cloud Service Mesh, devi prima eseguire tutti i cluster GKE nel mesh deve disporre di Cloud Service Mesh 1.10 o versioni successive e tutti i cluster devono essere configurati con un'opzione del piano di controllo che attiva la radice di attendibilità per l'autorità di certificazione Cloud Service Mesh distribuiti ai proxy di tutti i carichi di lavoro sul cluster. Quando processo completato, ogni proxy è configurato con il vecchio una nuova radice di attendibilità. Con questo schema, quando esegui la migrazione all'autorità di certificazione Cloud Service Mesh, che utilizza l'autorità di certificazione Cloud Service Mesh sarà in grado di eseguire l'autenticazione con 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 l'autorità di certificazione Cloud Service Mesh radice di attendibilità.

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

  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 del progetto progetto host del parco risorse.
  • --kubeconfig Il percorso verso File kubeconfig Puoi specificare un percorso relativo o un percorso completo. Ambiente la variabile $PWD non funziona qui.
  • --output_dir Includi questa opzione per specificare una directory dove asmcli scarica anthos-service-mesh pacchetto ed estrae il file di installazione, contiene, istioctl, esempi e manifest. Altrimenti asmcli scarica i file in una directory tmp. Puoi specificare un percorso relativo o un percorso completo. Ambiente la variabile $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 identifichi il mesh.
    • Registra il cluster nel parco risorse, se non è già registrato.
  • -ca citadel Per evitare tempi di inattività, specifica Istio CA (la "cittadella" corrisponde alla CA Istio). Non passare all'autorità di certificazione Cloud Service Mesh 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 rieseguire il deployment dei carichi di lavoro, questa opzione attiva la distribuzione della nuova radice di attendibilità proxy collaterali dei carichi di lavoro.
  • REVISION_1: consigliato. R L'[etichetta di revisione](/service-mesh/docs/revisions-overview) è una coppia chiave-valore impostato sul piano di controllo. La chiave dell'etichetta di revisione è sempre istio.io/rev. Per impostazione predefinita, lo strumento imposta il valore relativo etichetta di revisione basata sulla versione di Cloud Service Mesh, ad esempio: asm-11910-9. Ti consigliamo di includere questo e sostituisci REVISION_1 con un nome che descrive l'installazione, ad esempio asm-11910-9-distribute-root. Il nome deve essere un'etichetta DNS-1035 e deve essere composto da lettere minuscole caratteri alfanumerici o -, iniziano con un carattere alfabetico e terminano 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 il tuo spazi dei nomi con l'etichetta di revisione istio.io/rev=<var>REVISION_1</var>-distribute-root e riavvia il tuo carichi di lavoro con scale out impegnativi. Quando testi i carichi di lavoro dopo averli riavviati, esegui uno strumento per convalidare che il proxy sidecar sia configurato con la vecchia e la nuova root di attendibilità per l'autorità di certificazione Cloud Service Mesh.

  1. Imposta il contesto attuale per kubectl. Nel comando seguente, modifica Da --region a --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. La Lo strumento asmcli aggiunge un link simbolico a istioctl nella directory specificato per --output_dir. Assicurati che la directory si trovi l'inizio del percorso. Nel comando seguente, sostituisci ISTIOCTL_PATH con la directory che contiene istioctl scaricati dallo strumento.

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

  5. Recupera l'etichetta di revisione che si trova in istiod e in 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, annota il valore della revisione per la nuova revisione, che corrisponde all'etichetta di revisione che hai specificato al momento dell'esecuzione di asmcli install. In questo esempio, il valore è asm-11910-9-distribute-root.

    2. Quando avrai finito di spostare il dispositivo, dovrai eliminare la vecchia revisione di istiod carichi di lavoro con la nuova revisione. Prendi nota del valore nell'etichetta di revisione la vecchia revisione istiod. L'output di esempio mostra una migrazione Istio, che sta utilizzando la revisione default.

  6. Aggiungi l'etichetta di revisione a uno spazio dei nomi e rimuovi istio-injection dell'etichetta (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 ignoralo. Ciò significa che in precedenza lo spazio dei nomi non aveva Etichetta istio-injection. Poiché il comportamento dell'inserimento automatico è non definito quando uno spazio dei nomi ha sia istio-injection sia etichetta di revisione, tutti i comandi kubectl label in Cloud Service Mesh di sicurezza assicurano esplicitamente che ne sia impostata una sola.

  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 il dello spazio dei nomi e riavvia i pod.

  10. Verifica che i proxy collaterali per tutti i carichi di lavoro sul 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]

  11. Se devi eseguire la migrazione dei gateway, segui i passaggi descritti in Upgrade canary (avanzati) per installare nuovi deployment del gateway. Tieni presente quanto segue:

    • Usa REVISION_1 come etichetta di revisione.
    • Esegui il deployment delle risorse gateway nello stesso spazio dei nomi del gateway una precedente installazione per eseguire la migrazione senza tempi di inattività. Assicurati che Le risorse di servizio che puntano al gateway precedente devono includere il più recente i deployment.
    • Non eliminare i deployment dei gateway precedenti finché non hai la certezza che che l'applicazione funzioni correttamente (dopo il passaggio successivo).

  12. Se ritieni che la tua applicazione funzioni come previsto, continua con i passaggi per passare alla nuova versione di istiod. Se è presente 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 vecchio piano di controllo per completare la transizione alla nuova versione.

    1. Passa alla directory in cui si trovano i file dall'anthos-service-mesh Si trova il repository GitHub.

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

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

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

      Esegui migrazione

      Se hai eseguito la migrazione da Istio, la versione precedente di istio-ingressgateway non viene 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 seguente comando, sostituisci OLD_REVISION con l'etichetta di revisione della versione precedente 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 che usi dipende indica se stai eseguendo la migrazione da Istio o da una versione di Cloud Service Mesh.

      Esegui migrazione

      Se hai eseguito la migrazione da Istio, la versione precedente di istio-ingressgateway non viene 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 seguente, assicurati che OLD_REVISION corrisponde 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 dell'applicazione con la nuova di istiod, segui questi passaggi per tornare alla precedente versione:

    1. Elimina i nuovi deployment del gateway installati durante il passaggio 11.

    2. Rietichetta lo spazio dei nomi per abilitare l'inserimento automatico con la precedente versione di istiod. Il comando da utilizzare dipende dal fatto che tu ha utilizzato un'etichetta di revisione o istio-injection=enabled con la precedente completamente gestita.

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

      kubectl get ns NAMESPACE --show-labels

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

      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 di 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 carichi di lavoro sono configurati con entrambi i metodi la radice di attendibilità e la nuova radice di attendibilità per l'autorità di certificazione Cloud Service Mesh, i passaggi per di migrazione all'autorità di certificazione Cloud Service Mesh sono simili a quelle che hai distribuito La radice di attendibilità dell'autorità di certificazione Cloud Service Mesh:

Installa un nuovo piano di controllo con l'autorità di certificazione Cloud Service Mesh abilitata

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

  1. Se hai personalizzato l'installazione precedente, devi specificare uguale 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 \
   --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 del progetto progetto host del parco risorse.
      • --kubeconfig Il percorso verso File kubeconfig Puoi specificare un percorso relativo o un percorso completo. Ambiente la variabile $PWD non funziona qui.
      • --output_dir Includi questa opzione per specificare una directory dove asmcli scarica anthos-service-mesh pacchetto ed estrae il file di installazione, contiene istioctl, esempi e manifest. Altrimenti asmcli scarica i file in una directory tmp. Puoi specificare un percorso relativo o un percorso completo. Ambiente la variabile $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 identifichi 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, in quanto l'autorità di certificazione Cloud Service Mesh la radice di attendibilità sia stata distribuita.
      • REVISION_2 consigliato. Sostituisci REVISION_2 con un nome che descrive dell'installazione, ad esempio asm-11910-9-meshca-ca-migration. Il nome deve essere un'etichetta DNS-1035 e deve essere composto da lettere minuscole caratteri alfanumerici o -, iniziano con un carattere alfabetico e terminano con un carattere alfanumerico (come my-name o abc-123).
      • --option ca-migration-migration Quando [rieseguire il deployment dei 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 carichi di lavoro al nuovo piano di controllo

Per completare l'installazione, devi etichettare gli spazi dei nomi con il nuovo l'etichetta di revisione e riavvia i carichi di lavoro.

  1. Recupera l'etichetta di revisione che si trova in istiod e in 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, sotto la colonna REV, annota il valore della revisione l'etichetta 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 della versione precedente di istiod. Ti servirà per eliminare la versione precedente di istiod al termine dell'operazione e trasferire i carichi di lavoro alla nuova versione. Nell'esempio, il valore del parametro l'etichetta di revisione della 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 carichi di lavoro nella versione precedente e 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 il dello spazio dei nomi e riavvia i pod.

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

  7. Se ritieni che la tua applicazione funzioni come previsto, continua con i passaggi per passare al nuovo piano di controllo. Se è presente 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 vecchio piano di controllo per completare la transizione alla nuova versione.

    1. Passa alla directory in cui si trovano i file dall'anthos-service-mesh Si trova il repository GitHub.

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

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

    3. Elimina il precedente deployment istio-ingressgateway. Nel seguente sostituisci OLD_REVISION con la revisione dell'etichetta 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 revisione istiod precedente. Nel comando seguente, sostituisci OLD_REVISION con l'etichetta di revisione per alla 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 istiod revisione, segui questi passaggi per eseguire il rollback alla precedente revisione:

    1. Segui i passaggi descritti in Upgrade in loco per eseguire il downgrade dei deployment dei gateway di cui è già stato eseguito passaggio 6 di questa sezione alla revisione REVISION_1 precedente.

    2. Rietichetta lo spazio dei nomi per abilitare l'inserimento automatico con la precedente istiod revisione.

      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 alla revisione etichetta nella versione precedente di istiod:

      kubectl get ns NAMESPACE --show-labels

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

      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 corrisponde 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 piano di controllo

  1. Mantieni i secret nel caso ti servissero:

    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 della 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. Questo assicura che la vecchia radice di l'attendibilità viene rimossa da tutti i carichi di lavoro in esecuzione nel mesh.

    kubectl rollout restart deployment -n istio-system