Informazioni sui canali di rilascio

Utilizza i canali di rilascio per Google Kubernetes Engine (GKE) per scegliere le versioni dei tuoi cluster in base al bilanciamento scelto tra disponibilità e stabilità delle funzionalità.

GKE esegue automaticamente l'upgrade di tutti i cluster nel tempo, inclusi quelli non registrati in un canale di rilascio, per assicurarsi che ricevano aggiornamenti della sicurezza, correzioni di problemi noti, nuove funzionalità ed eseguino 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 ti offre il controllo più elevato in merito all'ambito delle esclusioni di manutenzione, impedendo tipi specifici di upgrade anziché tutti gli upgrade, e sequenziando l'implementazione degli upgrade del cluster. I cluster Autopilot possono essere registrati solo in un canale di rilascio.

Se non registri il tuo cluster Standard in un canale di rilascio, puoi disattivare gli upgrade automatici dei nodi per alcuni pool di nodi e gestire manualmente gli upgrade dei nodi in questi pool di nodi. Tuttavia, viene eseguito automaticamente l'upgrade dei control plane di tutti i cluster e, quando una versione raggiunge il termine del supporto, viene eseguito automaticamente l'upgrade dei control plane e dei nodi del cluster, indipendentemente dalla registrazione al canale di rilascio. Per approfondire, 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 che offre un compromesso tra disponibilità e stabilità delle funzionalità. Tutti i canali offrono release supportate di GKE e sono considerati con 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 sia le API Kubernetes GA che quelle beta.

Canale Disponibilità delle nuove release di Kubernetes Quando utilizzare questo canale
Rapida Diverse settimane dopo GA open source a monte 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 spesso l'upgrade del cluster per mantenere la versione della patch più recente disponibile e offrire funzionalità Kubernetes più recenti. I cluster iscritti al canale rapido utilizzano le versioni GA, tuttavia consigliamo di utilizzare il canale rapido per testare le versioni e le API di Kubernetes più recenti su ambienti di pre-produzione.
Normale (valore predefinito) 2-3 mesi dopo il rilascio in versione rapida Accedi alle funzionalità GKE e Kubernetes poco dopo la loro disponibilità al pubblico, ma su una versione che è stata 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 la pubblicazione nella versione normale Dai priorità alla stabilità rispetto alle nuove funzionalità. GKE implementa le modifiche e le nuove versioni in questo canale per ultime, dopo averle convalidate 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 con una versione secondaria in esecuzione il più a lungo possibile. Per scoprire di più, consulta Ricevere assistenza a lungo termine con il canale esteso.
Nessun canale (opzione non consigliata) In linea con il canale regolare Questa opzione non è consigliata. L'upgrade del control plane e dei nodi viene eseguito automaticamente in linea con i canali Regolare e Stabile. Quando devi disattivare 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, l'upgrade viene eseguito automaticamente a partire dalla data specificata nella colonna Upgrade automatico del programma delle release di GKE.

Quando una versione ha accumulato un utilizzo e ha 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 di alta priorità. Ogni promozione indica un livello crescente di stabilità e idoneità alla produzione, in base alle prestazioni osservate dei cluster che eseguono la versione.

Le patch di sicurezza critiche vengono inviate 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 hanno soddisfatto gli standard di idoneità per quel canale specifico. Questo insieme di versioni disponibili include una versione predefinita per la creazione del cluster, selezionata da un insieme di versioni disponibili del canale. Per sapere 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 release delle patch diventano disponibili almeno una settimana prima di diventare un target di upgrade automatico per tutti i canali.
  • Sono disponibili nuove release minori:
    • 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 del tuo ambiente di produzione. Ad esempio, puoi iscriverti alle notifiche di upgrade per ricevere informazioni sulle versioni appena disponibili ed eseguire in modo proattivo l'upgrade 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 le versioni più recenti prima dell'upgrade, ti consigliamo di utilizzare le esclusioni per la manutenzione.

Una volta resa disponibile in un canale di rilascio, una versione secondaria rimarrà disponibile in quel canale per i cluster nuovi ed esistenti fino alla data di fine del supporto.

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

Le note di rilascio di GKE elencano i nuovi target di upgrade automatico per i cluster che eseguono versioni secondarie specifiche con aggiornamenti della versione, come la nota 2024-R33. Quando sono disponibili nuovi target di upgrade automatico, GKE valuta se è necessario eseguire l'upgrade del tuo cluster specifico alla nuova versione. GKE valuta se il tuo cluster ha criteri di manutenzione o altri vincoli che impediscono l'upgrade automatico e non li ignora, tranne in rare situazioni di emergenza. Per ottenere i target di upgrade automatico per un cluster specifico, vedi Ottenere informazioni sugli upgrade di un cluster (anteprima).

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

  • Il tuo cluster non è temporaneamente idoneo per gli upgrade automatici. Questo potrebbe accadere 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 di manutenzione.
    • Gli upgrade automatici sono in pausa perché il tuo cluster utilizza funzionalità Kubernetes ritirate che verranno rimosse nella prossima versione secondaria.
    • È stato eseguito automaticamente l'upgrade del cluster a una versione con 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 interrotto l'implementazione del nuovo target di upgrade automatico per motivi tecnici o aziendali:
    • Sono stati rilevati problemi tecnici con la nuova versione.
    • È stato applicato un blocco della produzione a causa di una stagione commerciale critica, come il Black Friday.

Qual è la versione predefinita?

Quando crei un cluster in un canale di rilascio, per impostazione predefinita il cluster utilizza la versione con 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 e la versione predefinita a volte può essere uno dei target di upgrade automatico per un canale di rilascio.

Eseguire le versioni delle patch da un canale più recente

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

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

  • 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 nella versione 1.22.1-gke.400 potrebbe eseguire l'upgrade a 1.22.4-gke.1500, ma non a 1.23.2-gke.700 perché si tratta di una versione secondaria diversa.

Per eseguire l'upgrade a una versione con patch su un canale più recente, il piano di controllo del cluster deve eseguire una release con patch con la stessa versione secondaria. Ad esempio, se il cluster esegue la versione 1.21.3-gke.200, devi prima eseguire l'upgrade del cluster a una versione con patch disponibile nel canale di rilascio corrente, 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 1.22.4-gke.1500 e che è registrato nel canale regolare.

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

Scoprire 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 standard HTML o feed Atom.
Canale stabile HTML o feed Atom.

Scegli il canale di rilascio migliore per il tuo cluster

I canali includono solo le versioni GA di Kubernetes e ogni canale rappresenta un diverso livello 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 mostrato in questo diagramma, i canali di rilascio disponibili utilizzano le versioni nel mezzo del ciclo di adozione, tra cui Early Adopters (canale Rapido), Early Majority (canale Regolare) e Majority (canale Stabile). La parte iniziale 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 tardiva, in cui utilizzi una versione che sta per essere ritirata e devi passare a una versione supportata.

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

Per i workload di produzione che richiedono una maggiore 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 aggiornamento della versione Kubernetes OSS.
  • Se il tuo requisito è la maturità, in particolare per i cluster di produzione, utilizza il canale stabile.

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 puoi usufruire di:

  • Migliore controllo degli upgrade e allineamento con l'orario di lavoro.
  • Migliore prevedibilità perché GKE salta l'upgrade automatico dei cluster che soddisfano il target di rilascio (ovvero i cluster di cui è stato eseguito manualmente l'upgrade alla versione target successiva). Viene eseguito automaticamente l'upgrade dei nodi alla versione consigliata nel canale selezionato per allinearli alla versione del piano di controllo e per proteggerti da vulnerabilità e disallineamenti delle versioni non supportati.

Ricevere assistenza a lungo termine con il canale esteso

GKE fornisce assistenza a lungo termine per le versioni minori di Kubernetes tramite il canale esteso. Con questo canale, puoi rimanere su una versione secondaria per un massimo di 24 mesi. Dopo il 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.

In che modo GKE esegue automaticamente l'upgrade dei cluster nel canale Extended

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

  • Durante il periodo di supporto standard: GKE esegue l'upgrade dei cluster alle versioni delle 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 2 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à ritirate. Puoi utilizzare le esclusioni della manutenzione per impedire gli upgrade secondari fino alla fine del supporto esteso.
  • Al termine del 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 forniti da GKE durante il periodo di supporto esteso, consulta il ciclo di vita delle versioni secondarie GKE.

Limitazioni per la registrazione di un cluster nel canale esteso

Puoi registrare solo i cluster standard che eseguono la versione 1.27 o successive nel canale Extended. Sia il piano di controllo del cluster sia i nodi devono eseguire la versione 1.27 o successiva.

Non puoi registrare un cluster nel canale esteso se utilizzi le seguenti funzionalità:

Prezzi del supporto esteso

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

Best practice per il canale esteso

Esamina i seguenti scenari per capire come utilizzare il canale Extended per ridurre al minimo le interruzioni dovute agli upgrade delle versioni minori.

Gli scenari supportati richiedono alcune azioni manuali nel tempo per trarre il massimo vantaggio dal canale. Sconsigliamo di registrare un cluster nel canale senza pianificare il passaggio alla versione minore successiva, in quanto GKE eseguirà l'upgrade del cluster alle versioni minori più recenti con la stessa frequenza degli altri canali e il cluster potrebbe comportare un costo maggiore e ricevere le nuove funzionalità per ultimo.

Scenari supportati e non supportati

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

Scenario di upgrade Supportato Riepilogo Tempo tra le modifiche delle versioni secondarie Azione manuale richiesta
Rimanere temporaneamente con una versione secondaria per più tempo Rimani con una versione secondaria per ovviare a un problema che impedisce gli upgrade. Stessa frequenza media, con interruzione per un tempo extra in una versione secondaria.
  • Spostare temporaneamente un cluster nel canale esteso e viceversa.
  • Esegui manualmente l'upgrade del cluster alla nuova versione secondaria quando è tutto pronto.
Esegui l'upgrade manuale della versione secondaria 1-2 volte all'anno Ricevi nuove funzionalità, ma con upgrade minori meno frequenti, quando è ottimale per i workload nel cluster. 1-2 volte all'anno.
  • Esegui manualmente l'upgrade del cluster alla versione secondaria più recente.
Non fare nulla e ricevere upgrade minori con la stessa frequenza Ricevi gli upgrade delle versioni minori con la stessa frequenza degli altri canali e le nuove funzionalità il più tardi possibile. Ogni 4 mesi, in media.
  • 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 tu debba invece 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 automaticamente l'upgrade dei control plane di tutti i cluster e, quando una versione raggiunge il termine del supporto, viene eseguito automaticamente l'upgrade dei control plane e dei nodi del cluster.

Se vuoi impedire gli upgrade automatici per l'intero cluster Standard o per tutti i relativi pool di nodi, ti consigliamo di utilizzare un'esclusione per la 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 di pool di nodi se il tuo 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 uscita
  • Stessa data di inizio dell'upgrade automatico del canale stabile per le versioni secondarie
  • Le stesse versioni secondarie, le versioni di upgrade automatico delle patch e la versione predefinita disponibili nel canale regolare
  • Le stesse versioni delle patch disponibili nel canale Rapido per le versioni minori disponibili nel canale Regolare
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 minore" (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 cluster di canali rapidi e cluster alpha

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

  • È possibile eseguire l'upgrade dei cluster che utilizzano i canali di rilascio 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 hanno scadenza. I cluster alpha scadono dopo 30 giorni.
  • Le API Kubernetes alpha non sono abilitate nei cluster che utilizzano i canali di rilascio.

Passaggi successivi