Migrazione a Mesh CA basata su canary
Migrazione all'autorità di certificazione Cloud Service Mesh (Mesh CA) da Istio CA (nota anche come Citadel) richiede la migrazione del componente radice di fiducia. Prima di Cloud Service Mesh 1.10, se volevi eseguire la migrazione da Istio su Google Kubernetes Engine (GKE) a Cloud Service Mesh con Mesh CA, dovevi pianificare il tempo di riposo perché Cloud Service Mesh non era in grado di caricare più certificati principali. Pertanto, durante la migrazione, i carichi di lavoro appena di cui è stato eseguito il deployment si basano sul nuovo certificato radice, mentre altri si basano sul vecchio certificato radice. I carichi di lavoro che utilizzano certificati firmati da certificati radice diversi non possono autenticarsi tra loro. Ciò significa che il TLS (mTLS) il traffico viene interrotto durante la migrazione. L'intero cluster si riprende completamente solo quando il piano di controllo e tutti i carichi di lavoro in tutti gli spazi dei nomi vengono nuovamente implementati con il certificato dell'autorità di certificazione 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 on GKE al piano di controllo interno al cluster di Cloud Service Mesh 1.18.7-asm.26 con Mesh CA.
- Esegui l'upgrade da Cloud Service Mesh 1.15 o una release con patch 1.16 con Istio CA alla Piano di controllo nel cluster 1.18.7-asm.26 Cloud Service Mesh con Mesh CA.
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 per:- Installare gli strumenti necessari
- Scarica
asmcli
- Concedere le autorizzazioni di amministratore del cluster
- Convalida il progetto e il cluster
Strumenti richiesti
Durante la migrazione, esegui uno strumento fornito da Google, migrate_ca
, per verificare quanto segue per ogni pod del cluster:
- Il certificato radice per Istio CA e Mesh CA.
- Il certificato mTLS del carico di lavoro emesso dalla CA Istio e dalla CA Mesh.
- I domini attendibili configurati da Istio CA e Mesh CA.
Questo strumento ha le seguenti dipendenze:
awk
grep
istioctl
L'esecuzione delasmcli install
scarica la versione diistioctl
che corrisponda alla versione di Cloud Service Mesh che stai installando.jq
kubectl
openssl
Panoramica della migrazione
Per eseguire la migrazione a Mesh CA, segui la procedura di migrazione in base alle revisioni (indicata anche 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. Poi, muovi gradualmente i carichi di lavoro alla nuova revisione, il che ti consente di monitorare l'effetto della migrazione durante la procedura. Durante la procedura 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:
Distribuisci la radice di attendibilità Mesh CA.
Installa una nuova revisione del piano di controllo che utilizza la CA Istio con un che distribuirà la radice di attendibilità Mesh CA.
Esegui la migrazione dei carichi di lavoro al nuovo piano di controllo, uno spazio dei nomi alla volta, e testa la tua applicazione. Una volta eseguita correttamente la migrazione di tutti i carichi di lavoro nuovo piano di controllo, rimuovi quello precedente.
Esegui la migrazione a Mesh CA. Ora che tutti i proxy sidecar sono configurati vecchia radice di attendibilità 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 sulla revisione:
Installa una revisione del piano di controllo con Mesh CA abilitato.
Esegui la migrazione dei carichi di lavoro alla nuova revisione del piano di controllo, uno spazio dei nomi alla volta, e testa l'applicazione. Quando tutti i carichi di lavoro sono stati migrati correttamente al nuovo piano di controllo, rimuovi il vecchio piano di controllo.
Rimuovi nel cluster i secret delle CA associati alla vecchia CA e riavvia il nuovo piano di controllo.
Distribuisci la radice di attendibilità della CA Mesh
Prima di poter eseguire la migrazione a Mesh CA, 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 di piano di controllo che attivi la radice di attendibilità per la distribuzione di Mesh CA ai proxy di tutti i carichi di lavoro sul cluster. Al termine del processo, ogni proxy è configurato sia con la vecchia sia con la nuova radice della attendibilità. Con questo schema, quando esegui la migrazione a Mesh CA, i carichi di lavoro che utilizzano Mesh CA potranno autenticarsi con i carichi di lavoro che utilizzano la vecchia CA.
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.
Segui i passaggi descritti in Installare gli 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.Assicurati di avere la versione di
asmcli
che installa Cloud Service Mesh 1.11 o versioni successive:./asmcli --version
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 host del parco risorse.--kubeconfig
Il percorso del filekubeconfig
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 doveasmcli
scaricaanthos-service-mesh
pacchetto ed estrae il file di installazione, contiene,istioctl
, esempi e manifest. In caso contrario,asmcli
scarica i file in una directorytmp
. 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 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 la CA Istio (l'opzionecitadel
corrisponde alla CA Istio). A questo punto, non passare a Mesh CA.--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
: opzione consigliata. R revision label è una coppia chiave-valore impostato sul piano di controllo. La chiave dell'etichetta di revisione è sempreistio.io/rev
. Per impostazione predefinita, lo strumento imposta il valore per l'etichetta della revisione in base alla versione di Cloud Service Mesh, ad esempio:asm-1187-26
. Ti consigliamo di includere questa opzione e di sostituireREVISION_1
con un nome che descriva l'installazione, ad esempioasm-1187-26-distribute-root
. Il nome deve essere un'etichetta DNS-1035 e deve essere costituito da caratteri alfanumerici in minuscolo o-
, deve iniziare con un carattere alfabetico e terminare con un carattere alfanumerico (ad esempiomy-name
oabc-123
).
Esegui la migrazione dei carichi di lavoro al nuovo piano di controllo
Per completare la distribuzione della nuova radice di attendibilità, devi etichettare i tuoi spazi dei nomi con l'etichetta di revisioneistio.io/rev=<var>REVISION_1</var>-distribute-root
e riavviare i carichi di lavoro. 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 Mesh CA.
Imposta il contesto attuale per
kubectl
. Nel seguente comando, sostituisci--region
con--zone
se hai un cluster a zona singola.gcloud container clusters get-credentials CLUSTER_NAME \ --project=PROJECT_ID \ --region=CLUSTER_LOCATION
Scarica lo strumento di convalida:
curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/master/scripts/ca-migration/migrate_ca > migrate_ca
Imposta il bit eseguibile sullo strumento:
chmod +x migrate_ca
Lo strumento
migrate_ca
chiamaistioctl
, che dipende dalla versione. La Lo strumentoasmcli
aggiunge un link simbolico aistioctl
nella directory specificato per--output_dir
. Assicurati che la directory si trovi l'inizio del percorso. Nel comando seguente, sostituisciISTIOCTL_PATH
con la directory che contieneistioctl
scaricati dallo strumento.export PATH=ISTIOCTL_PATH:$PATH which istioctl echo $PATH
Recupera l'etichetta di revisione che si trova in
istiod
e inistio-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
Nell'output, nella colonna
REV
, prendi nota del valore dell'etichetta della revisione per la nuova revisione, che corrisponde all'etichetta della revisione specificata quando hai eseguitoasmcli install
. In questo esempio, il valore èasm-1187-26-distribute-root
.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 revisioneistiod
. L'output di esempio mostra una migrazione da Istio, che utilizza la revisionedefault
.
Aggiungi l'etichetta di revisione a uno spazio dei nomi e rimuovi l'etichetta
istio-injection
(se esistente). Nel comando seguente, sostituisciNAMESPACE
con lo spazio dei nomi da etichettare.kubectl label namespace NAMESPACE istio.io/rev=REVISION_1 istio-injection- --overwrite
Se nell'output viene visualizzato
"istio-injection not found"
, puoi ignorarlo. Ciò significa che lo spazio dei nomi non aveva precedentemente l'etichettaistio-injection
. Poiché il comportamento dell'inserimento automatico è non definito quando uno spazio dei nomi ha siaistio-injection
sia etichetta di revisione, tutti i comandikubectl label
in Cloud Service Mesh di sicurezza assicurano esplicitamente che ne sia impostata una sola.Riavvia i pod per attivare la re-iniezione.
kubectl rollout restart deployment -n NAMESPACE
Testa l'applicazione per verificare che i carichi di lavoro funzionino correttamente.
Se hai carichi di lavoro in altri spazi dei nomi, ripeti i passaggi per etichettare il dello spazio dei nomi e riavvia i pod.
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
Risultato previsto:
Namespace: foo httpbin-66cdbdb6c5-pmzps.foo trusts [CITADEL MESHCA] sleep-64d7d56698-6tmjm.foo trusts [CITADEL MESHCA]
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 del gateway nello stesso spazio dei nomi del gateway dell'installazione precedente per eseguire la migrazione senza tempi di riposo. Assicurati che e le risorse di servizio che puntano al gateway precedente devono includere il i deployment.
- Non eliminare i deployment dei gateway precedenti finché non hai la certezza che che l'applicazione funzioni correttamente (dopo il passaggio successivo).
- Usa
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.Completare la transizione
Se ritieni che la tua applicazione funzioni come previsto, rimuovi il vecchio piano di controllo per completare la transizione alla nuova versione.
Vai alla directory in cui si trovano i file del
anthos-service-mesh
repository GitHub.Configura il webhook di convalida per utilizzare il nuovo piano di controllo.
kubectl apply -f asm/istio/istiod-service.yaml
Elimina il vecchio
istio-ingressgateway
deployment. Il comando eseguito dipende dal fatto che tu stia eseguendo la migrazione da Istio o 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 precedenteistio-ingressgateway
.kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
Elimina la vecchia revisione di
istiod
. Il comando che utilizzi dipende se esegui la migrazione da Istio o 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 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 diistiod
.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
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:Elimina i nuovi deployment del gateway installati durante il passaggio 11.
Rinomina lo spazio dei nomi per attivare l'iniezione automatica con la versione precedente di
istiod
. Il comando da utilizzare dipende dal fatto che tu ha utilizzato un'etichetta di revisione oistio-injection=enabled
con la precedente completamente gestita.Se hai utilizzato un'etichetta di revisione per l'iniezione automatica:
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
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
Riavvia i pod per attivare la re-iniezione in modo che i proxy abbiano la versione precedente:
kubectl rollout restart deployment -n NAMESPACE
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
Rimuovi la nuova revisione di
istiod
.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_1 -n istio-system --ignore-not-found=true
Rimuovi la nuova configurazione di
IstioOperator
.kubectl delete IstioOperator installed-state-asm-1187-26-distribute-root -n istio-system
L'output previsto è simile al seguente:
istiooperator.install.istio.io "installed-state-asm-1187-26-distribute-root" deleted
Migrazione a Mesh CA
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 Mesh CA, i passaggi per eseguire la migrazione Mesh CA è simile a quelli che hai distribuito per la radice Mesh CA di attendibilità:
Installa un nuovo piano di controllo con Mesh CA abilitato
Utilizzi asmcli install
per installare una nuova revisione del piano di controllo con la CA Mesh attivata.
Se hai personalizzato l'installazione precedente, devi specificare uguale file di overlay quando esegui
asmcli install
.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 host del parco risorse.--kubeconfig
Il percorso delkubeconfig
file 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 doveasmcli
scaricaanthos-service-mesh
pacchetto ed estrae il file di installazione, contieneistioctl
, esempi e manifest. In caso contrario,asmcli
scarica i file in una directorytmp
. 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 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 a Mesh CA poiché la Mesh CA la radice di attendibilità sia stata distribuita.REVISION_2
consigliato. SostituisciREVISION_2
con un nome che descriva l'installazione, ad esempioasm-1187-26-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 (comemy-name
oabc-123
).--option ca-migration-migration
Quando esegui il ricollegamento dei carichi di lavoro, questa opzione configura i proxy in modo che utilizzino la CA radice di attendibilità di 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.
Recupera l'etichetta di revisione su
istiod
eistio-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-1187-26-distribute-root-65d884685d-6hrdk 1/1 Running 0 67m asm-1187-26-distribute-root istio-ingressgateway-asm-1187-26-distribute-root65d884685d-94wgz 1/1 Running 0 67m asm-1187-26-distribute-root istio-ingressgateway-asm-1187-26-meshca-ca-migration-8b5fc8767-gk6hb 1/1 Running 0 5s asm-1187-26-meshca-ca-migration istio-ingressgateway-asm-1187-26-meshca-ca-migration-8b5fc8767-hn4w2 1/1 Running 0 20s asm-1187-26-meshca-ca-migration istiod-asm-1187-26-distribute-root-67998f4b55-lrzpz 1/1 Running 0 68m asm-1187-26-distribute-root istiod-asm-1187-26-distribute-root-67998f4b55-r76kr 1/1 Running 0 68m asm-1187-26-distribute-root istiod-asm-1187-26-meshca-ca-migration-5cd96f88f6-n7tj9 1/1 Running 0 27s asm-1187-26-meshca-ca-migration istiod-asm-1187-26-meshca-ca-migration-5cd96f88f6-wm68b 1/1 Running 0 27s asm-1187-26-meshca-ca-migration
Nell'output, nella colonna
REV
, prendi nota del valore dell'etichetta della revisione per la nuova versione. In questo esempio, il valore èasm-1187-26-meshca-ca-migration
.Prendi nota anche del valore nell'etichetta di revisione della vecchia versione di
istiod
. Ti serve per eliminare la vecchia versione diistiod
al termine del trasferimento dei carichi di lavoro alla nuova versione. Nell'esempio, il valore del parametro l'etichetta di revisione della revisione precedente èasm-1187-26-distribute-root
.
Aggiungi la nuova etichetta di revisione a uno spazio dei nomi. Nel seguente comando, sostituire
NAMESPACE
con lo spazio dei nomi da etichettare.kubectl label namespace NAMESPACE istio.io/rev=REVISION_2 --overwrite
Riavvia i pod per attivare la re-iniezione.
kubectl rollout restart deployment -n NAMESPACE
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.
Se hai carichi di lavoro in altri spazi dei nomi, ripeti i passaggi per etichettare il dello spazio dei nomi e riavvia i pod.
Segui i passaggi descritti in Upgrade in loco per eseguire l'upgrade dei deployment dei gateway precedenti installati nel passaggio 11 della sezione precedente alla ultima revisione
REVISION_2
.Se ritieni che la tua applicazione funzioni come previsto, continua con i passaggi per la transizione al nuovo piano di controllo. Se si verifica un problema con l'applicazione, segui i passaggi per eseguire il rollback.
Completare la transizione
Se ritieni che la tua applicazione funzioni come previsto, rimuovi il vecchio piano di controllo per completare la transizione alla nuova versione.
Vai alla directory in cui si trovano i file del
anthos-service-mesh
repository GitHub.Configura il webhook di convalida per utilizzare il nuovo piano di controllo.
kubectl apply -f asm/istio/istiod-service.yaml
Elimina il deployment
istio-ingressgateway
precedente. Nel seguente comando, sostituisciOLD_REVISION
con l'etichetta della revisione per la versione precedente diistio-ingressgateway
.kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
Elimina la revisione
istiod
precedente. Nel comando seguente, sostituisciOLD_REVISION
con l'etichetta di revisione della versione precedente diistiod
.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
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:Segui i passaggi descritti nella sezione Upgrade in situ per eseguire il downgrade dei deployment dei gateway di cui è stato eseguito l'upgrade in precedenza nel passaggio 6 di questa sezione alla revisione precedente
REVISION_1
.Rinomina lo spazio dei nomi per attivare l'iniezione automatica con la revisione
istiod
precedente.kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
Risultato previsto:
namespace/NAMESPACE labeled
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
Riavvia i pod per attivare la re-iniezione in modo che i proxy abbiano la versione precedente:
kubectl rollout restart deployment -n NAMESPACE
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
Rimuovi la nuova versione di
istiod
. Assicurati che l'etichetta della revisione nel seguente comando corrisponda alla tua revisione.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_2 -n istio-system --ignore-not-found=true
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
Conserva i secret nel caso in cui ti servano:
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
Rimuovi i secret della CA nel cluster associato alla CA precedente:
kubectl delete secret cacerts istio-ca-secret -n istio-system --ignore-not-found
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