Pianificazione di un upgrade

Questa pagina fornisce informazioni utili per pianificare un upgrade di Cloud Service Mesh. Me ti consigliamo di consultare anche Note sull'upgrade di Istio.

Informazioni sugli upgrade canary

Ti consigliamo di eseguire l'upgrade di Cloud Service Mesh eseguendo prima un deployment canary del nuovo piano di controllo. Con un upgrade canary, asmcli installa una nuova revisione del controllo piano di controllo insieme al vecchio piano di controllo. Sia il vecchio che il nuovo piano di controllo sono etichettati con un'etichetta revision, che funge da identificatore per piani di controllo.

Per eseguire la migrazione dei carichi di lavoro al nuovo piano di controllo:

  1. Imposta l'etichetta revision del nuovo piano di controllo su uno degli spazi dei nomi.

  2. Esegui un riavvio in sequenza. Il riavvio reintegra i proxy sidecar nella i pod in modo che i proxy utilizzino il nuovo piano di controllo.

  3. Monitora l'effetto dell'upgrade sui carichi di lavoro. Se necessario per testare ripeti i passaggi precedenti.

  4. Dopo aver testato l'applicazione, puoi eseguire la migrazione di tutto il traffico alla nuova o rollback al piano di controllo precedente.

Una versione canary è molto più sicura rispetto a un upgrade in loco, in cui la nuova sostituisce quello precedente. Per la procedura dettagliata, vedi Passa al nuovo piano di controllo.

Personalizzare il piano di controllo

Se hai personalizzato l'installazione precedente, hai bisogno delle stesse personalizzazioni quando esegui l'upgrade di Cloud Service Mesh. Se hai personalizzato l'installazione aggiungendo il flag --set values a istioctl install, devi aggiungere queste impostazioni un file YAML IstioOperator, chiamato file overlay. Devi specificare overlay file utilizzando l'opzione --custom_overlay con il nome file quando esegui asmcli.

La anthos-service-mesh in GitHub contiene molti file di overlay. Questi file contengono personalizzazioni alla configurazione predefinita. Puoi utilizzare questi file mentre o apportare modifiche aggiuntive in base alle necessità. Alcuni file sono tenuti a abilitare le funzionalità facoltative di Cloud Service Mesh. Il pacchetto anthos-service-mesh viene scaricato quando esegui asmcli in convalida il progetto e il cluster.

Quando installi Cloud Service Mesh utilizzando asmcli install, puoi specificare uno o più file di overlay con --option o --custom_overlay. Se non devi apportare modifiche ai file in anthos-service-mesh repository, puoi utilizzare --option e lo script recupera il file da GitHub per te. Altrimenti, puoi apportare modifiche al file dell'overlay e utilizzare --custom_overlay per passarlo a asmcli.

Scegli un'autorità di certificazione

Se l'installazione attuale di Cloud Service Mesh utilizza Autorità di certificazione Cloud Service Mesh come autorità di certificazione (CA) per il rilascio TLS reciproco (mTLS) ti consigliamo di continuare a utilizzare l'autorità di certificazione Cloud Service Mesh per i seguenti motivi:

  • L'autorità di certificazione Cloud Service Mesh è un servizio altamente affidabile e scalabile, e ottimizzato per carichi di lavoro con scalabilità dinamica.
  • Con l'autorità di certificazione Cloud Service Mesh, Google gestisce la sicurezza e la disponibilità del backend della CA.
  • L'autorità di certificazione Cloud Service Mesh ti consente di affidarti a un'unica radice di attendibilità tra cluster.

Se la tua installazione attuale di Cloud Service Mesh utilizza Istio CA (precedentemente chiamata "Citadel"), puoi passare all'autorità di certificazione Cloud Service Mesh quando esegui l'upgrade, ma devi pianificare il tempo di riposo. Durante l'upgrade, il traffico mTLS viene interrotto finché tutti i carichi di lavoro non vengono passati all'utilizzo del nuovo piano di controllo con l'autorità di certificazione Cloud Service Mesh.

I certificati emessi dall'autorità di certificazione Cloud Service Mesh includono i seguenti dati su dei servizi della tua applicazione:

  • ID del progetto Google Cloud
  • Lo spazio dei nomi GKE
  • Il nome dell'account di servizio GKE

Identificazione della CA

Quando esegui asmcli install per l'upgrade, specifichi la CA che asmcli nel nuovo piano di controllo.

La modifica delle CA causa tempi di inattività quando esegui il deployment dei carichi di lavoro nel nuovo dal piano di controllo. Se non puoi pianificare il tempo di riposo, assicurati di specificare la stessa CA per il nuovo piano di controllo precedente. In caso di dubbi quale CA è abilitata sulla rete mesh, esegui questi comandi:

  1. Ottieni un elenco di pod da uno dei tuoi spazi dei nomi:

    kubectl get pods -n NAMESPACE

  2. Sostituisci POD_NAME con il nome di uno dei pod in il seguente comando:

    kubectl get pod POD_NAME -n NAMESPACE -o yaml | grep CA_ADDR -A 1

    Se l'autorità di certificazione Cloud Service Mesh è abilitata nello spazio dei nomi, vedrai il seguente output:

    - name: CA_ADDR
  value: meshca.googleapis.com:443

Prepara la configurazione del gateway

Cloud Service Mesh ti offre la possibilità di eseguire il deployment dei gateway e gestirli del tuo mesh di servizi. Un gateway descrive un bilanciatore del carico che opera a livello perimetrale del mesh che riceve connessioni HTTP/TCP in entrata o in uscita. I gateway sono Proxy Envoy che forniscono un controllo granulare sul traffico in entrata senza uscire dalla rete.

asmcli non installa istio-ingressgateway. Ti consigliamo di il deployment e la gestione del piano di controllo e dei gateway separatamente. Per maggiori informazioni consulta Installazione e upgrade dei gateway.

(Facoltativo) Esegui l'upgrade della tua piattaforma

Come best practice, dovresti eseguire l'upgrade di Cloud Service Mesh alla versione più recente versione supportata che supporta anche la tua attuale piattaforma. Quindi, esegui l'upgrade dell'ambiente in modo che che rientra nell'intervallo piattaforme supportate e versioni di Kubernetes. Infine, se necessario, esegui l'upgrade all'ultima versione versione supportata di Cloud Service Mesh.

Passaggi successivi