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 release di GKE programmazione.

Supporto delle versioni

Il supporto di GKE per le versioni secondarie di Kubernetes si basa su Kubernetes i criteri open source. GKE supporta una versione secondaria fornendo versioni patch della stessa release secondaria e, su una regolarmente, con l'upgrade automatico dei cluster alle patch più recenti.

In che modo Kubernetes supporta una versione secondaria

La community del software open source Kubernetes (OSS) rilascia una versione secondaria con nuove funzionalità e miglioramenti il triplo anno. Ogni ciclo di rilascio per un periodo di circa 15 settimane.

Kubernetes supporta ogni versione secondaria per 14 mesi. Bug principali e sicurezza le vulnerabilità trovate in una versione secondaria supportata vengono risolte con il rilascio una versione patch ad hoc. A volte la community Kubernetes rivede del supporto della versione, se necessario. Per saperne di più, consulta Assistenza punto.

In che modo GKE supporta una versione secondaria

Dopo che Kubernetes ha rilasciato una nuova versione secondaria, Introduce la versione secondaria nel canale Rapid. GKE fornisce versioni patch durante questo periodo, ma poiché il canale rapido offre la versione Versioni GKE, queste sono escluse dalla classe sullo SLA (accordo sul livello del servizio) di GKE e potrebbero contenere problemi senza soluzioni alternative note.

Dopo la disponibilità iniziale nel canale rapido, GKE promuove la nuova versione in modo minore al canale regolare. GKE offre fino a per un totale di 24 mesi di assistenza per una versione secondaria dopo che la versione è stata disponibili per la creazione di nuovi cluster Canale normale. Questo l'assistenza include circa 14 mesi di assistenza standard e circa altri 10 mesi di supporto esteso disponibile con il Estesa canale. Per verificare la disponibilità di specifiche versioni secondarie, consulta la Pianificazione 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. Kubernetes rilascia una nuova versione secondaria.
  2. GKE rende disponibile la nuova versione secondaria in Rapid canale.
  3. GKE rende disponibile la nuova versione secondaria nella canale (inizio del periodo di assistenza standard).
  4. Durante il periodo di assistenza standard, GKE fornisce le patch la versione secondaria che include nuove funzionalità e correzioni di bug.
  5. La versione secondaria raggiunge la fine del supporto standard dopo circa 14 mesi in totale, entrando nel periodo di supporto esteso. Trascorso questo periodo, GKE fornisce patch di sicurezza per i cluster Canale esteso.
  6. La versione secondaria raggiunge la fine del supporto esteso, il che significa che la versione secondaria non riceverà ulteriori patch di sicurezza.

Aggiustamenti della disponibilità delle versioni

GKE potrebbe rivedere la fine del supporto per GKE a causa dei cambiamenti nei criteri nella community Kubernetes OSS, di vulnerabilità o altri problemi tecnici che non possono essere ragionevolmente risolto. GKE potrebbe anche estendere le date di fine del supporto intorno ai valori chiave come il Black Friday e il Cyber Monday.

GKE offre almeno 14 mesi di assistenza standard e fino un totale di 24 mesi di assistenza con supporto esteso.

Per ottenere le ultime versioni disponibili, consulta la release di GKE note. GKE con regolarità aggiorna il programma delle release in base alle tempistiche degli upgrade automatici.

Periodi di disponibilità nel ciclo di vita della versione secondaria

GKE fornisce i seguenti periodi di disponibilità per Versione secondaria di Kubernetes:

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

Consulta la tabella seguente che riepiloga i periodi di disponibilità, descritti in nelle prossime sezioni:

Periodo di disponibilità Periodo di tempo approssimativo dalla disponibilità canale regolare Quale supporto offre GKE Accesso a questo periodo di disponibilità
Periodo di assistenza rapido Dal mese -1 al mese 0 GKE fornisce versioni patch con nuove funzionalità, correzioni di bug e correzioni di bug. Tuttavia, queste versioni sono escluse dallo SLA di GKE e potrebbero contenere problemi senza soluzioni alternative note. Solo canale rapido
Periodo di assistenza standard Dal mese 1 al mese 14 GKE fornisce versioni patch con nuove funzionalità, correzioni di bug e correzioni di bug. Rapido, regolare, stabile, esteso, nessun canale
Periodo di assistenza esteso Dal mese 15 al mese 24 GKE fornisce versioni patch con correzioni di sicurezza. Solo canale esteso (richiede GKE Enterprise o una tariffa aggiuntiva per cluster; consulta Ricevere assistenza a lungo termine con il canale Extended)

Periodo per il Supporto Rapido

GKE rilascia prima una nuova versione secondaria nel canale rapido. La versione accumula prima utilizzo e dimostra stabilità cluster in questo canale prima di essere promosso al canale regolare. Solo i cluster registrati nel canale rapido possono eseguire una nuova versione secondaria durante del periodo di assistenza.

Periodo per l'assistenza standard

Inizia il periodo di assistenza standard per una versione secondaria di GKE quando la versione viene rilasciata sul canale regolare. Tutti i cluster GKE cluster, indipendentemente dalla registrazione del canale di rilascio, possono eseguire una versione secondaria dell'assistenza standard. Durante questo periodo, GKE esegue automaticamente gli upgrade cluster a nuove versioni di patch, che includono nuove funzionalità, correzioni di sicurezza e bug.

GKE esegue automaticamente l'upgrade dei cluster nel seguente modo:

  • Rapido, regolare, stabile, senza canale: upgrade automatici ad altre piattaforme supportate versioni secondarie o versioni patch della stessa versione secondaria.
  • Esteso: GKE esegue automaticamente l'upgrade solo alla patch più recente della stessa versione secondaria.

Per i cluster non registrati nel canale di rilascio Extended, GKE alla fine esegue automaticamente l'upgrade dei cluster alla successiva versione secondaria supportata prima del termine del supporto standard, in base alla pianificazione per canale di rilascio. Per maggiori dettagli, consulta Pianificazione prevista del rilascio canali di YouTube. Tuttavia, GKE non esegue l'upgrade dei cluster durante questo periodo se o utilizzare funzioni o per le API. Puoi richiedere una procedura di manutenzione un'esclusione per impedire temporaneamente GKE dall'upgrade del cluster alla versione secondaria successiva.

Fine dell'assistenza standard (in precedenza fine del ciclo di vita)

Dopo il periodo di assistenza standard, la versione secondaria raggiunge la fine del l'assistenza standard (precedentemente nota come fine del ciclo di vita) e non sono più supportati e non sono disponibili per tutti i cluster non è stata effettuata la registrazione al canale Esteso.

I clienti che utilizzano una versione di fine assistenza riceveranno una notifica via email all'indirizzo il contatto del progetto prima della fine del supporto di una versione. GKE inizia anche ad eseguire l'upgrade automatico graduale dei nodi (indipendentemente all'abilitazione) eseguendo versioni non supportate per motivi di sicurezza e compatibilità perché non vengono fornite nuove patch di sicurezza o correzioni di bug per la fine del supporto versions. Prima di contattare l'assistenza clienti Google Cloud per eventuali problemi relativi a un cluster nodi che eseguono una versione non supportata, devi prima eseguire l'upgrade del cluster e nodi a una versione supportata.

Le versioni secondarie di GKE che hanno raggiunto la fine del supporto non sono più supportate ricevere patch di sicurezza o correzioni di bug. Applica patch a una versione secondaria che ha raggiunto la fine del supporto non sono supportati e non sono disponibili. GKE esegue automaticamente l'upgrade di tutti i cluster non registrati Canale esteso. Per saperne di più, consulta la sezione Upgrade automatici alla fine del assistenza.

Periodo di supporto esteso

Al termine dell'assistenza standard, la versione secondaria raggiunge il periodo di supporto esteso (dal mese dal 15 al mese 24). Durante questo periodo, GKE fornisce patch per le correzioni di sicurezza, tra cui le seguenti tipi di correzioni:

  • Patch di sicurezza medie, alte e critiche per i componenti principali di Kubernetes, dei nodi e dei container gestiti da Google in bundle con Versione del cluster GKE.
  • Per Container-Optimized OS, la fine del supporto del sistema operativo nodo potrebbero arrivare prima della fine del supporto esteso per una versione secondaria o introdurre modifiche incompatibili. Per saperne di più su come GKE continua a fornire assistenza, vedi Aggiornamenti di Container-Optimized OS durante il periodo di assistenza estesa.

Verso la fine del supporto esteso, GKE inizia l'upgrade cluster alla versione secondaria successiva. GKE non esegue l'upgrade dei cluster stanno usando funzionalità o API deprecate. Puoi utilizzare un'esclusione di manutenzione per impedire temporaneamente a GKE di eseguire l'upgrade del cluster successiva versione secondaria.

Fine del supporto esteso

Al termine del supporto esteso, GKE non fornisce patch. per le correzioni di sicurezza. La versione secondaria è considerata non supportata. GKE esegue gli upgrade dei cluster che ancora eseguono la versione secondaria non supportata alla versione secondaria successiva, indipendentemente dall'uso del cluster deprecato o API.

Upgrade automatici al termine del supporto

GKE pianifica upgrade automatici per i cluster di un minore alla versione secondaria successiva supportata prima che la versione secondaria raggiunga alla fine del supporto. Le tempistiche di questo upgrade dipendono dalla pianificazione dei canale di rilascio del cluster. Per maggiori dettagli, consulta Pianificazione prevista del rilascio canali di YouTube. Ad esempio, viene eseguito l'upgrade dei cluster registrati nel canale stabile al successivo versione secondaria più vicina alla fine del supporto standard rispetto ai cluster registrati in il canale rapido.

Durante il periodo di assistenza standard e il periodo di supporto esteso per i cluster registrata al canale Extended, puoi impedire l'upgrade di questa versione secondaria con un'esclusione di manutenzione e GKE non eseguirà l'upgrade dei cluster che utilizzano funzionalità o API deprecate.

Tuttavia, al termine del supporto standard o al termine del supporto esteso per registrati nel canale Extended, GKE esegue automaticamente l'upgrade dei cluster alla versione secondaria successiva supportata per garantire in modo che il cluster mantenga prestazioni, disponibilità e sicurezza.

Ogni versione GKE è supportata per 14 mesi di assistenza standard e per 24 mesi di assistenza totale, incluso il supporto esteso. Non puoi mantenere il tuo cluster su una versione a tempo indeterminato, perché il funzionamento di un cluster utilizzando la versione GKE non supportata offre una sicurezza significativa, il rischio di affidabilità e compatibilità in quanto GKE non fornisce patch di sicurezza o correzioni di bug per le versioni alla fine del supporto. GKE non possono impegnarsi a fornire patch o aggiornamenti per le versioni alla fine del supporto.

GKE esegue l'upgrade del cluster nel seguente modo:

  • Piano di controllo: GKE esegue automaticamente l'upgrade del controllo del cluster alle versioni supportate quando la versione del piano di controllo non è più disponibile per la creazione di nuovi cluster.
  • Nodi: GKE esegue automaticamente l'upgrade dei nodi in esecuzione una versione non supportata dopo che la versione ha raggiunto la fine del supporto per garantire l'integrità del cluster e l'allineamento con il disallineamento delle versioni open source . I nodi che eseguono versioni non supportate sono in genere pianificati per un upgrade automatico a una versione supportata entro un mese dalla fine del supporto data. È 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.

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

Durante il periodo di assistenza estesa per un Versione secondaria di GKE, GKE fornisce upgrade delle patch per il cluster, che potrebbero includere Aggiornamenti di Container-Optimized OS.

La release Container-Optimized OS LTS raggiunge la fine del supporto prima della versione secondaria

Container-Optimized OS LTS di lancio potrebbe raggiungere fine del supporto prima della fine del supporto esteso per la versione secondaria usando la release. In questo scenario, utilizza la prossima release LTS Container-Optimized OS disponibile in futuro se possibile. GKE esegue questo aggiornamento prima Release LTS Container-Optimized OS utilizzata dai nodi versione secondaria raggiunge la fine del supporto. Gli amministratori dei cluster devono valutare all'upgrade GKE successivo , che contiene una nuova release LTS Container-Optimized OS oppure rimanere nella stessa versione della patch GKE per non ricevere aggiornamenti nel dei nodi, e al contempo non riceve patch di sicurezza per le Componenti di Kubernetes in bundle con la versione del cluster GKE.

La prossima release Container-Optimized OS LTS introduce modifiche incompatibili con la versione secondaria esistente

La prossima release LTS Container-Optimized OS potrebbe introdurre modifiche con i componenti di sistema GKE non può fornire una versione patch con aggiornamenti del sistema operativo dei nodi. Gruppo gli amministratori devono valutare se eseguire l'upgrade al cluster GKE una versione secondaria o considerare gli stessi compromessi descritti nel paragrafo.

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.32 è la release secondaria che segue Kubernetes 1.31.
Release patch Kubernetes (z)
Nuove release di patch per Kubernetes (ad esempio 1.32.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.32.6-gke.N) può includere aggiornamenti della sicurezza e 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.

Utilizzare la console Google Cloud per controllare le versioni

Per vedere le versioni predefinite e disponibili, 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 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.

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

Versioni disponibili

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

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

Versioni disponibili

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

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

Versioni disponibili

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

Sostituisci quanto segue:

Esteso

Per visualizzare le versioni predefinite e disponibili nel canale di rilascio di Extended: esegui questi comandi:

Versione predefinita

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

Versioni disponibili

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

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

Versioni disponibili del piano di controllo

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

Versioni dei nodi disponibili

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

Sostituisci quanto segue:

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 mentre l'aereo è 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 e non è possibile specificarne una.

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.

Disallineamento delle versioni

Le versioni dei nodi e dei pool di nodi possono essere fino a due versioni secondarie precedenti alla del piano di controllo, ma non può essere più recente della versione del piano di controllo a causa Disallineamento delle versioni di Kubernetes OSS . A garantire supportabilità e affidabilità, i nodi devono utilizzare una versione supportata indipendentemente dal fatto di seguire un disallineamento valido delle versioni.

Supporto per saltare le versioni secondarie

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.32 alla 1.34 saltando Versione 1.33.

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.32 alla 1.34, prima esegui l'upgrade dalla versione 1.32 alla 1.33, 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.33 alla 1.34.

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.