Panoramica dell'upgrade

Questa pagina fornisce una panoramica del processo di upgrade e informazioni sul disallineamento delle versioni, utili per pianificare l'ordine di 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 Best practice per l'upgrade.

Sequenza di upgrade

Gli upgrade in loco a partire dalla versione 1.7 devono sempre seguire una sequenza specifica di upgrade:

  1. Esegui l'upgrade della workstation di amministrazione. Ti consigliamo di eseguire questa operazione anche se prevedi di utilizzare la console Google Cloud, Google Cloud CLI o Terraform per eseguire l'upgrade dei cluster utente.

  2. Esegui l'upgrade dei cluster utente, uno alla volta. Dalla versione 1.14 in poi, puoi facoltativamente eseguire l'upgrade del piano di controllo di un cluster utente separatamente dai pool di nodi sul cluster utente. Per informazioni sul motivo per cui potresti voler procedere, consulta Upgrade dei cluster utente.

    Quando tutti i pool di nodi in un cluster utente hanno la stessa versione del piano di controllo del cluster utente, l'upgrade del cluster utente viene completato.

    Un cluster di amministrazione non può avere una versione secondaria successiva di quella dei cluster utente che gestisce. Se uno dei cluster utente ha la stessa versione secondaria del cluster di amministrazione, non puoi eseguire l'upgrade del cluster di amministrazione.

  3. Se tutti i cluster utente hanno almeno una versione secondaria successiva rispetto al cluster di amministrazione, puoi facoltativamente eseguire l'upgrade del cluster di amministrazione.

Il disallineamento delle versioni e le regole delle versioni per gli upgrade sono cambiate nella versione 1.28 e successive. Per maggiori informazioni, consulta Disallineamento delle versioni.

Upgrade dei cluster utente

Quando esegui l'upgrade dei cluster utente, puoi scegliere di eseguire l'upgrade del cluster utente completo (ovvero 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, tra cui:

  • L'ambiente (di produzione o non di produzione) 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é richiede meno tempo e, con i piani di controllo ad alta disponibilità, l'upgrade del piano di controllo non dovrebbe interrompere i carichi di lavoro degli utenti. Se la versione del piano di controllo è 1.28 o successiva, puoi saltare una versione secondaria durante l'upgrade dei pool di nodi.

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.

Esegui l'upgrade selettivo dei pool di nodi

In determinate situazioni, potresti voler 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 con traffico scorrevole o che esegue i carichi di lavoro meno critici. Dopo aver appurato che i carichi di lavoro vengono eseguiti correttamente nella nuova versione, potresti 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

Google Distributed Cloud 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 in gkectl.

  • La console Google Cloud, Google Cloud CLI o Terraform, che puoi eseguire da qualsiasi computer dotato di connettività di rete all'API GKE On-Prem. Questi strumenti standard sono client dell'API GKE On-Prem, in esecuzione 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 l'interfaccia alla gcloud CLI per l'upgrade. Nella versione 1.16 e successive, i cluster creati utilizzando gkectl vengono registrati nell'API GKE On-Prem per impostazione predefinita. Per i cluster creati nelle versioni precedenti, puoi registrare il cluster dopo averlo creato.

      Anche se decidi di utilizzare gkectl per l'upgrade, ti consigliamo di registrare il cluster nell'API GKE On-Prem per ottenere informazioni sui cluster utilizzando la console o gcloud CLI.

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 gkectl supporta questo caso d'uso.

Upgrade dei cluster di amministrazione

Quando il piano di controllo e i pool di nodi su tutti i cluster utente sono successivi ad almeno una versione secondaria rispetto 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 si riferisce alla versione complessiva del piano di controllo e dei pool di nodi.

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.

In un ambiente multi-cluster, comprendere il disallineamento delle versioni supportato e le regole delle versioni per gli upgrade può aiutarti a pianificare l'ordine di upgrade dei cluster.

Disallineamento delle versioni dei cluster di amministrazione e degli utenti

Un cluster di amministrazione può gestire cluster utente con 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.

1,29 e successive

Il disallineamento delle versioni è lo stesso della versione 1.28. Nella versione 1.29, questa funzionalità è passata alla fase di disponibilità generale.

Nella versione 1.29 e successive, i cluster utente possono avere fino a 2 versioni secondarie superiori al cluster di amministrazione. Ad esempio, se un cluster di amministrazione si trova a 1,16, i cluster utente gestiti da quel cluster di amministrazione possono essere a 1,16, 1,28 o 1,29.

In termini generali, se 1.n è la versione secondaria del cluster di amministrazione, i cluster utente possono trovarsi all'indirizzo 1.n, 1.n+1 o 1.n+2. Non è possibile eseguire l'upgrade dei cluster utente in 1.n+2 alla versione secondaria successiva finché non viene eseguito l'upgrade del cluster di amministrazione di almeno una versione secondaria.

1,28

Nella versione 1.28, i cluster utente possono essere fino a 2 versioni secondarie superiori al loro cluster di amministrazione. Ad esempio, se un cluster di amministrazione si trova a 1,15, i cluster utente gestiti da quel cluster di amministrazione possono essere a 1,15, 1,16 o 1,28. Non è possibile eseguire l'upgrade dei cluster utente alla versione 1.28 alla versione 1.29 finché non viene eseguito l'upgrade del cluster di amministrazione ad almeno la versione 1.16.

1,16 e precedenti

Nella versione 1.16 e precedenti, i cluster utente possono avere solo una versione secondaria superiore rispetto al cluster di amministrazione. Ad esempio, se un cluster di amministrazione è a 1,15, i cluster utente gestiti da quel cluster di amministrazione possono essere a 1,15 o 1,16.

In termini generali, se 1.n è la versione secondaria del cluster di amministrazione, i cluster utente possono trovarsi all'indirizzo 1.n o 1.n+1. Non puoi eseguire l'upgrade dei cluster utente alla versione secondaria successiva finché il cluster di amministrazione non si trova alla stessa versione secondaria del cluster utente.

Disallineamento delle versioni del piano di controllo del cluster utente e del pool di nodi

1,29 e successive

Il disallineamento delle versioni è lo stesso della versione 1.28. Nella versione 1.29, questa funzionalità è passata alla fase di disponibilità generale.

Nella versione 1.29 e successive, il piano di controllo di un cluster utente può essere fino a due versioni secondarie superiori ai pool di nodi del cluster. Ad esempio, se il piano di controllo di un cluster utente è a 1,29, i pool di nodi nel cluster possono essere a 1,16, 1,28 o 1,29.

In termini generali, se 1.n è la versione secondaria di un piano di controllo del cluster utente, i pool di nodi nel cluster possono trovarsi su 1.n, 1.n-1 o 1.n-2. Non puoi eseguire l'upgrade dei piani di controllo dei cluster utente alla versione secondaria successiva finché tutti i pool di nodi non si trovano nella posizione 1.n o 1.n-1.

1,28

Nella versione 1.28, il piano di controllo di un cluster utente può includere fino a due versioni secondarie superiori ai pool di nodi nel cluster. Ad esempio, se il piano di controllo di un cluster utente è a 1,28, i pool di nodi nel cluster possono essere a 1,15, 1,16 o 1,28. Non puoi eseguire l'upgrade dei piani di controllo dei cluster utente alla versione 1.29 finché tutti i pool di nodi non saranno nella posizione 1.28 o 1.16.

1,16 e precedenti

Nella versione 1.16 e precedenti, il piano di controllo di un cluster utente può essere solo di una versione secondaria superiore rispetto ai pool di nodi del cluster. Ad esempio, se il piano di controllo di un cluster utente è impostato su 1,16, i pool di nodi nel cluster possono essere a 1,15 o 1,16.

In termini generali, se 1.n è la versione secondaria di un piano di controllo del cluster utente, i pool di nodi nel cluster possono trovarsi su 1.n o 1.n-1. Non puoi 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 di versione per gli upgrade del piano di controllo del cluster di amministrazione e del cluster utente

Le regole di versione per gli upgrade dei cluster di amministrazione e del piano di controllo dei cluster utente sono le stesse. Puoi eseguire l'upgrade direttamente a qualsiasi versione che si trova nella stessa release secondaria o nella release secondaria successiva. Ad esempio, puoi eseguire l'upgrade da 1.29.0 a 1.29.1 o da 1.28.1 a 1.29.0. Le versioni patch non influiscono sulle regole di upgrade della versione.

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 corrente e la versione secondaria. Ignorare una versione secondaria non è supportato. Ad esempio, se vuoi eseguire l'upgrade dalla versione 1.16.x alla versione 1.29.x, non puoi eseguire direttamente l'upgrade. Devi prima eseguire l'upgrade da 1.16.x a 1.28.x, quindi eseguire l'upgrade a 1.29.x.

In termini generali, sono supportati solo gli upgrade da 1.n a 1.n+1 per gli upgrade dei cluster di amministrazione e del piano di controllo del cluster utente.

Regole di versione per gli upgrade del pool di nodi

Dalla versione 1.28 in poi, puoi saltare una versione secondaria durante l'upgrade di un pool di nodi in un cluster utente. Ad esempio, se il piano di controllo di un cluster utente è a 1,29 e un pool di nodi è a 1,16, puoi saltare 1,28 ed eseguire l'upgrade del pool di nodi direttamente a 1,29. Le versioni patch non influiscono sulle regole della versione di upgrade.

In termini generali, se un piano di controllo del cluster utente si trova all'indirizzo 1.n, puoi eseguire l'upgrade dei pool di nodi che si trovano su 1.n-2 direttamente a 1.n. Ignorare una versione secondaria durante l'upgrade dei pool di nodi potrebbe ridurre il tempo necessario per eseguire due upgrade del pool di nodi (per eseguire l'upgrade da 1.n-2 a 1.n-1 e poi a 1.n). Questo è un altro motivo per cui potrebbe essere preferibile eseguire l'upgrade del piano di controllo di un cluster utente separatamente dai pool di nodi eseguiti sul cluster utente.

Upgrade delle versioni patch

Ti consigliamo di eseguire l'upgrade alla versione più recente della patch, quando possibile, per assicurarti che i cluster dispongano delle correzioni di sicurezza più recenti. Le versioni patch non influiscono sul disallineamento delle versioni e sulle regole di upgrade. Per una determinata versione secondaria, puoi eseguire l'upgrade a qualsiasi versione di patch superiore. In altre parole, puoi eseguire l'upgrade di un 1.29.X cluster della versione alla versione 1.29.Y purché Y sia superiore a X. Ad esempio, puoi eseguire l'upgrade da 1.28.0 a 1.28.1 e da 1.28.1 a 1.28.3.

Passaggi successivi

Rivedi le best practice per l'upgrade e crea un piano per l'upgrade dei cluster.