Informazioni sui canali di rilascio

Utilizza i canali di rilascio per Google Kubernetes Engine (GKE) per scegliere le versioni dei tuoi cluster per bilanciare la disponibilità e la stabilità delle funzionalità.

GKE esegue automaticamente l'upgrade di tutti i cluster nel tempo, inclusi quelli non registrati in un canale di rilascio, per garantire che ricevano aggiornamenti della sicurezza, correzioni di problemi noti, nuove funzionalità ed eseguano una versione di Kubernetes supportata. Puoi controllare la tempistica degli upgrade con periodi di manutenzione ed esclusioni.

Ti consigliamo di registrare il cluster in un canale di rilascio, in quanto ciò ti offre il massimo controllo per quanto riguarda l'ambito delle esclusioni di manutenzione, impedendo tipi specifici di upgrade anziché tutti gli upgrade, e la sequenza di implementazione degli upgrade del cluster. I cluster Autopilot possono essere registrati solo in un canale di rilascio.

Se non registri il cluster Standard in un canale di rilascio, puoi disabilitare gli upgrade automatici dei nodi per i pool di nodi selezionati e gestire manualmente gli upgrade ai nodi in questi pool di nodi. Tuttavia, viene eseguito automaticamente l'upgrade dei control plane di tutti i cluster e, quando una versione raggiunge la fine del supporto, viene eseguito automaticamente l'upgrade dei control plane e dei nodi del cluster indipendentemente dalla registrazione al canale di rilascio. Per scoprire di più, consulta il confronto tra i cluster registrati e non registrati in un canale di rilascio.

Quali canali sono disponibili

La tabella seguente illustra le proprietà dei canali di rilascio disponibili, ognuno dei quali offre un compromesso tra disponibilità e stabilità delle funzionalità. Tutti i canali offrono versioni supportate di GKE e sono considerati di disponibilità generale (GA), anche se le singole funzionalità potrebbero non essere sempre GA, come indicato. Le release di Kubernetes in questi canali sono release ufficiali di Kubernetes e includono API Kubernetes GA e beta.

Canale Disponibilità di una nuova release di Kubernetes Quando utilizzare questo canale
Rapido Diverse settimane dopo GA open source upstream Ricevi l'ultima release di Kubernetes il prima possibile per poter utilizzare le nuove funzionalità GKE nel momento in cui diventano disponibili al pubblico. GKE esegue l'upgrade del cluster di frequente per rimanere aggiornato con la versione della patch più recente disponibile e fornire funzionalità Kubernetes più recenti. I cluster iscritti al canale rapido utilizzano le versioni GA, ma ti consigliamo di utilizzare il canale rapido per testare le versioni e le API più recenti di Kubernetes su ambienti di pre-produzione.
Normale (predefinita) 2-3 mesi dopo il rilascio nella traccia di rilascio rapido Accedi alle funzionalità GKE e Kubernetes poco dopo la loro disponibilità generale, ma su una versione qualificata per un periodo di tempo più lungo. Offre un buon compromesso tra disponibilità di funzionalità e stabilità di release ed è l'opzione che consigliamo alla maggior parte degli utenti.
Stabile 2-3 mesi dopo il rilascio nella versione normale Dai priorità alla stabilità rispetto alle nuove funzionalità. GKE implementa le modifiche e le nuove versioni in questo canale per ultimo, dopo la convalida nei canali Rapido e Regolare, dedicando ancora più tempo alla convalida.
Esteso In linea con il canale regolare Utilizza questo canale per ricevere assistenza a lungo termine, mantenendo un cluster in esecuzione con una versione secondaria il più a lungo possibile. Per saperne di più, consulta Ricevere assistenza a lungo termine con il canale Extended.
Nessun canale (sconsigliato) In linea con il canale regolare Questa opzione non è consigliata. Il control plane e i nodi vengono aggiornati automaticamente in linea con i canali Regolare e Stabile. Quando devi disabilitare gli upgrade automatici dei nodi a livello di pool di nodi, puoi utilizzare questa opzione di configurazione. In alternativa, con i canali di rilascio puoi disattivare gli upgrade automatici dei nodi a livello di cluster. Per maggiori dettagli, consulta il confronto tra i cluster registrati e non registrati in un canale di rilascio.

Quando registri un cluster in un canale di rilascio, viene eseguito l'upgrade automatico del cluster a partire dalla data specificata nella colonna Upgrade automatico del programma di rilascio di GKE.

Quando una versione ha accumulato utilizzo e dimostrato stabilità nei cluster nel canale Rapido, viene promossa al canale Regolare. Alla fine, la versione viene promossa al canale Stabile, che riceve solo aggiornamenti ad alta priorità. Ogni promozione indica un livello crescente di stabilità e idoneità alla produzione, in base alle prestazioni osservate dei cluster che eseguono quella versione.

Le patch di sicurezza critiche vengono distribuite a tutti i canali di rilascio per proteggere i tuoi cluster e l'infrastruttura di Google. In rare situazioni di emergenza, GKE potrebbe eseguire l'upgrade automatico dei cluster a versioni non ancora disponibili nel relativo canale di rilascio.

Quali versioni sono disponibili in un canale

Ogni canale di rilascio offre più versioni secondarie. Queste versioni soddisfano gli standard di qualificazione per quel canale specifico. Questo insieme di versioni disponibili include una versione predefinita per la creazione del cluster, che viene selezionata da un insieme di versioni disponibili del canale. Per vedere quali versioni sono disponibili in un canale di rilascio, segui le istruzioni per visualizzare le versioni predefinite e disponibili per i canali di rilascio.

  • Le nuove versioni patch diventano disponibili almeno una settimana prima di diventare una destinazione di aggiornamento automatico per tutti i canali.
  • Sono disponibili nuove release secondarie:
    • almeno due settimane prima di diventare una destinazione di upgrade automatico per il canale rapido.
    • almeno quattro settimane prima di diventare un target di upgrade automatico per i canali Regolare e Stabile.

Puoi testare una versione di GKE appena disponibile prima di eseguire l'upgrade dell'ambiente di produzione. Ad esempio, puoi abbonarti alle notifiche di upgrade per ricevere informazioni sulle nuove versioni disponibili e poi eseguire l'upgrade proattivo di un ambiente di pre-produzione alla nuova versione prima che diventi la destinazione dell'upgrade automatico per i cluster nel tuo ambiente di produzione.

Se devi mantenere un cluster su una versione specifica, ad esempio per convalidare o testare versioni più recenti prima dell'upgrade, ti consigliamo di utilizzare le esclusioni dalla manutenzione.

Una volta resa disponibile una versione secondaria in un canale di rilascio, questa rimarrà disponibile in quel canale per i cluster nuovi o esistenti fino al raggiungimento della data di fine del supporto.

Cosa succede quando una versione diventa un target di upgrade automatico in un canale di rilascio

GKE esegue automaticamente l'upgrade dei cluster nel tempo ai nuovi target di upgrade automatico. Quando sono disponibili nuovi target di upgrade automatico, GKE valuta se il tuo cluster specifico deve essere sottoposto all'upgrade a quella nuova versione. GKE valuta se il cluster ha policy di manutenzione o altri vincoli che impediscono gli upgrade automatici e non ignora questi motivi tranne in rare situazioni di emergenza.

Puoi trovare le destinazioni di upgrade automatico per i tuoi cluster nei seguenti modi:

  • Per ottenere le destinazioni dell'upgrade automatico per un cluster specifico, consulta Ottenere informazioni sugli upgrade di un cluster.
  • La tabella delle versioni attuali fornisce un elenco dei target di upgrade automatico attuali per ogni canale di rilascio. La versione specifica che si applica al tuo cluster dipende dalla versione secondaria del cluster e da vincoli specifici.
  • Le note di rilascio di GKE elencano i nuovi target di upgrade automatico per i cluster che eseguono versioni secondarie specifiche con Aggiornamenti delle versioni, ad esempio la nota 2024-R33.

Se sono trascorsi 10 giorni da quando una nuova versione è diventata una destinazione di upgrade automatico per la versione secondaria del cluster nel canale di rilascio e gli upgrade automatici non sono iniziati per il cluster, il ritardo potrebbe essere dovuto a uno dei seguenti motivi:

  • Il cluster non è temporaneamente idoneo per gli upgrade automatici. Questo potrebbe succedere perché:
    • Il cluster non rientra nel periodo di tempo di un periodo di manutenzione configurato.
    • Il cluster rientra nel periodo di tempo di un'esclusione dalla manutenzione.
    • Gli upgrade automatici sono in pausa perché il cluster utilizza funzionalità di Kubernetes ritirate che verranno rimosse nella prossima versione secondaria.
    • È stato eseguito automaticamente l'upgrade del cluster a una versione patch meno di 24 ore fa.
    • È stato eseguito l'upgrade automatico del cluster a una versione secondaria meno di 30 giorni fa e la destinazione dell'upgrade automatico è una nuova versione secondaria.
  • GKE ha messo in pausa l'implementazione del nuovo target di upgrade automatico per motivi tecnici o aziendali:
    • Sono stati rilevati problemi tecnici con la nuova versione.
    • È in vigore un blocco della produzione a causa di una stagione aziendale critica, ad esempio il Black Friday.

Il target di upgrade automatico consigliato è la versione a cui GKE esegue gradualmente l'upgrade dei cluster nel tempo. Di tutti i target di upgrade automatico in un canale di rilascio, GKE sposta i cluster più vicino a questa versione quando esegue gli upgrade automatici.

Nel corso di più upgrade automatici, a meno che non vi siano vincoli che impediscono gli upgrade automatici, GKE esegue l'upgrade dei cluster in modo progressivo fino a raggiungere il target di upgrade automatico consigliato del canale di rilascio. Una volta raggiunto il target, il cluster utilizza continuamente il target di upgrade automatico consigliato esistente e passa al nuovo target consigliato quando viene rilasciato.

Che cos'è la versione predefinita?

Quando crei un cluster in un canale di rilascio, per impostazione predefinita il cluster utilizza la versione patch predefinita per la creazione del cluster nel canale di rilascio selezionato. Tuttavia, puoi specificare una versione disponibile diversa quando crei un cluster nel canale di rilascio.

I canali di rilascio hanno più versioni secondarie disponibili in un canale di rilascio e la versione predefinita a volte può essere una delle destinazioni di upgrade automatico per un canale di rilascio.

Informazioni su come ricevere le versioni patch in anticipo

Puoi ottenere le versioni patch in anticipo con gli upgrade automatici o manuali utilizzando i metodi descritti in questa sezione.

Upgrade automatici delle patch accelerati

GKE introduce per prima una nuova versione patch in un canale di rilascio rendendola disponibile per la creazione di nuovi cluster e gli upgrade manuali. Dopo che GKE ha stabilito che la versione patch è qualificata, imposta la nuova versione patch come target di upgrade automatico, il che significa che GKE inizia a eseguire automaticamente l'upgrade dei cluster a questa nuova versione patch. Il periodo di tempo che intercorre tra la disponibilità della versione e gli aggiornamenti automatici è in genere di almeno una settimana, ma dipende dal canale di rilascio e dalle circostanze specifiche di qualificazione della versione.

Per ulteriori informazioni sulla disponibilità della versione attuale:

Se vuoi ricevere gli upgrade delle patch non appena la versione è disponibile e prima che GKE la imposti come destinazione dell'upgrade automatico nel canale, puoi utilizzare gli upgrade automatici delle patch accelerati. Questa impostazione può essere utile se vuoi ricevere le patch di sicurezza il prima possibile tramite gli upgrade automatici.

Devi comprendere i rischi associati all'upgrade automatico del cluster in base a una pianificazione accelerata prima che GKE determini che i cluster nel canale devono essere aggiornati automaticamente alla nuova versione della patch. Questa pianificazione accelerata salta un passaggio nella procedura di qualifica per le versioni patch nei canali di rilascio. Tutte le versioni patch, non solo quelle con patch di sicurezza, vengono aggiornate con questa pianificazione accelerata. Questa impostazione non influisce sugli upgrade delle versioni secondarie ed è disponibile solo per i cluster registrati in un canale di rilascio.

Questa impostazione influisce solo sulla tempistica dell'upgrade automatico di GKE di un cluster a una nuova versione patch. GKE rispetta comunque le finestre e le esclusioni di manutenzione, segue l'ordine di una sequenza di implementazione e applica qualsiasi altra pratica standard in genere utilizzata per gli upgrade automatici.

Per ulteriori informazioni sulla configurazione di questa funzionalità, vedi Utilizzare gli aggiornamenti automatici delle patch accelerati.

In alternativa, puoi eseguire manualmente l'upgrade dei tuoi cluster se vuoi eseguire l'upgrade a una versione patch specifica non appena è disponibile e prima che venga impostata come destinazione dell'upgrade automatico.

Esegui le versioni patch da un canale più recente

Oltre alle versioni patch disponibili per un canale di rilascio, puoi eseguire versioni patch di canali di rilascio più recenti rispetto a quello a cui è registrato il cluster se la versione secondaria è disponibile nel canale di rilascio del cluster e utilizzi la gcloud CLI o l'API GKE.

Ad esempio, se le seguenti versioni fossero disponibili nei canali Rapido e Regolare:

  • Rapido: 1.23.2-gke.700, 1.22.4-gke.1500
  • Regolare: 1.21.4-gke.400, 1.22.1-gke.400

Un cluster registrato nel canale Regolare che esegue GKE versione 1.22.1-gke.400 potrebbe eseguire l'upgrade manuale alla versione 1.22.4-gke.1500, ma non alla versione 1.23.2-gke.700 perché si tratta di una versione secondaria diversa.

Per eseguire manualmente l'upgrade a una versione patch su un canale più recente, il control plane del cluster deve eseguire una release patch con la stessa versione secondaria. Ad esempio, se il cluster esegue la versione 1.21.3-gke.200, devi prima eseguire manualmente l'upgrade del cluster a una versione patch disponibile nel suo canale di rilascio attuale, 1.22.1-gke.400. Puoi quindi eseguire l'upgrade del cluster alla versione 1.22.4-gke.1500.

Puoi anche creare un nuovo cluster che esegue la versione 1.22.4-gke.1500 e registrato al canale regolare.

GKE mantiene il cluster sulla versione patch del canale più recente finché non diventa disponibile un target di upgrade automatico più recente nel canale registrato per il cluster.

Scopri le novità di un canale

Per scoprire le novità di un canale di rilascio, consulta le note di rilascio. Esistono note di rilascio separate per ogni canale di rilascio, oltre alle note di rilascio generali.

Canale di rilascio Note di rilascio
Canale rapido HTML o feed Atom.
Canale normale HTML o feed Atom.
Canale stabile HTML o feed Atom.

Scegliere il miglior canale di rilascio per il cluster

I canali includono solo le versioni GA di Kubernetes e ogni canale rappresenta un livello diverso di qualità e maturità delle release di Kubernetes e GKE. Il seguente diagramma illustra il ciclo di adozione per i canali di rilascio:

Ciclo di adozione dei canali di rilascio

Come mostra questo diagramma, i canali di rilascio disponibili utilizzano versioni a metà del ciclo di adozione, tra cui Early Adopter (canale rapido), Early Majority (canale regolare) e Majority (canale stabile). La prima parte del ciclo di adozione è costituita dagli innovatori, che testano le funzionalità più recenti utilizzando la release di Kubernetes upstream. L'ultima parte del ciclo di adozione è la maggioranza ritardataria, in cui utilizzi una versione che si sta avvicinando al ritiro e devi eseguire la transizione a una versione supportata.

Negli ambienti di pre-produzione, utilizza il canale rapido per le versioni più recenti in cui puoi testare le funzionalità non appena sono disponibili a livello generale.

Per i workload di produzione che richiedono maturità rispetto alle funzionalità più recenti, consigliamo di utilizzare il canale regolare (predefinito) o il canale stabile.

  • Se devi monitorare attentamente le nuove funzionalità, ti consigliamo di utilizzare il canale Normale, che offre un equilibrio tra stabilità e novità della versione OSS di Kubernetes.
  • Se il tuo requisito è la maturità, soprattutto per i cluster di produzione, utilizza il canale stabilee.

GKE esegue l'upgrade dei cluster a una versione più recente che soddisfa gli standard di qualità del canale. Tuttavia, ti consigliamo di eseguire l'upgrade dei cluster in anticipo perché in questo modo:

  • Maggiore controllo sugli aggiornamenti e allineamento con l'orario di lavoro.
  • Maggiore prevedibilità perché GKE salta l'upgrade automatico dei cluster che soddisfano la destinazione di rilascio (ovvero i cluster di cui è stato eseguito l'upgrade manuale alla versione di destinazione successiva). I nodi vengono aggiornati automaticamente alla versione consigliata nel canale selezionato per allinearsi alla versione del control plane e per proteggerti da vulnerabilità e disallineamento delle versioni non supportato.

Ricevere assistenza a lungo termine con il canale Esteso

GKE fornisce supporto a lungo termine per le versioni secondarie di Kubernetes tramite il canale Extended. Con questo canale, puoi rimanere su una versione secondaria per un massimo di 24 mesi. Al termine del periodo di assistenza standard di 14 mesi, il tuo cluster riceve patch di sicurezza per circa altri 10 mesi durante il periodo di assistenza estesa.

Come GKE esegue automaticamente l'upgrade dei cluster nel canale Extended

Per i cluster registrati nel canale Extended, GKE esegue automaticamente l'upgrade dei cluster nel seguente modo:

  • Durante il periodo di supporto standard: GKE esegue l'upgrade dei cluster alle versioni patch più recenti della stessa versione secondaria seguendo la stessa cadenza del canale regolare.
  • Durante il periodo di supporto esteso: GKE continua a fornire aggiornamenti delle patch di sicurezza per la versione secondaria. Circa due mesi prima della fine del supporto esteso, GKE inizia l'upgrade dei cluster alla versione secondaria successiva, a meno che il cluster non utilizzi API o funzionalità deprecate. Puoi utilizzare le esclusioni della manutenzione per impedire gli upgrade delle versioni secondarie fino alla fine del supporto esteso.
  • Al termine del periodo di supporto esteso: GKE esegue l'upgrade di tutti i cluster in cui è ancora in esecuzione la versione secondaria non più supportata, indipendentemente dai problemi di blocco. Non puoi configurare le esclusioni dalla manutenzione dopo questa data.

Per scoprire di più sui diversi periodi di disponibilità e sugli upgrade che GKE fornisce durante il periodo di supporto esteso, consulta Ciclo di vita della versione secondaria di GKE.

Limitazioni per la registrazione di un cluster nel canale esteso

Esamina le seguenti limitazioni per i cluster registrati nel canale Extended:

Prezzi del supporto esteso

Se vuoi registrare un cluster nel canale esteso, assicurati di aver esaminato i prezzi dell'assistenza estesa. Puoi registrare un cluster nel canale Extended senza costi aggiuntivi se il progetto ha abilitato GKE Enterprise. In alternativa, per i cluster della versione GKE Standard, i costi con pagamento in base al consumo sono applicati se il cluster è registrato nel canale esteso e per la versione secondaria del cluster inizia il periodo di assistenza esteso.

Best practice per il canale esteso

Esamina gli scenari seguenti per capire come utilizzare il canale Esteso per ridurre al minimo le interruzioni causate dagli upgrade delle versioni secondarie.

Gli scenari supportati richiedono un'azione manuale nel tempo per ottenere il massimo vantaggio dal canale. Non è consigliabile registrare un cluster nel canale senza prevedere di passare alla versione secondaria successiva, in quanto GKE alla fine eseguirà l'upgrade del cluster alle versioni secondarie più recenti con la stessa frequenza degli altri canali e il cluster potrebbe comportare costi maggiori e ricevere le nuove funzionalità per ultimo.

Scenari supportati e non supportati

Per saperne di più sugli scenari supportati e non supportati, consulta la tabella seguente e vedi Utilizzare il canale esteso quando hai bisogno di assistenza a lungo termine per maggiori dettagli. Un segno di spunta () indica uno scenario supportato:

Scenario di upgrade Supportato Riepilogo Tempo tra le modifiche alle versioni secondarie Azione manuale richiesta
Rimanere temporaneamente con una versione secondaria più a lungo Rimani con una versione secondaria per risolvere un problema che impedisce gli upgrade. Stessa frequenza media, con interruzione per tempo extra su una versione secondaria.
  • Spostare temporaneamente un cluster nel canale esteso e viceversa.
  • Esegui manualmente l'upgrade del cluster alla nuova versione secondaria quando è pronto.
Esegui l'upgrade manuale della versione secondaria 1-2 volte l'anno Ricevi nuove funzionalità, ma con upgrade secondari meno frequenti, quando è ottimale per i workload nel cluster. 1-2 volte all'anno.
  • Esegui manualmente l'upgrade del cluster a una versione secondaria più recente.
Non fare nulla e ricevere upgrade secondari con la stessa frequenza Ricevi gli upgrade delle versioni secondarie con la stessa frequenza degli altri canali e le nuove funzionalità il più tardi possibile. In media, ogni 4 mesi.
  • Monitoraggio degli upgrade automatici delle versioni secondarie da versioni non supportate.

Cluster non registrati in un canale di rilascio

Non consigliamo questa opzione di configurazione a causa delle limitazioni dei cluster non registrati nei canali di rilascio, ma puoi scegliere di non registrare un cluster Standard in un canale di rilascio (noto come nessun canale e precedentemente come statico). Non utilizzare questa opzione a meno che non sia possibile eseguire l'upgrade automatico dei singoli pool di nodi e devi eseguire l'upgrade manuale di questi nodi. Se il tuo cluster non è registrato in un canale di rilascio, puoi disattivare l'upgrade automatico dei nodi per i pool di nodi selezionati. Con i canali di rilascio, puoi ottenere lo stesso risultato a livello di cluster in tutti i pool di nodi. Tuttavia, indipendentemente dalla registrazione al canale di rilascio, viene eseguito l'upgrade automatico di tutti i control plane dei cluster e, quando una versione raggiunge la fine del supporto, viene eseguito l'upgrade automatico dei control plane e dei nodi del cluster.

Se vuoi impedire gli upgrade automatici per l'intero cluster Standard o per tutti i relativi node pool, ti consigliamo di utilizzare un'esclusione dalla manutenzione con il cluster registrato in un canale di rilascio. Con le esclusioni dalla manutenzione, puoi disattivare gli upgrade automatici dei nodi per tutti i node pool, mentre puoi disattivare gli upgrade automatici dei nodi a livello dpool di nodiol se il cluster non è registrato in un canale di rilascio.

Confronto tra i cluster registrati e non registrati in un canale di rilascio

Consulta la seguente tabella per comprendere le somiglianze e le differenze tra la registrazione e la mancata registrazione del cluster in un canale di rilascio:

Funzionalità Cluster registrato in un canale di rilascio Cluster non registrato in un canale di rilascio
Comportamento dell'upgrade condiviso
Tempistiche dell'upgrade In linea con il rispettivo canale di rilascio
  • Stessa data di inizio dell'upgrade automatico del canale stabile per le versioni secondarie
  • Stesse versioni secondarie disponibili, versioni di upgrade automatico delle patch e versione predefinita del canale regolare
  • Le stesse versioni patch disponibili del canale Rapido per le versioni secondarie disponibili nel canale Regolare
Upgrade automatici delle patch accelerati Disponibile Non disponibile
Controllo dell'interruzione del pool di nodi
Periodi di manutenzione Disponibile Disponibile
Esclusioni dalla manutenzione Ambiti di esclusione dalla manutenzione disponibili:
  • "Nessun upgrade" (30 giorni)
  • "Nessun upgrade secondario" (fino alla fine del supporto)
  • "Nessun upgrade secondario o di nodi" (fino alla fine del supporto)
 Limitato all'ambito "Nessun upgrade" (30 giorni)
Sequenza di implementazione Disponibile con sequenze basate sulla flotta e sull'ambito Non disponibile
Assistenza a lungo termine Disponibile solo con il canale di rilascio esteso Non disponibile
Autopilot Disponibile Non disponibile

Differenze tra i cluster Rapid e alpha

I cluster creati utilizzando il canale di rilascio rapido non sono cluster alpha. Ecco le differenze:

  • I cluster che utilizzano i canali di rilascio possono essere sottoposti ad upgrade e l'upgrade automatico è abilitato e non può essere disattivato. Non è possibile eseguire l'upgrade dei cluster alpha.
  • I cluster che utilizzano i canali di rilascio non scadono. I cluster alpha scadono dopo 30 giorni.
  • Le API alpha di Kubernetes non sono abilitate sui cluster che utilizzano i canali di rilascio.

Passaggi successivi