Questa pagina introduce il concetto di upgrade dei cluster per i cluster Google Kubernetes Engine (GKE). Se hai familiarità con il funzionamento degli upgrade dei cluster, consulta invece Implementare le best practice per l'upgrade dei cluster.
Che cosa sono gli upgrade dei cluster?
Un cluster Kubernetes in GKE è composto da un piano di controllo e da nodi worker, che eseguono i carichi di lavoro utente. 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 con una frequenza massima di una volta alla 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 esteso, gli upgrade secondari vengono eseguiti solo quando la versione secondaria si avvicina alla fine del supporto esteso.
Per i cluster non registrati in un canale di rilascio, GKE esegue automaticamente l'upgrade sia del control plane sia dei nodi. Per scoprire come GKE sceglie i target di upgrade automatico per questi cluster, consulta la riga Tempistica dell'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é lasciare che GKE esegua un upgrade automatico. Utilizza le funzionalità di GKE per scegliere quando e come GKE esegue l'upgrade dei cluster. Per saperne di più, consulta Controllare gli upgrade dei cluster.
Ottenere informazioni sugli upgrade dei cluster
Utilizza le seguenti risorse per i dettagli sugli upgrade attuali:
- Per informazioni sugli upgrade per cluster specifici, inclusi i target di upgrade automatico attuali, consulta Ottenere visibilità sugli upgrade dei cluster.
- Per recuperare i target di upgrade automatico generali, consulta la tabella Versioni attuali. Per un mapping specifico alla versione secondaria di un cluster, consulta le note di rilascio Aggiornamenti delle versioni.
- Consulta la pianificazione dei rilasci di GKE per una stima ottimistica di quando le versioni secondarie sono disponibili per gli upgrade, e raggiungono la fine del supporto.
- Utilizza le notifiche del cluster per rimanere informato sugli eventi di upgrade, ad esempio gli upgrade dei cluster pianificati (anteprima)—per i cluster che utilizzano Cloud Logging o Pub/Sub.
Utilizza insight e suggerimenti per ricevere i seguenti suggerimenti specifici per il cluster:
Controllare gli upgrade dei cluster
In qualità di amministratore della piattaforma, vuoi ridurre al minimo le interruzioni dei carichi di lavoro, mantenendoli al contempo efficienti, affidabili e sicuri. La responsabilità di GKE nell'ambito del modello di responsabilità condivisa di GKE è di eseguire l'upgrade del cluster per mantenerlo in esecuzione e servire i carichi di lavoro.
Nell'ambito della responsabilità condivisa con GKE, devi preparare i carichi di lavoro per gli upgrade dei cluster. Non puoi disabilitare completamente gli upgrade automatici, ma puoi controllare quando e come GKE esegue gli upgrade.
Per gestire gli upgrade dei cluster GKE, ottimizzati per i 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 disponibilità e stabilità delle funzionalità.
- Finestre di manutenzione: Specifica un periodo di tempo ricorrente in cui possono verificarsi determinati tipi di manutenzione dei cluster GKE, ad esempio gli upgrade.
- Esclusioni di manutenzione: impedisci che la manutenzione del cluster venga eseguita per un periodo di tempo specifico.
- Budget di interruzione dei cluster: personalizza l'intervallo di tempo minimo tra tipi specifici di upgrade dei cluster, inclusi gli upgrade delle patch o secondari.
- Strategie di upgrade dei nodi: se utilizzi un pool di nodi Standard, scegli come aggiornare i nodi (upgrade di sovraccarico, blu/verde o blu/verde con scalabilità automatica (anteprima)) per ridurre al minimo le interruzioni dei carichi di lavoro. Inoltre, scegli il numero di node pool di cui GKE esegue automaticamente l'upgrade contemporaneamente in un cluster.
- Sequenza di: implementazione qualifica gli upgrade in un ambiente di pre-produzione prima che GKE esegua l'upgrade dei cluster di produzione.
- Upgrade manuali: esegui manualmente l'upgrade del cluster ed esegui azioni come annullare, riprendere, eseguire il rollback e completare gli upgrade automatici o manuali in corso.
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 suggerimenti e le tecniche descritte in Gestire e monitorare il cluster, e Preparare i 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 dicontrollo di un cluster alle versioni secondarie e alle patch stabili più recenti di Kubernetes. GKE sceglie le nuove versioni per il tuo cluster in base alla registrazione del canale di rilascio del cluster.
In tutto il parco risorse di cluster GKE, gli upgrade automatici vengono in genere eseguiti in fasi per più settimane. Poiché la sicurezza dell'infrastruttura è una priorità assoluta per GKE, gli upgrade dei piani di controllo vengono eseguiti regolarmente e non possono essere disabilitati.
Sebbene non sia possibile disabilitare gli upgrade del control plane, puoi utilizzare le esclusioni di manutenzione per impedire temporaneamente tutti gli upgrade del control plane, inclusi gli upgrade secondari e delle patch , per un massimo di 30 giorni, indipendentemente dal fatto che il cluster sia registrato in un canale di rilascio. Per i cluster registrati in un canale di rilascio, puoi impedire gli upgrade delle versioni secondarie fino a quando la versione secondaria non raggiunge la fine del supporto.
Puoi utilizzare i periodi 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?
GKE esegue gli upgrade automatici dei nodi del cluster nei seguenti modi, a seconda del tipo di cluster e di nodi:
- Per i cluster Autopilot, i nodi vengono sempre eseguiti automaticamente all'upgrade alla versione del piano di controllo.
Per i cluster Standard, GKE esegue le seguenti operazioni:
- Per i node pool Standard, per impostazione predefinita, l'upgrade dei nodi viene eseguito automaticamente al target di upgrade automatico appropriato, ad esempio il control plane. Anche se non è consigliabile, puoi disabilitare gli upgrade automatici dei nodi. Puoi anche eseguire manualmente l'upgrade di questo tipo di pool di nodi.
- Per i node pool gestiti da Autopilot , l'upgrade dei nodi viene eseguito automaticamente alla versione del piano di controllo nel tempo. Puoi anche eseguire manualmente l'upgrade di questo tipo di pool di nodi.
Per entrambe le modalità dei cluster, puoi utilizzare i periodi di manutenzione e le esclusioni per controllare la tempistica e l'ambito degli upgrade dei nodi, come segue:
- Per i cluster registrati in un canale di rilascio, puoi utilizzare le esclusioni di manutenzione per impedire gli upgrade automatici dei nodi fino a quando la versione secondaria dei nodi non raggiunge la fine del supporto.
- Per i cluster Standard non registrati in 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 Standard, puoi disabilitare gli upgrade automatici fino a quando la versione secondaria del pool di nodi non raggiunge la fine del supporto standard.
Quando pianifichi di posticipare gli upgrade automatici dei nodi, tieni presente i seguenti vincoli per i nodi di un cluster GKE:
- I nodi non possono essere più di due versioni secondarie precedenti alla versione del piano di controllo.
- I nodi non possono eseguire una versione più recente della versione del piano di controllo corrente del cluster.
- I nodi non possono eseguire una versione secondaria che ha raggiunto la fine del supporto. Per i cluster nella maggior parte dei canali di rilascio, ciò significa la fine del supporto standard. Per i cluster registrati nel canale esteso, ciò significa la fine del supporto esteso. Per verificare se una versione secondaria è ancora supportata nel canale del cluster, consulta la pianificazione stimata per i canali di rilascio.
Per maggiori dettagli su questi vincoli, consulta le norme sul disallineamento delle versioni di GKE.
Upgrade automatici dei cluster per sicurezza e compatibilità
Se impedisci gli upgrade dei cluster con periodi di manutenzione ed esclusioni o se hai disabilitato gli upgrade automatici dei nodi per un pool di nodi Standard 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à. Alcuni dei motivi per cui GKE esegue l'upgrade del cluster indipendentemente da questi blocchi includono i seguenti:
- Piani di controllo del cluster che eseguono una versione di fine del supporto.
- Nodi del cluster che eseguono versioni di fine del supporto.
- Cluster con loop di stato, definiti come cluster con stati in loop da in esecuzione a degradato, in riparazione o sospeso e di nuovo in esecuzione.
Per maggiori dettagli, consulta Upgrade automatici alla fine del supporto e Una piattaforma gestita e responsabilità condivisa.
Upgrade e aggiornamenti con la gestione del ciclo di vita dei cluster GKE
In GKE, i termini upgrade dei cluster e aggiornamenti dei cluster hanno significati correlati.
In GKE, il termine upgrade dei cluster o semplicemente upgrade si riferisce all'aggiornamento della versione di Kubernetes del piano di controllo (upgrade del piano di controllo) o dei nodi (upgrade dei nodi) o di entrambi. Quando si utilizzano i cluster Standard, gli upgrade dei nodi possono essere definiti anche upgrade dei node pool perché GKE utilizza una singola operazione per eseguire l'upgrade di un node pool di nodi.
Il termine aggiornamenti dei cluster o semplicemente aggiornamenti è un termine più generale che si riferisce a qualsiasi tipo di modifica del control plane o dei nodi incluso l'aggiornamento delle versioni. GKE gestisce attivamente l'ambiente del cluster eseguendo upgrade, altri tipi di aggiornamenti e operazioni di manutenzione necessarie. Queste azioni garantiscono che il cluster rimanga efficiente, 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 dei cluster, inclusi gli upgrade, consulta Gestire le modifiche del ciclo di vita dei cluster per ridurre al minimo le interruzioni.
Passaggi successivi
- Scopri di più sugli upgrade dei cluster Autopilot.
- Scopri di più sugli upgrade dei cluster Standard.
- Scopri di più sul controllo delle versioni e sull'assistenza di GKE.
- Scopri di più sulle note di rilascio di GKE.
- Scopri come configurare gli upgrade automatici dei nodi.