Esegui l'upgrade di Cloud Service Mesh

Questa pagina spiega come:

  • Esegui asmcli per eseguire l'upgrade da Cloud Service Mesh a Cloud Service Mesh 1.26.4.

  • (Facoltativo) Esegui il deployment di un gateway in entrata.

  • Esegui un upgrade canary per eseguire la migrazione dei workload al nuovo control plane.

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

GKE

Puoi eseguire l'upgrade direttamente a Cloud Service Mesh 1.26.4-asm.7 su Google Kubernetes Engine dalle seguenti versioni:

1.24+

On-premise

Puoi eseguire l'upgrade direttamente a Cloud Service Mesh 1.26.4-asm.7 su Google Distributed Cloud (solo software) per VMware e Google Distributed Cloud (solo software) per bare metal dalle seguenti versioni:

1.24+

GKE su AWS

Puoi eseguire l'upgrade direttamente a Cloud Service Mesh 1.26.4-asm.7 su GKE su AWS dalle seguenti versioni:

1.24+

GKE su Azure

GKE su Azure supporta solo Cloud Service Mesh 1.16. Gli upgrade dalle versioni precedenti di Cloud Service Mesh non sono supportati.

Amazon EKS

Se hai installato Cloud Service Mesh 1.7 su EKS, devi installare Cloud Service Mesh 1.26 su un nuovo cluster. Gli upgrade da Cloud Service Mesh 1.7 a Cloud Service Mesh 1.26 non sono supportati.

Microsoft AKS

Se hai installato Cloud Service Mesh 1.7 su AKS, devi installare Cloud Service Mesh 1.26 su un nuovo cluster. Gli upgrade da Cloud Service Mesh 1.7 a Cloud Service Mesh 1.26 non sono supportati.

Prima di iniziare

Prima di iniziare, assicurati di:

Personalizzazioni del control plane

Se hai personalizzato l'installazione precedente, devi mantenere le stesse personalizzazioni quando esegui l'upgrade a una nuova versione di Cloud 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, denominato file di overlay. Specifichi il file di overlay utilizzando l'opzione --custom_overlay con il nome file quando esegui lo script. Lo script passa il file di overlay a istioctl install.

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 finché tutti i workload non vengono passati all'utilizzo del nuovo control plane con la nuova CA.

Esegui l'upgrade di Cloud Service Mesh

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

  1. Se esegui l'upgrade di un mesh multicluster su GKE che utilizza l'autorità di certificazione Cloud Service Mesh, esegui asmcli create-mesh per configurare il mesh multicluster in modo che consideri attendibile l'identità di workload del parco risorse per il bilanciamento del carico cross-cluster senza tempi di inattività durante l'upgrade.

  2. Esegui asmcli install per installare Cloud Service Mesh su un singolo cluster. Per esempi di righe di comando, consulta le sezioni seguenti. Gli esempi contengono sia argomenti obbligatori sia argomenti facoltativi che potresti trovare utili. Ti consigliamo di specificare sempre l'argomento output_dir in modo da poter individuare facilmente gateway e strumenti di esempio come istioctl. Consulta la barra di navigazione a destra per un elenco degli esempi.

  3. (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 la gestione del control plane e dei gateway separatamente. Se hai bisogno di istio-ingressgateway predefinito installato con il piano di controllo in-cluster, includi l'argomento --option legacy-default-ingressgateway.

  4. Per completare la configurazione di Cloud Service Mesh, devi abilitare l'inserimento automatico di sidecar e eseguire il deployment o il redeploy dei workload.

Configura il mesh multicluster in modo che consideri attendibile l'identità dei carichi di lavoro del parco risorse

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

  • Registra tutti i cluster nello stesso parco risorse.
  • Configura la mesh in modo che consideri attendibile l'identità del workload del parco risorse.
  • Crea secret remoti.

Puoi specificare l'URI per ogni 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 del cluster, la zona o la regione e l'ID progetto per ogni 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 le funzionalità predefinite e Mesh CA

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

GKE

Esegui questo comando per eseguire l'upgrade del control plane con le funzionalità predefinite e l'autorità di certificazione Cloud Service Mesh. 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 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.
  • --enable_all Consente allo script di:
    • Concedi le autorizzazioni IAM richieste.
    • Abilita le API Google richieste.
    • Imposta un'etichetta sul cluster che identifichi il mesh.
    • Registra il cluster nel parco risorse se non è già registrato.
  • --ca mesh_ca Utilizza l'autorità di certificazione Cloud Service Mesh come autorità di certificazione. La modifica delle autorità di certificazione durante un upgrade causa tempi di inattività. asmcliconfigura l'autorità di certificazione Cloud Service Mesh per utilizzare l'identità del workload del parco risorse

Altri cluster GKE Enterprise

Esegui i seguenti comandi sugli altri cluster GKE Enterprise per eseguire l'upgrade del control plane con le funzionalità predefinite e l'autorità di certificazione Cloud Service Mesh. Inserisci i tuoi valori nei segnaposto forniti.

  1. Imposta il contesto corrente sul cluster utente:

    kubectl config use-context CLUSTER_NAME

  2. Corsa 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 qui. Inoltre, le posizioni dei file kubeconfig relative 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, esempi e 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 è qualcosa di diverso Google Cloud, ad esempio on-premise o multi-cloud.
    • --enable_all Consente allo script di:
      • Concedi le autorizzazioni IAM richieste.
      • Abilita le API Google richieste.
      • Imposta un'etichetta sul cluster che identifichi il mesh.
      • Registra il cluster nel parco risorse se non è già registrato.
    • --ca mesh_ca Utilizza l'autorità di certificazione Cloud Service Mesh come autorità di certificazione. La modifica delle autorità di certificazione durante un upgrade causa tempi di inattività. asmcliconfigura l'autorità di certificazione Cloud Service Mesh per utilizzare l'identità del workload del parco risorse

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

Questa sezione mostra come eseguire asmcli per eseguire l'upgrade di Cloud Service Mesh con le funzionalità supportate predefinite per la tua piattaforma e attivare Certificate Authority Service.

GKE

Esegui questo comando per eseguire l'upgrade del control plane con le funzionalità predefinite e 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 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 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.
  • --enable_all Consente allo script di:
    • Concedi le autorizzazioni IAM richieste.
    • Abilita le API Google richieste.
    • Imposta un'etichetta sul cluster che identifichi il mesh.
    • Registra il cluster nel parco risorse se non è già registrato.
  • --ca gcp_cas Utilizza Certificate Authority Service come autorità di certificazione. La modifica delle autorità di certificazione durante un upgrade causa tempi di inattività. asmcliconfigura Certificate Authority Service per utilizzare Workload Identity del parco risorse
  • --ca_pool L'identificatore completo del pool di CA di Certificate Authority Service.

On-premise

Esegui i seguenti comandi su Google Distributed Cloud (solo software) per VMware o Google Distributed Cloud (solo software) per bare metal per eseguire l'upgrade del control plane con le funzionalità predefinite e Certificate Authority Service. Inserisci i valori nei segnaposto forniti.

  1. Imposta il contesto corrente sul cluster utente:

    kubectl config use-context CLUSTER_NAME

  2. Corsa 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 progetto del progetto host del parco risorse.
    • --kubeconfig Il percorso completo del file kubeconfig. La variabile di ambiente $PWD non funziona qui. Inoltre, le posizioni dei file kubeconfig relative 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, esempi e 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 è qualcosa di diverso Google Cloud, ad esempio on-premise o multi-cloud.
    • --enable_all Consente allo script di:
      • Concedi le autorizzazioni IAM richieste.
      • Abilita le API Google richieste.
      • Imposta un'etichetta sul cluster che identifichi il mesh.
      • Registra il cluster nel parco risorse se non è già registrato.
    • --ca gcp_cas Utilizza Certificate Authority Service come autorità di certificazione. La modifica delle autorità di certificazione durante un upgrade causa tempi di inattività. asmcliconfigura Certificate Authority Service per utilizzare Workload Identity del parco risorse
    • --ca_pool L'identificatore completo del pool di CA di Certificate Authority Service.

Eseguire l'upgrade delle funzionalità predefinite con l'autorità di certificazione (CA) Istio

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

GKE

Esegui il comando seguente per eseguire l'upgrade del control plane con le funzionalità predefinite e l'autorità di certificazione 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 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.
  • --enable_all Consente allo script di:
    • Concedi le autorizzazioni IAM richieste.
    • Abilita le API Google richieste.
    • Imposta un'etichetta sul cluster che identifichi il mesh.
    • Registra il cluster nel parco risorse se non è già registrato.
  • --ca citadel Utilizza la CA Istio. La modifica delle autorità di certificazione durante un upgrade causa tempi di inattività.

On-premise

Esegui i seguenti comandi su Google Distributed Cloud (solo software) per VMware o Google Distributed Cloud (solo software) per bare metal per eseguire l'upgrade del control plane con le funzionalità predefinite e l'autorità di certificazione Istio. Inserisci i valori nei segnaposto forniti.

  1. Imposta il contesto corrente sul cluster utente:

    kubectl config use-context CLUSTER_NAME

  2. Corsa 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 qui. Inoltre, le posizioni dei file kubeconfig relative 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, esempi e 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 è qualcosa di diverso Google Cloud, ad esempio on-premise o multi-cloud.
    • --enable_all Consente allo script di:
      • Concedi le autorizzazioni IAM richieste.
      • Abilita le API Google richieste.
      • Imposta un'etichetta sul cluster che identifichi il mesh.
      • Registra il cluster nel parco risorse se non è già registrato.
    • --ca citadel Utilizza Istio CA come autorità di certificazione.
    • --ca_cert Il certificato intermedio
    • --ca_key La chiave del certificato intermedio
    • --root_cert Il certificato radice
    • --cert_chain La catena di certificati

AWS

Esegui i seguenti comandi su GKE su AWS per eseguire l'upgrade del control plane con le funzionalità predefinite e l'autorità di certificazione Istio. Inserisci i valori nei segnaposto forniti. Puoi scegliere di abilitare l'ingresso per la subnet pubblica o per la subnet privata.

Pubblico

  1. Imposta il contesto corrente sul cluster utente:

    kubectl config use-context CLUSTER_NAME

  2. Corsa 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 qui. Inoltre, le posizioni dei file kubeconfig relative 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, esempi e 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 è qualcosa di diverso Google Cloud, ad esempio on-premise o multi-cloud.
    • --enable_all Consente allo script di:
      • Concedi le autorizzazioni IAM richieste.
      • Abilita le API Google richieste.
      • Imposta un'etichetta sul cluster che identifichi il mesh.
      • Registra il cluster nel parco risorse se non è già registrato.
    • --ca citadel Utilizza Istio CA come autorità di certificazione.
    • --ca_cert Il certificato intermedio
    • --ca_key La chiave del certificato intermedio
    • --root_cert Il certificato radice
    • --cert_chain La catena di certificati

Privato

  1. Imposta il contesto corrente sul cluster utente:

    kubectl config use-context CLUSTER_NAME

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

  3. Corsa 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 qui. Inoltre, le posizioni dei file kubeconfig relative 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, esempi e 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 è qualcosa di diverso Google Cloud, ad esempio on-premise o multi-cloud.
    • --enable_all Consente allo script di:
      • Concedi le autorizzazioni IAM richieste.
      • Abilita le API Google richieste.
      • Imposta un'etichetta sul cluster che identifichi il mesh.
      • Registra il cluster nel parco risorse se non è già registrato.
    • --ca citadel Utilizza Istio CA come autorità di certificazione.
    • --ca_cert Il certificato intermedio
    • --ca_key La chiave del certificato intermedio
    • --root_cert Il certificato radice
    • --cert_chain La catena di certificati

Amazon EKS

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

  1. Imposta il contesto corrente sul cluster utente:

    kubectl config use-context CLUSTER_NAME

  2. Corsa 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 qui. Inoltre, le posizioni dei file kubeconfig relative 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, esempi e 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 è qualcosa di diverso Google Cloud, ad esempio on-premise o multi-cloud.
    • --enable_all Consente allo script di:
      • Concedi le autorizzazioni IAM richieste.
      • Abilita le API Google richieste.
      • Imposta un'etichetta sul cluster che identifichi il mesh.
      • Registra il cluster nel parco risorse se non è già registrato.
    • --ca citadel Utilizza Istio CA come autorità di certificazione.
    • --ca_cert Il certificato intermedio
    • --ca_key La chiave del certificato intermedio
    • --root_cert Il certificato radice
    • --cert_chain La catena di certificati

Microsoft AKS

Esegui i seguenti comandi su Microsoft AKS per eseguire l'upgrade del control plane con le funzionalità predefinite e l'autorità di certificazione Istio. Inserisci i valori nei segnaposto forniti.

  1. Imposta il contesto corrente sul cluster utente:

    kubectl config use-context CLUSTER_NAME

  2. Corsa 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 progetto del progetto host del parco risorse.
    • --kubeconfig Il percorso completo del file kubeconfig. La variabile di ambiente $PWD non funziona qui. Inoltre, le posizioni dei file kubeconfig relative 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, esempi e 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 è qualcosa di diverso Google Cloud, ad esempio on-premise o multi-cloud.
    • --enable_all Consente allo script di:
      • Concedi le autorizzazioni IAM richieste.
      • Abilita le API Google richieste.
      • Imposta un'etichetta sul cluster che identifichi il mesh.
      • Registra il cluster nel parco risorse se non è già registrato.
    • --ca citadel Utilizza Istio CA come autorità di certificazione.
    • --ca_cert Il certificato intermedio
    • --ca_key La chiave del certificato intermedio
    • --root_cert Il certificato radice
    • --cert_chain La catena di certificati

Eseguire l'upgrade con funzionalità facoltative

Un file di overlay è un file YAML contenente una risorsa personalizzata (CR) IstioOperator che passi a asmcli per configurare il control plane. Puoi ignorare la configurazione predefinita del control plane e attivare una funzionalità facoltativa passando il file YAML a asmcli. Puoi aggiungere più overlay e ogni file di overlay sostituisce la configurazione dei livelli precedenti.

GKE

Esegui questo comando per installare il control plane con una funzionalità facoltativa. Per aggiungere più file, specifica --custom_overlay e il nome 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 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 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.
  • --enable_all Consente allo script di:
    • Concedi le autorizzazioni IAM richieste.
    • Abilita le API Google richieste.
    • Imposta un'etichetta sul cluster che identifichi il mesh.
    • Registra il cluster nel parco risorse se non è già registrato.
  • --ca mesh_ca Utilizza l'autorità di certificazione Cloud Service Mesh come autorità di certificazione. La modifica delle autorità di certificazione durante un upgrade causa tempi di inattività. asmcliconfigura l'autorità di certificazione Cloud Service Mesh per utilizzare l'identità del workload del parco risorse
  • --custom_overlay Specifica il nome del file di sovrapposizione.

Al di fuori di Google Cloud

Esegui i seguenti comandi su Google Distributed Cloud (solo software) per VMware, Google Distributed Cloud (solo software) per bare metal, GKE su AWS, Amazon EKS o Microsoft AKS. Inserisci i valori nei segnaposto forniti.

  1. Imposta il contesto corrente sul cluster utente:

    kubectl config use-context CLUSTER_NAME

  2. Corsa 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 qui. Inoltre, le posizioni dei file kubeconfig relative 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, esempi e 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 è qualcosa di diverso Google Cloud, ad esempio on-premise o multi-cloud.
    • --enable_all Consente allo script di:
      • Concedi le autorizzazioni IAM richieste.
      • Abilita le API Google richieste.
      • Imposta un'etichetta sul cluster che identifichi il mesh.
      • Registra il cluster nel parco risorse se non è già registrato.
    • --ca mesh_ca Utilizza l'autorità di certificazione Cloud Service Mesh come autorità di certificazione. La modifica delle autorità di certificazione durante un upgrade causa tempi di inattività. asmcliconfigura l'autorità di certificazione Cloud Service Mesh per utilizzare l'identità del workload del parco risorse
    • --custom_overlay Specifica il nome del file di sovrapposizione.

Eseguire l'upgrade dei gateway

Se hai gateway di cui è stato eseguito il deployment, dovrai eseguire l'upgrade anche di questi. Per un upgrade semplice, segui la sezione Upgrade in loco della guida Installazione e upgrade dei gateway.

Passare al nuovo control plane

  1. Ottieni l'etichetta di revisione presente 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-1264-7-67998f4b55-lrzpz           1/1     Running   0          68m   asm-1255-7
istiod-asm-1264-7-67998f4b55-r76kr           1/1     Running   0          68m   asm-1255-7
istiod-1255-7-1-5cd96f88f6-n7tj9    1/1     Running   0          27s   asm-1264-7
istiod-1255-7-1-5cd96f88f6-wm68b    1/1     Running   0          27s   asm-1264-7

    1. Nell'output, nella colonna REV, prendi nota del valore dell'etichetta di revisione per la nuova versione. In questo esempio, il valore è asm-1264-7.

    2. Prendi nota anche del valore nell'etichetta di revisione per la versione precedente di istiod. Ti serve per eliminare la versione precedente di istiod al termine del trasferimento dei carichi di lavoro alla nuova versione. Nell'output di esempio, il valore dell'etichetta di revisione per la versione precedente è asm-1255-7.

  2. Aggiungi l'etichetta di revisione a uno spazio dei nomi dell'applicazione e rimuovi l'etichetta istio-injection (se esiste). Nel comando seguente, modifica REVISION con il valore corrispondente 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 lo spazio dei nomi non aveva in precedenza l'etichetta istio-injection. Poiché il comportamento di inserimento automatico non è definito quando uno spazio dei nomi ha sia l'etichetta istio-injection sia quella di revisione, tutti i comandi kubectl label nella documentazione di Cloud Service Mesh assicurano esplicitamente che ne venga impostata solo una.

  3. Riavvia i pod per attivare la reiniezione.

    kubectl rollout restart deployment -n NAMESPACE

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

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

  6. Se ritieni che la tua applicazione funzioni come previsto, continua con i passaggi per la transizione alla nuova versione di istiod. Se si verifica un problema con l'applicazione, segui i passaggi per eseguire il rollback.

    Completa la transizione

    Se ritieni che la tua applicazione funzioni come previsto, rimuovi il vecchio control plane per completare la transizione alla nuova versione.

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

    2. Sposta il tag predefinito:

      <OUTPUT_DIR>/istioctl tag set default --revision <NEW REVISION NAME> --overwrite

    3. 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 Cloud Service Mesh.

      Esegui migrazione

      Se hai eseguito la migrazione da Istio, il vecchio istio-ingressgateway non ha un'etichetta di revisione:

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

      Esegui l'upgrade

      1. Se hai eseguito l'upgrade da una versione precedente di Cloud Service Mesh, nel comando seguente assicurati che OLD_REVISION corrisponda all'etichetta di revisione della versione precedente di istiod:

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

      2. Elimina le risorse validatingwebhookconfiguration, mutatingWebhookConfiguration, configMap, clusterRole e clusterRoleBinding per la revisione precedente:

        kubectl delete validatingwebhookconfiguration istio-validator-OLD_REVISION-istio-system --ignore-not-found
kubectl delete mutatingWebhookConfiguration istio-sidecar-injector-OLD_REVISION --ignore-not-found
kubectl delete configMap istio-OLD_REVISION istio-sidecar-injector-OLD_REVISION -n istio-system --ignore-not-found
kubectl delete clusterRole,clusterRoleBinding istio-reader-clusterrole-OLD_REVISION-istio-system istiod-clusterrole-OLD_REVISION-istio-system istiod-gateway-controller-OLD_REVISION-istio-system --ignore-not-found

    4. 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. Etichetta nuovamente lo spazio dei nomi per attivare l'inserimento automatico con la versione precedente di istiod. Il comando che utilizzi dipende dal fatto 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. Verifica che l'etichetta della revisione nello spazio dei nomi corrisponda a quella della revisione nella 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 di canonicalizzazione. Ti consigliamo di lasciarlo abilitato, ma se devi disabilitarlo, consulta Abilitazione e disabilitazione del controller del servizio di canonicalizzazione.

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

Deployment e nuovo deployment dei carichi di lavoro

L'installazione (o l'upgrade) non è completa finché non abiliti l'inserimento automatico del proxy sidecar. Le migrazioni da Istio OSS e gli upgrade seguono la procedura di upgrade basata sulla revisione (denominata "upgrade canary" nella documentazione di Istio). Con un upgrade basato sulla revisione, la nuova versione del control plane viene installata insieme a quella esistente. Poi sposti alcuni dei tuoi workload alla nuova versione, il che ti consente di monitorare l'effetto dell'upgrade con una piccola percentuale dei workload 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-1264-7 su istiod. Per attivare l'inserimento automatico, aggiungi un'etichetta di revisione corrispondente ai tuoi spazi dei nomi. L'etichetta di revisione viene utilizzata dal webhook dell'iniettore sidecar per associare i sidecar inseriti a una particolare revisione istiod. Dopo aver aggiunto l'etichetta, riavvia i pod nello spazio dei nomi per inserire i sidecar.

  1. Ottieni l'etichetta di revisione presente in istiod e istio-ingressgateway. Nel comando seguente, modifica il valore INGRESS_NAMESPACE con lo spazio dei nomi in cui è in esecuzione il gateway in entrata:

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

    L'output del comando è simile al seguente se il nome del gateway ingress è istio-ingressgateway:

    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-1264-7
istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2      1/1     Running   0          20s   asm-1264-7
istiod-asm-1264-7-67998f4b55-lrzpz          1/1     Running   0          68m   asm-1255-7
istiod-asm-1264-7-67998f4b55-r76kr          1/1     Running   0          68m   asm-1255-7
istiod-asm-1255-7-5cd96f88f6-n7tj9 1/1     Running   0          27s   asm-1264-7
istiod-asm-1255-7-5cd96f88f6-wm68b 1/1     Running   0          27s   asm-1264-7

    1. Nell'output, nella colonna REV, prendi nota del valore dell'etichetta di revisione per la nuova versione. In questo esempio, il valore è asm-1264-7.

    2. Prendi nota anche del valore nell'etichetta di revisione per la versione precedente di istiod. Ti servirà per eliminare la vecchia versione di istiod una volta terminato il trasferimento dei carichi di lavoro alla nuova versione. Nell'output di esempio, il valore dell'etichetta di revisione per la versione precedente è asm-1255-7.

  2. Passa al nuovo gateway in entrata. Nel comando seguente, modifica REVISION con il valore che corrisponde all'etichetta di revisione della nuova versione. Modifica INGRESS_NAMESPACE con lo spazio dei nomi in cui è in esecuzione il gateway in entrata e INGRESS_NAME con il nome del gateway in entrata.

    kubectl patch service -n INGRESS_NAMESPACE INGRESS_NAME --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION"}]'

    Output previsto: service/istio-ingressgateway patched

  3. Aggiungi l'etichetta di revisione a uno spazio dei nomi e rimuovi l'etichetta istio-injection (se esiste). Nel comando seguente, modifica REVISION con il valore corrispondente 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 lo spazio dei nomi non aveva in precedenza l'etichetta istio-injection. Poiché il comportamento di inserimento automatico non è definito quando uno spazio dei nomi ha sia l'etichetta istio-injection sia quella di revisione, tutti i comandi kubectl label nella documentazione di Cloud Service Mesh assicurano esplicitamente che ne venga impostata solo una.

  4. Riavvia i pod per attivare la reiniezione.

    kubectl rollout restart deployment -n NAMESPACE

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

  6. Se hai carichi di lavoro in altri spazi dei nomi, ripeti i passaggi per etichettare lo spazio dei nomi e riavvia i pod.

  7. Se ritieni che la tua applicazione funzioni come previsto, continua con i passaggi per la transizione alla nuova versione di istiod. Se si verifica un problema con l'applicazione, segui i passaggi per eseguire il rollback.

    Completa la transizione

    Se ritieni che la tua applicazione funzioni come previsto, rimuovi il vecchio control plane per completare la transizione alla nuova versione.

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

    2. Sposta il tag predefinito.

      <OUTPUT_DIR>/istioctl tag set default --revision <NEW REVISION NAME> --overwrite

    3. Elimina la vecchia implementazione del gateway in entrata. Il comando che esegui dipende dal fatto che tu stia eseguendo la migrazione da Istio o l'upgrade da una versione precedente di Cloud Service Mesh:

      Esegui migrazione

      Se hai eseguito la migrazione da Istio, il vecchio INGRESS_NAME non ha un'etichetta di revisione.

      kubectl delete deploy/INGRESS_NAME -n INGRESS_NAMESPACE

      Esegui l'upgrade

      Se hai eseguito l'upgrade da una versione precedente di Cloud Service Mesh, nel comando seguente sostituisci OLD_REVISION con l'etichetta di revisione della versione precedente di INGRESS_NAME.

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

    4. Elimina la vecchia versione 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 Cloud Service Mesh.

      Esegui migrazione

      Se hai eseguito la migrazione da Istio, il vecchio istiod non ha un'etichetta di revisione.

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

      Se hai il piano di controllo precedente, che ha l'etichetta di revisione OLD_REVISION, fai clic sulla scheda upgrade e completa l'eliminazione del piano di controllo istiod con OLD_REVISION.

      Esegui l'upgrade

      Se hai eseguito l'upgrade da una versione precedente di Cloud Service Mesh, nel comando seguente assicurati che OLD_REVISION corrisponda all'etichetta di revisione della versione precedente di istiod.

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

      Elimina le risorse validatingwebhookconfiguration, mutatingWebhookConfiguration, configMap, clusterRole e clusterRoleBinding per la revisione precedente:

      kubectl delete validatingwebhookconfiguration istio-validator-OLD_REVISION-istio-system  --ignore-not-found
kubectl delete mutatingWebhookConfiguration istio-sidecar-injector-OLD_REVISION --ignore-not-found
kubectl delete configMap istio-OLD_REVISION istio-sidecar-injector-OLD_REVISION -n istio-system --ignore-not-found
kubectl delete clusterRole,clusterRoleBinding istio-reader-clusterrole-OLD_REVISION-istio-system istiod-clusterrole-OLD_REVISION-istio-system istiod-gateway-controller-OLD_REVISION-istio-system --ignore-not-found

    5. Rimuovi la vecchia versione della configurazione di IstioOperator.

      kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system --ignore-not-found=true

      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. Etichetta nuovamente lo spazio dei nomi per attivare l'inserimento automatico con la versione precedente di istiod. Il comando che utilizzi dipende dal fatto 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. Verifica che l'etichetta della revisione nello spazio dei nomi corrisponda a quella della revisione nella 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 il nuovo deployment di 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

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

    6. Rimuovi la nuova versione della configurazione IstioOperator.

     kubectl delete IstioOperator installed-state-REVISION -n istio-system --ignore-not-found=true

    L'output previsto è simile al seguente:

     istiooperator.install.istio.io "installed-state-REVISION" deleted

    1. Se non hai incluso il flag --disable_canonical_service, lo script ha abilitato il controller del servizio di canonicalizzazione. Ti consigliamo di lasciarlo abilitato, ma se devi disabilitarlo, consulta Abilitazione e disabilitazione del controller del servizio di canonicalizzazione.