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 la pianificazione del supporto e dell'implementazione delle versioni attuali nella pianificazione delle release di GKE.

Supporto delle versioni

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

A partire da Kubernetes 1.19, OSS supporta ogni versione secondaria per 12 mesi. I bug più gravi e le vulnerabilità di sicurezza rilevati in una versione secondaria supportata vengono risolti con il rilascio di una versione di patch ad hoc. La community Kubernetes di tanto in tanto può rivedere il proprio calendario per il supporto delle versioni.

Google fornisce un totale di 14 mesi di assistenza per ogni versione secondaria di GKE dopo che la versione è stata resa disponibile nel canale Normale. Le versioni dei nodi e del pool di nodi possono essere fino a due versioni secondarie precedenti al piano di controllo, ma non possono essere più recenti della versione del piano di controllo a causa del criterio di disallineamento delle versioni di Kubernetes OSS. Per garantire supportabilità e affidabilità, i nodi devono utilizzare una versione supportata, indipendentemente dal fatto che segua un disallineamento valido delle versioni.

Dopo 12 mesi, una versione secondaria supportata entrerà in un periodo di manutenzione di 2 mesi prima di raggiungere la fine del ciclo di vita.

Ciclo di vita della versione secondaria di GKE

La prima fase del ciclo di vita della versione secondaria inizia con il rilascio di una versione GKE supportata. I cluster che eseguono una versione secondaria supportata riceveranno patch regolari per correggere i bug e i problemi di sicurezza segnalati. In base all'attuale criterio di supporto delle versioni della community Kubernetes OSS, GKE prevede di mantenere le versioni secondarie supportate per 14 mesi, inclusi i 12 mesi successivi al rilascio nel canale regolare, seguiti da un periodo di manutenzione di 2 mesi. Durante il periodo di manutenzione, non sarà consentita la creazione di nuovi pool di nodi per una versione di manutenzione, ma i pool di nodi esistenti che eseguono una versione di manutenzione continueranno a rimanere operativi.

Al termine del periodo di manutenzione, una versione secondaria raggiunge la fine del ciclo di vita e diventa ufficialmente non supportata e non disponibile. Le versioni secondarie di GKE che hanno raggiunto la fine del ciclo di vita non riceveranno più patch di sicurezza o correzioni di bug. Le versioni patch di una versione secondaria che ha raggiunto la fine del ciclo di vita non sono supportate e non sono disponibili.

A partire dalla versione 1.19 di GKE, GKE esegue l'upgrade dei nodi che eseguono una versione non supportata dopo che la versione ha raggiunto la fine del ciclo di vita per garantire l'integrità del cluster e l'allineamento con il criterio di disallineamento delle versioni open source. È possibile che l'upgrade dei nodi che eseguono versioni non supportate non venga eseguito immediatamente alla fine del ciclo di vita della versione e la tempistica effettiva può variare a discrezione di Google.

Google non può impegnarsi a fornire patch o aggiornamenti per le versioni alla fine del ciclo di vita.

Tieni presente che, in rari casi, potrebbe essere necessario rivedere il periodo di manutenzione o la fine del ciclo di vita delle versioni GKE, a causa di cambiamenti dei criteri nella community Kubernetes OSS o del rilevamento di vulnerabilità o di altri problemi tecnici che non possono essere ragionevolmente risolti. Per ottenere le ultime versioni disponibili, consulta le note di rilascio di GKE.

Schema di controllo delle versioni

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

Versione principale di Kubernetes (x)
In genere, le versioni principali vengono incrementate se nell'API pubblica vengono introdotte modifiche incompatibili con le versioni precedenti. 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 possono 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.19 è la release secondaria che segue Kubernetes 1.18.
Release patch Kubernetes (z)
In genere, nuove release di patch di Kubernetes (ad esempio 1.18.6) da utilizzare con GKE sono 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 es. 1.18.6-gke.N) include aggiornamenti della sicurezza e/o correzioni di bug per GKE oltre al software Kubernetes upstream open source. 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 le note di rilascio di GKE.

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

Utilizza gcloud CLI per verificare le versioni

Per visualizzare quali versioni sono disponibili e quali sono predefinite, esegui uno dei seguenti comandi gcloud per il tipo di cluster. Ogni scheda fornisce comandi per controllare le versioni per uno specifico canale di rilascio o per nessun canale (statico).

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=REGION_OR_ZONE

Versioni disponibili

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

Sostituisci quanto segue:

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=REGION_OR_ZONE

Versioni disponibili

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

Sostituisci quanto segue:

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=REGION_OR_ZONE

Versioni disponibili

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

Sostituisci quanto segue:

Nessun canale

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

Versione predefinita

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

Versioni disponibili del piano di controllo

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

Versioni dei nodi disponibili

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

Sostituisci quanto segue:

Utilizzare la console Google Cloud per controllare le versioni

Per vedere quali versioni sono disponibili e predefinite, 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à che ti interessa per il cluster.

  5. Nella sezione Versione piano di controllo, seleziona un canale di rilascio. Sono elencate tutte le versioni attualmente disponibili per quel canale. La versione predefinita viene selezionata automaticamente.

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 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 di patch più patch valida + gke.N nella versione secondaria 1.X
  • 1.X.Y: specifica la patch gke.N valida più elevata nella release 1.X.Y.
  • -: per i piani di controllo dei cluster, specifica la versione predefinita di Kubernetes per i piani di controllo. Per gli upgrade dei nodi, specifica la versione attualmente in esecuzione del piano di controllo del cluster.

La creazione o l'upgrade di un cluster specificando la versione come latest non fornisce upgrade automatici. Abilita gli upgrade automatici dei nodi per garantire che i nodi nel tuo cluster siano aggiornati con l'ultima versione stabile.

Specifica della versione del nodo

Questa sezione riguarda solo i cluster creati in modalità Standard. Nei cluster Autopilot, viene eseguito l'upgrade automatico dei nodi.

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 avere più di due versioni secondarie precedenti ai piani di controllo.

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

Domande frequenti sul supporto della versione

Quando inizia il periodo di assistenza per ogni versione secondaria?

Il supporto di una versione secondaria di Kubernetes inizia quando viene resa disponibile per la prima volta per la creazione di un nuovo cluster nel canale di rilascio Normale.

Per quanto tempo GKE supporta una versione secondaria di Kubernetes?

GKE offre 14 mesi di assistenza per ogni versione secondaria di Kubernetes resa disponibile. Le versioni riceveranno patch per bug e problemi di sicurezza per tutto il periodo di assistenza.

Qual è la differenza tra il periodo di manutenzione e quello di fine del ciclo di vita di una versione secondaria di GKE?

Il periodo di manutenzione indica che una versione dovrebbe entrare a breve nel periodo di fine del ciclo di vita. Al termine del periodo di vita, la versione secondaria di GKE non riceverà patch di sicurezza, correzioni di bug o nuove funzionalità.

Quando termina il supporto per una versione di Kubernetes in GKE?

Una versione secondaria di Kubernetes non è più supportata in GKE quando raggiunge la fine del ciclo di vita, dopo 14 mesi di assistenza.

Cosa succede alla data di inizio della manutenzione?

GKE informerà i clienti dell'imminente manutenzione e delle versioni di fine del ciclo di vita tramite touchpoint esistenti come note di rilascio, email ai contatti del progetto e notifiche di GKE, ove applicabile. I pool di nodi esistenti che eseguono una versione di manutenzione continueranno a funzionare e la creazione di nuovi pool di nodi per la versione di manutenzione verrà disabilitata.

Cosa succede alla data di fine del ciclo di vita?

I clienti che eseguono una versione di fine ciclo di vita verranno informati via email al contatto del progetto prima della fine del ciclo di vita di una versione. GKE inizierà anche ad eseguire l'upgrade automatico graduale dei nodi (indipendentemente dall'abilitazione dell'upgrade automatico) eseguendo le versioni di fine del ciclo di vita per motivi di sicurezza e compatibilità, perché per le versioni a fine del ciclo di vita non verranno fornite nuove patch di sicurezza o correzioni di bug. Prima di contattare l'assistenza clienti Google Cloud per eventuali problemi relativi a cluster o nodi in esecuzione in una versione di fine del ciclo di vita, devi prima eseguire l'upgrade del cluster e dei nodi a una versione supportata.

Quando verrà eseguito esattamente l'upgrade automatico del mio cluster?

Verrà eseguito l'upgrade automatico dei piani di controllo dei cluster alle versioni supportate quando la versione del piano di controllo non sarà più disponibile per la creazione di nuovi cluster.

Per i nodi che eseguono versioni non supportate verrà pianificato un upgrade automatico a una versione supportata entro un mese dalla data di fine del ciclo di vita.

Posso saltare le versioni di GKE durante l'upgrade di un cluster?

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

Per eseguire l'upgrade di un cluster in più versioni secondarie, esegui l'upgrade del piano di controllo a 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.23 alla versione 1.25, esegui prima l'upgrade dalla versione 1.23 alla 1.24, quindi esegui l'upgrade dei nodi worker in modo che corrispondano alla versione del piano di controllo e poi ripeti la procedura per eseguire l'upgrade dalla versione 1.24 alla versione 1.25.

L'upgrade dei nodi worker in modo che corrispondano alle versioni consente di evitare l'inclinazione della versione. 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 ed eseguire nuovamente il deployment dei carichi di lavoro.

Posso lasciare il mio cluster in una versione di Kubernetes a tempo indeterminato?

No, ogni versione GKE è supportata per 14 mesi e il funzionamento di un cluster utilizzando una versione GKE a fine del ciclo di vita comporta rischi significativi di sicurezza, affidabilità e compatibilità perché non verranno fornite patch di sicurezza o correzioni di bug per le versioni a fine del ciclo di vita.

Con quale frequenza dovrei eseguire l'upgrade di una versione di Kubernetes per continuare a usufruire dell'assistenza?

Ti consigliamo di attivare un canale di rilascio e abilitare gli upgrade automatici dei nodi per ridurre il carico operativo previsto dall'upgrade delle versioni GKE. Tuttavia, quando esegui l'upgrade manuale, ti consigliamo di eseguire l'upgrade non oltre ogni sei mesi per ottenere l'accesso alle nuove funzionalità e rimanere in una versione supportata.

Qual è il criterio di implementazione per i piani di controllo GKE?

L'upgrade dei piani di controllo dei cluster viene sempre eseguito regolarmente, indipendentemente dal fatto che il cluster sia registrato in un canale di rilascio o che l'upgrade automatico dei nodi sia disabilitato. Scopri di più in Upgrade automatici.