Panoramica dell'upgrade

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 eseguire l'upgrade dei cluster in un ambiente multi-cluster. Per informazioni più dettagliate sulla pianificazione, compreso un elenco di controllo che ti aiuta a pianificare l'upgrade, consulta 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:

  1. 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.

  2. Esegui l'upgrade dei cluster utente, uno alla volta. Dalla versione 1.14 in poi, se vuoi, puoi eseguire l'upgrade del piano di controllo di un cluster utente separatamente dai pool di nodi nel cluster utente. Per informazioni sul motivo per cui potresti voler eseguire questa operazione, 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ò essere a una versione secondaria successiva a quella di qualsiasi 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.

  3. Quando tutti i cluster utente sono di almeno una versione secondaria successiva 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 ulteriori informazioni, consulta la sezione Disallineamento delle versioni.

Upgrade dei cluster utente

Quando esegui l'upgrade dei cluster utente, puoi scegliere di eseguire l'upgrade del cluster utente nel suo complesso (puoi quindi 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, ad esempio:

  • 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, potrebbe essere opportuno eseguire l'upgrade solo del piano di controllo, perché questo richiede meno tempo e grazie a 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 selettivamente l'upgrade dei pool di nodi

In determinate situazioni, potresti voler eseguire l'upgrade di alcuni dei 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 leggero o che esegue i carichi di lavoro meno critici. Dopo aver verificato che i carichi di lavoro vengano eseguiti correttamente nella nuova versione, puoi eseguire l'upgrade di ulteriori 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, in esecuzione 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. Puoi specificare questo file nella riga di comando per gkectl.

  • La console Google Cloud, Google Cloud CLI o Terraform, che puoi eseguire da qualsiasi computer con 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 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 registrarlo dopo che è stato 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 insieme: 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 del cluster di amministrazione

Quando il piano di controllo e i pool di nodi su tutti i cluster utente sono successivi di 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 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 nel cluster utente.

In un ambiente multi-cluster, la comprensione del disallineamento delle versioni e delle regole di versione supportate per gli upgrade può aiutarti a pianificare l'ordine in cui eseguire l'upgrade dei cluster.

Disallineamento delle versioni dei cluster di amministrazione e utente

Un cluster di amministrazione può gestire i 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 della versione è 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 due versioni secondarie superiori rispetto al cluster di amministrazione. Ad esempio, se un cluster di amministrazione è impostato su 1.16, i cluster utente gestiti da questo cluster di amministrazione possono essere a 1.16, 1.28 o 1.29.

In generale, se 1.n è la versione secondaria del cluster di amministrazione, i cluster utente possono essere in 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 avere fino a due versioni secondarie superiori al relativo cluster di amministrazione. Ad esempio, se un cluster di amministrazione è impostato sulla versione 1.15, i cluster utente gestiti da questo cluster di amministrazione possono essere 1.15, 1.16 o 1.28. Non è possibile eseguire l'upgrade dei cluster utente dalla versione 1.28 alla versione 1.29 finché non viene eseguito l'upgrade del cluster di amministrazione almeno alla versione 1.16.

1,16 e inferiore

Nella versione 1.16 e precedenti, i cluster utente possono avere solo una versione secondaria superiore al relativo cluster di amministrazione. Ad esempio, se un cluster di amministrazione è impostato su 1,15, i cluster utente gestiti da questo 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 essere su 1.n o 1.n+1. Non è possibile eseguire l'upgrade dei cluster utente alla versione secondaria successiva finché il cluster di amministrazione non si trova sulla 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 della versione è 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ò avere 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,29, i pool di nodi nel cluster possono essere a 1,16, 1,28 o 1,29.

In generale, se 1.n è la versione secondaria di un piano di controllo del cluster utente, i pool di nodi nel cluster possono essere 1.n, 1.n-1 o 1.n-2. Non è possibile eseguire l'upgrade dei piani di controllo dei cluster utente alla versione secondaria successiva finché tutti i pool di nodi non sono impostati su 1.n o 1.n-1.

1,28

Nella versione 1.28, il piano di controllo di un cluster utente può avere 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 è possibile eseguire l'upgrade dei piani di controllo dei cluster utente a 1.29 finché tutti i pool di nodi non sono impostati su 1.28 o 1.16.

1,16 e inferiore

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

In generale, se 1.n è la versione secondaria di un piano di controllo del cluster utente, i pool di nodi nel cluster possono essere 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 del piano di controllo del cluster di amministrazione e del cluster utente

Le regole della 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 sia 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 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 ignorare una versione secondaria. 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 generale, per gli upgrade dei cluster di amministrazione e del piano di controllo dei cluster utente sono supportati solo gli upgrade da 1.n a 1.n+1.

Regole di versione per gli upgrade dei pool di nodi

A partire dalla versione 1.28, puoi saltare una versione secondaria quando esegui l'upgrade di un pool di nodi in un cluster utente. Ad esempio, se il piano di controllo di un cluster utente è 1,29 e un pool di nodi è 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 generale, se il piano di controllo di un cluster utente è impostato su 1.n, puoi eseguire l'upgrade dei pool di nodi che si trovano in 1.n-2 direttamente a 1.n. Ignorare una versione secondaria quando esegui l'upgrade dei pool di nodi potrebbe ridurre il tempo rispetto all'upgrade di due 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 potresti preferire l'upgrade del piano di controllo di un cluster utente separatamente dai pool di nodi in esecuzione sul cluster utente.

Upgrade della versione 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 delle patch non influiscono sul disallineamento delle versioni e sulle regole di upgrade. Per una determinata versione secondaria, puoi eseguire l'upgrade a una versione patch successiva. In altre parole, puoi eseguire l'upgrade di un 1.29.X cluster di 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 puoi eseguire l'upgrade da 1.28.1 a 1.28.3.

Passaggi successivi

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