Periodi di manutenzione ed esclusioni

Questa pagina descrive i periodi di manutenzione e le esclusioni di manutenzione, ovvero criteri che consentono di controllare quando alcune operazioni di manutenzione del cluster, come gli upgrade automatici, possono e non possono essere eseguite sui 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 importante del settore.

Informazioni sui criteri di manutenzione di GKE

I criteri di manutenzione di GKE, che includono periodi di manutenzione ed esclusioni, ti consentono di controllare quando può essere eseguita una determinata manutenzione automatica sui tuoi cluster, inclusi gli upgrade dei 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 è vietata la manutenzione automatica di GKE.

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

Altri tipi di manutenzione non dipendono dalle norme di manutenzione GKE, tra cui le operazioni di riparazione del piano di controllo e la manutenzione dei servizi su cui dipende GKE, come Compute Engine. Per saperne di più, consulta Manutenzione automatica che non rispetta i criteri di manutenzione.

Quali modifiche rispettano e non rispettano le norme di manutenzione di GKE

Prima di configurare i criteri di manutenzione di GKE, ovvero i periodi di manutenzione e le esclusioni, consulta le seguenti sezioni per capire in che modo GKE e i servizi correlati li rispettano e non li rispettano.

Manutenzione automatica che rispetta i criteri di manutenzione di GKE

Con i criteri di manutenzione GKE, puoi controllare la tempistica degli eventi riportati di seguito, che causano interruzioni temporanee del cluster:

Altri tipi di manutenzione automatica non dipendono dai criteri di manutenzione. Per scoprire di più, consulta Manutenzione automatica che non rispetta i criteri di manutenzione.

Manutenzione automatica che non rispetta i criteri di manutenzione di GKE

I periodi di manutenzione ed esclusioni di GKE non bloccano tutti i tipi di manutenzioni automatiche. Prima di configurare i criteri di manutenzione del tuo cluster GKE, assicurati di comprendere quali tipi di modifiche non rispettano le finestre di manutenzione e le esclusioni.

Altra manutenzione di 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 Compute Engine gestite da GKE per il tuo cluster. A volte le VM Compute Engine presentano eventi dell'host, che possono includere eventi di manutenzione o errori dell'host. Il comportamento delle VM durante questi eventi è determinato dai criteri di manutenzione dell'host della VM, che per impostazione predefinita per la maggior parte delle VM indica la migrazione live. In genere, questo significa che i tempi di riposo dei nodi sono ridotti al minimo 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 in modo che corrisponda ai tuoi criteri di manutenzione GKE.

Alcune VM, tra cui quelle con GPU e TPU, non possono eseguire la migrazione live. Se utilizzi questi acceleratori, scopri come gestire l'interruzione dovuta alla manutenzione dei nodi per le GPU o le TPU.

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

Riparazioni e ridimensionamenti automatici

GKE esegue riparazioni automatiche sui piani di controllo. Sono incluse procedure come l'aumento della dimensione del piano di controllo a una dimensione appropriata o il riavvio del piano di controllo 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 funzionali.

Non puoi disattivare le riparazioni del piano di controllo. Tuttavia, la maggior parte dei tipi di cluster, tra cui i cluster Autopilot e i cluster regionali standard, hanno più repliche dei piani di controllo, il che consente un'alta disponibilità 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. Sono inclusi i carichi di lavoro.

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

Applicazione di patch per vulnerabilità di sicurezza critiche

I periodi di manutenzione ed esclusioni possono causare ritardi nell'applicazione delle patch di sicurezza. Tuttavia, GKE si riserva il diritto di eseguire l'override dei criteri di manutenzione per vulnerabilità di sicurezza critiche.

Modifiche manuali che rispettano i criteri di manutenzione di GKE

Alcune modifiche ai nodi o alla configurazione di rete richiedono la loro riecreazione per applicare la nuova configurazione, tra cui alcune delle seguenti modifiche:

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

Modifiche manuali che non rispettano i criteri 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, vedi Modifiche manuali che ricreano i nodi utilizzando una strategia di upgrade dei nodi senza rispettare le norme di manutenzi.

Periodi di manutenzione

I periodi di manutenzione ti consentono di controllare quando possono avvenire 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:

  • Orari non di punta:per ridurre al minimo le probabilità di tempi di riposo, pianifica gli upgrade automatici durante gli orari non di punta, quando il traffico è ridotto.
  • A chiamata: 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 su più cluster in regioni diverse, uno alla volta e a intervalli specificati.

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

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

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 ritirato o obsoleto potrebbero avvenire 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.

Fusi orari per i periodi di manutenzione

Quando configuri e visualizzi i periodi di manutenzione, i tempi vengono mostrati in modo diverso in base allo 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, puoi utilizzare il fuso orario UTC o quello locale.

Quando configuri le finestre di manutenzione utilizzando il flag --maintenance-window più generico, non puoi specificare un fuso orario. UTC viene utilizzato quando si utilizza l'interfaccia a riga di comando gcloud o l'API, mentre la console Google Cloud mostra le ore 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 possono essere mostrati in UTC o nel fuso orario locale, a seconda di come visualizzi le informazioni:

  • Quando utilizzi la console Google Cloud per visualizzare le informazioni sul tuo cluster, le ore vengono sempre visualizzate nel tuo fuso orario locale.
  • Quando utilizzi gcloud CLI per visualizzare le informazioni sul tuo cluster, gli orari sono sempre indicati nel fuso orario UTC.

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

Esclusioni dalla manutenzione

Con le esclusioni di manutenzione, puoi impedire l'esecuzione automatica della manutenzione durante un determinato periodo di tempo. Ad esempio, molte attività di vendita al dettaglio hanno linee guida aziendali che vietano le modifiche dell'infrastruttura durante le festività di fine anno. Un altro esempio: se un'azienda utilizza un'API per la quale è prevista la ritirata, può utilizzare le esclusioni per la manutenzione per mettere in pausa gli upgrade minori e avere il tempo di eseguire la migrazione delle applicazioni.

Per gli eventi noti ad alto impatto, ti consigliamo di associare eventuali limitazioni relative alle modifiche interne a un'esclusione per manutenzione che inizi una settimana prima dell'evento e duri per tutta la sua durata.

Le esclusioni non sono ricorrenti. 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, consulta Configurare un'esclusione dalla manutenzione.

Ambito della manutenzione da escludere

Non solo puoi specificare quando impedire la manutenzione automatica del tuo cluster, ma puoi anche limitare l'ambito degli aggiornamenti automatici che potrebbero verificarsi. Gli ambiti di esclusione per la manutenzione sono utili, tra gli altri, per i seguenti tipi di scenari:

  • Nessun upgrade: evita la 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 temporaneamente la versione secondaria di un cluster per evitare modifiche all'API o convalidare la versione secondaria successiva.
  • Nessun upgrade secondario o di nodi: evita l'interruzione dei nodi: vuoi evitare temporaneamente l'espulsione e la 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 con patch per i nodi o i control plane del cluster.

Quando GKE esegue l'upgrade di un cluster, le VM per il piano di controllo e il nodo si riavviano. Per i piani di controllo, i cluster Autopilot e regionali standard mantengono la disponibilità del server API Kubernetes. Nei cluster di zona, che hanno un singolo nodo del piano di controllo, i riavvii della VM rendono temporaneamente non disponibile il piano di controllo. Per i nodi, i riavvii delle VM attivano la riprogrammazione dei pod, che può interrompere temporaneamente i carichi di lavoro esistenti. Puoi impostare la tolleranza per l'interruzione del carico di lavoro utilizzando un budget di interruzione dei pod (PDB).

Ambito Piano di controllo Nodi
Upgrade secondario automatico Upgrade automatico delle patch Upgrade secondario automatico Upgrade automatico delle patch
Nessun upgrade (impostazione predefinita) Non consentito Non consentito Non consentito Non consentito
Nessun upgrade secondario Non consentito Consentito Non consentito Consentito
Nessun upgrade secondario o di nodi Non consentito Consentito Non consentito Non consentito

Per le definizioni delle versioni secondarie e delle patch, vedi Schema di controllo delle versioni.

Più esclusioni

Puoi impostare più esclusioni in un cluster. Queste esclusioni possono avere scopi diversi e intervalli di tempo sovrapposti. Il caso d'uso relativo alle festività di fine anno è un esempio di esclusioni sovrapposte, in cui sono in uso sia gli scopi "Nessun upgrade" sia "Nessun upgrade minore".

Quando le esclusioni si sovrappongono, se un'esclusione attiva (ovvero l'ora corrente 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, per un cluster sono specificate le seguenti esclusioni:

  • 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 nel cluster:

  • Upgrade delle patch al pool di nodi il 25 novembre (rifiutato dall'esclusione "Nessun upgrade")
  • Upgrade secondario al piano di controllo il 20 dicembre (rifiutato dall'esclusione "Nessun upgrade secondario" e "Nessun upgrade")
  • Upgrade delle patch al piano di controllo 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 è consentita la seguente manutenzione:

  • Upgrade delle patch al piano di controllo il 10 novembre (consentito dall'esclusione "Nessun upgrade secondario")
  • Interruzione della VM a causa della manutenzione di GKE il 10 dicembre (consentita dall'esclusione "Nessun upgrade minore")

Scadenza dell'esclusione

Quando un'esclusione scade (ovvero quando l'ora corrente è successiva all'ora di fine specificata per l'esclusione), l'esclusione non impedirà più gli aggiornamenti di GKE. Altre esclusioni ancora valide (non scadute) continueranno a impedire gli aggiornamenti di GKE.

Quando non ci sono più esclusioni o altri fattori che impediscono gli upgrade dei cluster, GKE esegue gradualmente l'upgrade del cluster ai target di upgrade automatico idonei.

Se il tuo cluster ha perso più upgrade delle versioni secondarie a causa dell'esclusione, GKE pianifica circa un upgrade della versione secondaria al mese, eseguendo l'upgrade sia del piano di controllo del cluster sia dei nodi per assicurarsi che il cluster esegua una versione supportata. Puoi sempre eseguire upgrade manuali per portare il tuo cluster a una versione minore specifica in tempi più brevi.

Limitazioni alla configurazione delle esclusioni dalla manutenzione

Le esclusioni dalla manutenzione presentano le seguenti limitazioni:

  • Puoi limitare l'ambito degli upgrade automatici in un'esclusione di manutenzione solo per i cluster registrati in un canale di rilascio. Per i cluster non registrati in 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 per la manutenzione per ogni cluster.
  • Se non specifichi un ambito nell'esclusione, il valore predefinito è "no upgrades".
  • Puoi impostare le esclusioni per la manutenzione su durate diverse, a seconda dell'ambito. Per ulteriori dettagli, consulta la riga Lunghezza esclusione per manutenzione nella sezione Configurare un'esclusione per manutenzione.
  • Non puoi configurare un'esclusione dalla manutenzione in modo che includa o superi la data di fine del supporto della versione minore corrispondente alla registrazione al canale di rilascio del cluster. Consulta i seguenti esempi:
    • In un cluster è in esecuzione una versione secondaria nel canale stabile, dove la programmazione delle release 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 prima.
    • Un cluster esegue una versione secondaria nel canale Extended, dove 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 prima. Se vuoi cambiare il canale di rilascio del cluster in un altro canale, devi modificare l'ora di fine dell'esclusione per la manutenzione se supera la fine dell'assistenza standard. Per scoprire di più, consulta Modificare il cluster dal canale Extended.

Esempi di utilizzo

Di seguito sono riportati alcuni casi d'uso di esempio per limitare l'ambito degli aggiornamenti che possono verificarsi.

Esempio: rivenditore che si prepara per le 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 vanno dal Black Friday al Cyber Monday e il mese di dicembre fino all'inizio del nuovo anno. In preparazione per la stagione degli acquisti, l'amministratore del cluster configura le seguenti esclusioni:

  • Nessun upgrade secondario: consenti solo aggiornamenti delle patch sul piano di controllo e sui nodi tra il 30 settembre e il 15 gennaio.
  • Nessun upgrade: tutti gli upgrade verranno bloccati tra il 19 novembre e il 4 dicembre.
  • Nessun upgrade: tutti gli upgrade verranno bloccati tra il 15 dicembre e il 5 gennaio.

Se non vengono applicate altre finestre di esclusione alla scadenza dell'esclusione dalla manutenzione, viene eseguito l'upgrade del cluster a una nuova versione minore 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 precedente dell'azienda non è resiliente agli upgrade del pool di nodi

In questo esempio, un'azienda esegue un database che non risponde bene agli espulsioni 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 di nodi: blocca gli upgrade dei nodi per tre mesi. Quando l'azienda è pronta ad accettare il tempo di riposo del database, attiva un upgrade manuale dei nodi.

Passaggi successivi