Informazioni sui canali di rilascio

Usa i canali di rilascio per Google Kubernetes Engine (GKE) per scegliere le versioni dei cluster 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 le esclusioni, temporaneamente che impediscono tipi specifici di upgrade anziché tutti gli upgrade, e la sequenza l'implementazione del cluster upgrade. 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ù su quando non registrare il tuo cluster in una release di destinazione.

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 di GKE supportate e sono considerate generalmente disponibile (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à della nuova release Kubernetes Quando utilizzare questo canale
Rapida Diverse settimane dopo la GA open source upstream Ottieni l'ultima release di Kubernetes il prima possibile per poter e utilizzare le nuove funzionalità GKE non appena diventano disponibili. GKE esegue spesso l'upgrade del cluster per mantenere l'ultima patch disponibile e a fornire le funzionalità Kubernetes più recenti. Cluster che sono iscritti al canale Rapido utilizzano le versioni GA, ma consigliamo di e usare il canale Rapido per testare le nuove versioni e API di Kubernetes ambienti di pre-produzione.
Normale (opzione predefinita) 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 equilibrio tra disponibilità delle funzionalità e stabilità di rilascio, ed è quella che consigliamo alla maggior parte degli utenti.
Stabile 2-3 mesi dopo il rilascio nella versione regolare Dai la priorità alla stabilità rispetto alle nuove funzionalità. Implementazione di GKE modifiche e nuove versioni in questo canale per ultime, dopo la convalida i canali Rapido e Regolare, che concede ancora più tempo per la convalida.
Esteso Allineato al canale regolare Usa questo canale per ricevere assistenza a lungo termine, mantenendo un cluster in esecuzione su una versione secondaria il più a lungo possibile. Per scoprire di più, consulta Ricevere assistenza a lungo termine con il canale Extended.
Nessun canale (sconsigliato) Allineato al canale regolare Questa opzione non è consigliata. Quando devi disabilitare gli upgrade automatici dei nodi a livello di pool di nodi, puoi utilizzare questa opzione di configurazione. L'upgrade automatico del piano di controllo e dei nodi viene eseguito in allineamento con i canali Regolare e Stabile. Per scoprire di più, consulta Quando non registrare il cluster in un canale di rilascio.

Quando registri un cluster in un canale di rilascio, l'upgrade del cluster viene eseguito automaticamente a partire dalla data specificata nella colonna Upgrade della Pianificazione delle release di GKE.

Quando una versione ha accumulato utilizzo e ha dimostrato stabilità tra i cluster nel canale Rapid, viene promosso al canale Normale. In seguito, la versione viene promossa al canale Stabile, che riceve solo per gli 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 i tuoi cluster e l'infrastruttura di Google.

Quali versioni sono disponibili in un canale

Ogni canale di rilascio offre più versioni secondarie. Queste versioni hanno soddisfatto standard di qualificazione 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 vedere quali versioni sono disponibili in un canale di rilascio, segui le istruzioni per visualizza le versioni predefinite e disponibili per la release canali di YouTube.

  • Le nuove patch diventano disponibili almeno una settimana prima di diventare predefinite per tutti i canali.
  • Sono disponibili nuove uscite minori:
    • almeno due settimane prima di diventare predefinito per il canale rapido.
    • almeno quattro settimane prima di diventare predefinita per i canali Normale e Stabile.

Puoi testare una versione GKE appena disponibile prima dell'upgrade dell'ambiente di produzione. Ad esempio, puoi iscriverti alle notifiche relative agli upgrade per essere informati sulle nuove versioni disponibili ed eseguire l'upgrade di un di pre-produzione alla nuova versione prima che diventi la versione predefinita completamente gestita.

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 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 dal momento in cui una nuova versione è diventata predefinita nel canale di rilascio e upgrade automatici non sono stati avviati per il tuo cluster, il ritardo potrebbe essere per uno dei seguenti motivi:

  • Il cluster non è temporaneamente idoneo per gli upgrade automatici. Questo potrebbe si verificano perché:
    • Il cluster non rientra nel periodo di tempo di una configurazione periodo di manutenzione.
    • Il cluster si trova all'interno del periodo di tempo esclusione per la manutenzione.
    • Gli upgrade automatici sono paused perché il cluster utilizza funzionalità Kubernetes deprecate che sono state rimosse successiva versione secondaria.
    • È stato eseguito l'upgrade automatico del cluster versione patch precedente a 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.

Esegui le versioni delle patch da un canale più recente

Oltre alle patch disponibili elencate per un canale di rilascio, puoi eseguire versioni patch da canali di rilascio più recenti quello in cui è registrato il cluster se la minore è disponibile nella release del cluster canale.

Ad esempio, se le seguenti versioni erano disponibili nei campi Rapido e Canali abituali:

  • 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 release patch 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 esegua 1.22.4-gke.1500 e sia registrato in il 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 generali note di rilascio.

Rilascia canale Note di rilascio
Rapido canale HTML o Atom feed.
Regolare canale HTML o Atom feed.
Stabile canale 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 una livello diverso di qualità e maturità dell'IA delle release di GKE. Il seguente diagramma illustra l'adozione ciclo di rilascio 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 gli utenti iniziali (canale rapido), maggioranza precoce (canale regolare) e maggioranza (stabile) canale). La prima parte del ciclo di adozione è quella degli Innovatori, che testano le funzionalità più recenti usando la release upstream di Kubernetes. L'ultima parte di adozione è la tarda maggioranza, in cui utilizzi una versione si sta avvicinando al ritiro e devono passare a una versione supportata.

Nei tuoi ambienti di pre-produzione, utilizza il canale rapido per le versioni più recenti in cui è possibile testare le funzionalità non appena sono in disponibilità generale.

Per i carichi di lavoro di produzione che richiedono maturità rispetto alle funzionalità più recenti, consigliamo utilizzando il canale Normale (predefinito) o il canale Stabile.

  • Se hai bisogno di monitorare attentamente le nuove funzionalità, valuta la possibilità di usare lo strumento canale, che offre un equilibrio tra stabilità e freschezza dei la versione Kubernetes OSS.
  • Se il tuo requisito è la maturità, in particolare per i cluster di produzione, utilizza Canale stabile.

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

  • Migliore controllo sugli upgrade e allineamento con il lavoro nell'orario lavorativo locale del TAM.
  • 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 consigliata nel canale selezionato per allinearsi al piano di controllo dell'applicazione e per proteggerti da vulnerabilità e disallineamento delle versioni non supportate.

Ricevere assistenza a lungo termine con il canale Extended

GKE offre a lungo termine di Kubernetes per Kubernetes tramite il canale Extended. Con questo canale, puoi rimanere 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 patch più recenti della stessa versione secondaria seguendo la stessa cadenza del canale regolare.
  • Durante il periodo di supporto esteso: GKE continua a fornisce 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 secondarie fino a quando 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 di manutenzione dopo 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 lifecycle.

Limitazioni per la registrazione di un cluster nel canale Extended

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 quanto segue caratteristiche:

Prezzi per l'assistenza estesa

Se vuoi registrare un cluster nel canale Extended, assicurati di avere abbiamo esaminato i prezzi degli annunci assistenza. Puoi registrare un nel canale Extended senza costi aggiuntivi se il progetto ha attivata GKE Enterprise. Oppure per GKE Standard versione cluster, vengono applicati i costi di pagamento in base al consumo quando il cluster è registrato nella e la versione secondaria del cluster entra nel periodo di supporto 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 trarre vantaggio dal canale. Ti consigliamo di registrare un cluster nel senza avere intenzione di passare alla versione secondaria successiva, poiché GKE alla fine eseguirà l'upgrade del cluster a versioni secondarie più recenti con lo stesso frequenza maggiore degli altri canali e il tuo cluster potrebbe generare e ricevere le nuove funzionalità per ultimi.

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 contenuti 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 sulla versione secondaria più a lungo 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 Ottieni nuove funzionalità ma con upgrade di minore entità meno frequenti, quando è ottimale per i carichi di lavoro nel cluster. 1-2 volte l'anno.
  • Esegui manualmente l'upgrade del cluster a una versione secondaria più recente.
Non fare nulla e ricevere piccoli upgrade 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à. In media ogni 4 mesi.
  • Monitoraggio degli upgrade automatici delle versioni secondarie da versioni non supportate.

Quando non registrare il cluster in un canale di rilascio

Puoi scegliere di non registrare un cluster Standard in un canale di rilascio (noto come "nessun canale" e "statico"). A causa delle limitazioni imposte ai cluster non registrati nei canali di rilascio, utilizza questa opzione solo se alcuni pool di nodi non possono è 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.

Se vuoi impedire temporaneamente gli upgrade automatici per l'intero cluster o tutti i suoi nodi, usa una procedura di manutenzione esclusione con il cluster registrato in un canale di rilascio. Con le esclusioni di manutenzioni, puoi disabilitare temporaneamente gli upgrade automatici dei nodi per tutti i pool di nodi, mentre puoi disabilitare gli upgrade automatici dei nodi a livello del pool di nodi se il tuo cluster registrati a 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 Allineato al rispettivo canale di rilascio
  • 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 nel 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 di minore entità" (6 mesi)
  • "Nessun upgrade secondario o dei nodi" (6 mesi)
 Limitata a "Nessun upgrade" ambito (30 giorni)
Sequenza di implementazione Disponibile con sequenze basate sul parco risorse 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 canali di rilascio, anche se è abilitato l'upgrade automatico e non possono essere disabilitati. Impossibile 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