Controllo delle versioni e assistenza di GKE

Questa pagina spiega il controllo delle versioni in Google Kubernetes Engine (GKE) e le norme per il supporto delle versioni. Nel tempo, GKE esegue l'upgrade dei cluster alle versioni più recenti di Kubernetes. Per saperne di più su come funzionano gli upgrade, consulta Informazioni sugli upgrade dei cluster GKE.

Puoi visualizzare il programma di implementazione e assistenza delle versioni attuali nella programmazione delle release di GKE.

Nota: l'API Kubernetes ha un controllo delle versioni separato da Kubernetes stesso. Consulta la documentazione dell'API Kubernetes per informazioni sul controllo delle versioni dell'API Kubernetes.

Supporto delle versioni secondarie

Il supporto di GKE per le versioni secondarie di Kubernetes si basa sulle norme open source di Kubernetes. Per supportare una versione secondaria, GKE fornisce versioni patch della release secondaria ed esegue regolarmente upgrade automatici del cluster per applicare queste patch più recenti. Per ulteriori informazioni sul supporto delle versioni secondarie, consulta la sezione seguente. Per informazioni su come GKE supporta le versioni patch, consulta Supporto delle versioni patch.

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. I bug principali e le vulnerabilità di sicurezza rilevati in una versione secondaria supportata vengono corretti con il rilascio di una versione patch ad hoc. La community di Kubernetes a volte rivede il calendario di assistenza delle versioni, se necessario. Per saperne di più, consulta Periodo di assistenza.

Come GKE supporta una versione secondaria

Dopo il rilascio di una nuova versione secondaria di Kubernetes, GKE introduce prima la versione secondaria nel canale Rapido. GKE fornisce versioni 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 al canale regolare. GKE fornisce fino a un totale di 24 mesi di assistenza per una versione secondaria dopo che la versione è stata resa disponibile per la creazione di nuovi cluster nel canale Regolare. Questo supporto include circa 14 mesi di assistenza standard e circa altri 10 mesi di assistenza estesa disponibile con il canale Extended. Per visualizzare la disponibilità di versioni secondarie specifiche, consulta la programmazione delle release di GKE.

Ciclo di vita delle versioni secondarie di GKE

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

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

Modifiche alla disponibilità delle versioni

GKE potrebbe rivedere la fine del supporto per le versioni GKE a causa di cambiamenti nelle norme della community Kubernetes OSS, della scoperta di vulnerabilità o di altri problemi tecnici che non possono essere risolti in modo ragionevole. GKE potrebbe anche estendere le date di fine del supporto in periodi aziendali 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 ultime versioni disponibili, consulta le note di rilascio di GKE. GKE aggiorna regolarmente la pianificazione delle release per riflettere le tempistiche degli upgrade automatici.

Periodi di disponibilità nel ciclo di vita della versione secondaria

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

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

Periodo di disponibilità	Intervallo di tempo approssimativo dalla disponibilità canale regolare	Quale supporto fornisce GKE	Accesso a questo periodo di disponibilità
Periodo di disponibilità solo per Rapid	Mese -1 fino al mese 0	GKE fornisce versioni patch con nuove funzionalità, correzioni di sicurezza e correzioni di bug. Tuttavia, queste versioni sono escluse dallo 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 patch con nuove funzionalità, correzioni di sicurezza e correzioni di bug.	Rapido, Regolare, Stabile, Esteso, Nessun canale (ritirato)
Periodo di assistenza esteso	Dal 15° al 24° mese	GKE fornisce versioni patch con correzioni di sicurezza.	Solo canale esteso (richiede una tariffa aggiuntiva per cluster, vedi Ricevere assistenza a lungo termine con il canale esteso)

Periodo di disponibilità solo di Rapid

GKE rilascia prima una nuova versione secondaria nel canale rapido. La versione accumula prima l'utilizzo e dimostra stabilità nei 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 in genere dura circa 1-2 mesi, ma la tempistica esatta dipende da ogni versione secondaria. Per maggiori dettagli, consulta la sezione Programma stimato per i canali di rilascio.

Periodo di 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, indipendentemente dalla registrazione al canale di rilascio, possono eseguire una versione secondaria nell'assistenza standard. Durante questo periodo, GKE esegue automaticamente l'upgrade dei cluster a intervalli regolari alle nuove versioni patch, che includono nuove funzionalità, correzioni di sicurezza e correzioni di bug.

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

• Rapido, Regolare, Stabile, Nessun canale (ritirato): upgrade automatici ad altre versioni secondarie supportate o versioni delle patch della stessa versione secondaria.
• Esteso: GKE esegue automaticamente l'upgrade solo alle versioni patch più recenti della stessa versione secondaria.

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

Fine del supporto standard (in precedenza fine del ciclo di vita)

Nota: GKE in precedenza utilizzava il termine fine del ciclo di vita per indicare la data di fine dell'assistenza standard. Con l'introduzione del supporto esteso, abbiamo aggiornato questo termine per riflettere i diversi periodi di supporto per una versione secondaria di GKE.

Al termine del periodo di assistenza standard, la versione secondaria raggiunge la fine dell'assistenza standard (precedentemente nota come fine del ciclo di vita) e non è più supportata e disponibile per tutti i cluster non registrati nel canale esteso.

I clienti che utilizzano una versione alla fine del supporto ricevono una notifica via email al contatto del progetto prima della fine del supporto di una versione. GKE inizia anche a eseguire l'upgrade automatico graduale dei nodi (indipendentemente dall'attivazione dell'upgrade automatico) in esecuzione su versioni non supportate per motivi di sicurezza e compatibilità perché non vengono fornite nuove patch di sicurezza o correzioni di bug per le versioni alla fine del supporto. Prima di contattare l'assistenza clienti Google Cloud per eventuali problemi con un cluster o con nodi che eseguono una versione non supportata, devi prima eseguire l'upgrade del cluster e dei 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 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 Extended. Per saperne di più, consulta Upgrade automatici alla fine del supporto.

Periodo di supporto esteso

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

• Patch di sicurezza di livello medio, alto e critico per i componenti principali di Kubernetes, il sistema operativo del nodo e i container gestiti da Google inclusi nella versione del cluster GKE.
• Per Container-Optimized OS, la fine del supporto del sistema operativo del nodo potrebbe verificarsi prima della fine del supporto esteso per la versione secondaria di GKE 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 l'upgrade dei cluster alla versione secondaria successiva. GKE non esegue l'upgrade dei cluster se utilizzano API o funzionalità deprecate. Puoi utilizzare un'esclusione della manutenzione per impedire temporaneamente a GKE di eseguire l'upgrade del cluster alla versione secondaria successiva.

Fine del supporto esteso

Al termine del supporto esteso, GKE non fornisce patch per le correzioni di sicurezza e la versione secondaria non è più supportata. GKE esegue l'upgrade dei cluster in cui è ancora in esecuzione la versione secondaria non supportata alla versione secondaria successiva, indipendentemente dall'utilizzo di API o funzionalità deprecate del cluster.

Upgrade automatici al termine del supporto

GKE pianifica gli upgrade automatici dei cluster da una versione secondaria alla successiva supportata prima che la versione secondaria raggiunga la fine del supporto. La tempistica di questo upgrade dipende dalla pianificazione del canale di rilascio del cluster. Per maggiori dettagli, consulta la sezione Programma stimato per i canali di rilascio. Ad esempio, i cluster registrati nel canale stabile vengono sottoposti all'upgrade alla versione secondaria successiva più vicino alla fine del supporto standard rispetto ai cluster registrati nel canale rapido.

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

Tuttavia, al termine del supporto standard o del supporto esteso per i cluster registrati al canale Extended, GKE esegue automaticamente l'upgrade dei cluster alla successiva versione secondaria supportata per garantire che il cluster rimanga efficiente, disponibile e sicuro.

Ogni versione di GKE è supportata per 14 mesi di assistenza standard e per 24 mesi di assistenza totale, inclusa l'assistenza estesa. Non puoi mantenere il cluster su una versione a tempo indeterminato, perché l'utilizzo di un cluster con una versione di 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 alla fine del supporto. GKE non può impegnarsi a fornire patch o aggiornamenti per le versioni alla fine del supporto.

GKE esegue l'upgrade del cluster nel seguente modo:

• Control plane: GKE esegue automaticamente l'upgrade dei control plane del cluster alle versioni supportate quando la versione del control plane 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à del cluster e l'allineamento con le norme di distorsione della versione GKE. I nodi che eseguono versioni non supportate sono in genere pianificati per un upgrade automatico a una versione supportata entro un mese dalla data di fine del supporto. È possibile che i nodi che eseguono versioni non supportate non vengano sottoposti a upgrade immediatamente al fine del ciclo di vita della versione e la tempistica effettiva può variare a discrezione di Google.

Prevenzione temporanea e di emergenza degli upgrade automatici al termine del supporto

Come misura temporanea, da utilizzare solo in caso di emergenze in cui non sono disponibili altre opzioni, puoi ritardare gli upgrade automatici al termine del supporto fino a 90 giorni dopo la data di fine del supporto configurando un'esclusione dalla manutenzione con l'ambito predefinito "Nessun upgrade". Non consigliamo questa pratica a causa dei rischi associati all'esecuzione di una versione non supportata. Una volta scaduta l'esclusione dalla manutenzione, GKE esegue l'upgrade del cluster.

Identificare i cluster che eseguono una versione secondaria dopo la fine del supporto standard

GKE identifica i cluster che soddisfano entrambe le seguenti condizioni:

• Il control plane esegue una versione secondaria che ha raggiunto la fine dell'assistenza standard.
• Il cluster non è registrato nel canale esteso.

GKE consiglia di eseguire l'upgrade di questi cluster a causa dei rischi associati all'esecuzione di una versione secondaria non supportata. GKE esegue l'upgrade dei cluster alla successiva versione secondaria supportata se la versione esistente non è supportata nel canale di rilascio del cluster.

GKE fornisce queste indicazioni con un insight e un suggerimento tramite il servizio Recommender. Queste indicazioni non si applicano ai cluster registrati nel canale Extended, che possono continuare a eseguire una versione secondaria fino alla fine del supporto esteso. Per scoprire di più su come gestire gli approfondimenti e i suggerimenti di Recommender, consulta Ottimizzare l'utilizzo di GKE con approfondimenti e suggerimenti.

Per trovare i cluster in cui il control plane esegue una versione oltre la fine del supporto, puoi utilizzare uno dei seguenti modi:

• Utilizza la console Google Cloud .
• Utilizza gcloud CLI o l'API Recommender specificando il CLUSTER_VERSION_END_OF_LIFE sottotipo di motore per suggerimenti.

Per istruzioni, scopri come visualizzare approfondimenti e consigli.

Per implementare questo consiglio, esegui l'upgrade del control plane del cluster a una versione secondaria supportata. Per le versioni secondarie supportate e le date di fine del supporto, consulta la programmazione delle release di GKE. In alternativa, passa il cluster al canale Extended se vuoi continuare a utilizzare la versione secondaria esistente fino alla fine del supporto esteso.

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

Durante il periodo di supporto esteso per una versione secondaria di GKE, GKE fornisce upgrade delle patch per il cluster. Questi upgrade delle patch potrebbero includere aggiornamenti di Container-Optimized OS alla milestone Container-Optimized OS esistente utilizzata dalla versione secondaria di GKE. Le versioni secondarie di GKE in genere utilizzano un traguardo durante il periodo di assistenza standard fino all'inizio del periodo di supporto esteso.

Tuttavia, il traguardo di Container-Optimized OS utilizzato dalla versione secondaria di GKE raggiunge la fine del supporto, in genere durante il periodo di assistenza esteso per una versione secondaria di GKE. Quando si verifica questo problema, GKE crea tutte le versioni patch GKE successive con la successiva milestone di Container-Optimized OS. Per scoprire di più sui cicli di vita delle milestone, consulta lo schema di controllo delle versioni per Container-Optimized OS.

Esamina lo scenario seguente per capire come procedono gli upgrade automatici e quali decisioni devono prendere gli amministratori del cluster quando GKE non può più introdurre aggiornamenti di Container-Optimized OS nella stessa milestone per una versione secondaria di GKE.

La milestone di Container-Optimized OS raggiunge la fine del supporto prima della fine del supporto esteso della versione secondaria

Il traguardo di Container-Optimized OS raggiunge la propria fine del supporto prima della fine del supporto esteso per la versione secondaria che utilizza il traguardo. In questo scenario, GKE utilizza la prossima milestone disponibile di Container-Optimized OS per i futuri upgrade delle patch. GKE esegue questo aggiornamento prima che la milestone di Container-Optimized OS utilizzata dalla versione secondaria raggiunga la fine del supporto.

Gli amministratori del cluster devono valutare se eseguire l'upgrade dei nodi worker del cluster, perché GKE non eseguirà automaticamente l'upgrade di questi nodi alla versione patch successiva con il nuovo traguardo. Puoi eseguire l'upgrade manuale dei nodi alla successiva versione patch di GKE, che contiene un nuovo traguardo. In alternativa, puoi mantenere i nodi che eseguono la stessa versione patch di GKE per non utilizzare il nuovo traguardo. Tuttavia, i nodi non riceveranno patch di sicurezza fino all'upgrade alla patch o alla versione secondaria successiva.

Upgrade automatici per la nuova milestone di Container-Optimized OS

La successiva versione patch per una versione secondaria di GKE nel periodo di assistenza esteso utilizza una milestone più recente del Container-Optimized OS rispetto alle versioni patch precedenti. GKE esegue automaticamente l'upgrade dei cluster nei seguenti modi quando la nuova versione patch diventa un target di upgrade automatico:

• Upgrade dei control plane:
  • GKE esegue l'upgrade del control plane alla patch successiva, come di consueto.
• Upgrade dei nodi:
  • GKE non esegue l'upgrade dei nodi alla versione patch successiva.
  • GKE esegue l'upgrade dei nodi alla versione secondaria successiva verso la fine del supporto esteso, come di consueto. Per saperne di più, consulta Upgrade automatici alla fine del supporto.

Poiché la nuova versione milestone potrebbe introdurre modifiche incompatibili con i tuoi workload, GKE mette in pausa gli upgrade automatici dei nodi alla patch successiva. Puoi eseguire l'upgrade manuale alla nuova versione patch se hai stabilito che i tuoi workload sono compatibili con la successiva milestone di Container-Optimized OS. Se esegui l'upgrade manuale dei nodi a una versione patch che utilizza la nuova milestone di Container-Optimized OS, GKE riprende gli upgrade automatici delle patch dei nodi perché ora eseguono la nuova milestone.

Notifica del cluster quando le nuove versioni delle patch utilizzano il nuovo traguardo

GKE invia una notifica del cluster per informarti quando si verifica questa situazione. Questa notifica viene inviata quando la prima versione patch che utilizza la nuova milestone di Container-Optimized OS diventa disponibile nel canale Extended.

Quando ricevi questa notifica, valuta se vuoi eseguire manualmente l'upgrade dei nodi alla patch o alla versione secondaria successiva oppure se non vuoi ricevere versioni patch successive per questa versione secondaria durante il periodo di supporto esteso. Per saperne di più, consulta Le nuove versioni patch passano al nuovo traguardo di Container-Optimized OS durante il supporto esteso.

Schema di controllo delle versioni

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

Versione principale di Kubernetes (x)

Le versioni principali vengono in genere incrementate se vengono introdotte modifiche non compatibili con le versioni precedenti nell'API pubblica. Una versione principale incrementa la versione di Kubernetes 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. Le API deprecate potrebbero essere rimosse con una nuova versione secondaria, ad esempio con 1.22. Una versione secondaria 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.

Release patch di Kubernetes (z)

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

Release patch GKE (-gke.N)

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

Controllare le versioni disponibili e predefinite

Per informazioni sulle versioni disponibili, consulta le note di rilascio di GKE.

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

Utilizza la console Google Cloud per controllare le versioni

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

Per visualizzare le versioni predefinite e disponibili:

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 control plane, seleziona un canale di rilascio. Per quel 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 del completamento dell'implementazione di una versione, gli elenchi delle versioni disponibili potrebbero non essere accurati per la tua zona.

Utilizza gcloud CLI per controllare le versioni

Per vedere quali versioni sono disponibili e quali sono predefinite, esegui uno dei 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 (obsoleto).

Rapido

Per visualizzare le versioni predefinite e disponibili nel canale di rilascio 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: una posizione di Compute Engine.

Normale

Per visualizzare le versioni predefinite e disponibili nel canale di rilascio 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: una posizione di Compute Engine.

Stabile

Per visualizzare le versioni predefinite e disponibili nel canale di rilascio Stable, esegui questi 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: una posizione di Compute Engine.

Esteso

Per visualizzare le versioni predefinite e disponibili nel canale di rilascio 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: una posizione di Compute Engine.

Nessun canale (obsoleto)

Per visualizzare le versioni predefinite e disponibili per nessun canale (deprecato), esegui questi comandi:

Versione predefinita

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

Versioni del control plane disponibili

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

Versioni del nodo disponibili

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

Sostituisci quanto segue:

• COMPUTE_LOCATION: una posizione di Compute Engine.

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

Specificare la versione del cluster

Questa sezione si applica solo ai cluster creati in modalità Standard.

Quando crei o esegui l'upgrade di un cluster utilizzando gcloud CLI, puoi specificare 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 di Kubernetes più recente supportata attualmente disponibile su GKE nella zona o nella regione del cluster.
• 1.X: specifica la release della patch patch+gke.N valida più recente nella versione secondaria 1.X
• 1.X.Y: specifica la patch gke.N valida più recente nella release di patch 1.X.Y.
• -: per i control plane del cluster, specifica la versione predefinita di Kubernetes per i control plane. Per gli upgrade dei nodi, specifica la versione in esecuzione del control plane del cluster.

La creazione o l'upgrade di un cluster specificando la versione come latest non fornisce upgrade automatici. Attiva gli upgrade automatici dei nodi per assicurarti che i nodi del cluster siano aggiornati all'ultima versione stabile.

Specifica della versione del nodo

Questa sezione si applica solo ai cluster creati in modalità Standard. Nei cluster Autopilot, i nodi vengono aggiornati automaticamente alla versione del piano di controllo 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 control plane. I nodi non possono essere più vecchi di due versioni secondarie rispetto ai control plane.

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

Policy di asimmetria delle versioni di GKE

Il criterio di asimmetria delle versioni di GKE garantisce che un cluster GKE mantenga la compatibilità tra il control plane e i nodi. In un cluster GKE, i nodi possono corrispondere alla versione del control plane o eseguire fino a due versioni secondarie precedenti a quella del control plane.

I nodi non possono eseguire versioni più recenti di quella del control plane. Ad esempio, se il control plane del cluster esegue la versione 1.31, i nodi possono eseguire le seguenti versioni: 1.31, 1.30 o 1.29, ma non 1.28 o versioni precedenti. La versione dei nodi non può essere più recente di quella del control plane a causa delle norme sul disallineamento delle versioni OSS di Kubernetes.

Per garantire la compatibilità e l'affidabilità, i nodi devono utilizzare una versione supportata indipendentemente dal fatto che seguano una distorsione di versione valida.

Identificare i cluster con un disallineamento delle versioni non supportato

GKE identifica i cluster in cui i nodi eseguono una versione incompatibile con il control plane a causa del disallineamento delle versioni. GKE consiglia di eseguire l'upgrade dei nodi che eseguono questa versione non supportata, fornendo queste indicazioni con un approfondimento e un suggerimento tramite il servizio Recommender. Per scoprire di più su come gestire approfondimenti e suggerimenti di Recommender, consulta l'articolo Ottimizzare l'utilizzo di GKE con approfondimenti e suggerimenti.

Per trovare cluster con una distorsione della versione non supportata, puoi utilizzare uno dei seguenti modi:

• Utilizza la console Google Cloud .
• Utilizza gcloud CLI o l'API Recommender specificando il CLUSTER_VERSION_SKEW_UNSUPPORTED sottotipo di motore per suggerimenti.

Per istruzioni, scopri come visualizzare approfondimenti e consigli.

Per implementare questo consiglio, esegui l'upgrade di tutti i nodi che eseguono una versione secondaria precedente di più di due versioni secondarie rispetto alla versione del control plane.

Supporto per l'omissione delle versioni secondarie

GKE non consente di ignorare le versioni secondarie per il control plane del cluster, ma puoi ignorare le versioni patch. 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 saltando la versione 1.33.

Per eseguire l'upgrade di un cluster in più versioni secondarie, esegui l'upgrade del control plane di una versione secondaria alla volta ed esegui l'upgrade dei nodi worker alla stessa versione ogni volta. Ad esempio, per eseguire l'upgrade del control plane 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 control plane e poi ripeti la procedura per eseguire l'upgrade dalla versione 1.33 alla versione 1.34.

L'upgrade dei nodi di lavoro in modo che corrispondano alle versioni ti aiuta a evitare distorsioni di versione non supportate. Ti consigliamo di evitare di saltare le versioni, se possibile. Il salto delle versioni dei nodi di lavoro di solito implica un ambito di test più ampio che, sebbene gestibile, richiede maggiore attenzione.

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

Supporto delle versioni patch

GKE introduce prima una versione patch nel canale rapido, per poi promuoverla gradualmente negli altri canali di rilascio. Quando GKE rende disponibile una versione patch in un canale di rilascio, puoi creare, eseguire l'upgrade o, in casi specifici, il downgrade del cluster a questa versione. Mentre una versione secondaria è supportata, GKE continua a introdurre nuove versioni patch della versione secondaria in un canale di rilascio.

Le versioni patch precedenti rimangono disponibili nel canale di rilascio per i nodi fino a quando la versione secondaria non raggiunge la fine del supporto, ma vengono rimosse e rese non disponibili per l'utilizzo con il control plane prima di questa data. Quando GKE rimuove una versione patch per l'utilizzo con il control plane, non puoi creare, eseguire l'upgrade o il downgrade del control plane del cluster alla versione patch rimossa. Se il control plane del cluster esegue una versione patch rimossa, ti consigliamo di eseguire l'upgrade del control plane all'ultima destinazione di upgrade automatico.

Deprecazione delle versioni patch per il control plane

Le seguenti informazioni si applicano a qualsiasi versione patch in cui la versione secondaria è già stata introdotta nel canale regolare.

Prima di rimuovere le versioni delle patch da un canale di rilascio per l'utilizzo con un control plane del cluster, GKE ritira la versione della patch. Sebbene le versioni patch ritirate non siano più elencate come disponibili per il control plane, puoi comunque utilizzarle per creare, eseguire l'upgrade o il downgrade del control plane.

Ti consigliamo di eseguire l'upgrade a una versione patch più recente il prima possibile. Utilizza le versioni ritirate solo se la procedura di implementazione del tuo ambiente ti impedisce rigorosamente di eseguire l'upgrade prima. GKE ritira una versione patch per 90 giorni o finché la versione secondaria non raggiunge la fine del supporto standard (Regolare, Stabile, Nessun canale) o la fine del supporto esteso (canale Esteso).