Questa pagina fornisce una panoramica del processo di upgrade e delle informazioni sul disallineamento delle versioni che dovrebbero aiutarti a pianificare l'ordine in cui esegui l'upgrade dei cluster in un ambiente multi-cluster. Per informazioni più dettagliate sulla pianificazione, incluso un elenco di controllo che ti aiuti a pianificare l'upgrade, consulta le best practice per l'upgrade.
Esegui l'upgrade della sequenza
Gli upgrade in loco dalla versione 1.7 devono sempre seguire una sequenza specifica di upgrade:
Esegui l'upgrade della workstation di amministrazione. Ti consigliamo di farlo anche se prevedi di utilizzare la console Google Cloud, Google Cloud CLI o Terraform per eseguire l'upgrade dei cluster utente.
Esegui l'upgrade dei cluster utente, uno alla volta. Dalla versione 1.14 e successive, in alternativa, puoi eseguire l'upgrade del piano di controllo di un cluster utente separatamente dai pool di nodi sul cluster utente. Per informazioni sui motivi per cui eseguire questa operazione, consulta Upgrade dei cluster utente.
Una volta che tutti i pool di nodi in un cluster utente hanno la stessa versione del piano di controllo del cluster utente, il cluster utente viene aggiornato completamente.
Un cluster di amministrazione non può trovarsi in una versione secondaria successiva a qualsiasi altro cluster utente che gestisce. Se uno dei tuoi cluster utente ha la stessa versione secondaria del cluster di amministrazione, non puoi eseguire l'upgrade del cluster di amministrazione.
Se tutti i cluster utente sono una versione secondaria successiva al cluster di amministrazione, puoi facoltativamente eseguire l'upgrade del cluster di amministrazione.
Upgrade dei cluster utente
Quando esegui l'upgrade dei cluster utente, puoi scegliere di eseguire l'upgrade del cluster utente nel suo complesso (ovvero puoi eseguire l'upgrade del piano di controllo e di tutti i pool di nodi nel cluster) oppure puoi eseguire l'upgrade del piano di controllo del cluster utente e lasciare i pool di nodi alla versione attuale. L'approccio da adottare dipende da diversi fattori, quali:
- L'ambiente (di produzione o non) in cui si trova il cluster.
- La durata del periodo di manutenzione.
- La versione del cluster utente.
Ad esempio, in un ambiente di sviluppo potresti voler mantenere il processo semplice ed eseguire l'upgrade sia del piano di controllo del cluster utente sia di tutti i pool di nodi. Tuttavia, in un ambiente di produzione con un breve periodo di manutenzione, potresti voler eseguire l'upgrade solo del piano di controllo perché questo richiede meno tempo e con piani di controllo ad alta disponibilità, l'upgrade del piano di controllo non dovrebbe interrompere i carichi di lavoro degli utenti.
L'upgrade dei pool di nodi separatamente dal piano di controllo è supportato per i pool di nodi Ubuntu e COS, ma non per i pool di nodi Windows.
Upgrade selettivo dei pool di nodi
In determinate situazioni, potrebbe essere opportuno eseguire l'upgrade di alcuni pool di nodi, ma non di tutti, in un cluster utente. Ad esempio, dopo aver eseguito l'upgrade del piano di controllo, potresti eseguire l'upgrade di un pool di nodi che ha traffico leggero o esegue i carichi di lavoro meno critici. Una volta appurato che i carichi di lavoro vengano eseguiti correttamente nella nuova versione, puoi eseguire l'upgrade di altri pool di nodi, fino a quando non verrà eseguito l'upgrade di tutti i pool di nodi.
Scegli uno strumento per eseguire l'upgrade dei cluster utente
GKE su VMware offre una scelta di strumenti per l'upgrade dei cluster utente.
Lo strumento a riga di comando
gkectl, che esegui sulla workstation di amministrazione. Prima dell'upgrade, modifica il file di configurazione del cluster utente per impostare la versione di destinazione per il piano di controllo del cluster e, facoltativamente, per i pool di nodi. Devi specificare questo file nella riga di comando digkectl.La console Google Cloud, Google Cloud CLI o Terraform, che puoi eseguire da qualsiasi computer connesso all'API GKE On-Prem. Questi strumenti standard sono client dell'API GKE On-Prem, che viene eseguita sull'infrastruttura Google Cloud.
Puoi utilizzare Terraform per l'upgrade solo se hai creato il cluster utente utilizzando Terraform.
Se il cluster utente è stato creato utilizzando
gkectl, il cluster deve essere registrato nell'API GKE On-Prem per utilizzare la console o gcloud CLI per l'upgrade. In 1.16 e versioni successive, i cluster creati utilizzandogkectlsono registrati nell'API GKE On-Prem per impostazione predefinita. Per i cluster creati nelle versioni precedenti, puoi registrare il cluster dopo che è stato creato.Anche se decidi di utilizzare
gkectlper l'upgrade, è consigliabile registrare il cluster nell'API GKE On-Prem per ottenere informazioni sui cluster utilizzando la console o l'interfaccia a riga di comando gcloud.
Lo strumento che utilizzi dipende da come prevedi di eseguire l'upgrade dei cluster utente:
Esegui l'upgrade del cluster nel suo complesso: puoi utilizzare
gkectl, la console Google Cloud, Google Cloud CLI o Terraform per eseguire l'upgrade di un cluster utente (il piano di controllo insieme a tutti i pool di nodi).Esegui l'upgrade solo del piano di controllo: puoi utilizzare
gkectl, gcloud CLI o Terraform per eseguire l'upgrade del piano di controllo di un cluster utente separatamente dai pool di nodi. La console non supporta l'upgrade solo del piano di controllo.Esegui l'upgrade selettivo dei pool di nodi dopo l'upgrade del piano di controllo: puoi utilizzare
gkectl, gcloud CLI o Terraform per eseguire l'upgrade di pool di nodi specifici dopo l'upgrade del piano di controllo.Esegui l'upgrade del piano di controllo e di uno o più pool di nodi contemporaneamente: solo
gkectlsupporta questo caso d'uso.
Upgrade del cluster di amministrazione
Se il piano di controllo e i pool di nodi su tutti i cluster utente sono di una versione secondaria successiva al cluster di amministrazione, puoi facoltativamente eseguire l'upgrade del cluster di amministrazione. Solo gkectl supporta l'upgrade dei cluster di amministrazione. I client API GKE On-Prem non supportano l'upgrade dei cluster di amministrazione.
Disallineamento delle versioni
Il disallineamento delle versioni è la differenza, nelle versioni secondarie, tra un cluster di amministrazione e i relativi cluster utente gestiti. Nelle sezioni seguenti, la versione del cluster utente fa riferimento alla versione del piano di controllo e dei pool di nodi nel complesso.
Inoltre, il disallineamento delle versioni è la differenza nelle versioni secondarie tra il piano di controllo di un cluster utente e i pool di nodi sul cluster utente.
Disallineamento delle versioni dei cluster utente e di amministratore
Un cluster di amministrazione può gestire cluster utente in versioni diverse. Questa funzionalità consente di eseguire l'upgrade di un parco risorse di cluster utente in base a una pianificazione adatta alla tua organizzazione.
Nella versione 1.16 e precedenti, i cluster utente possono avere una sola versione secondaria successivamente al relativo cluster di amministrazione. Ad esempio, se un cluster di amministrazione è impostato su 1,15, i cluster utente gestiti da quel cluster di amministrazione possono essere a 1,15 o 1,16. In generale, se 1.n è la versione secondaria del cluster di amministrazione, i cluster utente possono trovarsi a 1.n o 1.n+1.
Non è possibile eseguire l'upgrade dei cluster utente alla versione secondaria successiva finché il cluster di amministrazione non ha la stessa versione secondaria del cluster utente.
Disallineamento delle versioni del piano di controllo del cluster utente e del pool di nodi
Nella versione 1.16 e precedenti, il piano di controllo di un cluster utente può essere successivo solo di 1 versione secondaria rispetto ai pool di nodi nel cluster. Ad esempio, se il piano di controllo di un cluster utente è impostato su 1,16, i pool di nodi nel cluster possono essere 1,15 o 1,16. In generale, se 1.n è la versione secondaria del piano di controllo di un cluster utente, i pool di nodi nel cluster possono trovarsi a 1.n o 1.n-1.
Non è possibile eseguire l'upgrade dei cluster utente alla versione secondaria successiva finché tutti i pool di nodi non hanno la stessa versione secondaria del piano di controllo.
Regole della versione per gli upgrade dei cluster di amministrazione e dei cluster utente
Le regole della versione per l'upgrade di un cluster di amministrazione, di un piano di controllo del cluster utente e dei pool di nodi del cluster utente sono le stesse. Puoi eseguire direttamente l'upgrade a qualsiasi versione presente nella stessa release secondaria o nella release secondaria successiva. Ad esempio, puoi eseguire l'upgrade da 1.16.0 a 1.16.1 o da 1.15.1 a 1.16.0. Le versioni della patch non influiscono sulle regole della versione di upgrade.
Se esegui l'upgrade a una versione che non fa parte della release secondaria successiva, devi eseguire l'upgrade di una versione di ogni release secondaria tra la versione attuale e quella di destinazione. Non è possibile saltare una versione secondaria. Ad esempio, se vuoi eseguire l'upgrade dalla versione 1.14.x alla versione 1.16.x, non puoi eseguire direttamente l'upgrade. Devi prima eseguire l'upgrade da 1.14.x a 1.15.x e poi a 1.16.x.
In generale, solo gli upgrade da 1.n a 1.n+1 sono supportati per gli upgrade dei cluster di amministrazione e dei cluster utente.
Upgrade delle versioni delle patch
Ti consigliamo di eseguire l'upgrade alla versione più recente della patch quando possibile per assicurarti che i tuoi cluster dispongano delle correzioni di sicurezza più recenti. Le versioni della patch non
influiscono sulle regole di disallineamento delle versioni e di upgrade. Per una determinata versione secondaria, puoi
eseguire l'upgrade a qualsiasi versione patch superiore. In altre parole, puoi eseguire l'upgrade di un 1.16.Xcluster di versione alla versione 1.16.Y a condizione che Y sia maggiore di X. Ad esempio, puoi eseguire l'upgrade da
1.15.0 a 1.15.1 e puoi eseguire l'upgrade da
1.15.1 a 1.15.3.
Passaggi successivi
Consulta le best practice per l'upgrade e crea un piano per l'upgrade dei cluster.