Panoramica dell'upgrade

Questa pagina fornisce una panoramica della procedura di upgrade e informazioni sull'eventuale sfasamento 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, incluso un elenco di controllo per aiutarti a pianificare l'upgrade, consulta Best practice per l'upgrade.

Sequenza di upgrade

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

  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 di utenti.

  2. Esegui l'upgrade dei cluster utente uno alla volta.

    • Nella versione 1.14 e successive, se vuoi, puoi eseguire l'upgrade del piano di controllo di un cluster utente separatamente dai pool di nodi del cluster utente.

    • Nella versione 1.16 e successive, puoi eventualmente saltare una versione minore durante l'upgrade dei node pool. Per ulteriori informazioni, consulta Ignorare una versione durante l'upgrade dei pool di nodi.

    Dopo che tutti i pool di nodi di un cluster utente sono nella stessa versione del piano di controllo del cluster utente, l'upgrade del cluster utente è completo.

    Un cluster di amministrazione non può avere una versione secondaria più recente rispetto a quella dei cluster utente che gestisce. Se uno dei tuoi cluster utente è alla stessa versione secondaria del cluster di amministrazione, non puoi eseguire l'upgrade del cluster di amministrazione.

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

Lo skew delle versioni e le regole delle versioni per gli upgrade sono cambiati nella versione 1.28 e successive. Per ulteriori informazioni, vedi 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 insieme (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 nella versione corrente. L'approccio che scegli dipende da diversi fattori, ad esempio:

  • 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, ti consigliamo di mantenere la procedura 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à (HA), l'upgrade del piano di controllo non dovrebbe interrompere i workload degli utenti. Quando il control plane è alla versione 1.28 o successiva, puoi saltare una versione secondaria durante l'upgrade dei node pool.

L'upgrade dei node pool separatamente dal piano di controllo è supportato per i node pool Ubuntu e COS, ma non per i node pool Windows.

Eseguire l'upgrade selettivo dei pool di nodi

In alcuni casi, potresti voler eseguire l'upgrade di alcuni, ma non di tutti i pool di nodi in un cluster di utenti. Ad esempio, dopo aver eseguito l'upgrade del piano di controllo, puoi eseguire l'upgrade di un pool di nodi con traffico ridotto o che esegue i carichi di lavoro meno critici. Una volta accertato che i tuoi workload funzionano correttamente sulla nuova versione, puoi eseguire l'upgrade di altri node pool, fino a quando non avrai eseguito l'upgrade di tutti i node pool. Per ulteriori informazioni, consulta Eseguire l'upgrade dei node pool.

Saltare una versione secondaria durante l'upgrade dei pool di nodi

Se i tuoi cluster sono alla versione 1.16 o successiva, puoi saltare una versione minore durante l'upgrade dei node pool. L'esecuzione di un upgrade con salto di versione dimezza il tempo necessario per eseguire l'upgrade sequenziale dei pool di nodi di due versioni. Inoltre, gli upgrade che ignorano le versioni ti consentono di aumentare il tempo tra gli upgrade necessari per continuare a utilizzare una versione supportata. La riduzione del numero di upgrade riduce le interruzioni del workload e i tempi di verifica. Per ulteriori informazioni, consulta Ignorare una versione durante l'upgrade dei 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 di utenti.

  • 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 node pool. Specifica questo file sulla riga di comando per gkectl.

  • La console Google Cloud, Google Cloud CLI o Terraform, che puoi eseguire da qualsiasi computer che dispone di connettività di rete 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 di utenti utilizzando Terraform.

    • Se il cluster utente è stato creato utilizzando gkectl, deve essere registrato nell'API GKE On-Prem per utilizzare la console o l'interfaccia alla gcloud CLI per l'upgrade. In 1.16 e versioni successive, i cluster creati utilizzando gkectl sono registrati nell'API GKE On-Prem per impostazione predefinita. Per i cluster creati in versioni precedenti, puoi registrarli dopo la creazione.

      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 intendi eseguire l'upgrade dei cluster di utenti:

  • 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 node pool. La console non supporta l'upgrade solo del piano di controllo.

  • Eseguire 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 control plane e di uno o più node pool contemporaneamente: solo gkectl supporta questo caso d'uso.

Upgrade dei cluster di amministrazione

Se il piano di controllo e i pool di nodi su tutti i cluster utente sono di almeno una versione secondaria successivi rispetto al cluster di amministrazione, puoi eseguire l'upgrade facoltativo del cluster di amministrazione. Solo gkectl supporta l'upgrade dei cluster di amministrazione. I client dell'API GKE On-Prem non supportano l'upgrade dei cluster di amministrazione.

Disallineamento delle versioni

Lo skew 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 del piano di controllo e dei pool di nodi nel loro insieme.

Inoltre, lo skew delle versioni è la differenza nelle versioni minori tra il piano di controllo di un cluster utente e i pool di nodi del cluster utente.

In un ambiente multi-cluster, comprendere il disallineamento delle versioni supportato e le regole per le versioni per gli upgrade potrebbe aiutarti a pianificare l'ordine in cui eseguire l'upgrade dei cluster.

Differenza di versione dei cluster di amministrazione e utente

Un cluster di amministrazione può gestire cluster utente con versioni diverse. Questa funzionalità ti consente di eseguire l'upgrade di un parco di cluster utente in base a una pianificazione adatta alla tua organizzazione.

1.29 e successive

Lo skew 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 essere fino a 2 versioni secondarie superiori rispetto al cluster di amministrazione. Ad esempio, se un cluster di amministrazione è alla versione 1.28, i cluster utente gestiti da quel cluster di amministrazione possono essere alla versione 1.28, 1.29 o 1.30.

In termini generali, 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 a 1.n+2 alla versione secondaria successiva finché non viene eseguito l'upgrade del cluster di amministrazione almeno a una versione secondaria.

1,28

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

1.16 e versioni precedenti

Nella versione 1.16 e precedenti, i cluster utente possono essere superiori di una sola versione secondaria rispetto al cluster di amministrazione. Ad esempio, se un cluster di amministrazione è alla versione 1.15, i cluster utente gestiti da quel cluster di amministrazione possono essere alla versione 1.15 o 1.16.

In termini generali, se 1.n è la versione secondaria del cluster di amministrazione, i cluster utente possono essere in 1.n o 1.n+1. Non è possibile eseguire l'upgrade dei cluster utente alla versione secondaria successiva finché il cluster di amministrazione non è alla stessa versione secondaria del cluster utente.

Mancata corrispondenza delle versioni del piano di controllo e del pool di nodi del cluster utente

1.29 e successive

Lo skew 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ò essere fino a 2 versioni secondarie superiori rispetto ai pool di nodi del cluster. Ad esempio, se il piano di controllo di un cluster utente è 1.30, i pool di nodi nel cluster possono essere 1.28, 1.29 o 1.30.

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

1,28

Nella versione 1.28, il piano di controllo di un cluster utente può essere fino a 2 versioni secondarie superiori rispetto ai pool di nodi del cluster. Ad esempio, se il control plane di un cluster utente è 1.28, i pool di nodi nel cluster possono essere 1.15, 1.16 o 1.28. Non è possibile eseguire l'upgrade dei piani di controllo dei cluster utente alla versione 1.29 finché tutti i pool di nodi non sono in 1.28 o 1.16.

1.16 e versioni precedenti

Nella versione 1.16 e precedenti, il piano di controllo di un cluster utente può essere superiore di una sola versione secondaria rispetto ai pool di nodi del cluster. Ad esempio, se il piano di controllo di un cluster utente è 1.16, i pool di nodi del cluster possono essere 1.15 o 1.16.

In termini generali, se 1.n è la versione minore di un piano di controllo del cluster utente, i pool di nodi nel cluster possono essere in 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 sono alla stessa versione secondaria del control plane.

Regole delle versioni per gli upgrade del piano di controllo del cluster di amministrazione e del cluster utente

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

Se stai eseguendo 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. Il salto di una versione secondaria non è supportato. Ad esempio, se vuoi eseguire l'upgrade dalla versione 1.28.x alla versione 1.30.x, non puoi eseguire l'upgrade direttamente. Devi prima eseguire l'upgrade da 1.28.x a 1.29.x, quindi eseguire l'upgrade a 1.30.x.

In termini generali, sono supportati solo gli upgrade da 1.n a 1.n+1 per gli upgrade dei cluster amministratore e dei control plane dei cluster utente.

Regole delle versioni per gli upgrade dei pool di nodi

Nella versione 1.28 e successive, puoi saltare una versione secondaria durante l'upgrade di un node pool in un cluster utente. Ad esempio, se un piano di controllo del cluster utente è alla versione 1.30 e un pool di nodi è alla versione 1.28, puoi saltare la versione 1.29 ed eseguire l'upgrade del pool di nodi direttamente alla versione 1.30. Le versioni delle patch non influiscono sulle regole delle versioni di upgrade.

In termini generali, se il piano di controllo di un cluster utente è in 1.n, puoi eseguire l'upgrade dei node pool in 1.n-2 direttamente a 1.n. Se salti una versione minore durante l'upgrade dei pool di nodi, il tempo necessario potrebbe essere inferiore rispetto a quello necessario per eseguire due upgrade dei pool di nodi (da 1.n-2 a 1.n-1 e poi a 1.n). Questo è un altro motivo per cui potresti preferire eseguire l'upgrade del piano di controllo di un cluster utente separatamente dai pool di nodi in esecuzione nel cluster utente.

Upgrade delle versioni patch

Ti consigliamo di eseguire l'upgrade alla versione più recente della patch, se possibile, per assicurarti che i tuoi cluster dispongano delle correzioni di sicurezza più recenti. Le versioni delle patch non influiscono sullo sfasamento delle versioni e sulle regole di upgrade. Per una determinata versione minore, puoi eseguire l'upgrade a qualsiasi versione della patch successiva. In altre parole, puoi eseguire l'upgrade di un cluster di versioni 1.30.X alla versione 1.30.Y purché Y sia maggiore di X. Ad esempio, puoi eseguire l'upgrade da 1.29.0 a 1.29.1 e da 1.29.1 a 1.29.3.

Passaggi successivi

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