Questa pagina fornisce una pianificazione stimata delle release per ogni versione minore supportata nei canali di release. Per i cluster non registrati in un canale di rilascio, le date dei traguardi della versione possono essere derivate dal programma del canale di rilascio.
Per scoprire come Google Kubernetes Engine (GKE) esegue l'upgrade dei cluster, consulta Informazioni sugli upgrade dei cluster GKE. Per maggiori dettagli sulle norme di assistenza per le versioni di GKE, consulta Controllo delle versioni e assistenza di GKE. Per informazioni sulle destinazioni di upgrade automatico, consulta Cosa succede quando una versione diventa una destinazione di upgrade automatico in un canale di release.
Questa pagina è rivolta ad amministratori, architetti e operatori che gestiscono il ciclo di vita dell'infrastruttura tecnologica di base. Per scoprire di più sui ruoli comuni e sugli esempi di attività a cui facciamo riferimento nei contenuti di Google Cloud, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.
Le date forniscono una stima generale
Le date nella tabella sono previsioni secondo il criterio del "best effort". In base alla qualifica e alla stabilitá delle release, le date di disponibilità e di upgrade potrebbero subire ritardi. Le date future vengono aggiornate periodicamente quando diventano disponibili nuove informazioni, mentre quelle passate vengono aggiornate per garantire l'accuratezza.
Per rimanere al corrente sulla disponibilità delle versioni e sulle tempistiche degli upgrade automatici, torna su questa pagina e iscriviti alle notifiche di upgrade di GKE. Per ottenere i target di upgrade automatico per un cluster specifico, consulta Ottenere informazioni sugli upgrade di un cluster (anteprima).
La tempistica degli upgrade automatici
Dopo che una versione è stata annunciata come destinazione dell'upgrade automatico, la data dell'upgrade effettivo del cluster dipende da alcuni dei seguenti fattori:
- Le tempistiche di implementazione della versione nella regione del cluster. GKE segue una pianificazione di implementazione di più giorni (in genere quattro o più giorni) per rendere disponibili nuove versioni ed eseguire l'upgrade automatico dei piani di controllo e dei nodi del cluster. I rollout vengono messi in pausa durante i fine settimana e le festività e includono il tempo necessario per osservare e monitorare la presenza di problemi.
- La configurazione del cluster di periodi di manutenzione ed esclusioni.
- L'esposizione del cluster alle API e alle funzionalità di Kubernetes ritirate.
- La partecipazione del cluster a una sequenza di implementazione.
Se la pianificazione o i vincoli della tua attività richiedono percorsi o strategie di upgrade diversi, puoi modificare l'ambito e le tempistiche degli upgrade automatici in modo da allinearli meglio alle esigenze della tua attività. Per ulteriori informazioni, consulta Esclusione per manutenzione e Ambito della manutenzione.
Programma stimato per i canali di rilascio
GKE esegue automaticamente l'upgrade dei cluster in un canale di rilascio a partire dalle date specificate nella colonna Upgrade automatico del seguente programma. Le patch di una versione secondaria rimangono disponibili in tutti i canali di rilascio fino alla fine del supporto standard (in precedenza fine del ciclo di vita), ad eccezione dei cluster registrati nel canale esteso, in cui la versione secondaria e le relative patch rimangono disponibili fino alla fine del supporto esteso. Puoi utilizzare le esclusioni di manutenzione per impedire l'upgrade automatico di un cluster fino alla data di fine del supporto.
Le date sono previsioni secondo il criterio del massimo impegno e vengono aggiornate periodicamente quando diventano disponibili nuove informazioni. Considera la documentazione in lingua inglese come fonte attendibile se le date in altre lingue sono diverse a causa di ritardi nella traduzione.
I cluster registrati in un canale di rilascio devono rispettare la seguente pianificazione:
| Versione secondaria (data di rilascio) | Rapida | Normale | Stabile | Esteso | Fine del supporto standard (in precedenza ritiro)3 | Fine del supporto esteso3 | ||||
|---|---|---|---|---|---|---|---|---|---|---|
| Disponibile1 | Upgrade automatico2 | Disponibile1 | Upgrade automatico2 | Disponibile1 | Upgrade automatico2 | Disponibile1 | Upgrade automatico2 | |||
| 1,26 | 2023-02-21 | 2023-06-16 | 2023-04-07 | 2023-06-23 | 2023-06-16 | 2024-01-25 | N/D5 | N/A5 | 30-06-20244 | N/A5 |
| 1,27 | 2023-06-09 | 2023-08-09 | 2023-06-16 | 2024-02-03 | 2023-07-06 | 2024-04-29 | 2023-06-16 | N/A5 | 2024-10-01 | 2025-06-14 |
| 1,28 | 2023-09-04 | 2024-01-05 | 2023-11-30 | 2024-06-11 | 2024-01-05 | 2024-07-23 | 2023-11-30 | 2025-04-14 | 2025-02-04 | 2025-12-04 |
| 1,29 | 2024-01-05 | 2024-04-15 | 2024-01-25 | 2024-07-09 | 2024-06-11 | 2024-08-09 | 2024-01-25 | 2025-10-04 | 2025-03-21 | 2026-01-25 |
| 1,30 | 2024-04-29 | 2024-07-30 | 2024-07-30 | 2024-09-17 | 2024-08-13 | 2024-09-24 | 2024-07-30 | 2025-11-25 | 2025-09-30 | 2026-07-30 |
| 1,31 | 2024-08-20 | 2024-09-17 | 2024-10-22 | 2024-126 | 2024-116 | 2025-016 | 2024-10-22 | 2026-05-30 | 2025-12-22 | 2026-10-22 |
Programma stimato per i cluster senza canale (in precedenza statici)
GKE esegue automaticamente l'upgrade dei cluster non in un canale di rilascio alle versioni secondarie più recenti a partire dalle date specificate nella colonna Upgrade automatico della pianificazione del canale di rilascio stabile. Puoi utilizzare le esclusioni per la manutenzione per impedire l'upgrade automatico di un cluster per fino a 30 giorni se il cluster non è registrato in un canale di rilascio.
I cluster non registrati in un canale di rilascio seguono questa pianificazione di disponibilità e assistenza:
- Data di disponibilità: la stessa data di disponibilità della versione secondaria di Kubernetes nel canale Regolare e le stesse versioni con patch disponibili nel canale Rapido per le versioni secondarie disponibili nel canale Regolare
- Data di upgrade automatico: la stessa data di upgrade automatico per la versione secondaria di Kubernetes nel canale Stable e la stessa data di upgrade automatico per le versioni delle patch del canale Regolare
- Fine dell'assistenza standard (in precedenza nota come fine vita): la stessa data di fine assistenza della versione secondaria di Kubernetes nei canali di rilascio diversi dal canale Esteso
Note
-
La data di disponibilità è la data approssimativa in cui la versione di Kubernetes raggiunge per la prima volta la produzione e occorre circa una settimana per renderla disponibile in tutte le regioni. ↩
-
Le versioni di Kubernetes sono generalmente disponibili su ogni canale di rilascio alcune settimane prima dell'inizio degli upgrade automatici, in modo da poter testare la nuova versione. A partire dalla data di inizio degli upgrade automatici, per i cluster iscritti ai canali di rilascio verrà eseguito automaticamente l'upgrade alla versione secondaria a cui si fa riferimento. ↩
-
Fine del supporto: per i cluster nei canali Rapido, Regolare, Stabile o senza canale, nuove funzionalità, patch di sicurezza o correzioni di bug verranno rese disponibili per questa versione secondaria fino alla data di fine del supporto standard (in precedenza fine del ciclo di vita). Per i cluster nel canale esteso, GKE continua a supportare la versione secondaria fino alla data di fine del supporto esteso. Se un cluster esegue una versione con patch di una versione secondaria che ha raggiunto la data di fine del supporto, GKE esegue l'upgrade automatico del cluster per garantire l'operabilità e la conformità del cluster. Per approfondire, consulta il ciclo di vita delle versioni secondarie di GKE. ↩
-
Dopo il 30 giugno 2024, quando la versione 1.26 raggiungerà la fine del supporto, GKE inizierà a eseguire l'upgrade automatico dei cluster che utilizzano ancora la versione 1.26 e le API ritirate (rimosse nella versione 1.27) alla versione 1.27. Dopo il 30 giugno 2024, GKE non metterà più in pausa gli upgrade automatici per i cluster che utilizzano ancora le API deprecate rimosse nella versione 1.27. Ti consigliamo di eseguire l'upgrade dei cluster alla versione 1.27 il prima possibile, poiché le versioni secondarie di GKE che hanno raggiunto la fine del supporto non riceveranno più patch di sicurezza e correzioni di bug. Per scoprire di più sul ciclo di vita delle versioni secondarie di GKE, consulta Controllo delle versioni e assistenza di GKE. ↩
-
Puoi registrare solo i cluster che eseguono la versione 1.27 o successive nel canale esteso. Le versioni precedenti non sono idonee per l'assistenza a lungo termine con il canale esteso. Per saperne di più, consulta Ricevere assistenza a lungo termine con il canale Extended. ↩
-
Le date con un solo mese (ad es. 03/2025) o un trimestre dell'anno (ad es. 3° trimestre 2025) sono approssimazioni che verranno aggiornate con una data quando sarà nota. ↩