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 tra disponibilità e stabilità delle funzionalità.

GKE esegue automaticamente l'upgrade di tutti i cluster nel tempo, inclusi non iscritti a un canale di rilascio, per garantire che ricevano informazioni aggiornamenti, correzioni di problemi noti, nuove funzionalità ed esecuzione di un completamente gestita. Puoi controllare le tempistiche degli upgrade con periodi di manutenzione e esclusioni.

Ti consigliamo di registrare il cluster in un canale di rilascio, perché in questo modo maggiore controllo per quanto riguarda l'ambito della manutenzione esclusioni, impedendo gli specifici tipi di upgrade anziché tutti gli upgrade, e la sequenza dell'implementazione di upgrade dei cluster. I cluster Autopilot possono essere registrati solo in un canale di rilascio.

Se non registri il tuo cluster Standard in una release puoi disabilitare il nodo di upgrade automatici pool di nodi selezionati e gestire manualmente gli upgrade ai nodi in questi piscine. Tuttavia, tutti i cluster l'upgrade automatico dei piani di controllo quando una versione raggiunge la fine dei cluster, dei piani di controllo e di nodi viene eseguito automaticamente indipendentemente dalla registrazione del canale di rilascio. A scopri di più, consulta il confronto tra cluster registrati e non registrati in un canale di rilascio.

Quali canali sono disponibili

La seguente tabella spiega le proprietà dei canali di rilascio disponibili, ciascuna offrendo un compromesso tra disponibilità e stabilità delle funzionalità. Tutti i canali offrono release supportate di GKE e sono considerati generalmente disponibili (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 che includono le API Kubernetes GA e 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 ti 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 Rapid Accedi alle funzionalità di GKE e Kubernetes subito dopo il loro ritiro GA, ma in una versione che è stata qualificata per un periodo più lungo di nel tempo. 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 la 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 normale Utilizza questo canale per ricevere assistenza a lungo termine, mantenendo un cluster in esecuzione di una versione secondaria il più a lungo possibile. Per saperne di più, consulta Ricevere assistenza a lungo termine con il canale esteso.
Nessun canale (opzione non consigliata) In linea con il canale normale Questa opzione non è consigliata. L'upgrade automatico del piano di controllo e dei nodi viene eseguito in allineamento 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 disabilitare 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. In seguito la versione viene promossa al canale Stable, che riceve solo aggiornamenti ad alta priorità. Ogni promozione segnala un livello elevato di stabilità e l'idoneità alla produzione, in base alle prestazioni osservate dei cluster in esecuzione completamente gestita.

Le patch di sicurezza critiche vengono distribuite in tutti i canali di rilascio per proteggere cluster e l'infrastruttura di Google. In rare situazioni di emergenza, GKE potrebbe eseguire l'upgrade automatico dei cluster a versioni che non lo sono ancora disponibili nel 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, che viene selezionato da un insieme di versioni disponibili da quel 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 predefinite per tutti i canali.
  • Sono disponibili nuove release minori:
    • almeno due settimane prima che venga impostato come predefinito per il canale Rapid.
    • almeno quattro settimane prima di diventare predefinita per i canali Normale 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 preproduzione alla nuova versione prima che diventi la versione predefinita.

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

Una volta resa disponibile in un canale di rilascio, una versione secondaria rimangono disponibili nel canale di rilascio per i cluster nuovi o esistenti finché raggiunge la fine del supporto data.

Cosa succede quando una nuova versione diventa predefinita in un canale di rilascio

Quando una nuova versione di GKE diventa predefinita in un canale di rilascio:

  • I nuovi cluster vengono creati utilizzando versione predefinita in il canale di rilascio selezionato.
  • L'upgrade dei cluster idonei esistenti viene eseguito automaticamente entro 10 giorni dopo la nuova versione diventa predefinita nel relativo canale di rilascio.

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

  • Il tuo cluster non è temporaneamente idoneo per gli upgrade automatici. Questo potrebbe si verificano perché:
    • Il cluster non rientra nel periodo di tempo di una finestra di manutenzione configurata.
    • Il cluster rientra nel periodo di tempo di un'esclusione di manutenzione.
    • Gli upgrade automatici sono paused perché il cluster utilizza funzionalità Kubernetes deprecate che sono state rimosse successiva 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 versione secondaria inferiore a 30 giorni fa e la nuova versione predefinita è una nuova versione secondaria.
  • GKE ha messo in pausa l'implementazione del nuovo versione predefinita per per motivi tecnici o commerciali:
    • Sono stati rilevati problemi tecnici con la nuova versione.
    • Si è verificato un blocco della produzione a causa di un periodo di business critico, ad esempio Black Friday.

Eseguire le versioni delle patch da un canale più recente

Oltre alle versioni delle patch disponibili elencate per un canale di rilascio, puoi eseguire versioni delle patch da 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.

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

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

Un cluster registrato nel canale regolare che esegue GKE alla versione 1.22.1-gke.400 potrebbe essere aggiornata alla 1.22.4-gke.1500, 1.23.2-gke.700 in quanto è una versione minore diversa.

Per eseguire l'upgrade a una versione della patch su un canale più recente, il piano di controllo del tuo cluster deve eseguire una patch release con la stessa versione secondaria. Ad esempio, se che il cluster sia in esecuzione 1.21.3-gke.200, devi prima eseguire l'upgrade del cluster a una patch disponibile nell'attuale canale di rilascio, 1.22.1-gke.400. Puoi quindi eseguire l'upgrade del cluster a 1.22.4-gke.1500.

Puoi anche creare un nuovo cluster che esegue 1.22.4-gke.1500 e che è registrato nel canale regolare.

Il cluster rimarrà nella versione patch del canale più recente fino a quando la versione predefinita del canale in cui è registrato il cluster diventa maggiore rispetto alla versione del cluster. A quel punto, verrà eseguito l'upgrade automatico del cluster la versione predefinita.

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

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 prima parte del ciclo di adozione è quella degli Innovators, che testano le funzionalità più recenti usando la release upstream di Kubernetes. L'ultima parte del ciclo di adozione è la maggioranza tardiva, in cui utilizzi una versione che è in procinto di 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 carichi di lavoro 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 open source di Kubernetes.
  • 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 di tempo perché in questo modo avrai:

  • Migliore controllo degli upgrade e allineamento con l'orario di lavoro.
  • Migliore prevedibilità perché GKE salta l'upgrade automatico che soddisfano il target di rilascio (ovvero, cluster che sono stati manualmente viene eseguito l'upgrade alla versione di destinazione successiva). Viene eseguito l'upgrade automatico dei nodi la versione consigliata nel canale selezionato per allinearsi con il gruppo di controllo planet e per proteggerti da vulnerabilità e non supportati il disallineamento delle versioni.

Ricevere assistenza a lungo termine con il canale Extended

GKE fornisce assistenza a lungo termine per le versioni minori 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 circa Altri 10 mesi durante il supporto esteso periodo.

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

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

  • Durante il periodo di assistenza 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 assistenza estesa: GKE continua a fornire aggiornamenti delle patch di sicurezza per la versione secondaria. Circa 2 mesi prima al termine del supporto esteso, GKE inizia l'upgrade dei cluster la versione secondaria successiva, a meno che il cluster non utilizzi funzionalità deprecate o su quelle di livello inferiore. Puoi utilizzare le esclusioni di manutenzione per impedire gli upgrade delle versioni minori fino alla fine del supporto esteso.
  • Al termine del supporto esteso: GKE esegue l'upgrade di tutti i cluster ancora in esecuzione la versione secondaria ora non supportata, indipendentemente dal blocco che le applicazioni presentino problemi di prestazioni. Non puoi configurare esclusioni dalla manutenzione oltre questa data.

Per saperne di più sui diversi periodi di disponibilità e sugli upgrade GKE fornisce durante il periodo di supporto esteso, consulta Versione secondaria di GKE del ciclo di vita.

Limitazioni per la registrazione di un cluster nel canale esteso

Puoi registrare solo cluster standard che eseguono la versione 1.27 o successive in il canale esteso. Sia il piano di controllo del cluster sia i nodi devono eseguire la versione 1.27 in un secondo momento.

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

Prezzi del supporto esteso

Se vuoi registrare un cluster nel canale Extended, assicurati di aver esaminato i prezzi dell'assistenza estesa. Puoi registrare un nel canale Extended senza costi aggiuntivi se il progetto ha attivata 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 Extended 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 lo strumento Extended per ridurre al minimo le interruzioni dovute agli upgrade delle versioni secondarie.

Gli scenari supportati richiedono un'azione manuale nel tempo per ottenere il massimo possono trarre 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 quanto segue e consulta l'articolo Usare il canale Esteso quando devi creare un'esperienza assistenza per ulteriori dettagli. Un segno di spunta () indica uno scenario supportato:

Scenario di upgrade Supportato Riepilogo Tempo tra le modifiche alla versione secondaria Azione manuale richiesta
Rimanere temporaneamente con una versione secondaria per più tempo Mantieni una versione secondaria per mitigare un problema che impedisce gli upgrade. Stessa frequenza media, con interruzione per tempo aggiuntivo su una versione secondaria.
  • Sposta temporaneamente un cluster da e verso il canale esteso.
  • Quando è tutto pronto, esegui l'upgrade manuale del cluster alla nuova versione secondaria.
Eseguire manualmente l'upgrade della versione secondaria 1-2 volte all'anno Ricevi nuove funzionalità, ma con upgrade minori meno frequenti, quando è ottimale per i carichi di lavoro 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 Ricevere upgrade delle versioni secondarie con la stessa frequenza di altri canali e con il più tardi possibile le nuove funzionalità. Ogni 4 mesi, in media.
  • Monitoraggio degli upgrade automatici delle versioni secondarie da versioni non supportate.

Cluster non registrati in un canale di rilascio

Sconsigliamo di utilizzare questa opzione di configurazione a causa delle limitazioni 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 "statico"). Non utilizzare questa opzione a meno che i singoli pool di nodi non possano è stato eseguito automaticamente ed è necessario eseguire manualmente l'upgrade di questi nodi. Se se il cluster non è registrato in un canale di rilascio, puoi disabilitare il nodo upgrade automatico per 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 dal canale di rilascio tutte le risorse dei cluster l'upgrade automatico dei piani di controllo e quando raggiunge la fine del supporto, viene eseguito l'upgrade automatico dei piani di controllo e dei nodi del cluster.

Se vuoi impedire che gli upgrade automatici degli annunci l'intero cluster Standard o tutti i suoi pool di nodi, utilizza un un'esclusione con il cluster registrato in un canale di rilascio. Con le esclusioni dalla manutenzione, puoi disattivare gli upgrade automatici dei nodi per tutti i pool di nodi, 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
  • Stesse versioni secondarie disponibili, versioni con upgrade automatico delle patch e versione predefinita del canale regolare
  • Stesse versioni di patch disponibili per il canale Rapido per le versioni secondarie disponibili nel canale regolare
Controllo dell'interruzione del pool di nodi
Periodi di manutenzione Disponibile Disponibile
Esclusioni di manutenzione Ambiti di esclusione della 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
Pilota automatico Disponibile Non disponibile

Differenze tra i cluster a canale rapido e i cluster alfa

I cluster creati utilizzando il canale di rilascio rapido 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 canali di rilascio non hanno scadenza. I cluster alpha scadono dopo il giorno 30 giorni.
  • Le API Kubernetes alpha non sono abilitate sui cluster che utilizzano canali di rilascio.

Passaggi successivi