Pianifica un upgrade
Questa pagina fornisce informazioni per aiutarti a pianificare un upgrade di Cloud Service Mesh. Ti consigliamo di consultare anche 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 control plane. Con un upgrade canary, asmcli installa una nuova revisione del control plane insieme a quello precedente. Il control plane precedente e quello nuovo sono contrassegnati con un'etichetta revision che funge da identificatore per i control plane.
Per eseguire la migrazione dei workload al nuovo control plane:
Imposta l'etichetta
revisiondel nuovo control plane su uno dei tuoi spazi dei nomi.Esegui un riavvio in sequenza. Il riavvio reinserisce i proxy sidecar nei pod in modo che utilizzino il nuovo control plane.
Monitora l'effetto dell'upgrade sui workload. Se necessario, ripeti i passaggi precedenti per testare l'applicazione.
Dopo aver testato l'applicazione, puoi eseguire la migrazione di tutto il traffico al nuovo control plane o eseguire il rollback al control plane precedente.
Un upgrade canary è molto più sicuro di un upgrade in loco, in cui il nuovo control plane sostituisce quello precedente. Per la procedura dettagliata, vedi Passa al nuovo control plane.
Personalizza il control plane
Se hai personalizzato l'installazione precedente, devi mantenere 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 di overlay. Per specificare il file di overlay, utilizza l'opzione --custom_overlay con il nome file quando esegui asmcli.
La
directory asmcli
in GitHub contiene molti file di overlay che contengono personalizzazioni comuni
alla configurazione predefinita. Puoi utilizzare questi file così come sono oppure apportare ulteriori modifiche in base alle tue esigenze. Alcuni file sono necessari 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 di 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 per te. In caso contrario, puoi apportare modifiche al file di overlay e quindi utilizzare l'opzione --custom_overlay per passarlo a asmcli.
Scegli un'autorità di certificazione
Se l'installazione attuale di Cloud Service Mesh utilizza l'autorità di certificazione (CA) Cloud Service Mesh 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 altamente affidabile e scalabile ottimizzato per i workload scalati dinamicamente.
- Con l'autorità di certificazione Cloud Service Mesh, Google gestisce la sicurezza e la disponibilità del backend CA.
- L'autorità di certificazione Cloud Service Mesh ti consente di affidarti a una singola radice di attendibilità in tutti i cluster.
Se l'installazione attuale di Cloud Service Mesh utilizza Istio CA (precedentemente chiamata "Citadel"), puoi passare all'autorità di certificazione Cloud Service Mesh durante l'upgrade, ma devi pianificare un periodo di inattività. Durante l'upgrade, il traffico mTLS viene interrotto finché tutti i workload non passano all'utilizzo del nuovo control plane con l'autorità di certificazione Cloud Service Mesh.
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 del service account GKE
Identifica la CA
Quando esegui asmcli install per l'upgrade, specifichi la CA che asmcli deve abilitare sul nuovo control plane.
La modifica delle CA causa tempi di inattività quando esegui il deployment dei workload nel nuovo control plane. Se non puoi pianificare tempi di inattività, assicurati di specificare la stessa CA per il nuovo control plane utilizzato dal control plane precedente. Se non sai quale CA è abilitata nel tuo 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 l'autorità di certificazione Cloud Service Mesh è abilitata nello spazio dei nomi, 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 dei gateway e di gestirli all'interno del mesh di servizi. Un gateway descrive un bilanciatore del carico che opera al limite del mesh e riceve connessioni HTTP/TCP in entrata o in uscita. I gateway sono proxy Envoy che 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 separatamente il control plane e i gateway. Per ulteriori informazioni, consulta Installazione e upgrade dei gateway.
Esegui l'upgrade della piattaforma (facoltativo)
Come best practice, devi eseguire l'upgrade di Cloud Service Mesh all'ultima versione supportata che supporta anche la tua piattaforma attuale. Poi, esegui l'upgrade del tuo 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.