Informazioni sugli upgrade dei cluster GKE

Questa pagina introduce il concetto di upgrade dei cluster per i cluster Google Kubernetes Engine (GKE). Se conosci il funzionamento degli upgrade dei cluster, consulta l'articolo sull'implementazione delle best practice per l'upgrade dei cluster.

Che cosa sono gli upgrade dei cluster?

Un cluster Kubernetes in GKE è costituito da un piano di controllo e da nodi worker che eseguono i carichi di lavoro degli utenti. Sia il piano di controllo sia i nodi worker eseguono una versione di Kubernetes. GKE esegue automaticamente l'upgrade della versione del piano di controllo e dei nodi per garantire che il cluster riceva nuove funzionalità, correzioni di bug e patch di sicurezza. Per scoprire di più su come GKE sceglie la versione per il tuo cluster, consulta Controllo delle versioni e assistenza di GKE.

GKE esegue i seguenti tipi di upgrade dei cluster, che includono sia gli upgrade del piano di controllo sia gli upgrade dei nodi:

  • Upgrade delle versioni patch: GKE esegue automaticamente l'upgrade dei cluster a una nuova patch ogni settimana, a seconda del canale di rilascio.
  • Upgrade delle versioni secondarie: gli upgrade secondari vengono eseguiti circa tre volte all'anno. Per i cluster del canale con supporto esteso, gli upgrade secondari vengono eseguiti solo quando la versione secondaria si avvicina alla fine del supporto esteso.

Per i cluster non registrati a un canale di rilascio, GKE esegue anche l'upgrade automatico sia del piano di controllo sia dei nodi. Per scoprire come GKE sceglie i target di upgrade automatico per questi cluster, consulta la riga Tempi di upgrade in una tabella che confronta i cluster registrati e non registrati in un canale di rilascio.

Puoi anche eseguire manualmente l'upgrade del piano di controllo e dei nodi di un cluster a una versione disponibile, anziché consentire a GKE di eseguire un upgrade automatico. Utilizza le funzionalità di GKE per scegliere quando e come GKE esegue l'upgrade dei tuoi cluster. Per scoprire di più, consulta Controllare gli upgrade del cluster.

Visualizzare informazioni sugli upgrade dei cluster

Per informazioni dettagliate sugli upgrade in corso, consulta le seguenti risorse:

Controllare gli upgrade dei cluster

In qualità di amministratore della piattaforma, vuoi ridurre al minimo le interruzioni dei tuoi carichi di lavoro mantenendoli performanti, affidabili e sicuri. La responsabilità di GKE nell'ambito del modello di responsabilità condivisa GKE è eseguire l'upgrade del cluster per mantenerlo in esecuzione e soddisfare i tuoi carichi di lavoro.

Nell'ambito della responsabilità condivisa con GKE, devi preparare i tuoi carichi di lavoro per gli upgrade del cluster. Non puoi disattivare completamente gli upgrade automatici, ma puoi controllare quando e come GKE li esegue.

Per gestire gli upgrade dei cluster GKE, ottimizzati per i tuoi carichi di lavoro, utilizza le seguenti funzionalità:

  • Canali di rilascio: scegli un canale di rilascio per ottenere le versioni del cluster con il bilanciamento scelto tra la disponibilità e la stabilità delle funzionalità.
  • Periodi di manutenzione: specifica un periodo di tempo ricorrente in cui possono verificarsi determinati tipi di manutenzione del cluster GKE, come gli upgrade.
  • Esclusioni di manutenzione: impedisci la manutenzione del cluster per un periodo di tempo specifico.
  • Strategie di upgrade dei nodi: se utilizzi i cluster standard, scegli come aggiornare i nodi, ovvero con upgrade di picco o blue-green, per ridurre al minimo l'interruzione dei carichi di lavoro.
  • Sequenza di implementazione: qualifica gli upgrade in un ambiente di pre-produzione prima che GKE esegui l'upgrade dei tuoi cluster di produzione.
  • Upgrade manuali: esegui l'upgrade manuale del cluster ed esegui azioni come annullamento, ripresa, rollback e completamento di upgrade in corso automatici o manuali.

Dopo aver appreso le funzionalità precedenti, potrai implementare le best practice per l'upgrade dei cluster.

Per massimizzare la disponibilità dei carichi di lavoro, utilizza anche i consigli e le tecniche descritti nella sezione sulla gestione e il monitoraggio del cluster e sulla preparazione dei carichi di lavoro.

Che cosa sono gli upgrade automatici del piano di controllo del cluster?

A intervalli regolari, GKE esegue automaticamente l'upgrade del piano di controllo di un cluster alle versioni secondarie e alle patch di Kubernetes più recenti e stabili. GKE sceglie le nuove versioni per il cluster in base alla registrazione al canale di rilascio del cluster.

Nell'intero parco risorse di cluster GKE, solitamente gli upgrade automatici vengono eseguiti in più fasi nell'arco di più settimane. Poiché la sicurezza dell'infrastruttura è una priorità elevata per GKE, gli upgrade dei piani di controllo vengono eseguiti regolarmente e non possono essere disattivati.

Anche se non puoi disattivare gli upgrade del piano di controllo, puoi utilizzare le esclusioni per la manutenzione per impedire temporaneamente tutti gli upgrade del piano di controllo, inclusi gli upgrade secondari e delle patch, per un massimo di 30 giorni, indipendentemente dal fatto che il cluster sia registrato o meno in un canale di rilascio. Per i cluster registrati in un canale di rilascio, puoi impedire gli upgrade alle versioni secondarie finché la versione secondaria non raggiunge la fine del supporto.

Puoi utilizzare le finestre di manutenzione per impostare un periodo di tempo ricorrente in cui GKE può eseguire l'upgrade del piano di controllo.

Che cosa sono gli upgrade automatici dei nodi del cluster?

Per i cluster Autopilot, l'upgrade dei nodi viene sempre eseguito automaticamente alla versione del piano di controllo. Per i cluster standard, per impostazione predefinita viene eseguito automaticamente l'upgrade dei nodi alla versione del piano di controllo.

Per entrambe le modalità dei cluster, puoi utilizzare i periodi di manutenzione e le esclusioni per controllare i tempi e l'ambito degli upgrade dei nodi, come segue:

  • Per i cluster registrati in un canale di rilascio, puoi utilizzare le esclusioni per la manutenzione per impedire gli upgrade automatici dei nodi finché la versione secondaria dei nodi non raggiunge la fine del supporto.
  • Per i cluster standard non registrati a un canale di rilascio, a livello di cluster puoi impedire gli upgrade automatici dei nodi per un massimo di 30 giorni. A livello di pool di nodi, puoi disattivare gli upgrade automatici finché la versione secondaria del pool di nodi non raggiunge la fine del supporto standard.

Quando prevedi di posticipare gli upgrade automatici dei nodi, tieni conto dei seguenti vincoli per i nodi di un cluster GKE:

  • I nodi non possono essere più indietro di due versioni secondarie rispetto alla versione del control plane.
  • I nodi non possono eseguire una versione più recente della versione corrente del piano di controllo del cluster.
  • I nodi non possono eseguire una versione secondaria che ha raggiunto la fine del supporto. Per i cluster della maggior parte dei canali di rilascio, ciò significa che l'assistenza standard verrà ritirata. Per i cluster registrati nel canale esteso, si tratta della fine del supporto esteso. Per verificare se una versione secondaria è ancora supportata nel canale del tuo cluster, consulta la programmazione stimata per i canali di rilascio.

Per ulteriori dettagli su questi vincoli, consulta le norme relative allo scostamento della versione GKE.

Upgrade automatici del cluster per sicurezza e compatibilità

Se impedisci gli upgrade del cluster con finestre di manutenzione ed esclusioni o hai disattivato gli upgrade automatici dei nodi per un pool di nodi specifico quando il cluster non è registrato in un canale di rilascio, in alcuni casi GKE potrebbe eseguire automaticamente l'upgrade del cluster per motivi di sicurezza e compatibilità. Ecco alcuni dei motivi per cui GKE esegue l'upgrade del tuo cluster indipendentemente da questi elementi bloccanti:

  • Piani di controllo del cluster che eseguono una versione in ritiro.
  • Nodi del cluster che eseguono versioni con fine del supporto.
  • Cluster con stato in loop, definiti come cluster con stati in loop da esecuzione a degradato, riparazione o sospensione e ritorno all'esecuzione.

Per maggiori dettagli, vedi Upgrade automatici al termine del supporto e Una piattaforma gestita e responsabilità condivisa.

Upgrade e aggiornamenti con la gestione del ciclo di vita dei cluster GKE

In GKE, gli upgrade e gli aggiornamenti dei cluster hanno significati correlati.

In GKE, il termine upgrade del cluster o semplicemente upgrade si riferisce all'aggiornamento della versione Kubernetes del piano di controllo (upgrade del piano di controllo) o dei nodi (upgrade dei nodi) o di entrambi. Quando utilizzi i cluster standard, gli upgrade dei nodi possono essere chiamati anche upgrade dei pool di nodi perché GKE utilizza una singola operazione per eseguire l'upgrade di un pool di nodi.

Il termine aggiornamenti del cluster, o semplicemente aggiornamenti, è un termine più generale che si riferisce a qualsiasi tipo di modifiche al control plane o ai nodi, incluso l'aggiornamento delle relative versioni. GKE gestisce attivamente il tuo ambiente cluster eseguendo upgrade, altri tipi di aggiornamenti e le operazioni di manutenzione necessarie. Queste azioni assicurano che il cluster rimanga performante, sicuro e aggiornato con le funzionalità e le correzioni di bug più recenti. GKE utilizza strumenti come le strategie di upgrade dei nodi e le policy di manutenzione per ridurre al minimo le interruzioni durante questi processi.

Per scoprire di più sulla gestione di tutte le modifiche del ciclo di vita del cluster, inclusi gli upgrade, consulta Gestire le modifiche del ciclo di vita del cluster per ridurre al minimo le interruzioni.

Passaggi successivi