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 l'etichetta revision, che funge da identificatore per
piani di controllo.
Per eseguire la migrazione dei carichi di lavoro al nuovo piano di controllo:
Imposta l'etichetta
revisiondel nuovo piano di controllo su uno degli spazi dei nomi.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.
Monitora l'effetto dell'upgrade sui carichi di lavoro. Se necessario, per testare la tua applicazione, ripeti i passaggi precedenti.
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 il vecchio. Per la procedura dettagliata, vedi Passa al nuovo piano di controllo.
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
un file YAML IstioOperator, chiamato file overlay. Devi specificare
overlay file utilizzando l'opzione --custom_overlay con il nome file quando
esegui asmcli.
La
directory asmcli
in GitHub contiene molti file overlay. Questi file contengono personalizzazioni comuni
alla configurazione predefinita. Puoi utilizzare questi file così come sono o apportare modifiche aggiuntive in base alle tue esigenze. Alcuni file sono necessari
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 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. 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 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 (in precedenza "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é non viene eseguito il passaggio a tutti i carichi di lavoro che utilizzano il nuovo piano di controllo con la CA 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 dell'account di servizio GKE
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 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. Se non sai con certezza quale CA è abilitata nel tuo mesh, esegui i seguenti 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 pod in il seguente comando: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, 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 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 Envoy che forniscono un controllo granulare sul traffico in entrata e escono 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.