Pianificazione di un upgrade

Questa pagina fornisce informazioni per aiutarti a pianificare un upgrade di Anthos Service Mesh. Ti consigliamo di consultare anche le note sull'upgrade di Istio.

Informazioni sugli upgrade canary

Ti consigliamo di eseguire l'upgrade di Anthos 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 insieme a quello precedente. Sia il piano di controllo precedente che quello nuovo sono etichettati con un'etichetta revision, che funge da identificatore per il piano 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 dei tuoi spazi dei nomi.

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

3. Monitora l'effetto dell'upgrade sui carichi di lavoro. Se necessario, 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 rispetto a un upgrade in loco in cui il nuovo piano di controllo sostituisce quello precedente. Per la procedura dettagliata, consulta Passare al nuovo piano di controllo.

Personalizzare il piano di controllo

Se hai personalizzato l'installazione precedente, hai bisogno delle stesse personalizzazioni per l'upgrade di Anthos 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. Puoi specificare il file di overlay utilizzando l'opzione --custom_overlay con il nome file quando esegui asmcli.

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

Il pacchetto anthos-service-mesh in GitHub contiene molti file di overlay. Questi file contengono personalizzazioni comuni della configurazione predefinita. Puoi utilizzare questi file così come sono o apportarvi modifiche aggiuntive, se necessario. Alcuni file sono necessari per abilitare le funzionalità facoltative di Anthos Service Mesh. Il pacchetto anthos-service-mesh viene scaricato quando esegui asmcli per convalidare il progetto e il cluster.

Quando installi Anthos 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 recupera il file da GitHub. In caso contrario, puoi apportare modifiche al file dell'overlay e poi utilizzare l'opzione --custom_overlay per passarlo a asmcli.

Scegli un'autorità di certificazione

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

Se la tua attuale installazione di Anthos Service Mesh utilizza l'autorità di certificazione Anthos Service Mesh (Mesh CA) come autorità di certificazione (CA) per rilasciare certificati mTLS (mutual TLS), ti consigliamo di continuare a utilizzare Mesh CA per i seguenti motivi:

• Mesh CA è un servizio altamente affidabile e scalabile, ottimizzato per carichi di lavoro con scalabilità dinamica su Google Cloud.
• Con Mesh CA, Google gestisce la sicurezza e la disponibilità del backend della CA.
• Mesh CA consente di fare affidamento su un'unica radice di attendibilità tra i cluster.

Se la tua attuale installazione di Anthos Service Mesh utilizza Istio CA (precedentemente nota come "Citadel"), puoi passare a Mesh CA quando esegui l'upgrade, ma devi pianificare il tempo di inattività. Durante l'upgrade, il traffico mTLS viene interrotto fino a quando tutti i carichi di lavoro non vengono passati all'utilizzo del nuovo piano di controllo con Mesh CA.

Nota sulla piattaforma: CA Service è supportato solo sulle seguenti piattaforme: cluster GKE su Google Cloud, GKE su VMware e GDCV per Bare Metal. Se esegui asmcli install e specifichi --ca gcp_cas su altre piattaforme, l'installazione sembra riuscita, ma i carichi di lavoro non verranno avviati.

I certificati di Mesh CA includono i seguenti dati sui servizi dell'applicazione:

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

Importante: i certificati emessi da Mesh CA devono essere utilizzati solo per consentire 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 durante le comunicazioni all'esterno del tuo mesh di servizi.

Identificazione della CA

Quando esegui asmcli install per eseguire l'upgrade, specifichi la CA che asmcli deve abilitare sul nuovo piano di controllo.

La modifica delle CA causa tempi di inattività quando esegui il deployment dei carichi di lavoro sul nuovo piano di controllo. Se non puoi pianificare il tempo di inattività, assicurati di specificare la stessa CA per il nuovo piano di controllo utilizzato dal piano di controllo precedente. Se non sai quale CA è abilitata sulla tua rete mesh, esegui questi 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 comando seguente:

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

   Se Mesh CA è abilitato nello spazio dei nomi, vedrai il seguente output:

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

Prepara la configurazione del gateway

Anthos Service Mesh ti offre la possibilità di eseguire il deployment e gestire gateway come parte del tuo mesh di servizi. Un gateway descrive un bilanciatore del carico che opera sul perimetro della rete mesh che riceve connessioni HTTP/TCP in entrata o in uscita. I gateway sono proxy Envoy che ti forniscono un controllo granulare sul traffico in entrata e in uscita dal mesh.

Per impostazione predefinita, asmcli non installa istio-ingressgateway. Ti consigliamo di eseguire il deployment e la gestione del piano di controllo e dei gateway separatamente. Per ulteriori informazioni, consulta Installazione e upgrade dei gateway. Se devi installare l'oggetto predefinito istio-ingressgateway con il piano di controllo nel cluster, includi l'argomento --option legacy-default-ingressgateway.

Eseguire l'upgrade della piattaforma (facoltativo)

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

Che cosa succede dopo?

• Installa strumenti dipendenti e convalida i cluster