Periodi di manutenzione ed esclusioni

Questa pagina descrive i periodi di manutenzione e le esclusioni di manutenzione, ovvero policy che consentono di controllare quando può essere eseguita la manutenzione di alcuni cluster, ad esempio gli upgrade automatici, nei cluster Google Kubernetes Engine (GKE). Ad esempio, un'attività di vendita al dettaglio potrebbe limitare la manutenzione solo alle serate dei giorni feriali e potrebbe impedire la manutenzione automatica durante un evento di vendita chiave del settore.

Informazioni sulle policy di manutenzione di GKE

Le policy di manutenzione di GKE, che includono periodi di manutenzione ed esclusioni, ti consentono di controllare quando può verificarsi una determinata manutenzione automatica nei cluster, inclusi gli upgrade del cluster e altre modifiche alla configurazione dei nodi o alla topologia di rete del cluster.

Un periodo di manutenzione è un periodo di tempo ricorrente durante il quale è consentita la manutenzione automatica di GKE.

Un'esclusione di manutenzione è un periodo di tempo non ricorrente durante il quale la manutenzione automatica di GKE è vietata.

GKE apporta modifiche automatiche che rispettano le policy di manutenzione del cluster quando è presente un periodo di manutenzione aperto e non è attiva alcuna esclusione dalla manutenzione. Per ogni cluster, puoi configurare un periodo di manutenzione ricorrente e più esclusioni di manutenzione.

Altri tipi di manutenzione non dipendono dalle norme di manutenzione di GKE, tra cui le operazioni di riparazione del control plane e la manutenzione dei servizi da cui dipende GKE, come Compute Engine. Per saperne di più, consulta Manutenzione automatica che non rispetta le policy di manutenzione.

Quali modifiche rispettano e quali no le norme di manutenzione di GKE

Prima di configurare le norme di manutenzione di GKE, ovvero i periodi di manutenzione e le esclusioni, consulta le sezioni seguenti per capire come GKE e i servizi correlati le rispettano e non le rispettano.

Manutenzione automatica che rispetta le policy di manutenzione di GKE

Con le policy di manutenzione di GKE, puoi controllare la tempistica dei seguenti tipi di eventi, che causano interruzioni temporanee al cluster:

Altri tipi di manutenzione automatica non dipendono dalle policy di manutenzione. Per saperne di più, consulta Manutenzione automatica che non rispetta le policy di manutenzione.

Manutenzione automatica che non rispetta le norme di manutenzione di GKE

I periodi di manutenzione e le esclusioni di GKE non bloccano tutti i tipi di manutenzione automatica. Prima di configurare le norme di manutenzione del cluster GKE, assicurati di comprendere quali tipi di modifiche non rispettano le finestre e le esclusioni di manutenzione.

Altra manutenzione Google Cloud

Le finestre di manutenzione e le esclusioni di GKE non impediscono la manutenzione automatica dei servizi Google Cloud sottostanti, principalmente Compute Engine, o dei servizi che installano applicazioni nel cluster, come Cloud Deploy.

Ad esempio, i nodi GKE sono VM di Compute Engine che GKE gestisce per il tuo cluster. A volte le VM Compute Engine subiscono eventi host, che possono includere eventi di manutenzione o errori dell'host. Il comportamento delle VM durante questi eventi è determinato dalla policy di manutenzione dell'host della VM, che, per impostazione predefinita per la maggior parte delle VM, prevede la migrazione live. In genere, ciò significa tempi di inattività minimi o nulli per i nodi e, per la maggior parte dei carichi di lavoro, i criteri predefiniti sono sufficienti. Per alcune famiglie di macchine VM, puoi monitorare e pianificare un evento di manutenzione dell'host e attivare un evento di manutenzione dell'host per sincronizzarlo con le tue policy di manutenzione di GKE.

Alcune VM, incluse quelle con GPU e TPU, non possono eseguire la migrazione live. Se utilizzi questi acceleratori, scopri come gestire le interruzioni dovute alla manutenzione dei nodi per GPU o TPU.

Ti consigliamo di esaminare le informazioni sugli eventi host, sulle norme di manutenzione dell'host e di verificare che i tuoi carichi di lavoro siano preparati per le interruzioni, soprattutto se vengono eseguiti su nodi che non possono eseguire una migrazione live.

Riparazioni e ridimensionamento automatici

GKE esegue riparazioni automatiche sui control planes. Ciò include processi come l'upscaling del control plane a una dimensione appropriata o il riavvio del control plane per risolvere i problemi. La maggior parte delle riparazioni ignora i periodi di manutenzione e le esclusioni perché la mancata esecuzione delle riparazioni può comportare cluster non funzionanti.

Non puoi disabilitare le riparazioni del control plane. Tuttavia, la maggior parte dei tipi di cluster, inclusi i cluster Autopilot e i cluster regionali Standard, hanno più repliche dei piani di controllo, il che consente l'alta affidabilità del server API Kubernetes anche durante gli eventi di manutenzione. I cluster zonali standard, che hanno un solo piano di controllo, non possono essere modificati durante le modifiche alla configurazione del piano di controllo e la manutenzione del cluster. Ciò include il deployment dei carichi di lavoro.

I nodi dispongono anche di una funzionalità di riparazione automatica, che puoi disattivare per i cluster standard.

Applicazione di patch per vulnerabilità di sicurezza critiche

I periodi di manutenzione e le esclusioni possono causare ritardi nell'applicazione delle patch di sicurezza. Tuttavia, GKE si riserva il diritto di ignorare le norme di manutenzione per le vulnerabilità di sicurezza critiche.

Manutenzione del database dello stato del cluster basato su Spanner

Alcuni cluster GKE utilizzano un database chiave-valore Spanner per archiviare lo stato delle risorse API Kubernetes. Le operazioni di manutenzione su questo database ignorano eventuali periodi di manutenzione ed esclusioni attivi. Tuttavia, il database dello stato del cluster basato su Spanner viene replicato e rimane disponibile durante gli eventi di manutenzione.

Modifiche manuali che rispettano le policy di manutenzione di GKE

Alcune modifiche alla configurazione dei nodi o del networking richiedono la ricreazione dei nodi per applicare la nuova configurazione, incluse alcune delle seguenti modifiche:

Queste modifiche rispettano le norme di manutenzione di GKE, il che significa che GKE attende un periodo di manutenzione aperto e che non sia attiva nessuna esclusione dalla manutenzione che impedisca la manutenzione dei nodi. Per applicare manualmente le modifiche ai nodi, utilizza Google Cloud CLI per chiamare il comando gcloud container clusters upgrade e passa il flag --cluster-version con la stessa versione di GKE già in esecuzione nel pool di nodi.

Modifiche manuali che non rispettano le policy di manutenzione di GKE

Alcune modifiche manuali ricreano i nodi utilizzando immediatamente una strategia di upgrade dei nodi senza rispettare le norme di manutenzione. Per maggiori dettagli, consulta Modifiche manuali che ricreano i nodi utilizzando una strategia di upgrade dei nodi senza rispettare le policy di manutenzione.

Periodi di manutenzione

I periodi di manutenzione ti consentono di controllare quando può avvenire la manutenzione automatica applicabile, inclusi gli upgrade automatici dei control plane e dei nodi, per mitigare le potenziali interruzioni temporanee dei workload. I periodi di manutenzione sono utili per i seguenti tipi di scenari, tra gli altri:

  • Ore non di punta: vuoi ridurre al minimo la possibilità di tempi di inattività pianificando gli upgrade automatici durante le ore non di punta, quando il traffico è ridotto.
  • Su richiesta:vuoi assicurarti che gli upgrade vengano eseguiti durante l'orario di lavoro in modo che qualcuno possa monitorarli e gestire eventuali problemi imprevisti.
  • Upgrade multi-cluster:vuoi implementare gli upgrade in più cluster in diverse regioni uno alla volta a intervalli specificati.

Oltre agli upgrade automatici, Google potrebbe occasionalmente dover eseguire altre attività di manutenzione e rispetta il periodo di manutenzione di un cluster, se possibile.

Se le attività vengono eseguite oltre il periodo di manutenzione, GKE tenta di metterle in pausa e di riprenderle durante il periodo di manutenzione successivo.

GKE si riserva il diritto di implementare upgrade di emergenza non pianificati al di fuori dei periodi di manutenzione. Inoltre, gli upgrade obbligatori da software obsoleto o ritirato potrebbero verificarsi automaticamente al di fuori dei periodi di manutenzione.

Per scoprire come configurare il periodo di manutenzione per un cluster nuovo o esistente, consulta Configurare un periodo di manutenzione.

Per i casi d'uso avanzati, puoi anche utilizzare i budget di interruzione dei cluster per personalizzare l'intervallo di tempo minimo tra tipi specifici di upgrade dei cluster, inclusi gli upgrade di patch o secondari.

Fusi orari per i periodi di manutenzione

Quando configuri e visualizzi le finestre di manutenzione, gli orari vengono visualizzati in modo diverso a seconda dello strumento che utilizzi:

Quando configuri i periodi di manutenzione

Gli orari vengono sempre memorizzati nel fuso orario UTC. Tuttavia, quando configuri la finestra di manutenzione, utilizzi l'ora UTC o il tuo fuso orario locale.

Quando configuri le finestre di manutenzione utilizzando il flag --maintenance-window più generico, non puoi specificare un fuso orario. L'ora UTC viene utilizzata quando si utilizza gcloud CLI o l'API, mentre la console Google Cloud mostra gli orari utilizzando il fuso orario locale.

Quando utilizzi flag più granulari, come --maintenance-window-start, puoi specificare il fuso orario come parte del valore. Se ometti il fuso orario, viene utilizzato il fuso orario locale.

Quando visualizzi i periodi di manutenzione

Quando visualizzi le informazioni sul tuo cluster, i timestamp per le finestre di manutenzione potrebbero essere visualizzati in formato UTC o nel tuo fuso orario locale, a seconda di come visualizzi le informazioni:

  • Quando utilizzi la console Google Cloud per visualizzare informazioni sul tuo cluster, gli orari vengono sempre visualizzati nel tuo fuso orario locale.
  • Quando utilizzi gcloud CLI per visualizzare le informazioni sul tuo cluster, gli orari vengono sempre visualizzati in formato UTC.

In entrambi i casi, RRULE è sempre nel fuso orario UTC. Ciò significa che, se specifichi, ad esempio, i giorni della settimana, questi sono in UTC.

Esclusioni dalla manutenzione

Con le esclusioni di manutenzione, puoi impedire che la manutenzione automatica applicabile venga eseguita durante un periodo di tempo specifico. Ad esempio, molte attività di vendita al dettaglio hanno linee guida aziendali che vietano modifiche all'infrastruttura durante le festività di fine anno. Un altro esempio: se un'azienda utilizza un'API la cui ritiro è pianificato, può utilizzare le esclusioni di manutenzione per sospendere gli aggiornamenti secondari per avere il tempo di migrare le applicazioni.

Per gli eventi noti ad alto impatto, ti consigliamo di abbinare eventuali limitazioni interne delle modifiche a un'esclusione della manutenzione che inizia una settimana prima dell'evento e dura per tutta la sua durata.

Le esclusioni non hanno ricorrenza. Crea invece ogni istanza di un'esclusione periodica separatamente.

Quando le esclusioni e i periodi di manutenzione si sovrappongono, le esclusioni hanno la precedenza.

Per scoprire come configurare le esclusioni dalla manutenzione per un cluster nuovo o esistente, vedi Configurare un'esclusione dalla manutenzione.

Tipi di esclusioni dalla manutenzione

Puoi impostare un'esclusione della manutenzione per l'intero cluster oppure, se hai bisogno di una granularità aggiuntiva, puoi impostare un'esclusione della manutenzione solo per un singolpool di nodiol. Esamina le sezioni seguenti per capire come funzionano i diversi tipi di esclusioni dalla manutenzione.

Esclusioni dalla manutenzione del cluster

A livello di cluster, puoi specificare sia quando impedire la manutenzione automatica del cluster sia l'ambito degli aggiornamenti automatici che potrebbero verificarsi. Di seguito sono riportati gli ambiti di esclusione della manutenzione del cluster e scenari pertinenti di esempio:

  • Nessun upgrade: evita qualsiasi manutenzione: vuoi evitare temporaneamente qualsiasi modifica al cluster durante un periodo di tempo specifico. Questo è l'ambito predefinito.
  • Nessun upgrade secondario: mantieni la versione secondaria di Kubernetes corrente. Vuoi mantenere la versione secondaria di un cluster, ad esempio per evitare modifiche all'API o convalidare la versione secondaria successiva.
  • Nessun upgrade secondario o di nodi: impedisci l'interruzione dei nodi. Vuoi evitare qualsiasi espulsione e riprogrammazione dei carichi di lavoro a causa degli upgrade dei nodi.

La tabella seguente elenca in che modo ciascuno di questi ambiti limita gli upgrade secondari o patch per i control plane o i nodi del cluster.

Ambito Control plane Nodi Durata massima dell'esclusione
Upgrade automatico della versione secondaria Upgrade automatico delle patch Upgrade automatico della versione secondaria Upgrade automatico delle patch
Nessun upgrade (impostazione predefinita) Non consentito Non consentito Non consentito Non consentito Non può superare i 90 giorni.
Nessun upgrade secondario Non consentito Consentito Non consentito Consentito

Puoi configurare l'esclusione della manutenzione in uno dei seguenti modi:

  • Ora di fine fissa: imposta l'ora di fine fino alla fine del supporto per la versione secondaria del cluster e il rispettivo canale di rilascio. Per i cluster registrati nei canali Rapid, Regular o Stable, si tratta della fine del supporto standard, mentre per il canale Extended, della fine del supporto esteso.
  • Monitora la fine del supporto: configura l'ora di fine per monitorare la fine del supporto per la versione secondaria del cluster. Se non esegui manualmente l'upgrade del cluster alla versione secondaria successiva prima della fine del supporto, GKE esegue gli upgrade automatici richiesti al termine del supporto e poi riattiva l'esclusione dalla manutenzione con l'ora di fine che tiene traccia della fine del supporto della nuova versione secondaria. Per saperne di più, consulta Come un'esclusione dalla manutenzione monitora la fine del supporto.
Nessun upgrade secondario o di nodi Non consentito Consentito Non consentito Non consentito

Quando GKE esegue l'upgrade di un cluster, le VM per il control plane e il nodo vengono riavviate. Per i piani di controllo, i cluster Autopilot e Standard regionali mantengono la disponibilità del server API Kubernetes. Nei cluster di zona, che hanno un singolo nodo del control plane, i riavvii delle VM rendono temporaneamente indisponibile il control plane. Per i nodi, i riavvii delle VM attivano la ripianificazione dei pod, che può interrompere temporaneamente i carichi di lavoro esistenti. Puoi impostare la tolleranza per l'interruzione del workload utilizzando un budget di interruzione dei pod (PDB).

Esclusioni dalla manutenzione del node pool

Se vuoi impedire gli upgrade automatici dei nodi del cluster per alcuni, ma non tutti, i node pool del cluster Standard, puoi utilizzare un'esclusione della manutenzione del node pool. Ad esempio, se hai alcuni node pool nel tuo cluster in cui vuoi che GKE esegua automaticamente l'upgrade dei nodi, ma altri node pool in cui vuoi gestire gli upgrade dei pool di nodi, puoi impostare esclusioni pool di nodi solo per i node pool che richiedono un controllo più manuale.

Quando abiliti questo tipo di esclusione dalla manutenzione, GKE esegue automaticamente l'upgrade del cluster solo se necessario quando la versione secondaria delpool di nodil raggiunge la fine del supporto. Per saperne di più, consulta Upgrade automatici al termine dell'assistenza.

La seguente tabella spiega come questa esclusione dalla manutenzione impedisce gli upgrade automatici del pool di nodi:

Tipo di esclusione dalla manutenzione Nodi Durata massima dell'esclusione
Upgrade automatico della versione secondaria Upgrade automatico delle patch
Node pool Non consentito Non consentito L'ora di fine monitora la fine del supporto per la versione secondaria del cluster. Se non esegui manualmente l'upgrade del cluster alla versione secondaria successiva prima della fine del supporto, GKE esegue gli upgrade automatici richiesti al termine del supporto e poi riattiva l'esclusione dalla manutenzione con l'ora di fine che tiene traccia della fine del supporto della nuova versione secondaria. Per saperne di più, consulta Come un'esclusione dalla manutenzione monitora la fine del supporto.

Scadenza e attivazione dell'esclusione

Un'esclusione dalla manutenzione del cluster diventa attiva immediatamente o alla data e all'ora specificate durante la configurazione dell'esclusione.

Un'esclusione dalla manutenzione scade o diventa inattiva al seguente orario:

  • Ora di fine fissa: quando l'ora di fine fissa che hai specificato per l'esclusione è trascorsa.

  • Monitora la fine del supporto: l'esclusione dalla manutenzione viene temporaneamente disattivata all'inizio della data di fine del supporto se il cluster non è ancora stato sottoposto all'upgrade alla versione secondaria successiva e utilizzi un'esclusione dalla manutenzione in uno dei seguenti modi:

    • Configura un'esclusione della manutenzione del cluster per l'ora di fine per monitorare la data di fine del supporto per la versione secondaria del cluster.
    • Imposta un'esclusione dalla manutenzione del pool di nodi.

    GKE riattiva l'esclusione dalla manutenzione dopo uno dei seguenti eventi:

Quando una manutenzione esclusa scade (ovvero l'ora attuale è successiva all'ora di fine specificata per l'esclusione) o diventa temporaneamente inattiva, l'esclusione non impedisce più gli aggiornamenti di GKE. Altre esclusioni ancora valide continueranno a impedire gli aggiornamenti di GKE.

Quando non rimangono esclusioni o altri fattori che impediscono gli upgrade del cluster, GKE esegue gradualmente l'upgrade del cluster alle destinazioni di upgrade automatico idonee.

Se il tuo cluster ha perso più upgrade di versioni secondarie a causa dell'esclusione, GKE pianifica circa un upgrade di versione secondaria al mese, eseguendo l'upgrade sia del control plane del cluster sia dei nodi, per garantire che il cluster esegua una versione supportata. Puoi sempre eseguire upgrade manuali per portare il tuo cluster a una versione secondaria specifica prima.

In che modo un'esclusione dalla manutenzione monitora la fine del supporto

Puoi configurare le esclusioni dalla manutenzione del cluster con l'ambito"Nessun upgrade secondario " o"Nessun upgrade secondario o di nodi" per monitorare la fine del supporto della versione secondaria del cluster, anziché impostare manualmente una data come ora di fine. Le esclusioni dalla manutenzione dei pool di nodi tengono traccia anche della fine del supporto.

Se imposti uno di questi tipi di esclusioni di manutenzione per monitorare la data di fine del supporto, nelle seguenti situazioni GKE aggiorna l'ora di fine dell'esclusione di manutenzione in modo che rifletta la nuova data di fine del supporto:

  • Tu o GKE eseguite l'upgrade del cluster a una nuova versione secondaria.
  • Modifichi la registrazione del cluster da o verso il canale Extended.
  • GKE aggiorna la data di fine del supporto della versione secondaria del cluster.

Con questi tipi di esclusioni dalla manutenzione, se non hai eseguito l'upgrade manuale del cluster alla versione secondaria successiva, GKE esegue gli upgrade automatici richiesti al termine del supporto e poi riattiva l'esclusione dalla manutenzione con l'ora di fine che tiene traccia della fine del supporto della nuova versione secondaria.

Per maggiori informazioni sulla fine del supporto, consulta il ciclo di vita delle versioni secondarie di GKE. Per visualizzare la data di fine del supporto per la versione secondaria del cluster, consulta Trovare la data di fine del supporto per la versione secondaria del cluster.

Prevenzione temporanea e di emergenza degli upgrade automatici al termine del supporto

Come misura temporanea, da utilizzare solo in caso di emergenza in cui 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". Non consigliamo questa pratica a causa dei rischi associati all'esecuzione di una versione non supportata. Una volta scaduta l'esclusione dalla manutenzione, GKE esegue l'upgrade del cluster.

L'utilizzo di un cluster che utilizza una versione GKE non supportata comporta rischi significativi per la sicurezza, l'affidabilità e la compatibilità perché GKE non fornisce patch di sicurezza o correzioni di bug per le versioni che hanno raggiunto la fine del supporto. GKE non può impegnarsi a fornire patch o aggiornamenti per le versioni alla fine del supporto.

Per saperne di più, consulta Upgrade automatici alla fine del supporto.

Limitazioni alla configurazione delle esclusioni dalla manutenzione

Le esclusioni dalla manutenzione del cluster presentano le seguenti limitazioni:

  • Puoi limitare solo l'ambito degli upgrade automatici in un'esclusione della manutenzione per i cluster registrati in un canale di rilascio. Per i cluster non registrati a un canale di rilascio, puoi creare un'esclusione dalla manutenzione solo con l'ambito predefinito "Nessun upgrade".
  • Puoi aggiungere un massimo di tre esclusioni dalla manutenzione che escludono tutti gli upgrade (ovvero un ambito "nessun upgrade"). Queste esclusioni devono essere configurate in modo da consentire almeno 48 ore di disponibilità per la manutenzione in una finestra temporale continua di 32 giorni.
  • Puoi avere un massimo di 20 esclusioni dalla manutenzione del cluster per ogni cluster.
  • Se non specifichi un ambito nell'esclusione, l'ambito predefinito è "nessun upgrade".

  • Non puoi configurare un'esclusione dalla manutenzione in modo che includa o superi la data di fine assistenza della versione secondaria corrispondente alla registrazione del canale di rilascio del cluster, tranne che come misura temporanea di emergenza con l'ambito "Nessun upgrade". Per impostare un orario di fine fisso intorno alla fine del supporto, vedi i seguenti esempi:

    • Un cluster esegue una versione secondaria nel canale stabile in cui il programma delle pubblicazioni di GKE indica che la data di fine dell'Assistenza Standard è il 5 giugno 2025. Devi impostare l'ora di fine dell'esclusione di manutenzione su 2025-06-05T00:00:00Z o precedente.
    • Un cluster esegue una versione secondaria nel canale Extended in cui la programmazione delle release di GKE indica che la data di fine del supporto esteso è il 5 aprile 2026. Devi impostare l'ora di fine dell'esclusione di manutenzione su 2026-04-0500:00:00Z o precedente. Se vuoi cambiare il canale di rilascio del cluster con un altro canale, devi modificare l'ora di fine dell'esclusione della manutenzione se supera la fine dell'assistenza standard. Per saperne di più, vedi Cambiare il cluster dal canale Extended.

    L'esclusione può, facoltativamente, monitorare la data di fine del supporto e diventa temporaneamente inattiva all'inizio della data di fine del supporto fino a quando il cluster non viene aggiornato alla versione secondaria successiva.

Le esclusioni dalla manutenzione dei node pool presentano le seguenti limitazioni:

  • Il cluster deve essere registrato in un canale di rilascio.
  • Puoi impostare una sola esclusione della manutenzione del pool di nodi per ogni pool di nodi.
  • Non puoi impostare un'esclusione dalla manutenzione del pool di nodi in modo che inizi in una data e un'ora future. L'esclusione dalla manutenzione inizia immediatamente quando la abiliti.
  • Non puoi utilizzare le esclusioni di manutenzione del pool di nodi con i cluster Autopilot, perché GKE gestisce i nodi per i cluster Autopilot.
  • L'esclusione dalla manutenzione del pool di nodi impedisce solo gli upgrade dei nodi (aggiornamenti della versione) e non impedisce altri tipi di aggiornamenti dei nodi.

Le esclusioni dalla manutenzione non influiscono sugli upgrade manuali e sulle versioni dei nuovi nodi

Le esclusioni dalla manutenzione impediscono l'upgrade automatico dei control plane e dei nodi esistenti, a seconda dell'ambito dell'esclusione dalla manutenzione. Tuttavia, le esclusioni per la manutenzione non impediscono le seguenti modifiche:

  • Upgrade manuale del piano di controllo o dei nodi del cluster.
  • Creazione di un nuovo pool di nodi Standard con una versione successiva rispetto ai node pool Standard esistenti in cui un'esclusione della manutenzione impedisce gli upgrade automatici.
  • Se il provisioning automatico dei nodi crea le seguenti risorse con una versione successiva rispetto ai nodi esistenti in cui un'esclusione di manutenzione impedisce gli upgrade automatici:
    • Nuovi node pool Standard.
    • Nuovi nodi in un cluster Autopilot.

Supponiamo di aver creato un'esclusione dalla manutenzione per il cluster con un ambito in cui GKE esegue automaticamente l'upgrade del control plane, ma non dei nodi, alle versioni patch successive. In questo scenario, GKE potrebbe creare nuovi pool di nodi o nodi creati tramite il provisioning automatico che eseguono la versione patch successiva del control plane.

I nodi del cluster possono eseguire solo versioni di GKE uguali o precedenti rispetto al control plane. Le esclusioni dalla manutenzione impediscono gli upgrade automatici dei nodi esistenti. Se il control plane ha una versione più recente rispetto ai nodi esistenti, i nodi appena creati o aggiornati manualmente potrebbero eseguire una versione più recente di GKE rispetto ai nodi con upgrade automatici limitati dalle esclusioni di manutenzione.

Più esclusioni

Puoi impostare più esclusioni per un cluster, incluse le esclusioni del pool di nodi. Queste esclusioni possono avere ambiti diversi e intervalli di tempo sovrapposti. Il caso d'uso delle festività di fine anno è un esempio di esclusioni sovrapposte, in cui vengono utilizzati sia gli ambiti "Nessun upgrade" sia "Nessun upgrade secondario".

Quando le esclusioni si sovrappongono, se un'esclusione attiva (ovvero l'ora attuale rientra nel periodo di tempo dell'esclusione) blocca un upgrade, l'upgrade verrà posticipato.

Utilizzando il caso d'uso relativo al periodo delle festività di fine anno, un cluster ha le seguenti esclusioni specificate:

  • Nessun upgrade secondario: 30 settembre - 15 gennaio
  • Nessun upgrade: 19 novembre - 4 dicembre
  • Nessun upgrade: 15 dicembre - 5 gennaio

A causa di queste esclusioni sovrapposte, i seguenti upgrade verranno bloccati sul cluster:

  • Upgrade della patch al pool di nodi il 25 novembre (rifiutato dall'esclusione "Nessun upgrade")
  • Upgrade secondario al control plane il 20 dicembre (rifiutato dall'esclusione "Nessun upgrade secondario" e "Nessun upgrade")
  • Upgrade della patch al control plane il 25 dicembre (rifiutato dall'esclusione "Nessun upgrade")
  • Upgrade secondario al pool di nodi il 1° gennaio (rifiutato dall'esclusione "Nessun upgrade secondario" e "Nessun upgrade")

Sul cluster sarebbe consentita la seguente manutenzione:

  • Upgrade della patch al control plane il 10 novembre (consentito dall'esclusione "Nessun upgrade secondario")
  • Interruzione della VM a causa della manutenzione di GKE del 10 dicembre (consentita dall'esclusione "Nessun upgrade secondario")

Esempi di utilizzo

Ecco alcuni casi d'uso di esempio per limitare l'ambito degli aggiornamenti che possono verificarsi.

Esempio: rivenditore che si prepara per il periodo delle festività di fine anno

In questo esempio, l'attività di vendita al dettaglio non vuole interruzioni durante i periodi di vendita con il volume più elevato, ovvero i quattro giorni che comprendono il Black Friday fino al Cyber Monday e il mese di dicembre fino all'inizio del nuovo anno. In preparazione alla stagione dello shopping, l'amministratore del cluster configura le seguenti esclusioni:

  • Nessun upgrade secondario: consente solo gli aggiornamenti delle patch sul control plane e sui nodi tra il 30 settembre e il 15 gennaio.
  • Nessun upgrade: blocca tutti gli upgrade tra il 19 novembre e il 4 dicembre.
  • Nessun upgrade: blocca tutti gli upgrade tra il 15 dicembre e il 5 gennaio.

Se non si applicano altre finestre di esclusione alla scadenza dell'esclusione dalla manutenzione, il cluster viene aggiornato a una nuova versione secondaria di GKE se ne è stata resa disponibile una tra il 30 settembre e il 6 gennaio.

Esempio: azienda che utilizza un'API beta in Kubernetes che verrà rimossa

In questo esempio, un'azienda utilizza l'API CustomResourceDefinition apiextensions.k8s.io/v1beta1, che verrà rimossa nella versione 1.22. Mentre l'azienda esegue versioni precedenti alla 1.22, l'amministratore del cluster configura la seguente esclusione:

  • Nessun upgrade secondario: blocca gli upgrade secondari per tre mesi durante la migrazione delle applicazioni dei clienti da apiextensions.k8s.io/v1beta1 a apiextensions.k8s.io/v1.

Esempio: il database legacy dell'azienda non è resiliente agli upgrade del pool di nodi

In questo esempio, un'azienda esegue un database che non risponde bene all'espulsione e alla riprogrammazione dei pod che si verificano durante l'upgrade di un pool di nodi. L'amministratore del cluster configura la seguente esclusione:

  • Nessun upgrade secondario o dei nodi: blocca gli upgrade dei nodi per tre mesi. Quando l'azienda è pronta ad accettare i tempi di inattività del database, attiva un upgrade manuale del nodo.

Esempio: l'azienda esegue un mix di carichi di lavoro per uso generico e tolleranti agli errori

In questo esempio, un'azienda utilizza un cluster per eseguire un mix di workload che possono e non possono tollerare gli upgrade automatici dei nodi. L'amministratore del cluster vuole che GKE gestisca gli upgrade dei nodi per alcuni pool di nodi, ma non per altri. L'amministratore del cluster utilizza un'esclusione della manutenzione del pool di nodi per tutti i node pool che possono essere sottoposti ad upgrade solo manualmente.

Passaggi successivi