Upgrade di Anthos Service Mesh

In questa pagina viene spiegato come:

• Esegui asmcli per eseguire l'upgrade da Anthos Service Mesh ad Anthos Service Mesh 1.11.8.

• Facoltativamente, esegui il deployment di un gateway in entrata.

• Esegui un upgrade canary per eseguire la migrazione dei carichi di lavoro al nuovo piano di controllo.

La versione di Anthos Service Mesh da cui puoi eseguire l'upgrade varia in base alla piattaforma.

GKE

Puoi eseguire l'upgrade direttamente ad Anthos Service Mesh 1.11.8-asm.4 su Google Kubernetes Engine dalle seguenti versioni:

1,9 e 1,10

On-premise

Puoi eseguire l'upgrade direttamente ad Anthos Service Mesh 1.11.8-asm.4 su GKE su VMware e Google Distributed Cloud Virtual for Bare Metal dalle seguenti versioni:

1,1

GKE su AWS

Puoi eseguire l'upgrade direttamente ad Anthos Service Mesh 1.11.8-asm.4 su GKE su AWS dalle seguenti versioni:

1,1

Amazon EKS

Se hai installato Anthos Service Mesh 1.7 su EKS, dovrai installare Anthos Service Mesh 1.11 su un nuovo cluster. Gli upgrade da Anthos Service Mesh 1.7 ad Anthos Service Mesh 1.11 non sono supportati.

Nota: l'aggiunta di macchine virtuali Compute Engine al mesh di servizi richiede opzioni specifiche quando esegui l'upgrade di Anthos Service Mesh. Per la procedura dettagliata, consulta Aggiungere macchine virtuali Compute Engine ad Anthos Service Mesh.

Prima di iniziare

Prima di iniziare, assicurati di:

• Esamina i prerequisiti.
• Consulta le informazioni riportate in Pianificare l'upgrade.
• Installare gli strumenti richiesti
• Scarica asmcli
• Concedi le autorizzazioni di amministratore del cluster
• Convalida progetto e cluster

Personalizzazioni del piano di controllo

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.

Attenzione: l'omissione del file overlay determina l'installazione corretta. Tuttavia, il mesh di servizi ha una configurazione diversa da quella prevista perché i valori omessi vengono reimpostati sui valori predefiniti quando viene eseguito nuovamente il deployment del piano di controllo e del gateway in entrata.

Autorità di certificazione

La modifica dell'autorità di certificazione (CA) durante un upgrade causa tempi di inattività. Durante l'upgrade, il traffico mTLS viene interrotto fino a quando tutti i carichi di lavoro non vengono passati al nuovo piano di controllo con la nuova CA.

Upgrade di Anthos Service Mesh

Di seguito viene descritto come eseguire l'upgrade di Anthos Service Mesh:

1. Se stai eseguendo l'upgrade di un mesh multi-cluster su GKE che utilizza l'autorità di certificazione Anthos Service Mesh (Mesh CA), esegui asmcli create-mesh per configurare la rete mesh multi-cluster in modo da considerare attendibili l'identità dei carichi di lavoro del parco risorse per evitare il bilanciamento del carico tra cluster durante l'upgrade.

2. Esegui asmcli install per installare Anthos Service Mesh su un singolo cluster. Consulta le seguenti sezioni per gli esempi di riga di comando. Gli esempi contengono sia argomenti obbligatori sia argomenti facoltativi che potrebbero esserti utili. Ti consigliamo di specificare sempre l'argomento output_dir in modo da poter individuare facilmente strumenti e gateway di esempio come istioctl. Consulta la barra di navigazione sulla destra per un elenco di esempi.

3. Facoltativamente, installa o esegui l'upgrade di un gateway in entrata. Per impostazione predefinita, asmcli non installa istio-ingressgateway. Ti consigliamo di eseguire il deployment e la gestione del piano di controllo e dei gateway separatamente. Se è necessario installare l'oggetto istio-ingressgateway predefinito con il piano di controllo nel cluster, includi l'argomento --option legacy-default-ingressgateway.

4. Per completare la configurazione di Anthos Service Mesh, devi abilitare l'inserimento automatico di file collaterali e eseguire il deployment o rieseguire il deployment dei carichi di lavoro.

Configura il mesh multi-cluster per considerare attendibile l'identità dei carichi di lavoro del parco risorse

Se esegui l'upgrade di un mesh multi-cluster su GKE che utilizza Mesh CA come autorità di certificazione, devi eseguire asmcli create-mesh prima di eseguire l'upgrade di ogni cluster. Questo comando configura la CA mesh in modo che utilizzi il pool di identità per i carichi di lavoro del parco risorse, FLEET_PROJECT_ID.svc.id.goog, come dominio di attendibilità dopo l'upgrade. Il comando asmcli create-mesh:

• Registra tutti i cluster nello stesso parco risorse.
• Configura il mesh in modo che consideri attendibile l'identità dei carichi di lavoro del parco risorse.
• Crea secret remoti.

Puoi specificare l'URI di ciascun cluster o il percorso del file kubeconfig.

URI cluster

Nel comando seguente, sostituisci FLEET_PROJECT_ID con l'ID progetto del progetto host del parco risorse e l'URI del cluster con il nome, la zona o la regione e l'ID progetto del cluster per ciascun cluster.

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    PROJECT_ID_1/CLUSTER_LOCATION_1/CLUSTER_NAME_1 \
    PROJECT_ID_2/CLUSTER_LOCATION_2/CLUSTER_NAME_2 # \
    # Add a line for each cluster in the mesh

file kubeconfig

Nel comando seguente, sostituisci FLEET_PROJECT_ID con l'ID progetto del progetto host del parco risorse e PATH_TO_KUBECONFIG con il percorso di ogni file kubeconfig.

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    PATH_TO_KUBECONFIG_1 \
    PATH_TO_KUBECONFIG_2 # \
    # Add a line for each cluster in the mesh

Esegui l'upgrade con funzionalità predefinite e Mesh CA

Questa sezione mostra come eseguire asmcli per eseguire l'upgrade di Anthos Service Mesh con le funzionalità supportate predefinite per la tua piattaforma e come abilitare l'autorità di certificazione Anthos Service Mesh (Mesh CA) come autorità di certificazione.

Nota sulla piattaforma: Mesh CA non è supportato in GKE su AWS o Amazon EKS. Se esegui asmcli install e specifichi --ca mesh_ca su queste piattaforme, l'installazione non va a buon fine.

GKE

Esegui questo comando per eseguire l'upgrade del piano di controllo con funzionalità predefinite e Mesh CA. Inserisci i valori nei segnaposto forniti.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca

• --project_id, --cluster_name e --cluster_location Specifica l'ID progetto in cui si trova il cluster, il nome del cluster e la zona o la regione del cluster.
• --fleet_id L'ID progetto del progetto host del parco risorse. Se non includi questa opzione, asmcli utilizza il progetto in cui è stato creato il cluster durante la registrazione del cluster.
• --output_dir Includi questa opzione per specificare una directory in cui asmcli scarica il pacchetto anthos-service-mesh ed estrae il file di installazione, che contiene istioctl, esempi e file manifest. In caso contrario, asmcli scarica i file in una directory tmp. Puoi specificare un percorso relativo o un percorso completo. La variabile di ambiente $PWD non funziona in questo caso.
  Nota: prendi nota di questa directory --output_dir. Dovrai farvi riferimento durante il deployment dei gateway.
• --enable_all Consente allo script di:
  • Concedi le autorizzazioni IAM richieste.
  • Abilita le API di Google richieste.
  • Imposta un'etichetta sul cluster che identifica il mesh.
  • Registra il cluster nel parco risorse, se non è già registrato.
• --ca mesh_ca Utilizza Mesh CA come autorità di certificazione. La modifica delle autorità di certificazione durante un upgrade causa tempi di inattività. asmcliConfigura la CA mesh per l'utilizzo dell'identità del carico di lavoro del parco risorse

On-premise

Esegui i comandi seguenti su GKE su VMware o Google Distributed Cloud Virtual for Bare Metal per eseguire l'upgrade del piano di controllo con funzionalità predefinite e Mesh CA. Inserisci i valori nei segnaposto forniti.

1. Imposta il contesto attuale per il tuo cluster utente:

   kubectl config use-context CLUSTER_NAME
   

2. Esegui asmcli install:

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca mesh_ca
   

   • --fleet_id L'ID progetto del progetto host del parco risorse.
   • --kubeconfig Il percorso completo del file kubeconfig. La variabile di ambiente $PWD non funziona in questo caso. Inoltre, le posizioni relative dei file kubeconfig che utilizzano il carattere "~" non funzioneranno.
   • --output_dir Includi questa opzione per specificare una directory in cui asmcli scarica il pacchetto anthos-service-mesh ed estrae il file di installazione, che contiene istioctl, esempi e file manifest. In caso contrario, asmcli scarica i file in una directory tmp. Puoi specificare un percorso relativo o un percorso completo. La variabile di ambiente $PWD non funziona in questo caso.
   • --platform multicloud Specifica che la piattaforma è diversa da Google Cloud, ad esempio on-premise o multi-cloud.
   • --enable_all Consente allo script di:
     • Concedi le autorizzazioni IAM richieste.
     • Abilita le API di Google richieste.
     • Imposta un'etichetta sul cluster che identifica il mesh.
     • Registra il cluster nel parco risorse, se non è già registrato.
   • --ca mesh_ca Utilizza Mesh CA come autorità di certificazione. La modifica delle autorità di certificazione durante un upgrade causa tempi di inattività. asmcliconfigura Mesh CA per utilizzare l'identità del carico di lavoro del parco risorse

Esegui l'upgrade delle funzionalità predefinite con Istio CA

Questa sezione mostra come eseguire asmcli per eseguire l'upgrade di Anthos Service Mesh con le funzionalità supportate predefinite per la tua piattaforma e abilitare la CA Istio.

GKE

Esegui questo comando per eseguire l'upgrade del piano di controllo con le funzionalità predefinite e la CA Istio. Inserisci i valori nei segnaposto forniti.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca citadel

• --project_id, --cluster_name e --cluster_location Specifica l'ID progetto in cui si trova il cluster, il nome del cluster e la zona o la regione del cluster.
• --fleet_id L'ID progetto del progetto host del parco risorse. Se non includi questa opzione, asmcli utilizza il progetto in cui è stato creato il cluster durante la registrazione del cluster.
• --output_dir Includi questa opzione per specificare una directory in cui asmcli scarica il pacchetto anthos-service-mesh ed estrae il file di installazione, che contiene istioctl, esempi e file manifest. In caso contrario, asmcli scarica i file in una directory tmp. Puoi specificare un percorso relativo o un percorso completo. La variabile di ambiente $PWD non funziona in questo caso.
  Nota: prendi nota di questa directory --output_dir. Dovrai farvi riferimento durante il deployment dei gateway.
• --enable_all Consente allo script di:
  • Concedi le autorizzazioni IAM richieste.
  • Abilita le API di Google richieste.
  • Imposta un'etichetta sul cluster che identifica il mesh.
  • Registra il cluster nel parco risorse, se non è già registrato.
• -ca citadel Usa la CA Istio. La modifica delle autorità di certificazione durante un upgrade causa tempi di inattività.

On-premise

Esegui i comandi seguenti su GKE su VMware o Google Distributed Cloud Virtual for Bare Metal per eseguire l'upgrade del piano di controllo con le funzionalità predefinite e la CA Istio. Inserisci i valori nei segnaposto forniti.

1. Imposta il contesto attuale per il tuo cluster utente:

   kubectl config use-context CLUSTER_NAME
   

2. Esegui asmcli install:

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
   

   • --fleet_id L'ID progetto del progetto host del parco risorse.
   • --kubeconfig Il percorso completo del file kubeconfig. La variabile di ambiente $PWD non funziona in questo caso. Inoltre, le posizioni relative dei file kubeconfig che utilizzano il carattere "~" non funzioneranno.
   • --output_dir Includi questa opzione per specificare una directory in cui asmcli scarica il pacchetto anthos-service-mesh ed estrae il file di installazione, che contiene istioctl, esempi e file manifest. In caso contrario, asmcli scarica i file in una directory tmp. Puoi specificare un percorso relativo o un percorso completo. La variabile di ambiente $PWD non funziona in questo caso.
   • --platform multicloud Specifica che la piattaforma è diversa da Google Cloud, ad esempio on-premise o multi-cloud.
   • --enable_all Consente allo script di:
     • Concedi le autorizzazioni IAM richieste.
     • Abilita le API di Google richieste.
     • Imposta un'etichetta sul cluster che identifica il mesh.
     • Registra il cluster nel parco risorse, se non è già registrato.
   • -ca citadel Utilizza la CA Istio come autorità di certificazione.
   • --ca_cert Il certificato intermedio
   • --ca_key La chiave per il certificato intermedio
   • --root_cert Il certificato radice
   • --cert_chain La catena di certificati

AWS

Esegui i comandi seguenti su GKE su AWS per eseguire l'upgrade del piano di controllo con funzionalità predefinite e CA Istio. Inserisci i valori nei segnaposto forniti. Puoi scegliere di abilitare Ingress per la subnet pubblica o privata.

Pubblico

1. Imposta il contesto attuale per il tuo cluster utente:

   kubectl config use-context CLUSTER_NAME
   

2. Esegui asmcli install:

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
   

   • --fleet_id L'ID progetto del progetto host del parco risorse.
   • --kubeconfig Il percorso completo del file kubeconfig. La variabile di ambiente $PWD non funziona in questo caso. Inoltre, le posizioni relative dei file kubeconfig che utilizzano il carattere "~" non funzioneranno.
   • --output_dir Includi questa opzione per specificare una directory in cui asmcli scarica il pacchetto anthos-service-mesh ed estrae il file di installazione, che contiene istioctl, esempi e file manifest. In caso contrario, asmcli scarica i file in una directory tmp. Puoi specificare un percorso relativo o un percorso completo. La variabile di ambiente $PWD non funziona in questo caso.
   • --platform multicloud Specifica che la piattaforma è diversa da Google Cloud, ad esempio on-premise o multi-cloud.
   • --enable_all Consente allo script di:
     • Concedi le autorizzazioni IAM richieste.
     • Abilita le API di Google richieste.
     • Imposta un'etichetta sul cluster che identifica il mesh.
     • Registra il cluster nel parco risorse, se non è già registrato.
   • -ca citadel Utilizza la CA Istio come autorità di certificazione.
   • --ca_cert Il certificato intermedio
   • --ca_key La chiave per il certificato intermedio
   • --root_cert Il certificato radice
   • --cert_chain La catena di certificati

Privato

1. Imposta il contesto attuale per il tuo cluster utente:

   kubectl config use-context CLUSTER_NAME
   

2. Salva il seguente file YAML in un file denominato istio-operator-internal-lb.yaml:

   apiVersion: install.istio.io/v1alpha1
   kind: IstioOperator
   spec:
     components:
       ingressGateways:
       - enabled: true
         k8s:
           serviceAnnotations:
             service.beta.kubernetes.io/aws-load-balancer-internal: "true"
         name: istio-ingressgateway
   

3. Esegui asmcli install:

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
     --custom_overlay istio-operator-internal-lb.yaml
   

   • --fleet_id L'ID progetto del progetto host del parco risorse.
   • --kubeconfig Il percorso completo del file kubeconfig. La variabile di ambiente $PWD non funziona in questo caso. Inoltre, le posizioni relative dei file kubeconfig che utilizzano il carattere "~" non funzioneranno.
   • --output_dir Includi questa opzione per specificare una directory in cui asmcli scarica il pacchetto anthos-service-mesh ed estrae il file di installazione, che contiene istioctl, esempi e file manifest. In caso contrario, asmcli scarica i file in una directory tmp. Puoi specificare un percorso relativo o un percorso completo. La variabile di ambiente $PWD non funziona in questo caso.
   • --platform multicloud Specifica che la piattaforma è diversa da Google Cloud, ad esempio on-premise o multi-cloud.
   • --enable_all Consente allo script di:
     • Concedi le autorizzazioni IAM richieste.
     • Abilita le API di Google richieste.
     • Imposta un'etichetta sul cluster che identifica il mesh.
     • Registra il cluster nel parco risorse, se non è già registrato.
   • -ca citadel Utilizza la CA Istio come autorità di certificazione.
   • --ca_cert Il certificato intermedio
   • --ca_key La chiave per il certificato intermedio
   • --root_cert Il certificato radice
   • --cert_chain La catena di certificati

Amazon EKS

Esegui i comandi seguenti su Amazon EKS per eseguire l'upgrade del piano di controllo con funzionalità predefinite e CA Istio. Inserisci i valori nei segnaposto forniti.

Nota sulla piattaforma: se hai installato Anthos Service Mesh 1.7 su EKS, dovrai installare Anthos Service Mesh 1.11 su un nuovo cluster. Gli upgrade da Anthos Service Mesh 1.7 ad Anthos Service Mesh 1.11 non sono supportati.

1. Imposta il contesto attuale per il tuo cluster utente:

   kubectl config use-context CLUSTER_NAME
   

2. Esegui asmcli install:

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
   

   • --fleet_id L'ID progetto del progetto host del parco risorse.
   • --kubeconfig Il percorso completo del file kubeconfig. La variabile di ambiente $PWD non funziona in questo caso. Inoltre, le posizioni relative dei file kubeconfig che utilizzano il carattere "~" non funzioneranno.
   • --output_dir Includi questa opzione per specificare una directory in cui asmcli scarica il pacchetto anthos-service-mesh ed estrae il file di installazione, che contiene istioctl, esempi e file manifest. In caso contrario, asmcli scarica i file in una directory tmp. Puoi specificare un percorso relativo o un percorso completo. La variabile di ambiente $PWD non funziona in questo caso.
   • --platform multicloud Specifica che la piattaforma è diversa da Google Cloud, ad esempio on-premise o multi-cloud.
   • --enable_all Consente allo script di:
     • Concedi le autorizzazioni IAM richieste.
     • Abilita le API di Google richieste.
     • Imposta un'etichetta sul cluster che identifica il mesh.
     • Registra il cluster nel parco risorse, se non è già registrato.
   • -ca citadel Utilizza la CA Istio come autorità di certificazione.
   • --ca_cert Il certificato intermedio
   • --ca_key La chiave per il certificato intermedio
   • --root_cert Il certificato radice
   • --cert_chain La catena di certificati

Esegui l'upgrade con funzionalità facoltative

Un file overlay è un file YAML contenente una risorsa IstioOperator personalizzata (CR) che passi a asmcli per configurare il piano di controllo. Puoi eseguire l'override della configurazione predefinita del piano di controllo e abilitare una funzionalità facoltativa passando il file YAML a asmcli. Puoi aggiungere più overlay: ogni file di overlay sostituisce la configurazione dei livelli precedenti.

GKE

Esegui questo comando per installare il piano di controllo con una funzionalità facoltativa. Per aggiungere più file, specifica --custom_overlay e il nome del file, ad esempio: --custom_overlayoverlay_file1.yaml --custom_overlay overlay_file2.yaml --custom_overlay overlay_file3.yaml Inserisci i tuoi valori nei segnaposto forniti.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca \
  --custom_overlay OVERLAY_FILE

• --project_id, --cluster_name e --cluster_location Specifica l'ID progetto in cui si trova il cluster, il nome del cluster e la zona o la regione del cluster.
• --fleet_id L'ID progetto del progetto host del parco risorse. Se non includi questa opzione, asmcli utilizza il progetto in cui è stato creato il cluster durante la registrazione del cluster.
• --output_dir Includi questa opzione per specificare una directory in cui asmcli scarica il pacchetto anthos-service-mesh ed estrae il file di installazione, che contiene istioctl, esempi e file manifest. In caso contrario, asmcli scarica i file in una directory tmp. Puoi specificare un percorso relativo o un percorso completo. La variabile di ambiente $PWD non funziona in questo caso.
  Nota: prendi nota di questa directory --output_dir. Dovrai farvi riferimento durante il deployment dei gateway.
• --enable_all Consente allo script di:
  • Concedi le autorizzazioni IAM richieste.
  • Abilita le API di Google richieste.
  • Imposta un'etichetta sul cluster che identifica il mesh.
  • Registra il cluster nel parco risorse, se non è già registrato.
• --ca mesh_ca Utilizza Mesh CA come autorità di certificazione. La modifica delle autorità di certificazione durante un upgrade causa tempi di inattività. asmcliConfigura la CA mesh per l'utilizzo dell'identità del carico di lavoro del parco risorse
• --custom_overlay Specifica il nome del file dell'overlay.

Al di fuori di Google Cloud

Esegui i comandi seguenti su GKE su VMware, Google Distributed Cloud Virtual for Bare Metal, GKE on AWS o Amazon EKS. Inserisci i tuoi valori nei segnaposto forniti.

Nota sulla piattaforma: se hai installato Anthos Service Mesh 1.7 su EKS, dovrai installare Anthos Service Mesh 1.11 su un nuovo cluster. Gli upgrade da Anthos Service Mesh 1.7 ad Anthos Service Mesh 1.11 non sono supportati.

1. Imposta il contesto attuale per il tuo cluster utente:

   kubectl config use-context CLUSTER_NAME
   

2. Esegui asmcli install:

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca mesh_ca \
     --custom_overlay OVERLAY_FILE
   

   • --fleet_id L'ID progetto del progetto host del parco risorse.
   • --kubeconfig Il percorso completo del file kubeconfig. La variabile di ambiente $PWD non funziona in questo caso. Inoltre, le posizioni relative dei file kubeconfig che utilizzano il carattere "~" non funzioneranno.
   • --output_dir Includi questa opzione per specificare una directory in cui asmcli scarica il pacchetto anthos-service-mesh ed estrae il file di installazione, che contiene istioctl, esempi e file manifest. In caso contrario, asmcli scarica i file in una directory tmp. Puoi specificare un percorso relativo o un percorso completo. La variabile di ambiente $PWD non funziona in questo caso.
   • --platform multicloud Specifica che la piattaforma è diversa da Google Cloud, ad esempio on-premise o multi-cloud.
   • --enable_all Consente allo script di:
     • Concedi le autorizzazioni IAM richieste.
     • Abilita le API di Google richieste.
     • Imposta un'etichetta sul cluster che identifica il mesh.
     • Registra il cluster nel parco risorse, se non è già registrato.
   • --ca mesh_ca Utilizza Mesh CA come autorità di certificazione. La modifica delle autorità di certificazione durante un upgrade causa tempi di inattività. asmcliConfigura la CA mesh per l'utilizzo dell'identità del carico di lavoro del parco risorse
   • --custom_overlay Specifica il nome del file dell'overlay.

Esegui l'upgrade dei gateway

Se hai eseguito il deployment dei gateway, dovrai eseguire l'upgrade anche di questi. Per un upgrade semplice, segui la sezione Upgrade in loco nella guida Installare ed eseguire l'upgrade dei gateway.

Avviso: se hai installato Anthos Service Mesh con un metodo diverso da asmcli, il gateway in entrata predefinito installato verrà rimosso a meno che non passi l'argomento --option legacy-default-ingressgateway.

Passa al nuovo piano di controllo

1. Recupera l'etichetta di revisione che si trova il giorno istiod.

   kubectl get pod -n istio-system -L istio.io/rev
   

   L'output del comando è simile al seguente.

   NAME                                             READY   STATUS    RESTARTS   AGE   REV
   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 allo spazio dei nomi di un'applicazione 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 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
      

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

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

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

      kubectl rollout restart deployment -n NAMESPACE
      

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

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

   6. Se non hai incluso il flag --disable_canonical_service, asmcli ha abilitato il controller del servizio canonico. Ti consigliamo di lasciarlo abilitato, ma se devi disabilitarlo, consulta Attivazione e disattivazione del controller del servizio canonico.

   7. Se hai eseguito il deployment di gateway, assicurati di modificare l'etichetta di revisione nello spazio dei nomi o nel deployment in modo che corrisponda alla versione precedente di istiod. Segui la stessa procedura descritta nella sezione Upgrages in loco nella guida Installare ed eseguire l'upgrade dei gateway.

Deployment e nuovo deployment dei carichi di lavoro

L'installazione (o l'upgrade) non sarà completata finché non abiliti l'inserimento automatico del proxy sidecar (inserimento automatica). Le migrazioni da Istio OSS e dagli upgrade seguono il processo di upgrade basato sulle 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 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.

Lo script imposta 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.