Panoramica dell'upgrade

Questa pagina fornisce una panoramica del processo di upgrade e del disallineamento delle versioni informazioni che dovrebbero aiutarti a 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 aiuterà 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 un upgrade specifico sequenza:

  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 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 dal nodo pool sul cluster utente. Per informazioni sul motivo per cui potresti voler eseguire questa operazione, consulta Upgrade dei cluster utente.

    Dopo che tutti i pool di nodi in un cluster utente hanno la stessa versione dell'utente di controllo del cluster, l'upgrade del cluster utente è stato completamente eseguito.

    Un cluster di amministrazione non può avere una versione secondaria successiva di quella di qualsiasi altro utente ai cluster che gestisce. Se uno qualsiasi dei tuoi cluster utente ha lo stesso secondaria come cluster di amministrazione, quindi non puoi eseguire l'upgrade in un cluster Kubernetes.

  3. Quando tutti i cluster utente hanno almeno una versione secondaria successiva alla 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 come (ovvero puoi eseguire l'upgrade del piano di controllo e di tutti i pool di nodi cluster) oppure puoi eseguire l'upgrade del piano di controllo del cluster utente pool di nodi nella versione attuale. L'approccio da adottare dipende da vari come 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, 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. Ma in un ambiente di produzione con un breve periodo di manutenzione, potresti di eseguire l'upgrade solo del piano di controllo, perché richiede meno tempo e per i piani di controllo della disponibilità (HA), l'upgrade del piano carichi di lavoro utente. Se la versione del piano di controllo è 1.28 o successive, puoi: ignora una versione secondaria quando l'upgrade dei pool di nodi.

L'upgrade dei pool di nodi separatamente dal piano di controllo è supportato per 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, ma non di tutti i nodi pool di utenti in un cluster utente. Ad esempio, dopo l'upgrade del piano di controllo, potresti eseguire l'upgrade di un pool di nodi con traffico scorrevole o che esegue carichi di lavoro con scale out impegnativi. Dopo aver convinto che i carichi di lavoro vengono eseguiti correttamente nuova versione, puoi eseguire l'upgrade di altri pool di nodi, fino a quando viene eseguito 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 utente.

  • Lo strumento a riga di comando gkectl, che esegui sulla workstation di amministrazione. Prima dell'upgrade, devi modificare il cluster utente file di configurazione per impostare la versione di destinazione per il piano di controllo del cluster e, facoltativamente, per dai pool di nodi. Devi specificare questo file nella riga di comando in gkectl.

  • La console Google Cloud, Google Cloud CLI Terraform, che puoi eseguire da qualsiasi computer con connettività di rete all'API GKE On-Prem. Questi strumenti standard sono clienti API GKE On-Prem, che viene eseguito sull'infrastruttura Google Cloud.

    • Puoi utilizzare Terraform per l'upgrade solo se hai creato tu l'utente utilizzando Terraform.

    • Se il cluster utente è stato creato utilizzando gkectl, deve essere registrati nell'API GKE On-Prem per utilizzare la console con gcloud CLI per l'upgrade. Nella versione 1.16 e successive, i cluster creati utilizzando gkectl sono registrati nell'API GKE On-Prem per impostazione predefinita. Per in cluster creati nelle versioni precedenti, puoi registrare il cluster dopo che è stato creato.

      Anche se decidi di utilizzare gkectl per l'upgrade, ti consigliamo di registra il cluster nell'API GKE On-Prem per ricevere informazioni sul utilizzando la console con 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 di un utente del piano di controllo del cluster 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: Per eseguire l'upgrade puoi utilizzare gkectl, gcloud CLI o Terraform 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 almeno uno successiva al cluster di amministrazione, puoi facoltativamente eseguire l'upgrade del cluster di amministrazione. Solo gkectl supporta l'upgrade dei cluster di amministrazione. La 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, l'utente La versione del cluster si riferisce alla versione del piano di controllo e dei pool di nodi. tutti insieme.

Inoltre, il disallineamento delle versioni è la differenza nelle versioni secondarie tra dal piano di controllo del cluster utente e dai pool di nodi sul cluster utente.

In un ambiente multi-cluster, comprendi il disallineamento delle versioni supportato e le regole della versione per gli upgrade possono aiutarti a pianificare l'ordine di upgrade cluster.

Disallineamento delle versioni dei cluster di amministrazione e degli utenti

Un cluster di amministrazione può gestire cluster utente con versioni diverse. Questo consente di eseguire l'upgrade di un parco risorse di cluster utente in base a una pianificazione che funzioni per la tua organizzazione.

1,29 e successive

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

Nella versione 1.29 e successive, i cluster utente possono includere fino a 2 versioni secondarie superiore rispetto al relativo cluster di amministrazione. Ad esempio, se un cluster di amministrazione si trova 1.28, i cluster utente gestiti da quel cluster di amministrazione possono trovarsi 1,28, 1,29 o 1,30.

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

1,28

Nella versione 1.28, i cluster utente possono essere fino a 2 versioni secondarie superiori a il proprio cluster di amministrazione. Ad esempio, se un cluster di amministrazione si trova alla versione 1.15, i cluster gestiti da quel cluster di amministrazione possono essere 1.15, 1.16 o 1.28. Utente non è possibile eseguire l'upgrade dei cluster alla versione 1.28 alla versione 1.29 finché il cluster di amministrazione aggiornato alla versione 1.16.

1,16 e precedenti

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

In termini generali, se 1.n è la versione secondaria del cluster di amministrazione, l'utente i cluster possono trovarsi su 1.n o 1.n+1. Non è possibile eseguire l'upgrade dei cluster utente successiva finché il cluster di amministrazione non raggiunge la stessa versione secondaria nel 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 funzione è stata trasferita alla fase di disponibilità generale.

Nella versione 1.29 e successive, il piano di controllo di un cluster utente può essere versioni secondarie superiori ai pool di nodi nel cluster. Ad esempio, se un di controllo del cluster utente è impostato su 1.30, i pool di nodi del cluster può essere 1,28, 1,29 o 1,30.

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

1,28

Nella versione 1.28, il piano di controllo di un cluster utente può includere fino a 2 versioni secondarie superiore rispetto ai pool di nodi nel cluster. Ad esempio, se l'istanza di un cluster il piano di controllo è impostato su 1,28, i pool di nodi nel cluster possono trovarsi su 1,15, 1,16 o 1,28. Non è possibile eseguire l'upgrade dei piani di controllo dei cluster utente alla versione 1.29 finché non i pool di nodi si trovano in corrispondenza di 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 1 versione secondaria superiore ai pool di nodi nel cluster. Ad esempio, se un di controllo del cluster utente è 1.16, i pool di nodi nel cluster possono a 1.15 o 1.16.

In termini generali, se 1.n è la versione secondaria di un controllo del cluster utente , i pool di nodi nel cluster possono trovarsi su 1.n o 1.n-1. Cluster utente non può essere eseguito l'upgrade alla versione secondaria successiva finché tutti i pool di nodi non si trovano 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 del cluster utente sono le stesse. Puoi eseguire l'upgrade direttamente a qualsiasi versione dello stesso minore o alla successiva uscita minore. 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 patch non influiscono sulla versione di upgrade le regole del caso.

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 tua versione attuale e la versione di destinazione. Ignorare una versione secondaria non è supportato. Per Ad esempio, se vuoi eseguire l'upgrade dalla versione 1.28.x alla versione 1.30.x, non puoi eseguire direttamente l'upgrade. Devi prima eseguire l'upgrade da da 1.28.x a 1.29.x, quindi esegui l'upgrade 1,30,x.

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

Regole di versione per gli upgrade del pool di nodi

Nella versione 1.28 e successive, puoi saltare una versione secondaria durante l'upgrade di un nodo in un cluster utente. Ad esempio, se un piano di controllo del cluster utente si trova 1,30 e un pool di nodi è 1,28, puoi saltare 1.29 ed eseguire l'upgrade del pool di nodi direttamente alla 1.30. 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 Esegui l'upgrade dei pool di nodi che si trovano in 1.n-2 direttamente a 1.n. Saltare un minorenne quando si esegue l'upgrade dei pool di nodi potrebbe ridurre la quantità di tempo rispetto alle operazioni 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 potresti preferire l'upgrade del piano di controllo di un cluster utente separatamente dai pool di nodi eseguiti sul cluster utente.

Upgrade delle versioni delle patch

Ti consigliamo di eseguire l'upgrade alla versione più recente della patch, quando possibile per assicurati che nei cluster siano applicate le correzioni di sicurezza più recenti. Le versioni patch non il disallineamento delle versioni e le regole di upgrade. Per una determinata versione secondaria, puoi eseguire l'upgrade a qualsiasi versione della patch superiore. Vale a dire che puoi eseguire l'upgrade di 1.30.X dal cluster alla versione 1.30.Y a lungo Y è maggiore di X. Ad esempio, puoi eseguire l'upgrade Da 1.29.0 a 1.29.1 e puoi eseguire l'upgrade da 1.29.1 a 1.29.3.

Passaggi successivi

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