Controllo delle versioni e assistenza di GKE

Questa pagina descrive il controllo delle versioni in Google Kubernetes Engine (GKE) e i criteri per il supporto delle versioni. Puoi vedere la pianificazione dell'implementazione e del supporto delle versioni attuali nel programma delle release di GKE.

Supporto delle versioni

La community OSS (Open Source Software) di Kubernetes attualmente rilascia una versione secondaria con nuove funzionalità e miglioramenti tre volte l'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 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 Kubernetes può rivedere di tanto in tanto il calendario del supporto delle versioni.

Google offre un totale di 14 mesi di assistenza per ogni versione secondaria di GKE una volta che la versione viene resa disponibile nel canale Regular. I nodi e le versioni dei 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 del sistema operativo Kubernetes. Per garantire supportabilità e affidabilità, i nodi devono utilizzare una versione supportata, indipendentemente dal fatto di seguire un disallineamento della versione valido.

Dopo 12 mesi, per una versione secondaria supportata verrà applicato un periodo di manutenzione di 2 mesi prima che raggiunga 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 di 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 OSS Kubernetes, 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. L'upgrade dei nodi che eseguono versioni non supportate potrebbe non essere eseguito immediatamente al fine del ciclo di vita della versione; inoltre, le tempistiche effettive possono variare a discrezione di Google.

Google non può impegnarsi a fornire patch o aggiornamenti per le versioni a 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 nei criteri nella community OSS di Kubernetes, del rilevamento di vulnerabilità o di altri problemi tecnici che non possono essere ragionevolmente risolti. Per ottenere le versioni più recenti disponibili, consulta le note di rilascio di GKE.

Schema di controllo delle versioni

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

Versione principale di Kubernetes (x)
In genere, le versioni principali vengono incrementate se nell'API pubblica vengono apportate 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 l'anno. Ogni ciclo di rilascio dura circa 15 settimane. Le API deprecate possono essere rimosse con una nuova versione secondaria, ad esempio con la versione 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 sono disponibili nuove release di patch di Kubernetes (come 1.18.6) per l'utilizzo con GKE 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 (come 1.18.6-gke.N) include aggiornamenti della sicurezza e/o correzioni di bug per GKE insieme al software Kubernetes upstream open source. Questi aggiornamenti o correzioni sono necessari per la compatibilità e l'interoperabilità con Google Cloud.

Verifica 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 controllare le versioni

Per vedere quali versioni sono disponibili e quali predefinite, esegui uno dei seguenti comandi gcloud per il tuo tipo di cluster. Ogni scheda fornisce comandi per verificare le versioni di uno specifico canale di rilascio o di 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 (statica), esegui questi comandi:

Versione predefinita

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

Versioni del piano di controllo disponibili

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, svolgi i seguenti 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 preferisci per il cluster.

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

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 regione del cluster.
  • 1.X: specifica il rilascio di patch patch+gke.N valido più alto nella versione secondaria 1.X
  • 1.X.Y: specifica la patch gke.N valida più alta nella release della patch 1.X.Y.
  • -: per i piani di controllo del 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 consente di eseguire upgrade automatici. Abilita gli upgrade automatici dei nodi per assicurarti che i nodi nel tuo cluster siano aggiornati con l'ultima versione stabile.

Specifica della versione del nodo

Questa sezione si applica solo ai cluster creati in modalità Standard. Nei cluster Autopilot, l'upgrade dei nodi viene eseguito automaticamente.

Quando crei o esegui l'upgrade di un pool di nodi, puoi specificarne la versione. Per impostazione predefinita, i nodi eseguono la stessa versione di GKE del piano di controllo. I nodi non possono essere più vecchi di due versioni secondarie rispetto 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 nuovi cluster nel canale di rilascio Normale.

Per quanto tempo GKE è supportata da una versione secondaria di Kubernetes?

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

Qual è la differenza tra i periodi di manutenzione e di fine del ciclo di vita per una versione secondaria di GKE?

Il periodo di manutenzione indica che una versione dovrebbe entrare a breve nella fine del periodo di vita. Durante la fine 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 al termine del ciclo di vita, dopo 14 mesi di assistenza.

Cosa succede alla data di inizio della manutenzione?

GKE comunicherà ai clienti le operazioni di manutenzione e fine del ciclo di vita imminenti tramite touchpoint esistenti come: note di rilascio, email ai contatti del progetto e notifiche di GKE, se 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 riceveranno una notifica via email al contatto del progetto prima della fine del ciclo di vita di una versione. Inoltre, GKE inizierà a eseguire gradualmente l'upgrade automatico dei nodi (indipendentemente dall'abilitazione dell'upgrade automatico) che eseguono le versioni di fine del ciclo di vita per motivi di sicurezza e compatibilità, poiché non verranno fornite nuove patch di sicurezza o correzioni di bug per le versioni di fine del ciclo di vita. Prima di contattare l'assistenza clienti Google Cloud per eventuali problemi con un cluster o nodi che eseguono una versione di fine del ciclo di vita, devi eseguire l'upgrade del cluster e dei nodi a una versione supportata.

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

Quando la versione del piano di controllo non sarà più disponibile per la creazione di nuovi cluster, verrà eseguito automaticamente l'upgrade dei piani di controllo del cluster alle versioni supportate.

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 un upgrade del 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 1.25, ignorando la versione 1.24.

Per eseguire l'upgrade di un cluster in più versioni secondarie, esegui l'upgrade del piano di controllo una versione secondaria alla volta ed esegui ogni volta l'upgrade dei nodi worker alla stessa versione. 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 corrisponda alla versione del piano di controllo, quindi ripeti la procedura per eseguire l'upgrade dalla versione 1.24 alla 1.25.

L'upgrade dei nodi worker in modo che corrispondano alle versioni ti aiuta a evitare il disallineamento delle versioni. Ti consigliamo di evitare che la versione salti, se possibile. Ignorare le versioni dei nodi worker di solito comporta 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 per un tempo indeterminato?

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

Con quale frequenza devo eseguire l'upgrade di una versione di Kubernetes per continuare a supportarla?

Ti consigliamo di attivare un canale di rilascio e di abilitare gli upgrade automatici dei nodi per ridurre il carico operativo associato all'upgrade delle versioni di 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 del cluster viene sempre eseguito su base regolare, indipendentemente dal fatto che il cluster sia registrato in un canale di rilascio o dal fatto che l'upgrade automatico dei nodi sia disabilitato. Scopri di più nella pagina Upgrade automatici.