Esegui l'upgrade di Anthos Service Mesh su GKE in un mesh multiprogetto

Questa guida spiega come eseguire l'upgrade da 1.9 or a 1.10 patch release ad Anthos Service Mesh 1.11.8 su un cluster Google Kubernetes Engine (GKE) per una mesh contenente più cluster in diversi progetti Google Cloud.

Prima di iniziare

Prima di installare Anthos Service Mesh, assicurati di avere:

Preparazione per l'upgrade

Se hai personalizzato l'installazione precedente, avrai bisogno delle stesse personalizzazioni quando esegui l'upgrade a una nuova versione di Anthos Service Mesh o esegui la migrazione da Istio. Se hai personalizzato l'installazione aggiungendo il flag --set values a istioctl install, devi aggiungere queste impostazioni a un file YAML IstioOperator, chiamato file di overlay. Puoi specificare il file dell'overlay utilizzando l'opzione --custom_overlay con il nome del file quando esegui lo script. Lo script passa il file dell'overlay a istioctl install.

Lo script segue il processo di upgrade di revisione (indicato come upgrade "canary" nella documentazione di Istio). Con un upgrade basato su revisioni, lo script installa una nuova revisione del piano di controllo insieme a quello esistente. Durante l'installazione della nuova versione, lo script include un'etichetta revision che identifica il nuovo piano di controllo.

Successivamente, potrai eseguire la migrazione alla nuova versione impostando la stessa etichetta revision sui carichi di lavoro ed eseguendo un riavvio in sequenza per inserire nuovamente i proxy in modo che utilizzino 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 versione. Questo approccio è molto più sicuro rispetto all'upgrade in loco in cui i nuovi componenti del piano di controllo sostituiscono la versione precedente.

Configurazione delle variabili di ambiente

  1. Recupera l'ID per il progetto in cui è stato creato il cluster e il numero per il progetto host Environ.

    gcloud

    Esegui questo comando:

    gcloud projects list

    Console

    1. Vai alla pagina Dashboard nella console Google Cloud.

      Vai alla pagina Dashboard

    2. Fai clic sull'elenco a discesa Seleziona da nella parte superiore della pagina. Nella finestra Seleziona da visualizzata, scegli il tuo progetto.

      L'ID progetto viene visualizzato nella scheda Informazioni sul progetto della dashboard del progetto.

  2. Crea una variabile di ambiente per l'ID del progetto in cui è stato creato il cluster: 

    export PROJECT_ID=YOUR_PROJECT_ID

  3. Crea una variabile di ambiente per il numero di progetto del progetto host environ.

    export ENVIRON_PROJECT_NUMBER=YOUR_ENVIRON_PROJECT_NUMBER

  4. Crea le seguenti variabili di ambiente:

    • Imposta il nome del cluster: 

      export CLUSTER_NAME=YOUR_CLUSTER_NAME

    • Imposta CLUSTER_LOCATION sulla zona o sulla regione del cluster: 

      export CLUSTER_LOCATION=YOUR_ZONE_OR_REGION

  5. Imposta la zona o la regione predefinita per Google Cloud CLI. Se non imposti il valore predefinito qui, assicurati di specificare l'opzione --zone o --region nei comandi gcloud container clusters in questa pagina.

    • Se hai un cluster a zona singola, imposta la zona predefinita:

      gcloud config set compute/zone ${CLUSTER_LOCATION}

    • Se hai un cluster a livello di regione, imposta la regione predefinita:

      gcloud config set compute/region ${CLUSTER_LOCATION}

    Suggerimento: per semplificare la configurazione dell'ambiente shell in futuro, puoi copiare e incollare le istruzioni export per ogni variabile di ambiente in un semplice script shell che source quando avvii una nuova shell. Puoi anche aggiungere i comandi gcloud che impostano i valori predefiniti allo script. In alternativa, puoi utilizzare gcloud init per creare e attivare una configurazione gcloud denominata.

Impostazione di credenziali e autorizzazioni

  1. 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}

  2. 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

  1. 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

  2. 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.

  3. 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 directory bin.
    • I profili di configurazione di Anthos Service Mesh si trovano nella directory manifests/profiles.

  4. Assicurati di essere nella directory principale dell'installazione di Anthos Service Mesh.

    cd istio-1.11.8-asm.4

Mac OS

  1. 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

  2. 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.

  3. 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 directory bin.
    • I profili di configurazione di Anthos Service Mesh si trovano nella directory manifests/profiles.

  4. Assicurati di essere nella directory principale dell'installazione di Anthos Service Mesh.

    cd istio-1.11.8-asm.4

Windows

  1. 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

  2. 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.

  3. 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 directory bin.
    • I profili di configurazione di Anthos Service Mesh si trovano nella directory manifests/profiles.

  4. 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

  1. 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.

  2. Passa alla directory in cui vuoi scaricare il pacchetto Anthos Service Mesh.

  3. 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.

  4. Scarica il pacchetto:

    kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.11 asm

  5. Imposta l'ID per il progetto in cui è stato creato il cluster:

    kpt cfg set asm gcloud.core.project ${PROJECT_ID}

  6. Imposta il numero di progetto per il progetto host del parco risorse:

    kpt cfg set asm gcloud.project.environProjectNumber ${FLEET_PROJECT_NUMBER}

  7. Imposta il nome del cluster:

    kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}

  8. Imposta la zona o la regione predefinita:

    kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}

  9. Imposta il tag sulla versione di Anthos Service Mesh che stai installando:

    kpt cfg set asm anthos.servicemesh.tag 1.11.8-asm.4

  10. 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.

  11. 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.

    1. Recupera l'ID progetto di tutti i cluster che saranno nel mesh multi-cluster/più progetti.

    2. 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 e PROJECT_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.

  12. 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

  1. 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.

  2. Passa alla directory in cui vuoi scaricare il pacchetto Anthos Service Mesh.

  3. 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)"

  4. Scarica il pacchetto:

    kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.11 asm

  5. Imposta l'ID per il progetto in cui è stato creato il cluster:

    kpt cfg set asm gcloud.core.project ${PROJECT_ID}

  6. Imposta il numero di progetto per il progetto host del parco risorse:

    kpt cfg set asm gcloud.project.environProjectNumber ${FLEET_PROJECT_NUMBER}

  7. Imposta il nome del cluster:

    kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}

  8. Imposta la zona o la regione predefinita:

    kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}

  9. Imposta il tag sulla versione di Anthos Service Mesh che stai installando:

    kpt cfg set asm anthos.servicemesh.tag 1.11.8-asm.4

  10. Imposta la revisione nei file di configurazione delle risorse del pacchetto Anthos Service Mesh:

    kpt cfg set asm anthos.servicemesh.rev asm-1118-4

  11. 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.

Upgrade di Anthos Service Mesh

Mesh CA

  1. 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 setter kpt devono corrispondere. Se necessario, esegui il comando gcloud container clusters get-credentials per impostare il contesto attuale di kubeconfig.

  2. Se necessario, passa alla directory istio-1.11.8-asm.4. Il client istioctl dipende dalla versione. Assicurati di utilizzare la versione presente nella directory istio-1.11.8-asm.4/bin.

  3. 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 a istiod un'etichetta di revisione nel formato istio.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 revisione istiod. Per abilitare l'inserimento automatico collaterale per uno spazio dei nomi, devi etichettarlo con una revisione che corrisponda a un deployment istiod.

    I seguenti file eseguono l'override delle impostazioni nel file istio-operator.yaml:

    • Il file multiproject.yaml imposta il profilo asm-gcp-multiproject.

    • Il file multicluster.yaml configura le impostazioni necessarie ad Anthos Service Mesh per una configurazione multi-cluster.

  4. 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
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.

  5. 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

  1. 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 setter kpt devono corrispondere. Se necessario, esegui il comando gcloud container clusters get-credentials per impostare il contesto attuale di kubeconfig.

  2. Se necessario, passa alla directory istio-1.11.8-asm.4. Il client istioctl dipende dalla versione. Assicurati di utilizzare la versione presente nella directory istio-1.11.8-asm.4/bin.

  3. 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 a istiod un'etichetta di revisione nel formato istio.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 revisione istiod. Per abilitare l'inserimento automatico collaterale per uno spazio dei nomi, devi etichettarlo con una revisione che corrisponda a un deployment istiod.

    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 profilo asm-gcp-multiproject.

    • Il file multicluster.yaml configura le impostazioni necessarie ad Anthos Service Mesh per una configurazione multi-cluster.

  4. 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
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.

  5. 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.

  1. Recupera l'etichetta di revisione che si trova su istiod e istio-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

    1. 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.

    2. Nota anche il valore nell'etichetta di revisione per la vecchia versione di istiod. Questa operazione ti consente di eliminare la versione precedente di istiod 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.

  2. Aggiungi l'etichetta di revisione a uno spazio dei nomi e rimuovi l'etichetta istio-injection (se esistente). Nel comando seguente, imposta REVISION sul valore che corrisponde alla nuova revisione di istiod.

    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'etichetta istio-injection. Poiché l'inserimento automatica non riesce se uno spazio dei nomi contiene sia l'etichetta istio-injection sia l'etichetta di revisione, tutti i comandi kubectl label nella documentazione di Anthos Service Mesh comprendono la rimozione dell'etichetta istio-injection.

  3. Riavvia i pod per attivare la reinserimento.

    kubectl rollout restart deployment -n NAMESPACE

  4. Testa l'applicazione per verificare che i carichi di lavoro funzionino correttamente.

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

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

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

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

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

    3. Elimina il vecchio istio-ingressgatewaydeployment. 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 di istio-ingressgateway.

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true

    4. Elimina la versione precedente di istiod. 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 di istiod nel comando seguente.

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

    5. 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:

    1. Torna alla versione precedente di istio-ingressgateway. Nel comando seguente, sostituisci OLD_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"}]'

    2. 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 o istio-injection=enabled con la versione precedente.

      • Se hai utilizzato un'etichetta di revisione per l'inserimento automatico:

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

      • Se utilizzavi istio-injection=enabled:

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

      Output previsto:

      namespace/NAMESPACE labeled

    3. Conferma che l'etichetta della revisione nello spazio dei nomi corrisponda all'etichetta della revisione della versione precedente di istiod:

      kubectl get ns NAMESPACE --show-labels

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

      kubectl rollout restart deployment -n NAMESPACE

    5. Rimuovi il nuovo deployment istio-ingressgateway. Assicurati che il valore di REVISION nel seguente comando sia corretto.

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION -n istio-system --ignore-not-found=true

    6. Rimuovi la nuova versione di istiod. Assicurati che il valore di REVISION nel seguente comando sia corretto.

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

    7. 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

    8. 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