Controllo delle versioni e assistenza di GKE

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

Puoi visualizzare l'implementazione delle versioni attuali e la pianificazione dell'assistenza nella programmazione delle release di GKE.

Supporto delle versioni secondarie

Il supporto di GKE per le versioni secondarie di Kubernetes si basa sulle policy open source di Kubernetes. Per supportare le versioni secondarie disponibili durante il loro ciclo di vita, GKE fornisce versioni patch ed esegue regolarmente upgrade automatici dei cluster per applicare le patch più recenti. Per informazioni su come GKE supporta le versioni patch, consulta Supporto delle versioni patch.

Oltre a supportare le versioni secondarie disponibili, GKE fornisce anche versioni patch alpha della versione secondaria successiva nel ciclo di rilascio di Kubernetes fino a quattro mesi prima che la versione secondaria diventi disponibile per tutti i cluster nel canale rapido. Queste versioni alpha sono disponibili solo per i cluster GKE alpha nel canale rapido e sono destinate agli early adopter che vogliono sperimentare le funzionalità in arrivo.

In che modo Kubernetes supporta una versione secondaria

La community di software open source (OSS) Kubernetes rilascia una versione secondaria con nuove funzionalità e miglioramenti tre volte l'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 proprio calendario di assistenza per le versioni, se necessario. Per saperne di più, consulta Periodo di assistenza.

In che modo GKE supporta una versione secondaria

Prima del rilascio di una nuova versione secondaria stabile, il progetto Kubernetes rilascia versioni patch sperimentali e instabili di quella versione secondaria. GKE introduce versioni patch alpha basate su queste versioni sperimentali nel canale Rapido solo per i cluster GKE alpha. Analogamente ad altre versioni patch nel canale rapido, le versioni alpha sono escluse dallo SLA di GKE.

Dopo che Kubernetes ha rilasciato la nuova versione secondaria stabile, GKE rimuove le versioni alpha di quella versione secondaria e rende disponibili le versioni patch per quella versione secondaria per qualsiasi cluster nel canale rapido. Poiché il canale rapido fornisce le versioni patch di GKE più recenti, queste versioni sono escluse dallo 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 questa è stata resa disponibile per la creazione di nuovi cluster nel canale Regolare. Questa assistenza include circa 14 mesi di assistenza standard e circa altri 10 mesi di assistenza estesa disponibili con il canale Esteso. Per visualizzare la disponibilità di versioni secondarie specifiche, consulta la programmazione delle release di GKE.

Ciclo di vita della versione secondaria di GKE

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

  1. Fino a quattro mesi prima della data di rilascio di una versione secondaria, GKE rende disponibili le versioni patch alpha per quella versione secondaria nel canale rapido solo per i cluster alpha.
  2. Kubernetes rilascia la nuova versione secondaria.
  3. GKE rende disponibile la nuova versione secondaria nel canale rapido e rimuove tutte le versioni patch alpha esistenti per quella versione secondaria.
  4. GKE rende disponibile la nuova versione secondaria nel canale regolare (inizio del periodo di assistenza standard).
  5. Durante il periodo di assistenza standard, GKE fornisce patch per la versione secondaria che includono nuove funzionalità, correzioni di sicurezza e correzioni di bug.
  6. La versione secondaria raggiunge la fine dell'assistenza standard dopo circa 14 mesi in totale, entrando nel periodo di assistenza estesa. Trascorso questo periodo, GKE fornisce patch di sicurezza per i cluster nel canale Extended.
  7. 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 di GKE a causa di modifiche alle policy nella community OSS di Kubernetes, della scoperta di vulnerabilità o di altri problemi tecnici che non possono essere ragionevolmente risolti. 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 il programma 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:

Periodi di assistenza. GKE supporta una versione secondaria per un totale di 24 mesi.

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à del canale regolare Che tipo di assistenza fornisce GKE Accesso a questo periodo di disponibilità
Periodo di disponibilità della versione alpha Mese -5 fino al mese -1 GKE introduce nuove versioni patch alpha nel canale rapido fino all'inizio del periodo di disponibilità solo per il canale rapido. Le versioni alpha delle patch sono disponibili solo per i cluster alpha, non hanno assistenza tecnica o SLA ed è molto probabile che contengano problemi. Quando la versione secondaria diventa disponibile per tutti i cluster nel canale rapido alla fine del periodo di disponibilità solo alpha, GKE rimuove tutte le versioni alpha dal canale rapido. Solo canale rapido (richiede cluster alpha)
Periodo di disponibilità solo per Rapid Mese -1 fino al mese 0 GKE rende disponibile la versione secondaria per tutti i cluster nel canale rapido fornendo 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. GKE rimuove anche tutte le versioni alpha disponibili per quella versione secondaria dal canale rapido. Solo canale rapido
Periodo di assistenza standard Mese 1 - 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 estesa Dal 15° al 24° mese GKE fornisce versioni patch con correzioni di sicurezza. Solo canale esteso (richiede una tariffa aggiuntiva per cluster, consulta Ottieni assistenza a lungo termine con il canale esteso)

Periodo di disponibilità della versione alpha

GKE rilascia versioni patch alpha di una versione secondaria imminente nel canale rapido fino a quattro mesi prima del rilascio della versione secondaria. Le versioni alpha sono disponibili solo per i cluster alpha. GKE rilascia ulteriori versioni patch alpha nelle settimane successive e, in genere, mantiene da una a tre versioni alpha attive.

Questo periodo dura fino a quando GKE non rilascia la versione secondaria stabile nel canale rapido. Dopo la release stabile, GKE rimuove tutte le versioni delle patch alpha per quella versione secondaria dal canale rapido, perché sono disponibili per l'installazione le versioni delle patch stabili.

Periodo di disponibilità solo per Rapid

GKE rilascia per prima cosa una nuova versione secondaria nel canale rapido. La versione accumula prima l'utilizzo e dimostra la stabilità tra i cluster in 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 la tempistica esatta dipende da ogni versione secondaria. Per maggiori dettagli, consulta Pianificazione stimata 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 in assistenza standard. Durante questo periodo, GKE esegue automaticamente l'upgrade dei cluster a nuove versioni patch su base regolare, 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 (deprecato): upgrade automatici ad altre versioni secondarie supportate o versioni 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 Extended, 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 stimata per i canali di rilascio. Tuttavia, GKE non esegue l'upgrade dei cluster durante questo periodo se utilizzano funzionalità o API deprecate. Puoi utilizzare una esclusione dalla manutenzione per impedire temporaneamente a GKE di eseguire l'upgrade del cluster alla versione secondaria successiva.

Fine del supporto standard (precedentemente fine del ciclo di vita)

Dopo il 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 eseguono una versione non più supportata vengono informati tramite un'email inviata al contatto del progetto prima della fine del supporto di una versione. GKE inizia anche 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à, perché non vengono fornite nuove patch di sicurezza o correzioni di bug per le versioni non più supportate. 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 al termine del supporto.

Periodo di assistenza estesa

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 medie, alte e critiche per i componenti principali di Kubernetes, il sistema operativo dei nodi 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 avvenire 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 estesa.

Verso la fine del periodo di assistenza estesa, GKE inizia a eseguire l'upgrade dei cluster alla versione secondaria successiva. GKE non eseguirà l'upgrade dei cluster che utilizzano API o funzionalità 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 esteso

Al termine del periodo di assistenza estesa, 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 alla fine 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. La tempistica di questo upgrade dipende dalla pianificazione del canale di rilascio del cluster. Per maggiori dettagli, consulta Pianificazione stimata per i canali di rilascio. Ad esempio, l'upgrade dei cluster registrati nel canale stabile alla versione secondaria successiva viene eseguito più vicino alla fine del periodo di assistenza 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 l'upgrade della versione secondaria con esclusioni dalla manutenzione a livello di cluster o scegliendo i tipi di upgrade eseguiti da GKE in una sequenza di implementazione. Inoltre, GKE non eseguirà l'upgrade dei cluster che utilizzano funzionalità o API deprecate.

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

Ogni versione secondaria 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 secondaria a tempo indeterminato, perché l'utilizzo di un cluster che utilizza una versione secondaria di GKE non supportata comporta rischi significativi di sicurezza, affidabilità e compatibilità, in quanto GKE non fornisce patch di sicurezza o correzioni di bug per le versioni secondarie alla fine del supporto. GKE non può impegnarsi a fornire patch o aggiornamenti per le versioni secondarie al termine del supporto.

GKE esegue l'upgrade del cluster nel seguente modo:

  • Control plane: GKE esegue automaticamente l'upgrade dei control plane dei 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 secondaria non supportata dopo che la versione secondaria ha raggiunto la fine del supporto per garantire l'integrità del cluster e l'allineamento con la policy di disallineamento delle versioni di GKE. In genere, l'upgrade automatico dei nodi che eseguono versioni secondarie non supportate a una versione secondaria supportata viene pianificato entro un mese dalla data di fine del supporto. L'upgrade dei nodi che eseguono versioni secondarie non supportate potrebbe non essere eseguito immediatamente al fine del ciclo di vita della versione secondaria e i tempi effettivi possono variare a discrezione di Google.

Analogamente, GKE esegue l'upgrade dei control plane del cluster di cui non è stato eseguito l'upgrade a una nuova versione entro 90 giorni. Per saperne di più, consulta Policy di applicazione delle patch di 90 giorni del control plane.

Prevenzione temporanea di emergenza degli upgrade automatici al termine del supporto

Come misura temporanea, da utilizzare solo in caso di emergenza quando 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". Sconsigliamo questa pratica a causa dei rischi associati all'esecuzione di una versione non supportata. Dopo la scadenza dell'esclusione dalla manutenzione, GKE esegue l'upgrade del cluster.

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

GKE identifica i cluster che soddisfano entrambe le seguenti condizioni:

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 versione secondaria supportata successiva 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 esteso, che possono continuare a eseguire una versione secondaria fino alla fine del supporto esteso. Per scoprire di più su come gestire insight e suggerimenti dal motore per suggerimenti, consulta Ottimizza l'utilizzo di GKE con insight e suggerimenti.

Per trovare i cluster in cui il control plane esegue una versione successiva alla fine del supporto, puoi utilizzare uno dei seguenti metodi:

Per istruzioni, consulta la sezione su come visualizzare insight e consigli.

Per implementare questo suggerimento, 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, cambia il canale del cluster in Esteso se vuoi continuare a utilizzare la versione secondaria esistente fino alla fine del periodo di assistenza esteso.

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

Durante il periodo di assistenza 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 di Container-Optimized OS esistente utilizzata dalla versione secondaria di GKE. Le versioni secondarie di GKE in genere utilizzano un'attività cardine durante il periodo di assistenza standard fino all'inizio del periodo di assistenza estesa.

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

Esamina il seguente scenario per capire come procedono gli upgrade automatici e quali decisioni devono prendere gli amministratori dei 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

La milestone di Container-Optimized OS raggiunge la fine del supporto prima della fine del supporto esteso per la versione secondaria che utilizza la milestone. In questo scenario, GKE utilizza la successiva milestone di Container-Optimized OS disponibile 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 milestone. Puoi eseguire manualmente l'upgrade dei nodi alla versione patch di GKE successiva, che contiene un nuovo milestone. In alternativa, puoi mantenere i nodi che eseguono la stessa versione patch di GKE per non utilizzare la nuova milestone. 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 versione patch successiva per una versione secondaria di GKE nel periodo di assistenza estesa utilizza una milestone di Container-Optimized OS più recente 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 versione 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 scoprire di più, consulta Upgrade automatici al termine 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 versione patch successiva. Puoi eseguire manualmente l'upgrade alla nuova versione patch se hai stabilito che i tuoi workload sono compatibili con la milestone successiva di Container-Optimized OS. Se esegui manualmente l'upgrade 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 i nodi eseguono la nuova milestone.

Notifica del cluster quando le nuove versioni delle patch utilizzano la nuova milestone

GKE invia una notifica del cluster per informarti quando si verifica questa situazione. Questa notifica viene inviata quando la prima versione della 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 versione patch o secondaria successiva o se non vuoi ricevere versioni patch successive per questa versione secondaria durante il periodo di assistenza estesa. Per saperne di più, consulta Le nuove versioni patch passano alla nuova milestone di Container-Optimized OS durante il periodo di assistenza estesa.

Schema di controllo delle versioni

Le release di Kubernetes utilizzano lo standard di controllo delle versioni semantico per i numeri di versione (X.Y.Z). GKE aggiunge un numero di versione della patch GKE alla versione di Kubernetes (X.Y.Z-gke.N).

Versione principale di Kubernetes (X)
In genere, le versioni principali vengono incrementate se vengono introdotte modifiche incompatibili 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 release di 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.
Versione patch di Kubernetes (Z)
Kubernetes rilascia versioni patch durante il periodo di 12 mesi successivo al rilascio di una versione secondaria. La release di una versione patch incrementa la versione di Kubernetes da X.Y.Z a X.Y.Z+1. Ad esempio, 1.32.6 è la release patch che segue 1.32.5.
Versione patch GKE (-gke.N)

GKE rilascia versioni patch che corrispondono alle versioni patch di Kubernetes upstream. Le versioni patch di GKE possono includere aggiornamenti della sicurezza, modifiche alle funzionalità e correzioni di bug per GKE, oltre al software Kubernetes open source. Questi aggiornamenti o correzioni sono necessari per la compatibilità e l'interoperabilità con Cloud de Confiance by S3NS.

GKE potrebbe rilasciare più versioni patch GKE per ogni versione patch di Kubernetes. Ad esempio, la versione patch di Kubernetes 1.35.6 ha versioni patch di GKE come 1.35.6-gke.1638000, 1.35.6-gke.1641000 e 1.35.6-gke.1250000.

In genere, le versioni patch di GKE diventano disponibili ogni settimana. Le release delle patch vengono implementate in modo incrementale in ogni zona.

Versione patch alpha di GKE (X.Y+1.Z-gke.N+preview) - solo cluster alpha

GKE rilascia versioni patch alpha per una versione secondaria di Kubernetes imminente fino a quattro mesi prima della data di rilascio di quella versione secondaria. Queste versioni patch pre-release sono disponibili per la sperimentazione e i test nei cluster GKE alpha registrati nel canale di rilascio rapido. Le versioni delle patch alpha hanno sempre come target la versione secondaria successiva nel ciclo di release di Kubernetes prima della release di quella versione secondaria. Ad esempio, se la versione secondaria 1.36 è la release stabile più recente e la versione 1.37 non è ancora stata rilasciata, le versioni patch alpha sono per la versione 1.37.

Controllo delle versioni disponibili e predefinite

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

Per controllare le versioni di GKE predefinite e disponibili, seleziona una delle seguenti opzioni:

Console

  1. Nella console Cloud de Confiance , vai alla pagina Crea un cluster Kubernetes:

    Vai a Crea un cluster Kubernetes

  2. Nella sezione Tipo di località, scegli un tipo di località e la regione o la zona del control plane del cluster.

  3. Nell'elenco Canale di rilascio di destinazione, seleziona un canale di rilascio.

  4. Apri l'elenco Target version (Versione target). Questo elenco mostra tutte le versioni patch di GKE disponibili per il canale di rilascio. La versione patch predefinita per il canale di rilascio viene selezionata automaticamente. Se selezioni il canale di rilascio rapido, vedrai anche tutte le versioni patch alpha disponibili per la versione secondaria imminente.

gcloud

Per controllare le versioni disponibili e predefinite per un canale di rilascio specifico, esegui uno dei seguenti comandi:

  • Controlla le versioni disponibili:

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

    Sostituisci quanto segue:

    • RELEASE_CHANNEL: il nome del canale di rilascio. Specifica uno dei seguenti valori:

      • RAPID
      • REGULAR
      • STABLE
      • EXTENDED

    • COMPUTE_LOCATION: la località di Compute Engine che vuoi controllare.

    L'output è simile al seguente:

    channels:
  channel: RAPID
  validVersions:
  - 1.36.2-gke.2064000
  - 1.36.2-gke.1498000
  - 1.35.6-gke.1641000
  - 1.35.6-gke.1638000
  - 1.35.6-gke.1258000
  - 1.34.9-gke.1610000
  - 1.34.9-gke.1322000
  - 1.33.13-gke.1269000
  - 1.33.13-gke.1109000

    Nel canale rapido, il campo previewVersions indica le versioni delle patch alpha di GKE per la versione secondaria di Kubernetes in arrivo. Queste versioni sono disponibili solo per i cluster alpha.

  • Controlla la versione predefinita:

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

    L'output è simile al seguente:

    channels:
  channel: RAPID
  defaultVersion: 1.36.2-gke.1498000

  • Controlla le versioni patch alpha disponibili nel canale Rapido:

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

    L'output è simile al seguente:

    channels:
  channel: RAPID
  previewVersions:
  - 1.37.0-gke.2064000+preview

Per controllare le versioni disponibili e predefinite per i cluster che non utilizzano canali (deprecati), esegui uno dei seguenti comandi:

  • Controlla la versione predefinita:

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

    Sostituisci COMPUTE_LOCATION con la località di Compute Engine che vuoi controllare.

    L'output è simile a 1.35.6-gke.1127000.

  • Controlla le versioni del control plane disponibili:

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

    L'output è simile al seguente:

    validMasterVersions:
- 1.36.2-gke.2064000
- 1.36.2-gke.1498000
- 1.36.2-gke.1346000
- 1.36.0-gke.4681000
- 1.36.0-gke.4447000
- 1.35.6-gke.1641000
- 1.35.6-gke.1638000
- 1.35.6-gke.1258000
- 1.35.6-gke.1250000
- 1.35.6-gke.1127000
- 1.35.6-gke.1049000

  • Controlla le versioni dei nodi disponibili:

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

    L'output è simile al seguente:

    validNodeVersions:
- 1.36.2-gke.2064000
- 1.36.2-gke.1498000
- 1.36.2-gke.1346000
- 1.36.0-gke.4681000
- 1.36.0-gke.4447000
- 1.35.6-gke.1641000
- 1.35.6-gke.1638000
- 1.35.6-gke.1258000
- 1.35.6-gke.1250000
- 1.35.6-gke.1127000
- 1.35.6-gke.1049000
# Multiple lines are omitted here

Specificare la versione del cluster

Quando crei o esegui l'upgrade di un cluster utilizzando gcloud CLI, puoi utilizzare il flag --cluster-version per specificare una versione del cluster o un alias.

Per i cluster Autopilot e Standard, puoi utilizzare il seguente alias quando crei un cluster:

  • upgrade-target (anteprima): per i cluster registrati in una sequenza di implementazione, questo alias viene risolto nella versione di destinazione della fase di un cluster. In caso contrario, GKE utilizza la versione target di upgrade automatico del canale di rilascio. Puoi utilizzare questo alias solo durante la creazione del cluster. Non può essere utilizzato durante gli upgrade del cluster.

Solo per i cluster Standard, puoi specificare una versione disponibile (ad esempio 1.30.2-gke.1500) o utilizzare uno dei seguenti alias:

  • latest: la versione di Kubernetes supportata più recente disponibile nella zona o nella regione del cluster. Se specifichi latest, non vengono forniti upgrade automatici. Attiva gli upgrade automatici dei nodi per assicurarti che i nodi nel tuo cluster siano aggiornati all'ultima versione stabile.
  • 1.X: la release patch valida più recente nella versione secondaria specificata.
  • 1.X.Y: la patch gke.N valida più recente nella release della patch specificata.

  • -: la versione predefinita di Kubernetes per i control plane. Per gli upgrade dei nodi, specifica la versione in esecuzione nel control plane del cluster.

    Puoi utilizzare questi alias sia per la creazione che per gli upgrade dei cluster.

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 control plane e non puoi specificare una versione.

Quando crei o esegui l'upgrade di un node pool, 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.

Le versioni patch precedenti rimangono disponibili per i nodi fino alla fine del supporto della versione secondaria, anche dopo che non sono più disponibili per il control plane. In rari casi, una versione del nodo potrebbe non essere più disponibile prima.

Policy di applicazione delle patch di 90 giorni del control plane

Per garantire che un cluster GKE riceva patch di sicurezza critiche e altre correzioni in modo tempestivo, GKE richiede che venga eseguito l'upgrade del control plane di un cluster a una nuova versione patch (o secondaria) almeno ogni 90 giorni. Per impostazione predefinita, GKE esegue automaticamente l'upgrade del control plane dei cluster più frequentemente di ogni 90 giorni. Tuttavia, puoi ritardare questi upgrade del control plane configurando le esclusioni dalla manutenzione o scegliendo i tipi di upgrade eseguiti da GKE in una sequenza di implementazione. Tuttavia, analogamente agli upgrade automatici al termine del supporto, se hai un cluster GKE di cui non è stato eseguito l'upgrade come richiesto, GKE esegue automaticamente l'upgrade del cluster a una versione patch successiva, indipendentemente dalle policy configurate.

Policy di disallineamento delle versioni di GKE

La policy di disallineamento 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 rispetto al 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 precedenti. La versione dei nodi non può essere più recente della versione del control plane a causa della policy di disallineamento delle versioni di Kubernetes OSS.

Per garantire l'assistenza e l'affidabilità, i nodi devono utilizzare una versione supportata, indipendentemente dal fatto che seguano un disallineamento delle versioni valido.

Identifica i cluster con un disallineamento delle versioni non supportato

GKE identifica i cluster in cui i nodi eseguono una versione non compatibile 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 questa indicazione con un insight e un suggerimento tramite il servizio Recommender. Per scoprire di più su come gestire insight e suggerimenti dal motore per suggerimenti, consulta Ottimizza l'utilizzo di GKE con insight e suggerimenti.

Per trovare i cluster con una deviazione della versione non supportata, puoi utilizzare uno dei seguenti metodi:

Per istruzioni, consulta la sezione su come visualizzare insight e consigli.

Per implementare questo suggerimento, 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 saltare le versioni secondarie

GKE non consente di saltare le versioni secondarie per il control plane del cluster, ma puoi saltare 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 su più versioni secondarie, esegui l'upgrade del control plane 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 1.34, esegui prima l'upgrade dalla versione 1.32 alla 1.33, poi esegui l'upgrade dei nodi worker in modo che corrispondano alla versione del control plane e infine ripeti la procedura per eseguire l'upgrade dalla versione 1.33 alla 1.34.

Eseguire l'upgrade dei nodi worker in modo che corrispondano alle versioni ti aiuta a evitare il disallineamento delle versioni non supportato. Ti consigliamo di evitare di saltare le versioni, quando possibile. Il salto delle versioni dei nodi worker 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 rifare il deployment dei workload.

Supporto delle versioni delle patch

GKE introduce prima una versione patch nel canale rapido, poi la promuove gradualmente attraverso 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 al termine del supporto della versione secondaria, 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 tuo cluster esegue una versione patch rimossa, ti consigliamo di eseguire l'upgrade del control plane alla versione target più recente dell'upgrade automatico.

Ritiro 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 patch da un canale di rilascio per l'utilizzo con un control plane del cluster, GKE le ritira. Anche se le versioni patch ritirate non sono 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 deprecate solo se il processo di implementazione del tuo ambiente ti impedisce di eseguire l'upgrade prima. GKE ritira una versione patch per 90 giorni o fino a quando la versione secondaria non raggiunge la fine del supporto standard (canale regolare, stabile, nessun canale) o la fine del supporto esteso (canale esteso).

Supporto delle versioni alpha

Le versioni alpha sono versioni patch GKE di una versione secondaria di Kubernetes imminente che GKE rilascia fino a quattro mesi prima che la versione secondaria sia disponibile per tutti i cluster nel canale rapido. Queste versioni alpha sono disponibili solo nei cluster alpha di GKE e sono destinate agli early adopter che vogliono sperimentare le funzionalità in arrivo senza aspettative di stabilità o assistenza.

Il canale rapido ha da una a tre versioni di patch alpha disponibili per la versione secondaria imminente. Nei mesi precedenti alla disponibilità della versione secondaria per tutti i cluster nel canale rapido, GKE introduce nuove versioni patch alpha e rimuove le versioni esistenti. Poiché le versioni patch alpha sono disponibili solo nei cluster alpha, si applicano le seguenti considerazioni:

  • Non puoi eseguire l'upgrade dei cluster alpha a nuove versioni. Per testare una nuova versione alpha, crea un cluster alpha che esegua quella versione.
  • I cluster alpha che eseguono una versione alpha rimossa continuano a esistere fino alla scadenza dei cluster 30 giorni dopo la creazione o fino a quando non li elimini.
  • Le correzioni per CVE e bug in componenti di sistema specifici non vengono applicate retroattivamente alle versioni alpha esistenti delle patch. Per ottenere queste correzioni, devi creare un cluster alpha che esegua una versione patch alpha più recente.

Dopo che GKE rilascia una versione secondaria stabile nel canale rapido, GKE rimuove le versioni delle patch alpha per quella versione secondaria. Le versioni alpha della versione secondaria successiva nel ciclo di rilascio diventano disponibili nel canale rapido fino a quattro mesi prima della data di rilascio della versione secondaria.

Ciclo di vita della versione alpha

Il ciclo di vita della versione alpha prevede le seguenti tappe:

  1. Kubernetes rilascia la prima versione di sviluppo per la versione secondaria imminente (X.Y+1.0-alpha.0).
  2. Fino a quattro mesi prima della data di rilascio della versione secondaria imminente, GKE introduce le versioni patch alpha per quella versione secondaria nel canale Rapido (X.Y+1.0-gke.N+preview).
  3. Kubernetes rilascia la versione secondaria stabile (X.Y.0).
  4. GKE rende disponibile la versione secondaria stabile nel canale rapido (X.Y.0-gke.N). GKE rimuove le versioni alpha per quella versione secondaria dal canale rapido.

Il ciclo di vita di una versione alpha non influisce sul ciclo di vita delle versioni secondarie di GKE.