Panoramica dell'upgrade

Questa pagina fornisce una panoramica della procedura di upgrade e informazioni sull'eventuale discrepanza tra le versioni per Google Distributed Cloud (solo software) per i cluster VMware. Queste informazioni 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.

Questa pagina è rivolta agli amministratori IT e agli operatori che gestiscono il ciclo di vita dell'infrastruttura tecnologica di base. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti, consulta Ruoli e attività comuni degli utenti di GKE Enterprise. Google Cloud

Regole Verson

Le regole per gli upgrade dipendono dalla versione secondaria del cluster.

  • Per le versioni 1.30 e precedenti, la versione secondaria del cluster utente deve essere maggiore o uguale alla versione secondaria del cluster di amministrazione. La versione del patch non è importante. Ad esempio, se un cluster utente è alla versione 1.30.1, è possibile eseguire l'upgrade del cluster di amministrazione a una versione patch successiva, ad esempio 1.30.3.

  • Per le versioni 1.31 e successive, la versione del cluster di amministrazione, inclusa la versione della patch, deve essere maggiore o uguale alla versione del cluster utente. Ad esempio, se un cluster di amministrazione è alla versione 1.31.1, la versione massima a cui è possibile eseguire l'upgrade del cluster utente è 1.31.1.

Quando vuoi eseguire l'upgrade dei cluster alla versione 1.31, devi prima eseguire l'upgrade di tutti i cluster alla versione 1.30. Dopo che tutti i cluster sono alla versione 1.30, esegui l'upgrade del cluster di amministrazione alla versione 1.31. Dopodiché, puoi eseguire l'upgrade dei cluster utente alla stessa versione della patch 1.31 del cluster di amministrazione.

Regole delle versioni per gkectl

La versione di gkectl che puoi utilizzare per l'upgrade dipende dalla versione del cluster di destinazione (ovvero la versione del cluster a cui esegui l'upgrade). In genere, utilizzi la stessa versione di gkectl della versione di destinazione del cluster. Durante l'upgrade vengono applicate le seguenti regole:

  • La versione gkectl non può essere una versione secondaria precedente alla versione secondaria del cluster di destinazione. Ad esempio, se esegui l'upgrade di un cluster 1.29 a 1.30, non puoi utilizzare gkectl 1.29 perché è precedente alla versione del cluster di destinazione. Le versioni con patch non contano. Ad esempio, puoi utilizzare la gkectl versione 1.29.0-gke.1456 per eseguire l'upgrade a una versione patch successiva, ad esempio 1.29.1000-gke.94.

  • La versione gkectl non può essere superiore di più di due versioni minori rispetto alla versione corrente del cluster. Ad esempio, se stai eseguendo l'upgrade di un cluster 1.28 alla versione 1.29, la versione gkectl può essere 1.29 o 1.30. Tuttavia, non puoi utilizzare la versione 1.31 di gkectl perché è tre versioni secondarie successive alla versione del cluster.

Se necessario, consulta la sezione Scaricare gkectl per ottenere una versione supportata di gkectl.

Per informazioni sugli scostamenti delle versioni tra i cluster di amministrazione e utente, consulta la sezione Scostamento della versione di questo documento.

Sequenza di upgrade

La sequenza in cui esegui l'upgrade dei cluster di amministrazione e utente dipende dalla versione del cluster a cui esegui l'upgrade, indicata come versione di destinazione:

1.31 e successive

Se la versione di destinazione è 1.31 o successiva, devi eseguire l'upgrade del cluster di amministrazione prima di eseguire l'upgrade dei cluster utente gestiti dal cluster di amministrazione. I seguenti passaggi descrivono la sequenza 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 di utenti.

  2. Esegui l'upgrade del cluster di amministrazione.

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

    • Se vuoi, puoi eseguire l'upgrade del piano di controllo di un cluster utente separatamente dai pool di nodi del cluster utente. Per ulteriori informazioni, consulta Eseguire l'upgrade dei node pool.

      Non disponibile per i cluster avanzati.

    • Se vuoi, puoi saltare una versione secondaria durante l'upgrade dei pool di nodi. Per maggiori informazioni, consulta Ignorare una versione durante l'upgrade dei pool di nodi.

      Non disponibile per i cluster avanzati.

    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.

1,30 o meno

Se la versione di destinazione è 1.30 o precedente, devi eseguire l'upgrade di tutti i cluster utente prima di eseguire l'upgrade del cluster di amministrazione che li gestisce.

  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 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 superiore a quella di nessuno 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 e le regole delle versioni per gli upgrade sono cambiati nella versione 1.28 e quelle successive. Per ulteriori informazioni, consulta la sezione Spostamento della versione in questo documento.

Upgrade dei cluster di amministrazione

1.31 e successive

Se la versione di destinazione è 1.31 o successiva, devi prima eseguire l'upgrade del cluster di amministrazione e poi dei cluster utente.

Puoi utilizzare gkectl o l'interfaccia a riga di comando gcloud per eseguire l'upgrade dei cluster di amministrazione.

1,30 o meno

Se la versione di destinazione è 1.30 o precedente, esegui prima l'upgrade di tutti i cluster utente, poi esegui l'upgrade del cluster di amministrazione. Puoi eseguire l'upgrade del cluster di amministrazione quando il piano di controllo e i pool di nodi su tutti i cluster utente sono almeno di una versione secondaria superiore rispetto al 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.

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 una breve finestra di manutenzione, potresti 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 piano di controllo è alla versione 1.28 o successiva, puoi saltare una versione secondaria durante l'upgrade dei node pool.

Non disponibile nei cluster avanzati.

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.

    Se hai attivato i cluster avanzati, devi utilizzare gkectl per l'upgrade. I client dell'API GKE On-Prem non sono supportati nei cluster avanzati.

  • 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' Google Cloud infrastruttura.

    • 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 a riga di comando gcloud 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.

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.31 e successive

Nella versione 1.31 e successive, il cluster di amministrazione può essere fino a 2 versioni secondarie superiore ai cluster utente. Ad esempio, se un cluster di amministrazione è alla versione 1.31, i cluster utente gestiti da quel cluster di amministrazione possono essere alla versione 1.29, 1.30 o 1.31.

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

1,29 - 1,30

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.29, i cluster utente gestiti da quel cluster di amministrazione possono essere alla versione 1.29, 1.30 o 1.31.

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 alla versione secondaria successiva fino a quando non viene eseguito l'upgrade del cluster di amministrazione almeno di una versione secondaria.1.n+2

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.31, i pool di nodi nel cluster possono essere 1.29, 1.30 o 1.31.

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 alla versione 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.31.0 a 1.31.1 o da 1.30.1 a 1.31.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.29.x alla versione 1.31.x, non puoi eseguire l'upgrade direttamente. Devi prima eseguire l'upgrade da 1.29.x a 1.30.x, quindi eseguire l'upgrade a 1.31.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 node pool

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.31 e un pool di nodi è alla versione 1.29, puoi saltare la versione 1.30 ed eseguire l'upgrade del pool di nodi direttamente alla versione 1.31. 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.

Non disponibile nei cluster avanzati.

Upgrade delle versioni patch

Ti consigliamo di eseguire l'upgrade alla versione più recente della patch ogni volta che è possibile per assicurarti che i tuoi cluster dispongano delle correzioni di sicurezza più recenti. Le versioni con patch non influiscono sullo skew 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.31.X alla versione 1.31.Y purché Y sia maggiore di X. Ad esempio, puoi eseguire l'upgrade da 1.30.0 a 1.30.1 e da 1.30.1 a 1.30.3.

Passaggi successivi

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