Controllo delle versioni e assistenza di GKE

---

Questa pagina illustra il controllo delle versioni in Google Kubernetes Engine (GKE) e i criteri per il supporto delle versioni. Puoi vedere l'implementazione e l'assistenza delle versioni attuali nella release di GKE programmazione.

Nota: la versione dell'API Kubernetes è separata da quella di Kubernetes stesso. Consulta la documentazione dell'API Kubernetes per informazioni sul versionamento dell'API Kubernetes.

Supporto delle versioni

Il supporto di GKE per le versioni minori di Kubernetes si basa sulle norme open source di Kubernetes. GKE supporta una versione secondaria fornendo versioni patch della stessa release secondaria e, su base regolare, eseguendo automaticamente l'upgrade dei cluster alle patch più recenti.

In che modo Kubernetes supporta una versione secondaria

La community del software open source (OSS) Kubernetes rilascia una versione secondaria con nuove funzionalità e miglioramenti tre volte all'anno. Ogni ciclo di rilascio dura circa 15 settimane.

Kubernetes supporta ogni versione secondaria per 14 mesi. Bug principali e sicurezza le vulnerabilità trovate in una versione secondaria supportata vengono risolte con il rilascio una versione patch ad hoc. A volte la community Kubernetes rivede del supporto della versione, se necessario. Per saperne di più, consulta Assistenza punto.

In che modo GKE supporta una versione secondaria

Dopo che Kubernetes rilascia una nuova versione secondaria, GKE la introduce prima nel canale Rapido. GKE fornisce versioni con patch durante questo periodo, ma poiché il canale rapido fornisce le versioni GKE più recenti, queste versioni sono escluse dall' SLA di GKE e potrebbero contenere problemi senza soluzioni alternative note.

Dopo la disponibilità iniziale nel canale Rapido, GKE promuove la nuova versione secondaria nel canale Regolare. GKE offre fino a per un totale di 24 mesi di assistenza per una versione secondaria dopo che la versione è stata disponibili per la creazione di nuovi cluster Canale normale. Questo l'assistenza include circa 14 mesi di assistenza standard e circa altri 10 mesi di supporto esteso disponibile con il Estesa canale. Per conoscere la disponibilità di versioni secondarie specifiche, consulta la programmazione delle release di GKE.

Ciclo di vita delle versioni minori di GKE

Il ciclo di vita di una versione minore di GKE include i seguenti passaggi chiave:

1. Kubernetes rilascia una nuova versione secondaria.
2. GKE rende disponibile la nuova versione secondaria nel canale rapido.
3. GKE rende disponibile la nuova versione secondaria nel canale regolare (inizio del periodo di assistenza standard).
4. Durante il periodo di assistenza standard, GKE fornisce le patch la versione secondaria che include nuove funzionalità e correzioni di bug.
5. La versione secondaria raggiunge la fine del supporto standard dopo circa 14 mesi in totale, entrando nel periodo di supporto esteso. Trascorso questo periodo, GKE fornisce patch di sicurezza per i cluster Canale esteso.
6. La versione minore raggiunge la fine del supporto esteso, il che significa che non riceverà ulteriori patch di sicurezza.

Aggiustamenti della disponibilità delle versioni

GKE potrebbe rivedere la fine del supporto per GKE a causa dei cambiamenti nei criteri nella community Kubernetes OSS, di vulnerabilità o altri problemi tecnici che non possono essere ragionevolmente risolto. GKE potrebbe anche estendere le date di fine del supporto intorno ai valori chiave come il Black Friday e il Cyber Monday.

GKE fornisce almeno 14 mesi di assistenza standard e fino a un totale di 24 mesi di assistenza con l'assistenza estesa.

Per ottenere le versioni più recenti disponibili, consulta le note di rilascio di GKE. GKE con regolarità aggiorna il programma delle release in base alle tempistiche degli upgrade automatici.

Periodi di disponibilità nel ciclo di vita della versione secondaria

GKE fornisce i seguenti periodi di disponibilità per Versione secondaria di Kubernetes:

Consulta la seguente tabella che riassume i periodi di disponibilità, descritti in dettaglio nelle sezioni successive:

Periodo di disponibilità	Periodo di tempo approssimativo dalla disponibilità canale regolare	Quale assistenza fornisce GKE	Accesso a questo periodo di disponibilità
Periodo di disponibilità solo rapida	Da mese -1 a mese 0	GKE fornisce versioni con patch che includono nuove funzionalità, correzioni di sicurezza e correzioni di bug. Tuttavia, queste versioni sono escluse dall'SLA di GKE e potrebbero contenere problemi senza soluzioni alternative note.	Solo canale rapido
Periodo di assistenza standard	Dal mese 1 al mese 14	GKE fornisce versioni con patch che includono nuove funzionalità, correzioni di sicurezza e correzioni di bug.	Rapido, regolare, stabile, esteso, nessun canale
Periodo di supporto esteso	Dal mese 15 al mese 24	GKE fornisce versioni con patch con correzioni di sicurezza.	Solo canale esteso (richiede GKE Enterprise o una tariffa aggiuntiva per cluster; consulta Ricevere assistenza a lungo termine con il canale Extended)

Periodo di disponibilità solo Rapida

GKE rilascia prima una nuova versione secondaria nel canale rapido. La versione accumula prima l'utilizzo e dimostra la stabilità tra i cluster di questo canale prima di essere promossa al canale Regolare. Solo i cluster registrati nel canale Rapido possono eseguire una nuova versione secondaria durante questo periodo di disponibilità.

Questo periodo dura in genere circa 1-2 mesi, ma il tempo esatto dipende per ogni versione secondaria. Per maggiori dettagli, consulta la Pianificazione stimata per i canali di rilascio.

Periodo per l'assistenza standard

Il periodo di assistenza standard per una versione secondaria di GKE inizia quando la versione viene rilasciata nel canale regolare. Tutti i cluster GKE cluster, indipendentemente dalla registrazione del canale di rilascio, possono eseguire una versione secondaria dell'assistenza standard. Durante questo periodo, gli upgrade automatici di GKE cluster a nuove versioni di patch, che includono nuove funzionalità, correzioni di sicurezza e bug.

GKE esegue automaticamente l'upgrade dei cluster nel seguente modo:

• Rapido, regolare, stabile, senza canale: upgrade automatici ad altre piattaforme supportate versioni secondarie o versioni patch della stessa versione secondaria.
• Esteso: GKE esegue automaticamente l'upgrade solo alla patch più recente della stessa versione secondaria.

Per i cluster non registrati nel canale di rilascio esteso, GKE esegue automaticamente l'upgrade dei cluster alla versione secondaria supportata successiva prima della fine del supporto standard, in base alla pianificazione del canale di rilascio del cluster. Per maggiori dettagli, consulta Pianificazione prevista del rilascio canali di YouTube. Tuttavia, GKE non esegue l'upgrade dei cluster durante questo periodo se o utilizzare funzionalità obsolete o per le API. Puoi utilizzare un'esclusione per la manutenzione per impedire temporaneamente a GKE di eseguire l'upgrade del cluster alla versione secondaria successiva.

Fine dell'assistenza standard (in precedenza fine del ciclo di vita)

Nota: GKE utilizzava in precedenza il termine fine ciclo di vita per fare riferimento alla fine della data di assistenza standard. Con l'introduzione del supporto esteso, ha aggiornato questo termine per riflettere i vari periodi di assistenza per un la versione secondaria di GKE.

Dopo il periodo di assistenza standard, la versione secondaria raggiunge la fine del l'assistenza standard (precedentemente nota come fine del ciclo di vita) e non sono più supportati e non sono disponibili per tutti i cluster non è stata effettuata la registrazione al canale Esteso.

I clienti che utilizzano una versione di fine assistenza riceveranno una notifica via email all'indirizzo il contatto del progetto prima della fine del supporto di una versione. GKE inizia inoltre a eseguire gradualmente l'upgrade automatico dei nodi (indipendentemente dall'attivazione dell'upgrade automatico) che eseguono versioni non supportate per motivi di sicurezza e compatibilità, poiché non vengono fornite nuove patch di sicurezza o correzioni di bug per le versioni di fine supporto. Prima di contattare l'assistenza clienti Google Cloud per eventuali problemi relativi a un cluster nodi che eseguono una versione non supportata, devi prima eseguire l'upgrade del cluster e nodi a una versione supportata.

Le versioni secondarie di GKE che hanno raggiunto la fine del supporto non ricevono più patch di sicurezza o correzioni di bug. Le versioni con patch di una versione secondaria che ha raggiunto la fine del supporto non sono supportate e non sono disponibili. GKE esegue automaticamente l'upgrade di tutti i cluster non registrati nel canale esteso. Per saperne di più, consulta la sezione Upgrade automatici alla fine del assistenza.

Periodo di supporto esteso

Al termine dell'assistenza standard, la versione secondaria raggiunge il periodo di supporto esteso (dal mese dal 15 al mese 24). Durante questo periodo, GKE fornisce patch per correzioni di sicurezza, inclusi i seguenti tipi di correzioni:

• Patch di sicurezza medie, alte e critiche per i componenti principali di Kubernetes, dei nodi e dei container gestiti da Google in bundle con Versione del cluster GKE.
• Per Container-Optimized OS, la fine del supporto del sistema operativo nodo potrebbero arrivare prima della fine del supporto esteso per una versione secondaria o introdurre modifiche incompatibili. Per scoprire di più su come GKE continua a fornire assistenza, consulta Aggiornamenti di Container-Optimized OS durante il periodo di assistenza esteso.

Verso la fine del supporto esteso, GKE inizia a eseguire l'upgrade dei cluster alla versione secondaria successiva. GKE non esegue l'upgrade dei cluster stanno usando funzionalità o API deprecate. Puoi utilizzare un'esclusione di manutenzione per impedire temporaneamente a GKE di eseguire l'upgrade del cluster successiva versione secondaria.

Fine del supporto esteso

Al termine del supporto esteso, GKE non fornisce patch per le correzioni di sicurezza e la versione secondaria è considerata non supportata. GKE esegue l'upgrade dei cluster che eseguono ancora la versione secondaria non supportata alla versione secondaria successiva, indipendentemente dall'utilizzo da parte del cluster di funzionalità o API ritirate.

Upgrade automatici al termine del supporto

GKE pianifica gli upgrade automatici dei cluster da una versione secondaria alla versione secondaria supportata successiva prima che la versione secondaria raggiunga la fine del supporto. Le tempistiche di questo upgrade dipendono dalla pianificazione dei canale di rilascio del cluster. Per maggiori dettagli, consulta Pianificazione prevista del rilascio canali di YouTube. Ad esempio, viene eseguito l'upgrade dei cluster registrati nel canale stabile al cluster versione secondaria più vicina alla fine del supporto standard rispetto ai cluster registrati in il canale rapido.

Durante il periodo di assistenza standard e il periodo di supporto esteso per i cluster registrata al canale Extended, puoi impedire l'upgrade di questa versione secondaria con un'esclusione di manutenzione e GKE non eseguirà l'upgrade dei cluster che utilizzano funzionalità o API deprecate.

Tuttavia, al termine del supporto standard o al termine del supporto esteso per registrati nel canale Extended, GKE esegue automaticamente l'upgrade dei cluster alla versione secondaria successiva supportata per garantire in modo che il cluster mantenga prestazioni, disponibilità e sicurezza.

Ogni versione di GKE è supportata per 14 mesi di assistenza standard e per 24 mesi di assistenza totale, incluso il supporto esteso. Non puoi mantenere il tuo cluster su una versione a tempo indeterminato, perché l'utilizzo di una versione GKE non supportata comporta rischi significativi per la sicurezza, l'affidabilità e la compatibilità, in quanto GKE non fornisce patch di sicurezza o correzioni di bug per le versioni con il supporto terminato. GKE non possono impegnarsi a fornire patch o aggiornamenti per le versioni alla fine del supporto.

GKE esegue l'upgrade del cluster nel seguente modo:

• Piano di controllo: GKE esegue automaticamente l'upgrade dei piani di controllo dei cluster alle versioni supportate quando la versione del piano di controllo non è più disponibile per la creazione di nuovi cluster.
• Nodi: GKE esegue automaticamente l'upgrade dei nodi che eseguono una versione non supportata dopo che la versione ha raggiunto la fine del supporto per garantire l'integrità e l'allineamento del cluster con le norme di scostamento della versione GKE. I nodi che eseguono versioni non supportate sono di solito viene pianificato per un upgrade automatico a una versione supportata entro un mese di fine del supporto data. L'upgrade dei nodi che eseguono versioni non supportate potrebbe non essere eseguito immediatamente al termine del ciclo di vita della versione e le tempistiche effettive possono variare a discrezione di Google.

Aggiornamenti di Container-Optimized OS durante il periodo di supporto esteso

Durante il periodo di assistenza estesa per un Versione secondaria di GKE, GKE fornisce upgrade delle patch per il cluster, che potrebbero includere Aggiornamenti di Container-Optimized OS.

La release Container-Optimized OS LTS raggiunge la fine del supporto prima della versione secondaria

La release LTS di Container-Optimized OS potrebbe raggiungere il termine del supporto prima del termine del supporto esteso per la versione secondaria che utilizza la release. In questo scenario, GKE utilizza la prossima release LTS di Container-Optimized OS disponibile per gli upgrade futuri delle patch, se possibile. GKE esegue questo aggiornamento prima Release LTS Container-Optimized OS utilizzata dai nodi versione secondaria raggiunge la fine del supporto. Gli amministratori del cluster devono valutare se eseguire l'upgrade alla versione successiva della patch GKE, che contiene una nuova release LTS del sistema operativo ottimizzato per i container, o rimanere nella stessa versione della patch GKE per non ricevere aggiornamenti nel sistema operativo del nodo e non ricevere nemmeno le patch di sicurezza per i componenti di base di Kubernetes in bundle con la versione del cluster GKE.

La prossima release LTS di Container-Optimized OS introduce modifiche incompatibili con la versione minore esistente

La prossima release LTS Container-Optimized OS potrebbe introdurre modifiche con i componenti di sistema GKE non può fornire una versione patch con aggiornamenti del sistema operativo dei nodi. Gruppo gli amministratori devono valutare se eseguire l'upgrade al cluster GKE una versione secondaria o considerare gli stessi compromessi descritti nel paragrafo.

Schema di controllo delle versioni

GKE aggiunge una versione patch di GKE standard di settore con controllo delle versioni semantico(x.y.z-gke.N):

Versione principale di Kubernetes (x)

In genere, le versioni principali vengono incrementate se vengono introdotte modifiche non compatibili con le versioni precedenti nell'API pubblica. Una versione principale incrementa il livello versione da x.y a x+1.y.

Versione secondaria di Kubernetes (y)

Kubernetes rilascia una nuova versione secondaria tre volte all'anno. Ogni ciclo di rilascio dura circa 15 settimane. Obsoleta API può essere rimossa con una nuova versione in modo minore, ad esempio con 1,22. Minore la versione incrementa la versione di Kubernetes da 1.y a 1.y+1; ad esempio Kubernetes 1.32 è la release secondaria che segue Kubernetes 1.31.

Uscita della patch Kubernetes (z)

In genere, ogni settimana diventano disponibili nuove release delle patch di Kubernetes (ad esempio 1.32.6) da utilizzare con GKE. Le release delle patch vengono implementate in modo incrementale in ogni zona.

Release patch GKE (-gke.N)

Una release patch con il suffisso -gke.N (ad esempio 1.32.6-gke.N) può includere aggiornamenti della sicurezza e correzioni di bug per GKE insieme all'open source il software Kubernetes upstream. Questi aggiornamenti o correzioni sono necessari per la compatibilità e l'interoperabilità con Google Cloud.

Controllo delle versioni disponibili e predefinite in corso...

Per informazioni sulle versioni disponibili, consulta Note di rilascio di GKE.

Puoi anche controllare quali versioni di Kubernetes sono disponibili e predefinite in un una determinata zona dalla console Google Cloud o utilizzando Google Cloud CLI.

Utilizzare la console Google Cloud per controllare le versioni

Nota: le versioni precedenti a quella predefinita di un canale sono visibili solo tramite gcloud CLI e l'API Kubernetes Engine.

Per vedere le versioni predefinite e disponibili, segui questi passaggi:

1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud.

   Vai a Google Kubernetes Engine

2. Fai clic su Crea.

3. Scegli la modalità cluster Standard, quindi fai clic su Configura.

4. Nella sezione Tipo di località, scegli un tipo di località e la località prevista per il cluster.

5. Nella sezione Versione del piano di controllo, seleziona un canale di rilascio. Per il canale vengono elencate tutte le versioni attualmente disponibili. La versione predefinita viene selezionata automaticamente.

Nota: se utilizzi la console Google Cloud per creare un cluster prima di una versione l'implementazione è stata completata, gli elenchi delle versioni disponibili potrebbero non essere precisi per la tua zona.

Utilizzare gcloud CLI per controllare le versioni

Per sapere quali versioni sono disponibili e quali sono predefinite, esegui una delle i seguenti comandi gcloud per il tuo tipo di cluster. Ogni scheda fornisce comandi per controllare le versioni per un canale di rilascio specifico o per nessun canale (statico).

Rapida

Per visualizzare le versioni predefinite e disponibili nel canale di rilascio di Rapid: esegui questi comandi:

Versione predefinita

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=RAPID" \
   --format="yaml(channels.channel,channels.defaultVersion)" \
   --location=COMPUTE_LOCATION

Versioni disponibili

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=RAPID" \
   --format="yaml(channels.channel,channels.validVersions)" \
   --location=COMPUTE_LOCATION

Sostituisci quanto segue:

• COMPUTE_LOCATION: un'ubicazione Compute Engine.

Normale

Per visualizzare le versioni predefinite e disponibili nel canale di rilascio di Regular: esegui questi comandi:

Versione predefinita

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=REGULAR" \
   --format="yaml(channels.channel,channels.defaultVersion)" \
   --location=COMPUTE_LOCATION

Versioni disponibili

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=REGULAR" \
   --format="yaml(channels.channel,channels.validVersions)" \
   --location=COMPUTE_LOCATION

Sostituisci quanto segue:

• COMPUTE_LOCATION: un Località di Compute Engine.

Stabile

Per visualizzare le versioni predefinite e disponibili nel canale di release Stable, esegui i seguenti comandi:

Versione predefinita

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=STABLE" \
   --format="yaml(channels.channel,channels.defaultVersion)" \
   --location=COMPUTE_LOCATION

Versioni disponibili

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=STABLE" \
   --format="yaml(channels.channel,channels.validVersions)" \
   --location=COMPUTE_LOCATION

Sostituisci quanto segue:

• COMPUTE_LOCATION: un'ubicazione Compute Engine.

Esteso

Per visualizzare le versioni predefinite e disponibili nel canale di rilascio di Extended: esegui questi comandi:

Versione predefinita

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=EXTENDED" \
   --format="yaml(channels.channel,channels.defaultVersion)" \
   --location=COMPUTE_LOCATION

Versioni disponibili

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=EXTENDED" \
   --format="yaml(channels.channel,channels.validVersions)" \
   --location=COMPUTE_LOCATION

Sostituisci quanto segue:

• COMPUTE_LOCATION: un Località di Compute Engine.

Nessun canale

Per visualizzare le versioni predefinite e disponibili per nessun canale (statiche), esegui il seguenti comandi:

Versione predefinita

gcloud container get-server-config \
   --format="yaml(defaultClusterVersion)" \
   --location=COMPUTE_LOCATION

Versioni disponibili del piano di controllo

gcloud container get-server-config \
   --format="yaml(validMasterVersions)" \
   --location=COMPUTE_LOCATION

Versioni dei nodi disponibili

gcloud container get-server-config \
   --format="yaml(validNodeVersions)" \
   --location=COMPUTE_LOCATION

Sostituisci quanto segue:

• COMPUTE_LOCATION: un'ubicazione Compute Engine.

Nota: per la manipolazione avanzata dell'output get-server-config, consulta gcloud documentazione sui filtri e formattazione.

Specificare la versione del cluster

Questa sezione riguarda solo i cluster creati in modalità Standard.

Quando crei o esegui l'upgrade di un cluster utilizzando gcloud CLI, puoi specifica una versione del cluster utilizzando il flag --cluster-version. Puoi utilizzare una versione specifica, ad esempio 1.9.7-gke.N. Puoi anche utilizzare un alias di versione:

• latest: specifica la versione Kubernetes supportata più recente attualmente disponibile su GKE nella zona o nella regione del cluster.
• 1.X: specifica la release della patch+gke.N valida più recente nella versione minore 1.X
• 1.X.Y: specifica la patch gke.N valida più recente nella release della patch 1.X.Y.
• -: per i control plane del cluster, specifica la versione Kubernetes predefinita per i control plane. Per gli upgrade dei nodi, specifica la versione controllata dal cluster mentre l'aereo è in esecuzione.

La creazione o l'upgrade di un cluster specificando la versione come latest forniscono upgrade automatici. Abilita gli upgrade automatici dei nodi per assicurarti che i nodi nel tuo cluster siano aggiornati con la versione completamente gestita.

Specifica della versione del nodo

Questa sezione riguarda solo i cluster creati in modalità Standard. Nei cluster Autopilot, l'upgrade dei nodi alla versione del piano di controllo avviene automaticamente e non puoi specificare una versione.

Quando crei o esegui l'upgrade di un pool di nodi, puoi specificarne la versione. Per impostazione predefinita, i nodi eseguono la stessa versione di GKE del piano di controllo. I nodi non possono essere meno recenti dei piani di controllo di più di due versioni secondarie.

A rare eccezioni, le versioni dei nodi rimangono disponibili anche se la versione del cluster non è più disponibile.

Criterio di disallineamento delle versioni di GKE

Il criterio di sfasamento della versione GKE garantisce che un cluster GKE mantenga la compatibilità tra il piano di controllo e i nodi. In un cluster GKE, i nodi possono corrispondere alla versione del piano di controllo o eseguire fino a due versioni secondarie precedenti al piano di controllo.

I nodi non possono eseguire versioni successive a quella del piano di controllo. Ad esempio: Se il piano di controllo del cluster esegue la versione 1.31, i nodi possono eseguire seguenti: 1.31, 1.30 o 1.29, ma non 1.28 o precedenti. La versione dei nodi non può essere successiva a quella del piano di controllo a causa del disallineamento delle versioni OSS di Kubernetes.

Per garantire la supportabilità e l'affidabilità, i nodi devono utilizzare una versione supportata, indipendentemente dal fatto che segua uno scostamento di versione valido.

Supporto per saltare le versioni secondarie

GKE non consente di saltare le versioni secondarie per il piano di controllo del cluster, ma puoi saltare patch le versioni secondarie. I nodi worker possono saltare le versioni secondarie. Ad esempio, è possibile eseguire l'upgrade di un pool di nodi dalla versione 1.32 alla 1.34 ignorando la versione 1.33.

Per eseguire l'upgrade di un cluster a più versioni secondarie, esegui l'upgrade del piano di controllo una versione secondaria alla volta ed esegui l'upgrade dei nodi worker alla stessa versione ogni volta. Ad esempio, per eseguire l'upgrade del piano di controllo dalla versione 1.32 alla versione 1.34, esegui prima l'upgrade dalla versione 1.32 alla versione 1.33, poi esegui l'upgrade dei nodi worker in modo che corrispondano alla versione del piano di controllo e ripeti la procedura per eseguire l'upgrade dalla versione 1.33 alla versione 1.34.

L'upgrade dei nodi worker in modo che corrispondano alle versioni ti aiuta a evitare un disallineamento delle versioni non supportato. Ti consigliamo di evitare di saltare le versioni, se possibile. Ignorare le versioni dei nodi worker di solito implica un ambito di test più ampio che, sebbene gestibile, richiede una maggiore considerazione.

In alternativa, puoi creare un nuovo cluster con la versione che preferisci rieseguire il deployment dei carichi di lavoro.