Pianificazione di un upgrade

Questa pagina fornisce informazioni utili per pianificare un upgrade di Cloud Service Mesh. Ti consigliamo inoltre di consultare le 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 piano di controllo accanto 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 i piani di controllo.

Per eseguire la migrazione dei workload al nuovo piano di controllo:

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

2. Esegui un riavvio graduale. Il riavvio re-inietta i proxy sidecar nei pod in modo che utilizzino il nuovo piano di controllo.

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

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

Un upgrade canary è molto più sicuro di un upgrade in situ in cui il nuovo piano di controllo sostituisce quello precedente. Per la procedura dettagliata, vedi Passare al nuovo control plane.

Personalizzare il piano di controllo

Se hai personalizzato l'installazione precedente, devi eseguire le 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 a un file YAML IstioOperator, chiamato file overlay. Specifica il file overlay utilizzando l'opzione --custom_overlay con il nome del file quando esegui asmcli.

Attenzione: l'omissione del file overlay comporta un'installazione riuscita. Tuttavia, il tuo mesh di servizi ha una configurazione diversa da quella prevista perché i valori omessi vengono reimpostati sui valori predefiniti quando il control plane viene reimplementato.

Il pacchetto anthos-service-mesh su GitHub contiene molti file di overlay. Questi file contengono personalizzazioni comuni della configurazione predefinita. Puoi utilizzare questi file così come sono o apportare ulteriori modifiche in base alle tue esigenze. Alcuni file sono obbligatori per abilitare le funzionalità facoltative di Cloud Service Mesh. Il pacchetto anthos-service-mesh viene scaricato quando esegui asmcli per convalidare il progetto e il cluster.

Quando installi Cloud Service Mesh utilizzando asmcli install, puoi specificare uno o più file overlay con --option o --custom_overlay. Se non devi apportare modifiche ai file nel repository anthos-service-mesh, puoi utilizzare --option e lo script recupererà il file da GitHub per te. In caso contrario, puoi apportare modifiche al file overlay e utilizzare l'opzione --custom_overlay per trasmetterlo a asmcli.

Scegli un'autorità di certificazione

Se la tua attuale installazione di Cloud Service Mesh utilizza l'autorità di certificazione Cloud Service Mesh come autorità di certificazione (CA) per l'emissione di certificati mutual TLS (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 estremamente affidabile e scalabile ottimizzato per i carichi di lavoro con scalabilità dinamica.
• Con l'autorità di certificazione Cloud Service Mesh, Google gestisce la sicurezza e la disponibilità del backend dell'autorità di certificazione.
• L'autorità di certificazione Cloud Service Mesh ti consente di fare affidamento su una singola radice di attendibilità nei diversi cluster.

Se la tua attuale installazione di Cloud Service Mesh utilizza la CA Istio (in precedenza chiamata "Citadel"), puoi passare alla CA Cloud Service Mesh durante l'upgrade, ma devi pianificare il tempo di riposo. Durante l'upgrade, il traffico mTLS viene interrotto finché non viene eseguito il passaggio a tutti i carichi di lavoro che utilizzano il nuovo piano di controllo con la CA Cloud Service Mesh.

Nota sulla piattaforma: il servizio CA è supportato solo sulle seguenti piattaforme: cluster GKE su Google Cloud, Google Distributed Cloud e Distributed Cloud. Se esegui asmcli install e specifichi --ca gcp_cas su altre piattaforme, l'installazione sembra essere andata a buon fine, ma i carichi di lavoro non riusciranno a essere avviati.

I certificati dell'autorità di certificazione Cloud Service Mesh includono i seguenti dati sui servizi della tua applicazione:

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

Importante: i certificati emessi dalla CA mesh devono essere utilizzati solo per abilitare la comunicazione sicura tra servizi all'interno del tuo mesh di servizi e non devono essere utilizzati per altri scopi. Questi certificati vengono inviati ogni volta che i servizi tentano di comunicare tra loro utilizzando TLS reciproco. Assicurati di non esporre inavvertitamente informazioni riservate utilizzando questi certificati quando comunichi al di fuori del tuo mesh di servizi.

Identificazione della CA

Quando esegui asmcli install per eseguire l'upgrade, specifica la CA che asmcli deve attivare nel nuovo piano di controllo.

La modifica delle CA causa un tempo di riposo quando esegui il deployment dei carichi di lavoro nel nuovo piano di controllo. Se non riesci a pianificare il tempo di riposo, assicurati di specificare la stessa CA per il nuovo piano di controllo utilizzata dal vecchio piano di controllo. Se non sai con certezza quale CA è abilitata nel tuo mesh, esegui i seguenti comandi:

1. Recupera 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 tuoi pod nel seguente comando:

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

   Se l'autorità di certificazione Cloud Service Mesh è attivata nel nome di spazio, viene visualizzato 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 e gestire i gateway all'interno del tuo mesh di servizi. Un gateway descrive un bilanciatore del carico che opera all'esterno della rete mesh e riceve connessioni HTTP/TCP in entrata o in uscita. I gateway sono proxy Envoy che ti offrono un controllo granulare sul traffico in entrata e in uscita dal mesh.

asmcli non installa istio-ingressgateway. Ti consigliamo di eseguire il deployment e gestire il piano di controllo e i gateway separatamente. Per ulteriori informazioni, consulta Installare e eseguire l'upgrade dei gateway.

Esegui l'upgrade della piattaforma (facoltativo)

Come best practice, ti consigliamo di eseguire l'upgrade di Cloud Service Mesh all'ultima versione supportata che supporta anche la tua piattaforma attuale. Esegui quindi l'upgrade dell'ambiente in modo che rientri nell'intervallo di piattaforme e versioni Kubernetes supportate. Infine, se necessario, esegui l'upgrade all'ultima versione supportata di Cloud Service Mesh.

Passaggi successivi

• Installa gli strumenti dipendenti e convalida i cluster