Questa pagina è stata tradotta dall'API Cloud Translation.

Upgrade di Anthos Service Mesh

Questa pagina spiega come:

Esegui asmcli per eseguire l'upgrade da Anthos Service Mesh ad Anthos Service Mesh 1.16.2.
Facoltativamente, esegui il deployment di un gateway in entrata.
Esegui un upgrade canary per eseguire la migrazione dei carichi di lavoro nel 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.16.2-asm.2 su Google Kubernetes Engine dalle seguenti versioni:

1.14+

On-premise

Puoi eseguire l'upgrade direttamente ad Anthos Service Mesh 1.16.2-asm.2 su Cluster Anthos su VMware e Anthos su Bare Metal dalle seguenti versioni:

1.14+

Anthos clusters on AWS

Puoi eseguire l'upgrade direttamente ad Anthos Service Mesh 1.16.2-asm.2 in Cluster Anthos su AWS dalle seguenti versioni:

1.14+

Anthos clusters on Azure

I cluster Anthos su Azure supportano solo Anthos Service Mesh 1.16. Gli upgrade delle versioni precedenti di Anthos Service Mesh non sono supportati.

Amazon EKS

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

Microsoft AKS

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

Prima di iniziare

Prima di iniziare, assicurati di:

Esamina i prerequisiti.
Consulta le informazioni in Pianifica l'upgrade.
Installa gli strumenti richiesti.
Scarica asmcli.
Concedi le autorizzazioni di amministratore del cluster.
Convalidare progetto e cluster.

Personalizzazioni del piano di controllo

Se hai personalizzato l'installazione precedente, hai 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 le impostazioni a un file YAML IstioOperator, indicato come file overlay. Puoi specificare il file overlay utilizzando l'opzione --custom_overlay con il nome del file quando esegui lo script. Lo script trasmette il file di overlay a istioctl install.

Autorità di certificazione

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

Upgrade di Anthos Service Mesh

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

Se stai eseguendo l'upgrade di un mesh multi-cluster su GKE che utilizza Anthos Service Mesh Certificate (Mesh CA), esegui asmcli create-mesh per configurare il mesh multi-cluster in modo che ritenga attendibile l'identità del carico di lavoro del parco risorse per evitare il bilanciamento del carico tra i cluster durante il tempo di upgrade.
Esegui asmcli install per installare Anthos Service Mesh su un unico cluster. Consulta le seguenti sezioni per gli esempi di riga di comando. Gli esempi contengono sia gli argomenti obbligatori sia quelli facoltativi che potresti trovare utili. Ti consigliamo di specificare sempre l'argomento output_dir, in modo da poter individuare facilmente i gateway e gli strumenti di esempio come istioctl. Consulta la barra di navigazione a destra per un elenco di esempi.
(Facoltativo) 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 gestire separatamente il piano di controllo e i gateway. Se devi installare l'elemento istio-ingressgateway predefinito con il piano di controllo nel cluster, includi l'argomento --option legacy-default-ingressgateway.
Per completare la configurazione di Anthos Service Mesh, devi abilitare l'inserimento automatico delle sidecar ed eseguire il deployment o il nuovo deployment dei carichi di lavoro.

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

Se stai eseguendo 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 Mesh CA per l'utilizzo del pool Workload Identity 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 per considerare attendibile l'identità del carico di lavoro del parco risorse.
Crea secret da remoto.

Puoi specificare l'URI per 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 del progetto 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 abilitare l'autorità di certificazione Anthos Service Mesh (Mesh CA) come autorità di certificazione.

GKE

Esegui questo comando per eseguire l'upgrade del piano di controllo con le 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 del progetto host del parco risorse. Se non includi questa opzione, asmcli utilizza il progetto in cui è stato creato il cluster al momento della 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, gli esempi e i 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 qui.
Nota: prendi nota della directory --output_dir. Sarà necessario farvi riferimento al momento di eseguire 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 un tempo di inattività. asmcliconfigura mesh CA per l'utilizzo dell'identità del carico di lavoro del parco risorse

Altri cluster Anthos

Esegui questi comandi su altri cluster Anthos per eseguire l'upgrade del piano di controllo con funzionalità predefinite e Mesh CA. Inserisci i valori nei segnaposto forniti.

Imposta il contesto attuale per il tuo cluster utente:
```
kubectl config use-context CLUSTER_NAME
```
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 del progetto host del parco risorse.
- --kubeconfig Il percorso completo del file kubeconfig. La variabile di ambiente $PWD non funziona qui. Inoltre, i percorsi di kubeconfig relativi che utilizzano "~" 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, gli esempi e i 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 qui.
- --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 un tempo di inattività. asmcliconfigura la rete mesh per utilizzare l'identità del carico di lavoro del parco risorse

Eseguire l'upgrade delle funzionalità predefinite con il servizio 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 Service Authority Service.

GKE

Esegui questo comando per eseguire l'upgrade del piano di controllo con le funzionalità predefinite e con Certificate Authority Service. 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 gcp_cas \
  --ca_pool projects/PROJECT_NAME/locations/ca_region/caPools/CA_POOL

--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 del progetto host del parco risorse. Se non includi questa opzione, asmcli utilizza il progetto in cui è stato creato il cluster al momento della 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, gli esempi e i 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 qui.
Nota: prendi nota della directory --output_dir. Sarà necessario farvi riferimento al momento di eseguire 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 gcp_cas Utilizza Certificate Authority Service come autorità di certificazione. La modifica delle autorità di certificazione durante un upgrade causa un tempo di inattività. asmcliconfigura il Certificate Authority Service per l'utilizzo dell'identità del carico di lavoro del parco risorse
--ca_pool L'identificatore completo per Certificate Authority Service Pool CA.

On-premise

Esegui questi comandi sui cluster Anthos su VMware o Anthos su Bare Metal per eseguire l'upgrade del piano di controllo con funzionalità predefinite e Certificate Authority Service. Inserisci i valori nei segnaposto forniti.

Imposta il contesto attuale per il tuo cluster utente:
```
kubectl config use-context CLUSTER_NAME
```
Esegui asmcli install:
```
./asmcli install \
 --kubeconfig KUBECONFIG_FILE \
 --fleet_id FLEET_PROJECT_ID \
 --output_dir DIR_PATH \
 --enable_all \
 --ca gcp_cas \
 --platform multicloud \
 --ca_pool projects/PROJECT_NAME/locations/ca_region/caPools/CA_POOL
```
- --fleet_id: l'ID del progetto host del parco risorse.
- --kubeconfig Il percorso completo del file kubeconfig. La variabile di ambiente $PWD non funziona qui. Inoltre, i percorsi di kubeconfig relativi che utilizzano "~" 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, gli esempi e i 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 qui.
- --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 gcp_cas Utilizza Certificate Authority Service come autorità di certificazione. La modifica delle autorità di certificazione durante un upgrade causa un tempo di inattività. asmcliconfigura il Certificate Authority Service per l'utilizzo dell'identità del carico di lavoro del parco risorse
- --ca_pool L'identificatore completo del pool di CA di Certificate Authority Service.

Eseguire 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 Istio CA.

GKE

Esegui questo comando per eseguire l'upgrade del piano di controllo con le funzionalità predefinite e Istio 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 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 del progetto host del parco risorse. Se non includi questa opzione, asmcli utilizza il progetto in cui è stato creato il cluster al momento della 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, gli esempi e i 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 qui.
Nota: prendi nota della directory --output_dir. Sarà necessario farvi riferimento al momento di eseguire 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 Utilizza Istio CA. La modifica delle autorità di certificazione durante un upgrade causa un tempo di inattività.

On-premise

Esegui questi comandi sui cluster Anthos su VMware o Anthos su Bare Metal per eseguire l'upgrade del piano di controllo con funzionalità predefinite e Istio CA. Inserisci i valori nei segnaposto forniti.

Imposta il contesto attuale per il tuo cluster utente:
```
kubectl config use-context CLUSTER_NAME
```
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 del progetto host del parco risorse.
- --kubeconfig Il percorso completo del file kubeconfig. La variabile di ambiente $PWD non funziona qui. Inoltre, i percorsi di kubeconfig relativi che utilizzano "~" 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, gli esempi e i 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 qui.
- --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 Istio CA 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 questi comandi sui cluster Anthos su AWS per eseguire l'upgrade del piano di controllo con funzionalità predefinite e Istio CA. Inserisci i valori nei segnaposto forniti. Puoi scegliere di attivare Ingress per la subnet pubblica o la subnet privata.

Elemento pubblico

Imposta il contesto attuale per il tuo cluster utente:
```
kubectl config use-context CLUSTER_NAME
```
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 del progetto host del parco risorse.
- --kubeconfig Il percorso completo del file kubeconfig. La variabile di ambiente $PWD non funziona qui. Inoltre, i percorsi di kubeconfig relativi che utilizzano "~" 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, gli esempi e i 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 qui.
- --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 Istio CA 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

Imposta il contesto attuale per il tuo cluster utente:
```
kubectl config use-context CLUSTER_NAME
```

Salva il seguente 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

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 del progetto host del parco risorse.
- --kubeconfig Il percorso completo del file kubeconfig. La variabile di ambiente $PWD non funziona qui. Inoltre, i percorsi di kubeconfig relativi che utilizzano "~" 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, gli esempi e i 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 qui.
- --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 Istio CA 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 questi comandi su Amazon EKS per eseguire l'upgrade del piano di controllo con funzionalità predefinite e Istio CA. Inserisci i valori nei segnaposto forniti.

Imposta il contesto attuale per il tuo cluster utente:
```
kubectl config use-context CLUSTER_NAME
```
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 del progetto host del parco risorse.
- --kubeconfig Il percorso completo del file kubeconfig. La variabile di ambiente $PWD non funziona qui. Inoltre, i percorsi di kubeconfig relativi che utilizzano "~" 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, gli esempi e i 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 qui.
- --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 Istio CA 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

Microsoft AKS

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

Imposta il contesto attuale per il tuo cluster utente:
```
kubectl config use-context CLUSTER_NAME
```
Esegui asmcli install:
```
HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer ./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 del progetto host del parco risorse.
- --kubeconfig Il percorso completo del file kubeconfig. La variabile di ambiente $PWD non funziona qui. Inoltre, i percorsi di kubeconfig relativi che utilizzano "~" 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, gli esempi e i 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 qui.
- --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 Istio CA 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

Eseguire l'upgrade con funzionalità facoltative

Un file overlay è un file YAML contenente una risorsa personalizzata (CR) IstioOperator che passi a asmcli per configurare il piano di controllo. Puoi eseguire l'override della configurazione del piano di controllo predefinito e attivare una funzionalità facoltativa passando il file YAML a asmcli. Puoi aggiungere più overlay e ogni file di overlay sostituisce la configurazione nei 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 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 del progetto host del parco risorse. Se non includi questa opzione, asmcli utilizza il progetto in cui è stato creato il cluster al momento della 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, gli esempi e i 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 qui.
Nota: prendi nota della directory --output_dir. Sarà necessario farvi riferimento al momento di eseguire 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 un tempo di inattività. asmcliconfigura mesh CA per l'utilizzo dell'identità del carico di lavoro del parco risorse
--custom_overlay Specifica il nome del file di overlay.

Al di fuori di Google Cloud

Esegui i comandi seguenti su Cluster Anthos su VMware, Anthos su Bare Metal, Cluster Anthos su AWS, Amazon EKS o Microsoft AKS. Inserisci i valori nei segnaposto forniti.

Imposta il contesto attuale per il tuo cluster utente:
```
kubectl config use-context CLUSTER_NAME
```
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 del progetto host del parco risorse.
- --kubeconfig Il percorso completo del file kubeconfig. La variabile di ambiente $PWD non funziona qui. Inoltre, i percorsi di kubeconfig relativi che utilizzano "~" 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, gli esempi e i 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 qui.
- --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 un tempo di inattività. asmcliconfigura mesh CA per l'utilizzo dell'identità del carico di lavoro del parco risorse
- --custom_overlay Specifica il nome del file di overlay.

Upgrade dei gateway

Se hai implementato gateway, dovrai eseguirne l'upgrade. Per un semplice upgrade, segui la sezione Upgrade in loco nella guida all'installazione e all'upgrade dei gateway.

Passa al nuovo piano di controllo

Ottieni l'etichetta di revisione su 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-1162-1-67998f4b55-lrzpz           1/1     Running   0          68m   asm-1155-2
istiod-asm-1162-1-67998f4b55-r76kr           1/1     Running   0          68m   asm-1155-2
istiod-1155-2-1-5cd96f88f6-n7tj9    1/1     Running   0          27s   asm-1162-2
istiod-1155-2-1-5cd96f88f6-wm68b    1/1     Running   0          27s   asm-1162-2
```
1. Nell'output, nella colonna REV, indica il valore dell'etichetta di revisione per la nuova versione. In questo esempio, il valore è asm-1162-2.
2. Prendi inoltre nota del valore nell'etichetta di revisione della versione precedente di istiod. È necessario per eliminare la versione precedente di istiod quando hai completato il passaggio dei carichi di lavoro alla nuova versione. Nell'output di esempio, il valore dell'etichetta di revisione per la versione precedente è asm-1155-2.
Aggiungi l'etichetta di revisione a uno spazio dei nomi dell'applicazione e rimuovi l'etichetta istio-injection (se esistente). Nel comando seguente, modifica REVISION nel valore che corrisponde alla nuova revisione di istiod.
```
kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite
```
Se nell'output vedi "istio-injection not found", puoi ignorarlo. Ciò significa che in precedenza lo spazio dei nomi non aveva l'etichetta istio-injection. Poiché l'inserimento automatico non riesce se uno spazio dei nomi ha sia l'etichetta istio-injection che di revisione, tutti i comandi kubectl label nella documentazione di Anthos Service Mesh specificano esplicitamente entrambe le etichette.

Riavvia i pod per attivare la nuova iniezione.

kubectl rollout restart deployment -n NAMESPACE

Testa la tua applicazione per verificare che i carichi di lavoro funzionino correttamente.
Se hai carichi di lavoro in altri spazi dei nomi, ripeti i passaggi per etichettare lo spazio dei nomi e riavviare i pod.
Se ritieni che la tua applicazione funzioni come previsto, continua con la procedura per eseguire la transizione alla nuova versione di istiod. Se si verifica un problema con la tua applicazione, segui i passaggi per eseguire il rollback.
Completa la transizione
Se ritieni che la tua applicazione funzioni come previsto, rimuovi il vecchio piano di controllo per completare la transizione alla nuova versione.
1. Passa alla directory in cui si trovano i file del repository GitHub.anthos-service-mesh
2. Configura il webhook di convalida per l'utilizzo del nuovo piano di controllo:
```
kubectl apply -f asm/istio/istiod-service.yaml
```
3. Sposta il tag predefinito:
```
<OUTPUT_DIR>/istioctl tag set default --revision <NEW REVISION NAME>
```
4. Elimina la versione precedente di istiod. Il comando che utilizzi dipende dal fatto che tu stia eseguendo la migrazione da Istio o l'upgrade da una versione precedente di Anthos Service Mesh.
  Migrazione
  Se hai eseguito la migrazione da Istio, la versione precedente di istio-ingressgateway non ha un'etichetta di revisione:
  
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
  
  Upgrade
  1. Se hai eseguito l'upgrade da una versione precedente di Anthos Service Mesh, assicurati che OLD_REVISION nel comando corrisponda all'etichetta di revisione della versione precedente di istiod:
    
    kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
  2. Elimina la risorsa validatingwebhookconfiguration per la revisione precedente:
    
    kubectl delete validatingwebhookconfiguration istio-validator-OLD_REVISION-istio-system -n istio-system --ignore-not-found
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 eseguire il rollback alla versione precedente:
1. Rietichetta lo spazio dei nomi per abilitare l'inserimento automatico con la versione precedente di istiod. Il comando che utilizzi dipende dall'uso o meno di un'etichetta di revisione o da 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 hai usato istio-injection=enabled:
    
    kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
  Output previsto:
```
namespace/NAMESPACE labeled
```
2. Conferma che l'etichetta di revisione nello spazio dei nomi corrisponda all'etichetta di revisione della versione precedente di istiod:
```
kubectl get ns NAMESPACE --show-labels
```
3. Riavvia i pod per attivare la nuova inserimento in modo che i proxy dispongano della versione precedente:
```
kubectl rollout restart deployment -n NAMESPACE
```
4. Rimuovi la nuova versione di istiod. Assicurati che il valore di REVISION nel comando seguente 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 attivato il controller del servizio canonico. Consigliamo di lasciarlo abilitato, ma se devi disattivarlo, consulta Attivare e disattivare il controller del servizio canonico.
7. Se hai eseguito il deployment dei 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 relativo all'upgrade in loco nella guida all'installazione e all'upgrade dei gateway.

Deployment e nuovo deployment dei carichi di lavoro

L'installazione (o l'upgrade) non verrà completata finché non attivi l'inserimento automatico del proxy sidecar (inserimento automatico). Le migrazioni da OSS Istio e dagli upgrade seguono il processo di upgrade basato sulle revisioni (chiamato "upgrade canary" nella documentazione di Istio). Con un upgrade basato su revisioni, la nuova versione del piano di controllo viene installata insieme al piano di controllo esistente. Quindi sposti alcuni dei tuoi carichi di lavoro nella nuova versione, che ti consente di monitorare l'effetto dell'upgrade con una piccola percentuale dei carichi di lavoro prima di eseguire la migrazione di tutto il traffico nella nuova versione.

Lo script imposta un'etichetta di revisione nel formato istio.io/rev=asm-1162-2 il giorno istiod. Per abilitare l'inserimento automatico, aggiungi un'etichetta di revisione corrispondente agli spazi dei nomi. L'etichetta di revisione viene utilizzata dal webhook iniettore sidecar per associare le sidecar inserite a una determinata revisione istiod. Dopo aver aggiunto l'etichetta, riavvia i pod nello spazio dei nomi per inserire i sidecar.

Ottieni l'etichetta di revisione 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-1162-2
istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2      1/1     Running   0          20s   asm-1162-2
istiod-asm-1162-1-67998f4b55-lrzpz          1/1     Running   0          68m   asm-1155-2
istiod-asm-1162-1-67998f4b55-r76kr          1/1     Running   0          68m   asm-1155-2
istiod-asm-1155-2-5cd96f88f6-n7tj9 1/1     Running   0          27s   asm-1162-2
istiod-asm-1155-2-5cd96f88f6-wm68b 1/1     Running   0          27s   asm-1162-2

Nell'output, nella colonna REV, indica il valore dell'etichetta di revisione per la nuova versione. In questo esempio, il valore è asm-1162-2.
Prendi inoltre nota del valore nell'etichetta di revisione della versione precedente di istiod. È necessario per eliminare la versione precedente di istiod quando hai completato il passaggio dei carichi di lavoro alla nuova versione. Nell'output di esempio, il valore dell'etichetta di revisione per la versione precedente è asm-1155-2.

Imposta istio-ingressgateway sulla nuova revisione. Nel comando seguente, modifica REVISION nel valore che corrisponde all'etichetta di revisione della nuova versione.
```
kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION"}]'
```
Output previsto: service/istio-ingressgateway patched
Aggiungere l'etichetta di revisione a uno spazio dei nomi e rimuovere l'etichetta istio-injection (se esistente). Nel comando seguente, modifica REVISION nel valore che corrisponde alla nuova revisione di istiod.
```
kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite
```
Se nell'output vedi "istio-injection not found", puoi ignorarlo. Ciò significa che in precedenza lo spazio dei nomi non aveva l'etichetta istio-injection. Poiché l'inserimento automatico non riesce se uno spazio dei nomi ha sia l'etichetta istio-injection che di revisione, tutti i comandi kubectl label nella documentazione di Anthos Service Mesh specificano esplicitamente entrambe le etichette.

Riavvia i pod per attivare la nuova iniezione.

kubectl rollout restart deployment -n NAMESPACE

Testa la tua applicazione per verificare che i carichi di lavoro funzionino correttamente.
Se hai carichi di lavoro in altri spazi dei nomi, ripeti i passaggi per etichettare lo spazio dei nomi e riavviare i pod.
Se ritieni che la tua applicazione funzioni come previsto, continua con la procedura per eseguire la transizione alla nuova versione di istiod. Se si verifica un problema con la tua applicazione, segui i passaggi per eseguire il rollback.
Completa la transizione
Se ritieni che la tua applicazione funzioni come previsto, rimuovi il vecchio piano di controllo per completare la transizione alla nuova versione.
1. Passa alla directory in cui si trovano i file del repository GitHub.anthos-service-mesh
2. Configura il webhook di convalida per l'utilizzo del nuovo piano di controllo.
```
kubectl apply -f asm/istio/istiod-service.yaml
```
3. Sposta il tag predefinito.
```
<OUTPUT_DIR>/istioctl tag set default --revision <NEW REVISION NAME>
```
4. Elimina il vecchio istio-ingressgatewaydeployment. Il comando che esegui dipende da se stai eseguendo la migrazione da Istio o dall'upgrade da una versione precedente di Anthos Service Mesh:
  Migrazione
  Se hai eseguito la migrazione da Istio, la versione precedente di istio-ingressgateway non ha un'etichetta di revisione.
  
  kubectl delete deploy/istio-ingressgateway -n istio-system
  
  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
5. Elimina la versione precedente di istiod. Il comando che utilizzi dipende dal fatto che tu stia eseguendo la migrazione da Istio o l'upgrade da una versione precedente di Anthos Service Mesh.
  Migrazione
  Se hai eseguito la migrazione da Istio, la versione precedente di istio-ingressgateway non ha un'etichetta di revisione.
  
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
  
  Upgrade
  Se hai eseguito l'upgrade da una versione precedente di Anthos Service Mesh, assicurati che OLD_REVISION nel comando corrisponda all'etichetta di revisione della versione precedente di istiod.
  
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
6. Rimuovi la versione precedente della configurazione IstioOperator.
```
kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
```
  L'output previsto è simile al seguente:
```
istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted
```
Esegui il rollback
Se hai riscontrato un problema durante il test dell'applicazione con la nuova versione di istiod, segui questi passaggi per eseguire il rollback alla versione precedente:
1. Rietichetta lo spazio dei nomi per abilitare l'inserimento automatico con la versione precedente di istiod. Il comando che utilizzi dipende dall'uso o meno di un'etichetta di revisione o da 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 hai usato istio-injection=enabled:
    
    kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
  Output previsto:
```
namespace/NAMESPACE labeled
```
2. Conferma che l'etichetta di revisione nello spazio dei nomi corrisponda all'etichetta di revisione della versione precedente di istiod:
```
kubectl get ns NAMESPACE --show-labels
```
3. Riavvia i pod per attivare la nuova inserimento in modo che i proxy dispongano della versione precedente:
```
kubectl rollout restart deployment -n NAMESPACE
```
4. Rimuovi il nuovo deployment di istio-ingressgateway. Assicurati che il valore di REVISION nel comando seguente sia corretto.
```
kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION -n istio-system --ignore-not-found=true
```
5. Rimuovi la nuova versione di istiod. Assicurati che il valore di REVISION nel comando seguente sia corretto.
```
kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true
```
6. 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
```
7. Se non hai incluso il flag --disable_canonical_service, lo script ha attivato il controller del servizio canonico. Consigliamo di lasciarlo abilitato, ma se devi disattivarlo, consulta Attivare e disattivare il controller del servizio canonico.

Upgrade di Anthos Service Mesh

GKE

On-premise

Anthos clusters on AWS

Anthos clusters on Azure

Amazon EKS

Microsoft AKS

Prima di iniziare

Personalizzazioni del piano di controllo

Autorità di certificazione

Upgrade di Anthos Service Mesh

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

URI cluster

File kubeconfig

Esegui l'upgrade con funzionalità predefinite e Mesh CA

GKE

Altri cluster Anthos

Eseguire l'upgrade delle funzionalità predefinite con il servizio CA

GKE

On-premise

Eseguire l'upgrade delle funzionalità predefinite con Istio CA

GKE

On-premise

AWS

Elemento pubblico

Privato

Amazon EKS

Microsoft AKS

Eseguire l'upgrade con funzionalità facoltative

GKE

Al di fuori di Google Cloud

Upgrade dei gateway

Passa al nuovo piano di controllo

Completa la transizione

Migrazione

Upgrade

Esegui il rollback

Deployment e nuovo deployment dei carichi di lavoro

Completa la transizione

Migrazione

Upgrade

Migrazione

Upgrade

Esegui il rollback