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.
Quindi, eseguirai la migrazione dei carichi di lavoro al nuovo piano di controllo impostando la stessa etichetta revision negli spazi dei nomi ed eseguendo un riavvio in sequenza. Il riavvio reinietta i proxy sidecar nei pod in modo che i proxy utilizzino il nuovo piano di controllo. Con questo approccio, puoi monitorare l'effetto dell'upgrade
su una piccola percentuale dei tuoi carichi di lavoro. 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. Questo approccio è molto più sicuro rispetto a un upgrade in loco in cui il nuovo piano di controllo sostituisce quello precedente.
Per questa anteprima iniziale, asmcli installa l'elemento istio-ingressgateway con
un'etichetta di revisione per impostazione predefinita. In questo modo puoi eseguire un upgrade canary di istio-ingressgateway e del 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 lo script.
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
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.
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
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:
Recupera un elenco di pod da uno dei tuoi spazi dei nomi:
kubectl get pods -n NAMESPACESostituisci
POD_NAMEcon il nome di uno dei tuoi pod nel comando seguente:kubectl get pod POD_NAME -n NAMESPACE -o yaml | grep CA_ADDR -A 1Se Mesh CA è abilitato nello spazio dei nomi, vedi il seguente output:
- name: CA_ADDR value: meshca.googleapis.com:443Prepara 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.