Questa pagina fa parte di una guida di più pagine che spiega come eseguire la migrazione da Istio alla versione 1.11.8 di Anthos Service Mesh su un cluster GKE per un mesh contenente più cluster che si trovano in diversi progetti Google Cloud. Se hai una versione precedente di Istio, devi eseguire l'upgrade prima di eseguire la migrazione ad Anthos Service Mesh. Se devi eseguire l'upgrade, vai alla pagina Esegui l'upgrade di Istio nella versione applicabile di Istio. Tieni presente che l'upgrade di Istio in più di una versione secondaria (ad esempio da 1.6.x a 1.8.x) in un solo passaggio non è ufficialmente testato né consigliato.
Per le migrazioni su un mesh a cluster singolo o per un mesh contenente più cluster nello stesso progetto Google Cloud, consulta Installazione, migrazione ed upgrade per GKE.
Prima di iniziare
Prima di installare Anthos Service Mesh, assicurati di avere:
- Configura il tuo ambiente per installare gli strumenti di cui hai bisogno.
- Configura il tuo progetto per abilitare le API richieste e impostare le autorizzazioni.
- Configura il tuo cluster per abilitare le opzioni richieste per il cluster.
Preparazione per la migrazione
Assicurati di consultare la Preparazione per la migrazione da Istio.
Per eseguire la migrazione da Istio, devi seguire il processo di upgrade della revisione (indicato come upgrade "canary" nella documentazione di Istio). Con un upgrade basato su revisione,
installi una nuova revisione del piano di controllo insieme a quello esistente. Quando esegui istioctl install
, includi un'opzione per impostare un'etichetta
revision
che identifica il nuovo piano di controllo.
Quindi eseguirai la migrazione alla nuova versione impostando la stessa etichetta revision
sui tuoi carichi di lavoro ed eseguendo un riavvio in sequenza per reinserire i proxy con la nuova versione e configurazione di Anthos Service Mesh. Con questo approccio, puoi monitorare l'effetto dell'upgrade su una piccola percentuale dei carichi di lavoro. Dopo aver testato l'applicazione, puoi eseguire la migrazione di tutto il traffico alla nuova revisione. Questo approccio è molto più sicuro rispetto a un upgrade in loco in cui un nuovo piano di controllo sostituisce immediatamente la versione precedente.
Impostazione di credenziali e autorizzazioni
Inizializza il progetto per prepararlo per l'installazione. Tra le altre cose, questo comando crea un account di servizio per consentire ai componenti del piano dati, come il proxy sidecar, di accedere in modo sicuro ai dati e alle risorse del tuo progetto.
curl --request POST \ --header "Authorization: Bearer $(gcloud auth print-access-token)" \ --data '' \ "https://meshconfig.googleapis.com/v1alpha1/projects/${PROJECT_ID}:initialize"
Il comando risponde con parentesi graffe vuote:
{}
Ottieni credenziali di autenticazione per interagire con il cluster. Questo comando imposta anche il contesto attuale per
kubectl
nel cluster.gcloud container clusters get-credentials ${CLUSTER_NAME} \ --project=${PROJECT_ID}
Concedi all'utente corrente le autorizzazioni di amministratore del cluster. Devi disporre di queste autorizzazioni per creare le regole di controllo dell'controllo dell'accesso basato sui ruoli (RBAC) necessarie per Anthos Service Mesh.
kubectl create clusterrolebinding cluster-admin-binding \ --clusterrole=cluster-admin \ --user="$(gcloud config get-value core/account)"
Se viene visualizzato l'errore "cluster-admin-binding" already exists
, puoi tranquillamente ignorarlo e continuare con l'associazione cluster-admin-binding esistente.
Download del file di installazione in corso...
Linux
Scarica il file di installazione di Anthos Service Mesh nella tua directory di lavoro attuale:
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.11.8-asm.4-linux-amd64.tar.gz
Scarica il file della firma e utilizza
openssl
per verificare la firma:curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.11.8-asm.4-linux-amd64.tar.gz.1.sig openssl dgst -verify /dev/stdin -signature istio-1.11.8-asm.4-linux-amd64.tar.gz.1.sig istio-1.11.8-asm.4-linux-amd64.tar.gz <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
L'output previsto è:
Verified OK
.Estrai i contenuti del file in qualsiasi posizione nel file system. Ad esempio, per estrarre i contenuti nella directory di lavoro corrente:
tar xzf istio-1.11.8-asm.4-linux-amd64.tar.gz
Il comando crea una directory di installazione nella directory di lavoro corrente denominata
istio-1.11.8-asm.4
che contiene:- Applicazioni di esempio nella directory
samples
. - Lo strumento a riga di comando
istioctl
che utilizzi per installare Anthos Service Mesh si trova nella directorybin
. - I profili di configurazione di Anthos Service Mesh si trovano nella directory
manifests/profiles
.
- Applicazioni di esempio nella directory
Assicurati di essere nella directory principale dell'installazione di Anthos Service Mesh.
cd istio-1.11.8-asm.4
Mac OS
Scarica il file di installazione di Anthos Service Mesh nella directory di lavoro attuale:
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.11.8-asm.4-osx.tar.gz
Scarica il file della firma e utilizza
openssl
per verificare la firma:curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.11.8-asm.4-osx.tar.gz.1.sig openssl dgst -sha256 -verify /dev/stdin -signature istio-1.11.8-asm.4-osx.tar.gz.1.sig istio-1.11.8-asm.4-osx.tar.gz <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
L'output previsto è:
Verified OK
.Estrai i contenuti del file in qualsiasi posizione nel file system. Ad esempio, per estrarre i contenuti nella directory di lavoro corrente:
tar xzf istio-1.11.8-asm.4-osx.tar.gz
Il comando crea una directory di installazione nella directory di lavoro corrente denominata
istio-1.11.8-asm.4
che contiene:- Applicazioni di esempio nella directory
samples
. - Lo strumento a riga di comando
istioctl
che utilizzi per installare Anthos Service Mesh si trova nella directorybin
. - I profili di configurazione di Anthos Service Mesh si trovano nella directory
manifests/profiles
.
- Applicazioni di esempio nella directory
Assicurati di essere nella directory principale dell'installazione di Anthos Service Mesh.
cd istio-1.11.8-asm.4
Windows
Scarica il file di installazione di Anthos Service Mesh nella directory di lavoro attuale:
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.11.8-asm.4-win.zip
Scarica il file della firma e utilizza
openssl
per verificare la firma:curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.11.8-asm.4-win.zip.1.sig openssl dgst -verify - -signature istio-1.11.8-asm.4-win.zip.1.sig istio-1.11.8-asm.4-win.zip <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
L'output previsto è:
Verified OK
.Estrai i contenuti del file in qualsiasi posizione nel file system. Ad esempio, per estrarre i contenuti nella directory di lavoro corrente:
tar xzf istio-1.11.8-asm.4-win.zip
Il comando crea una directory di installazione nella directory di lavoro corrente denominata
istio-1.11.8-asm.4
che contiene:- Applicazioni di esempio nella directory
samples
. - Lo strumento a riga di comando
istioctl
che utilizzi per installare Anthos Service Mesh si trova nella directorybin
. - I profili di configurazione di Anthos Service Mesh si trovano nella directory
manifests/profiles
.
- Applicazioni di esempio nella directory
Assicurati di essere nella directory principale dell'installazione di Anthos Service Mesh.
cd istio-1.11.8-asm.4
Preparazione dei file di configurazione delle risorse
Quando esegui il comando istioctl install
, specifichi
-f istio-operator.yaml
nella riga di comando. Questo file contiene informazioni sul progetto e sul cluster richieste da Anthos Service Mesh. Devi scaricare un pacchetto contenente istio-operator.yaml
e altri file di configurazione delle risorse per poter impostare le informazioni sul progetto e sul cluster.
Per preparare i file di configurazione delle risorse:
Mesh CA
Crea una nuova directory per i file di configurazione delle risorse del pacchetto Anthos Service Mesh. Ti consigliamo di utilizzare il nome del cluster come nome della directory.
Passa alla directory in cui vuoi scaricare il pacchetto Anthos Service Mesh.
Verifica la versione di
kpt
. Assicurati di eseguire una versione precedente alla versione 1.x di kpt:kpt version
L'output dovrebbe essere simile al seguente:
0.39.2
Se hai
kpt
versione 1.x o successiva, consulta la sezione relativa alla configurazione dell'ambiente per scaricare la versione richiesta per il tuo sistema operativo.Scarica il pacchetto:
kpt pkg get \ https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.11 asm
Imposta l'ID per il progetto in cui è stato creato il cluster:
kpt cfg set asm gcloud.core.project ${PROJECT_ID}
Imposta il numero di progetto per il progetto host del parco risorse:
kpt cfg set asm gcloud.project.environProjectNumber ${FLEET_PROJECT_NUMBER}
Imposta il nome del cluster:
kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}
Imposta la zona o la regione predefinita:
kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}
Imposta il tag sulla versione di Anthos Service Mesh che stai installando:
kpt cfg set asm anthos.servicemesh.tag 1.11.8-asm.4
Imposta la revisione nei file di configurazione delle risorse del pacchetto Anthos Service Mesh:
kpt cfg set asm anthos.servicemesh.rev asm-1118-4
Quando installi Anthos Service Mesh, imposti un'etichetta di revisione su
istiod
. Devi impostare la stessa revisione sul webhook di convalida.Poiché i cluster nella tua configurazione multi-cluster si trovano in progetti diversi, devi configurare gli alias dominio di attendibilità per gli altri progetti che formeranno il mesh di servizi multi-cluster/multiprogetto.
Recupera l'ID progetto di tutti i cluster che saranno nel mesh multi-cluster/più progetti.
Per l'ID progetto di ogni cluster, imposta gli alias dominio di attendibilità. Ad esempio, se hai cluster in 3 progetti, esegui il comando seguente e sostituisci
PROJECT_ID_1
,PROJECT_ID_2
ePROJECT_ID_3
con l'ID progetto di ogni cluster.kpt cfg set asm anthos.servicemesh.trustDomainAliases PROJECT_ID_1.svc.id.goog PROJECT_ID_2.svc.id.goog PROJECT_ID_3.svc.id.goog
Quando configuri i cluster negli altri progetti, puoi utilizzare lo stesso comando.
Gli alias dominio di attendibilità consentono a Mesh CA di autenticare i carichi di lavoro su cluster in altri progetti. Oltre a impostare gli alias dominio di attendibilità, dopo l'installazione di Anthos Service Mesh, devi abilitare il bilanciamento del carico tra cluster.
Restituisce come output i valori dei setter
kpt
:kpt cfg list-setters asm
L'output del comando è simile al seguente:
NAME VALUE anthos.servicemesh.canonicalServiceHub gke.gcr.io/asm/canonical-service-controller:1.11.8-asm.4 anthos.servicemesh.controlplane.monitoring.enabled true anthos.servicemesh.hub gke.gcr.io/asm anthos.servicemesh.hubMembershipID MEMBERSHIP_ID anthos.servicemesh.tag 1.11.8-asm.4 anthos.servicemesh.trustDomainAliases [example-project-12345.svc.id.goog,example-project-23456.svc.id.goog,example-project-98765.svc.id.goog] base-dir base gcloud.compute.location us-central gcloud.compute.network default gcloud.compute.subnetwork default gcloud.container.cluster example-cluster-1 gcloud.container.cluster.clusterSecondaryRange gcloud.container.cluster.releaseChannel REGULAR gcloud.container.cluster.servicesSecondaryRange gcloud.container.nodepool.max-nodes 4 gcloud.core.project example-project-12345 gcloud.project.environProjectID FLEET_PROJECT_ID gcloud.project.environProjectNumber 1234567890123 gcloud.project.projectNumber 9876543210987
Verifica che i valori dei seguenti setter siano corretti:
- anthos.servicemesh.rev
- anthos.servicemesh.tag
- anthos.servicemesh.trustDomainAliases
- gcloud.compute.location
- gcloud.container.cluster
- gcloud.core.project
- gcloud.project.environProjectNumber
Puoi ignorare i valori degli altri impostatori.
CA Istio
Crea una nuova directory per i file di configurazione delle risorse del pacchetto Anthos Service Mesh. Ti consigliamo di utilizzare il nome del cluster come nome della directory.
Passa alla directory in cui vuoi scaricare il pacchetto Anthos Service Mesh.
Verifica la versione di
kpt
. Assicurati di eseguire una versione precedente alla versione 1.x di kpt:kpt version
L'output dovrebbe essere simile al seguente:
0.39.2
Se disponi di
kpt
versione 1.x o successiva, scarica la versione richiesta:curl -L https://github.com/GoogleContainerTools/kpt/releases/download/v0.39.2/kpt_linux_amd64 > kpt_0_39_2 chmod +x kpt_0_39_2 alias kpt="$(readlink -f kpt_0_39_2)"
Scarica il pacchetto:
kpt pkg get \ https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.11 asm
Imposta l'ID per il progetto in cui è stato creato il cluster:
kpt cfg set asm gcloud.core.project ${PROJECT_ID}
Imposta il numero di progetto per il progetto host del parco risorse:
kpt cfg set asm gcloud.project.environProjectNumber ${FLEET_PROJECT_NUMBER}
Imposta il nome del cluster:
kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}
Imposta la zona o la regione predefinita:
kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}
Imposta il tag sulla versione di Anthos Service Mesh che stai installando:
kpt cfg set asm anthos.servicemesh.tag 1.11.8-asm.4
Imposta la revisione nei file di configurazione delle risorse del pacchetto Anthos Service Mesh:
kpt cfg set asm anthos.servicemesh.rev asm-1118-4
Restituisce come output i valori dei setter
kpt
:kpt cfg list-setters asm
L'output del comando è simile al seguente:
NAME VALUE anthos.servicemesh.canonicalServiceHub gke.gcr.io/asm/canonical-service-controller:1.11.8-asm.4 anthos.servicemesh.controlplane.monitoring.enabled true anthos.servicemesh.hub gke.gcr.io/asm anthos.servicemesh.hubMembershipID MEMBERSHIP_ID anthos.servicemesh.tag 1.11.8-asm.4 anthos.servicemesh.trustDomainAliases base-dir base gcloud.compute.location us-central gcloud.compute.network default gcloud.compute.subnetwork default gcloud.container.cluster example-cluster-1 gcloud.container.cluster.clusterSecondaryRange gcloud.container.cluster.releaseChannel REGULAR gcloud.container.cluster.servicesSecondaryRange gcloud.container.nodepool.max-nodes 4 gcloud.core.project example-project-12345 gcloud.project.environProjectID FLEET_PROJECT_ID gcloud.project.environProjectNumber 1234567890123 gcloud.project.projectNumber 9876543210987
Verifica che i valori dei seguenti setter siano corretti:
- anthos.servicemesh.rev
- anthos.servicemesh.tag
- gcloud.compute.location
- gcloud.container.cluster
- gcloud.core.project
- gcloud.project.environProjectNumber
Puoi ignorare i valori degli altri impostatori.
Migrazione ad Anthos Service Mesh
Mesh CA
Verifica che il contesto
kubeconfig
attuale punti al cluster su cui vuoi installare Anthos Service Mesh:kubectl config current-context
L'output è nel seguente formato:
gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME
Il contesto
kubeconfig
e i valori dei setterkpt
devono corrispondere. Se necessario, esegui il comandogcloud container clusters get-credentials
per impostare il contesto attuale dikubeconfig
.Se necessario, passa alla directory
istio-1.11.8-asm.4
. Il clientistioctl
dipende dalla versione. Assicurati di utilizzare la versione presente nella directoryistio-1.11.8-asm.4/bin
.Esegui questo comando per eseguire il deployment del nuovo piano di controllo con il profilo
asm-gcp-multiproject
. Se vuoi abilitare una funzionalità facoltativa supportata, includi-f
e il nome del file YAML nella riga di comando seguente. Per ulteriori informazioni, consulta Attivazione delle funzionalità facoltative.bin/istioctl install \ -f asm/istio/istio-operator.yaml \ -f asm/istio/options/multiproject.yaml \ -f asm/istio/options/multicluster.yaml \ --revision=asm-1118-4
L'argomento
--revision
aggiunge aistiod
un'etichetta di revisione nel formatoistio.io/rev=asm-1118-4
. L'etichetta della revisione viene utilizzata dal webhook automatico dell'iniettore sidecar per associare i file collaterali inseriti a una determinata revisioneistiod
. Per abilitare l'inserimento automatico collaterale per uno spazio dei nomi, devi etichettarlo con una revisione che corrisponda a un deploymentistiod
.I seguenti file eseguono l'override delle impostazioni nel file
istio-operator.yaml
:Il file
multiproject.yaml
imposta il profiloasm-gcp-multiproject
.Il file
multicluster.yaml
configura le impostazioni necessarie ad Anthos Service Mesh per una configurazione multi-cluster.
Verifica che i pod del piano di controllo in
istio-system
siano attivi:kubectl get pods -n istio-system
Output di esempio:
NAME READY STATUS RESTARTS AGE istio-ingressgateway-c56675fcd-86zdn 1/1 Running 0 2m9s istio-ingressgateway-c56675fcd-vn4nv 1/1 Running 0 2m21s istiod-asm-1118-4-6d5cfd4b89-xztlr 1/1 Running 0 3m44s istiod-fb7f746f4-wcntn 1/1 Running 0 50m
Hai due deployment e servizi del piano di controllo in esecuzione affiancati.
Esegui il deployment del controller del servizio canonico nel cluster:
kubectl apply -f asm/canonical-service/controller.yaml
Il controller di servizio canonico raggruppa i carichi di lavoro appartenenti allo stesso servizio logico. Per ulteriori informazioni sui servizi canonici, consulta la panoramica del servizio canonico.
CA Istio
Verifica che il contesto
kubeconfig
attuale punti al cluster su cui vuoi installare Anthos Service Mesh:kubectl config current-context
L'output è nel seguente formato:
gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME
Il contesto
kubeconfig
e i valori dei setterkpt
devono corrispondere. Se necessario, esegui il comandogcloud container clusters get-credentials
per impostare il contesto attuale dikubeconfig
.Se necessario, passa alla directory
istio-1.11.8-asm.4
. Il clientistioctl
dipende dalla versione. Assicurati di utilizzare la versione presente nella directoryistio-1.11.8-asm.4/bin
.Esegui questo comando per eseguire il deployment del nuovo piano di controllo con il profilo
asm-gcp-multiproject
. Se vuoi abilitare una funzionalità facoltativa supportata, includi-f
e il nome del file YAML nella riga di comando seguente. Per ulteriori informazioni, consulta Attivazione delle funzionalità facoltative.bin/istioctl install \ -f asm/istio/istio-operator.yaml \ -f asm/istio/options/citadel-ca.yaml \ -f asm/istio/options/multiproject.yaml \ -f asm/istio/options/multicluster.yaml \ --revision=asm-1118-4
L'argomento
--revision
aggiunge aistiod
un'etichetta di revisione nel formatoistio.io/rev=asm-1118-4
. L'etichetta della revisione viene utilizzata dal webhook automatico dell'iniettore sidecar per associare i file collaterali inseriti a una determinata revisioneistiod
. Per abilitare l'inserimento automatico collaterale per uno spazio dei nomi, devi etichettarlo con una revisione che corrisponda a un deploymentistiod
.I seguenti file eseguono l'override delle impostazioni nel file
istio-operator.yaml
:L'istanza
citadel-ca.yaml
configura la CA Istio come autorità di certificazione.Il file
multiproject.yaml
imposta il profiloasm-gcp-multiproject
.Il file
multicluster.yaml
configura le impostazioni necessarie ad Anthos Service Mesh per una configurazione multi-cluster.
Verifica che i pod del piano di controllo in
istio-system
siano attivi:kubectl get pods -n istio-system
Output di esempio:
NAME READY STATUS RESTARTS AGE istio-ingressgateway-c56675fcd-86zdn 1/1 Running 0 2m9s istio-ingressgateway-c56675fcd-vn4nv 1/1 Running 0 2m21s istiod-asm-1118-4-6d5cfd4b89-xztlr 1/1 Running 0 3m44s istiod-fb7f746f4-wcntn 1/1 Running 0 50m
Hai due deployment e servizi del piano di controllo in esecuzione affiancati.
Esegui il deployment del controller del servizio canonico nel cluster:
kubectl apply -f asm/canonical-service/controller.yaml
Il controller di servizio canonico raggruppa i carichi di lavoro appartenenti allo stesso servizio logico. Per ulteriori informazioni sui servizi canonici, consulta la panoramica del servizio canonico.
Deployment e nuovo deployment dei carichi di lavoro
L'installazione non è completa finché non abiliti l'iniezione automatica del proxy sidecar (inserimento automatica). Le migrazioni da Istio OSS e dagli upgrade seguono il processo di upgrade basato su revisioni (indicati come "upgrade canary" nella documentazione di Istio). Con un upgrade basato su revisione, la nuova versione del piano di controllo viene installata insieme al piano di controllo esistente. Puoi quindi spostare alcuni dei tuoi carichi di lavoro alla nuova versione, in modo da monitorare l'effetto dell'upgrade con una piccola percentuale dei carichi di lavoro, prima di eseguire la migrazione di tutto il traffico alla nuova versione.
Quando hai eseguito istioctl install
, hai impostato un'etichetta di revisione nel formato istio.io/rev=asm-1118-4
su istiod
. Per abilitare l'inserimento automatico, aggiungi un'etichetta di revisione corrispondente agli spazi dei nomi. L'etichetta di revisione viene utilizzata dal webhook dell'iniettore sidecar per associare i file collaterali inseriti a una determinata revisione istiod
. Dopo aver aggiunto l'etichetta, riavvia i pod nello spazio dei nomi per consentire l'inserimento dei file collaterali.
Recupera l'etichetta di revisione che si trova su
istiod
eistio-ingressgateway
.kubectl get pod -n istio-system -L istio.io/rev
L'output del comando è simile al seguente.
NAME READY STATUS RESTARTS AGE REV istio-ingressgateway-65d884685d-6hrdk 1/1 Running 0 67m istio-ingressgateway-65d884685d-94wgz 1/1 Running 0 67m istio-ingressgateway-asm-182-2-8b5fc8767-gk6hb 1/1 Running 0 5s asm-1118-4 istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2 1/1 Running 0 20s asm-1118-4 istiod-asm-176-1-67998f4b55-lrzpz 1/1 Running 0 68m asm-1107-1 istiod-asm-176-1-67998f4b55-r76kr 1/1 Running 0 68m asm-1107-1 istiod-asm-182-2-5cd96f88f6-n7tj9 1/1 Running 0 27s asm-1118-4 istiod-asm-182-2-5cd96f88f6-wm68b 1/1 Running 0 27s asm-1118-4
Nell'output, sotto la colonna
REV
, prendi nota del valore dell'etichetta di revisione per la nuova versione. In questo esempio, il valore èasm-1118-4
.Nota anche il valore nell'etichetta di revisione per la vecchia versione di
istiod
. Questa operazione ti consente di eliminare la versione precedente diistiod
quando hai finito di spostare i carichi di lavoro alla nuova versione. Nell'output di esempio, il valore dell'etichetta di revisione per la versione precedente èasm-1107-1
.
Aggiungi l'etichetta di revisione a uno spazio dei nomi e rimuovi l'etichetta
istio-injection
(se esistente). Nel comando seguente, impostaREVISION
sul valore che corrisponde alla nuova revisione diistiod
.kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite
Se vedi
"istio-injection not found"
nell'output, puoi ignorarlo. Ciò significa che in precedenza lo spazio dei nomi non aveva l'etichettaistio-injection
. Poiché l'inserimento automatica non riesce se uno spazio dei nomi contiene sia l'etichettaistio-injection
sia l'etichetta di revisione, tutti i comandikubectl label
nella documentazione di Anthos Service Mesh comprendono la rimozione dell'etichettaistio-injection
.Riavvia i pod per attivare la reinserimento.
kubectl rollout restart deployment -n NAMESPACE
Testa l'applicazione per verificare che i carichi di lavoro funzionino correttamente.
Se disponi di carichi di lavoro in altri spazi dei nomi, ripeti i passaggi per etichettare lo spazio dei nomi e riavviare i pod.
Se sei soddisfatto del funzionamento previsto dell'applicazione, continua con i passaggi per la transizione alla nuova versione di
istiod
. Se si verifica un problema con l'applicazione, segui la procedura per eseguire il rollback.Completa la transizione
Se l'applicazione funziona come previsto, rimuovi il piano di controllo precedente per completare la transizione alla nuova versione.
Passa alla directory in cui si trovano i file del repository GitHub di
anthos-service-mesh
.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 da eseguire varia a seconda che tu stia eseguendo la migrazione da Istio o da una versione precedente di Anthos Service Mesh:Esegui migrazione
Se hai eseguito la migrazione da Istio, il vecchio
istio-ingressgateway
non avrà un'etichetta di revisione.kubectl delete deploy/istio-ingressgateway -n istio-system
Esegui l'upgrade
Se hai eseguito l'upgrade da una versione precedente di Anthos Service Mesh, nel comando seguente sostituisci
OLD_REVISION
con l'etichetta di revisione della versione precedente diistio-ingressgateway
.kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
Elimina la versione precedente di
istiod
. Il comando da utilizzare varia a seconda che tu stia eseguendo la migrazione da Istio o da una versione precedente di Anthos Service Mesh.Esegui migrazione
Se hai eseguito la migrazione da Istio, il vecchio
istio-ingressgateway
non avrà un'etichetta di revisione.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
Esegui l'upgrade
Se hai eseguito l'upgrade da una versione precedente di Anthos Service Mesh, assicurati che
OLD_REVISION
corrisponda all'etichetta di revisione della versione precedente diistiod
nel comando seguente.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
Rimuovi la versione precedente della configurazione di
IstioOperator
.kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
L'output previsto è simile al seguente:
istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted
Esegui il rollback
Se hai riscontrato un problema durante il test dell'applicazione con la nuova versione di
istiod
, segui questi passaggi per ripristinare la versione precedente:Torna alla versione precedente di
istio-ingressgateway
. Nel comando seguente, sostituisciOLD_REVISION
con la revisione precedente.kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "OLD_REVISION"}]'
Rietichetta lo spazio dei nomi per abilitare l'inserimento automatico con la versione precedente di
istiod
. Il comando da utilizzare varia a seconda che tu abbia utilizzato un'etichetta di revisione oistio-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
Conferma che l'etichetta della revisione nello spazio dei nomi corrisponda all'etichetta della revisione della versione precedente di
istiod
:kubectl get ns NAMESPACE --show-labels
Riavvia i pod per attivare la reiniezione in modo che i proxy abbiano la versione precedente:
kubectl rollout restart deployment -n NAMESPACE
Rimuovi il nuovo deployment
istio-ingressgateway
. Assicurati che il valore diREVISION
nel seguente comando sia corretto.kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION -n istio-system --ignore-not-found=true
Rimuovi la nuova versione di
istiod
. Assicurati che il valore diREVISION
nel seguente comando sia corretto.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true
Rimuovi la nuova versione della configurazione
IstioOperator
.kubectl delete IstioOperator installed-state-REVISION -n istio-system
L'output previsto è simile al seguente:
istiooperator.install.istio.io "installed-state-REVISION" deleted
Se non hai incluso il flag
--disable_canonical_service
, lo script abilitava il controller del servizio canonico. Ti consigliamo di lasciarlo abilitato, ma se devi disabilitarlo, consulta Attivazione e disattivazione del controller del servizio canonico.
Passaggi successivi
- Esegui il deployment dell'applicazione di esempio di Boutique Online
- Configurazione di un mesh multi-cluster