Panoramica dell'upgrade

Questa pagina fornisce una panoramica della procedura di upgrade e informazioni sull'inclinazione della versione 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, inclusa una lista 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 sottostante. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti, consulta Ruoli utente e attività comuni di GKE. Google Cloud

Differenze tra i cluster avanzati

Quando sono abilitati i cluster avanzati, ci sono alcune differenze con gli upgrade, in particolare nell'anteprima dei cluster avanzati nella versione 1.31. Per visualizzare le differenze dell'upgrade, cerca la parola advanced in questo documento. Per una tabella di tutte le differenze, consulta Differenze durante l'esecuzione di cluster avanzati.

Regole di versione

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 a quella del cluster di amministrazione. La versione patch non è importante. Ad esempio, se un cluster utente ha la versione 1.30.1, il cluster di amministrazione può essere aggiornato a una versione patch superiore, 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 ha la versione 1.31.1, la versione più recente a cui è possibile eseguire l'upgrade del cluster utente è la 1.31.1.

Quando vuoi eseguire l'upgrade dei cluster alla versione 1.31, devi prima portare 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 patch 1.31 del cluster di amministrazione.

Regole di versione 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 stai eseguendo 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 inferiore a quella del cluster secondario di destinazione. Ad esempio, se esegui l'upgrade di un cluster 1.29 alla versione 1.30, non puoi utilizzare gkectl 1.29 perché è inferiore alla versione del cluster di destinazione. Le versioni patch non sono importanti. Ad esempio, puoi utilizzare 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 di gkectl non può essere superiore di più di due versioni secondarie rispetto alla versione attuale del cluster. Ad esempio, se esegui l'upgrade di un cluster 1.28 alla versione 1.29, la versione di gkectl può essere 1.29 o 1.30. Tuttavia, non puoi utilizzare la versione 1.31 perché è tre versioni secondarie successive alla versione del cluster.gkectl

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

Per informazioni sulle differenze di versione tra i cluster di amministrazione e utente, consulta la sezione Differenza di versione in 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, denominata versione di destinazione:

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 (il che significa che puoi eseguire l'upgrade del piano di controllo e di tutti i node pool nel cluster) oppure puoi eseguire l'upgrade del piano di controllo del cluster utente e lasciare i node pool alla versione attuale. L'approccio che scegli 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 semplificare il processo ed eseguire l'upgrade sia del control plane 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 control plane perché richiede meno tempo e, con i control plane ad alta disponibilità, l'upgrade del control plane non dovrebbe interrompere i workload utente. Quando il control plane è alla versione 1.28 o successive, puoi saltare una versione secondaria durante l'upgrade dei node pool.

• Versione 1.31: non disponibile sui cluster avanzati.
• Versione 1.32 e successive: disponibile sui cluster avanzati.

Esegui l'upgrade selettivo dei node pool

In determinate situazioni, potresti voler eseguire l'upgrade di alcuni pool di nodi in un cluster utente, ma non di tutti. Ad esempio, dopo aver eseguito l'upgrade del control plane, puoi 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 tuoi workload funzionino correttamente nella nuova versione, puoi eseguire l'upgrade di altri node pool, finché non saranno tutti aggiornati. Per ulteriori informazioni, vedi Eseguire l'upgrade dei node pool.

Ignora una versione secondaria durante l'upgrade dei node pool

Se i tuoi cluster hanno la versione 1.16 o successive, puoi saltare una versione secondaria quando esegui 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 con salto di versione ti consentono di aumentare il tempo tra gli upgrade necessari per rimanere su una versione supportata. La riduzione del numero di upgrade riduce le interruzioni del workload e il tempo di verifica. Per maggiori informazioni, consulta Ignorare una versione durante l'upgrade dei node pool.

Scegliere 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, modifichi il file di configurazione del cluster utente per impostare la versione di destinazione per il control plane del cluster e, facoltativamente, per i node pool. Specifichi questo file sulla riga di comando per gkectl.

  Se hai abilitato il cluster avanzato, devi utilizzare gkectl per l'upgrade. I client API GKE On-Prem non sono supportati sui cluster avanzati.

• 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, 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, deve essere registrato nell'API GKE On-Prem per utilizzare la console o gcloud CLI per l'upgrade. Nelle versioni 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 registrarli dopo la creazione.

    Anche se decidi di utilizzare gkectl per l'upgrade, potresti voler 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 dell'intero cluster: puoi utilizzare gkectl, la console Google Cloud , Google Cloud CLI o Terraform per eseguire l'upgrade di un cluster utente (il control plane insieme a tutti i pool di nodi).

• Esegui l'upgrade solo del control plane: puoi utilizzare gkectl, gcloud CLI o Terraform per eseguire l'upgrade del control plane di un cluster utente separatamente dai node pool. La console non supporta l'upgrade del solo control plane.

• Esegui l'upgrade selettivo dei node pool dopo l'upgrade del control plane: puoi utilizzare gkectl, gcloud CLI o Terraform per eseguire l'upgrade di node pool specifici dopo l'upgrade del control plane.

• Esegui l'upgrade del control plane e di uno o più node pool contemporaneamente: solo gkectl supporta questo caso d'uso.

Disallineamento delle versioni

La differenza di versione è la differenza tra le versioni secondarie di un cluster di amministrazione e i relativi cluster utente gestiti. Nelle sezioni seguenti, la versione del cluster utente si riferisce alla versione del control plane e dei pool di nodi nel loro complesso.

Inoltre, la distorsione della versione è la differenza tra le versioni secondarie del piano di controllo di un cluster utente e i pool di nodi del cluster utente.

In un ambiente multicluster, comprendere le regole di disallineamento e delle versioni supportate per gli upgrade può aiutarti a pianificare l'ordine in cui eseguire l'upgrade dei cluster.

Differenza tra le versioni 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.

Disallineamento delle versioni del control plane e pool di nodi del cluster utente

Regole di versione per gli upgrade del control plane del cluster di amministrazione e del cluster utente

Le regole di versione per gli upgrade del control plane dei cluster di amministrazione e 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.32.0 a 1.32.1 o da 1.31.1 a 1.32.0. Le versioni patch non influiscono sulle regole della versione di upgrade.

Se esegui l'upgrade a una versione che non fa parte della prossima release secondaria, 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.30.x alla versione 1.32.x, non puoi eseguire l'upgrade direttamente. Devi prima eseguire l'upgrade da 1.30.x a 1.31.x, quindi eseguire l'upgrade a 1.32.x.

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

Regole di versione per gli upgrade dei pool di nodi

Nella versione 1.28 e successive, puoi saltare una versione secondaria quando esegui l'upgrade di un node pool in un cluster utente. Ad esempio, se un control plane del cluster utente è alla versione 1.32 e un pool di nodi è alla versione 1.30, puoi saltare la versione 1.31 ed eseguire l'upgrade del pool di nodi direttamente alla versione 1.32. Le versioni patch non influiscono sulle regole della versione di upgrade.

In termini generali, se un control plane del cluster utente è alla versione 1.n, puoi eseguire l'upgrade dei node pool alla versione 1.n-2 direttamente alla versione 1.n. Se salti una versione secondaria durante l'upgrade dei pool di nodi, potresti ridurre il tempo necessario rispetto all'esecuzione di due upgrade dei 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 eseguire l'upgrade del control plane di un cluster utente separatamente dai pool di nodi in esecuzione sul cluster utente.

• Versione 1.31: non disponibile sui cluster avanzati.
• Versione 1.32 e successive: disponibile sui cluster avanzati.

Upgrade della versione patch

Ti consigliamo di eseguire l'upgrade alla versione patch più recente ogni volta che è possibile per assicurarti che i tuoi cluster dispongano delle correzioni di sicurezza più recenti. Le versioni delle patch non influiscono sulle regole di upgrade e sulla distorsione della versione. Per una determinata versione secondaria, puoi eseguire l'upgrade a qualsiasi versione patch successiva. ovvero puoi eseguire l'upgrade di un cluster 1.32.X alla versione 1.32.Y, purché Y sia maggiore di X. Ad esempio, puoi eseguire l'upgrade da 1.31.0 a 1.31.1 e da 1.31.1 a 1.31.3.

Passaggi successivi

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