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 l'assistenza delle versioni attuali nella programmazione delle release di GKE.

Supporto delle versioni

La community del software open source Kubernetes attualmente rilascia 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 principali bug e vulnerabilità di sicurezza rilevati in una versione secondaria supportata sono: è stato risolto con il rilascio di una versione di patch ad hoc. La community Kubernetes può di tanto in tanto possono rivedere il calendario del supporto della versione.

Google offre un totale di 14 mesi di assistenza per ogni GKE versione secondaria dopo che la versione è stata resa disponibile nella versione Normale canale. Le versioni dei nodi e dei pool di nodi possono essere fino a due versioni secondarie precedenti a del piano di controllo, ma non può essere più recente della versione del piano di controllo a causa Criterio di disallineamento delle versioni di Kubernetes OSS. Per garantire supportabilità e affidabilità, i nodi devono utilizzare una senza dover seguire un disallineamento valido delle versioni.

Dopo 12 mesi, una versione secondaria supportata entrerà in una manutenzione di 2 mesi un periodo di tempo 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 un la versione GKE supportata. Cluster che eseguono una versione secondaria supportata riceveremo patch regolari per correggere bug e problemi di sicurezza segnalato. In base all'attuale criterio di supporto della versione della community OSS di Kubernetes, GKE prevede di mantenere le versioni secondarie supportate per 14 mesi, inclusi i 12 mesi successivi al lancio 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 essere in funzione.

Al termine del periodo di manutenzione, una versione secondaria raggiunge la fine del della vita di tutti i giorni e diventa ufficialmente non supportati e non disponibili. Le versioni secondarie di GKE che hanno raggiunto alla fine del ciclo di vita non riceverà più patch di sicurezza o correzioni di bug. Patch versioni secondarie di una versione secondaria che ha raggiunto la fine del ciclo di vita non sono supportati 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 per garantire l'integrità del cluster e l'allineamento con i criteri di disallineamento delle versioni open source. È possibile che l'upgrade dei nodi che eseguono versioni non supportate non venga eseguito immediatamente della versione e le tempistiche effettive possono 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 la manutenzione o alla fine del ciclo di vita delle versioni GKE, a causa di modifiche alle norme nella community Kubernetes OSS, il rilevamento di vulnerabilità o altre problemi tecnici che non possono essere ragionevolmente risolti. Per ottenere le ultime novità consulta le note di rilascio di GKE.

Schema di controllo delle versioni

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

Versione principale di Kubernetes (x)
In genere, le versioni principali vengono incrementate nel caso di modifiche incompatibili con le versioni precedenti verranno introdotti all'API pubblica. Una versione principale incrementa il livello versione 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. Obsoleta API può essere rimossa con una nuova versione in modo minore, ad esempio con 1,22. Minore la versione 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)
Nuove release di patch per Kubernetes (ad esempio 1.18.6) da utilizzare con GKE in genere diventano disponibili ogni settimana. Le release patch vengono implementate per ogni zona in modo incrementale.
Release patch GKE (-gke.N)
Una release patch con il suffisso -gke.N (ad esempio 1.18.6-gke.N) include sicurezza aggiornamenti e/o correzioni di bug per GKE insieme all'open source il software Kubernetes upstream. Questi aggiornamenti o correzioni sono necessari per compatibilità e interoperabilità con Google Cloud.

Controllo delle versioni disponibili e predefinite in corso...

Per informazioni sulle versioni disponibili, consulta Note di rilascio di GKE.

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

Utilizza gcloud CLI per verificare le versioni

Per sapere quali versioni sono disponibili e quali sono predefinite, esegui una delle i seguenti comandi gcloud per il tuo tipo di cluster. Ogni scheda fornisce comandi per controllare le versioni di un canale di rilascio specifico, o per nessun canale (statico).

Rapida

Per visualizzare le versioni predefinite e disponibili nel canale di rilascio di 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 di 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 di 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 il seguenti 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 sono le versioni disponibili e quelle predefinite, procedi nel seguente modo 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 l'opzione località desiderata per il tuo 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 specifica una versione del cluster utilizzando il flag --cluster-version. Puoi utilizzare uno dei seguenti versione specifica, ad esempio 1.9.7-gke.N. Puoi anche utilizzare alias della 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 valida più recente + gke.N nella versione secondaria 1.X versione
  • 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 piani di controllo. Per gli upgrade dei nodi, specifica la versione controllata dal cluster e il piano è attualmente in esecuzione.

La creazione o l'upgrade di un cluster specificando la versione come latest forniscono upgrade automatici. Abilita gli upgrade automatici dei nodi per assicurarti che i nodi nel tuo cluster siano aggiornati con la versione completamente gestita.

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 GKE come piano di controllo. I nodi non possono essere più di due minori le versioni 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 nuovi cluster nella versione Regular canale di rilascio.

Per quanto tempo GKE supporta una versione secondaria di Kubernetes?

GKE offre 14 mesi di assistenza per ogni versione secondaria di Kubernetes resa disponibile. Versioni riceverà 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 entro la fine del ciclo di vita punto. Durante il periodo di fine del ciclo di vita, la versione secondaria di GKE non ricevere 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 invia una notifica ai clienti circa la manutenzione imminente di vita tramite i touchpoint esistenti, come: note di rilascio, email ai contatti di progetto e notifiche di GKE, ove applicabile. I pool di nodi esistenti che eseguono una versione di manutenzione continueranno per funzionare e la creazione di nuovi pool di nodi per la versione di manutenzione sarà disattivata.

Cosa succede alla data di fine del ciclo di vita?

I clienti che utilizzano una versione di fine del ciclo di vita riceveranno una notifica via email all'indirizzo il 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 l'abilitazione degli upgrade automatici) eseguendo le versioni alla fine del ciclo di vita per motivi di sicurezza per motivi di compatibilità, perché non verranno implementate nuove patch di sicurezza o correzioni di bug forniti per le versioni alla fine del ciclo di vita. Prima di contattare l'assistenza clienti Google Cloud per per problemi con un cluster o i nodi che eseguono 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 è più disponibile per il nuovo cluster per la creazione di contenuti.

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 patch le versioni secondarie. I nodi worker possono saltare le versioni secondarie. Per Ad esempio, è possibile eseguire l'upgrade di un pool di nodi dalla versione 1.23 alla 1.25 saltando 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 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 1.25, esegui prima l'upgrade dalla versione 1.23 alla 1.24, quindi esegui l'upgrade del tuo worker nodi in modo che corrispondano alla versione del piano di controllo, poi 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 la versione disallineamento. Ti consigliamo di evitare di saltare le versioni, se possibile. Ignorazione del nodo 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 rieseguire il deployment dei carichi di lavoro.

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

No, ogni versione di GKE è supportata per 14 mesi e utilizza una di un cluster con una versione GKE di fine del ciclo di vita comporta rischi per sicurezza, affidabilità e compatibilità perché non esistono patch o bug di sicurezza le correzioni verranno fornite per le versioni alla 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 dell'upgrade di GKE versions. Tuttavia, in caso di upgrade manuale, ti consigliamo di pianificare di non eseguire entro ogni sei mesi per ottenere l'accesso alle nuove funzionalità e rimanere supportata.

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

L'upgrade dei piani di controllo dei cluster viene sempre eseguito su base regolare, indipendentemente se il cluster è registrato in un canale di rilascio o se l'upgrade automatico è disabilitato. Scopri di più in Upgrade automatici.