Periodi di manutenzione ed esclusioni

Questa pagina descrive i periodi di manutenzione e le esclusioni dalla manutenzione, ovvero criteri che forniscono il controllo su 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

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 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 norme di manutenzione del cluster quando è presente un periodo di manutenzione aperto e non è attiva alcuna esclusione dalla manutenzione. Per ogni cluster, puoi configurare una 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 scoprire di più, vedi 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 norme di manutenzione di GKE

Con i criteri di manutenzione di GKE, puoi controllare la tempistica dei seguenti tipi di eventi, che causano un'interruzione temporanea del 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 riscontrano 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 norme 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. Sono inclusi 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 disattivare le riparazioni del control plane. Tuttavia, la maggior parte dei tipi di cluster, inclusi i cluster Autopilot e i cluster regionali standard, dispone di più repliche dei piani di controllo, il che consente l'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. 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 di rete 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 immediatamente i nodi utilizzando 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 policy di manutenzione.

Periodi di manutenzione

I periodi di manutenzione consentono di controllare quando possono avvenire gli upgrade automatici dei control plane e dei nodi, per ridurre 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 eseguire il deployment degli upgrade su 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 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 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.

Fusi orari per i periodi di manutenzione

Quando configuri e visualizzi i periodi 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 il fuso orario UTC o locale.

Quando configuri le finestre di manutenzione utilizzando il flag --maintenance-window più generico, non puoi specificare un fuso orario. Il fuso orario UTC viene utilizzato 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 tuo 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 Google Cloud console 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 nel fuso orario UTC.

Esclusioni dalla manutenzione

Con le esclusioni di manutenzione, puoi impedire che la manutenzione automatica 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 deprecazione è pianificata, può utilizzare le esclusioni di manutenzione per sospendere gli aggiornamenti secondari e avere il tempo di eseguire la migrazione delle applicazioni.

Per gli eventi noti ad alto impatto, ti consigliamo di abbinare eventuali limitazioni interne alle modifiche con 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, 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 della manutenzione sono utili per i seguenti tipi di scenari, tra gli altri:

  • 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 attuale di Kubernetes. Vuoi mantenere temporaneamente la versione secondaria di un cluster per evitare modifiche alle API o convalidare la versione secondaria successiva.
  • Nessun upgrade secondario o dei nodi: impedisci l'interruzione dei nodi. Vuoi evitare temporaneamente qualsiasi espulsione e riprogrammazione dei tuoi 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.

Quando GKE esegue l'upgrade di un cluster, le VM per il piano di controllo 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 riprogrammazione dei pod, che può interrompere temporaneamente i carichi di lavoro esistenti. Puoi impostare la tolleranza all'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.

Esclusioni multiple

Puoi impostare più esclusioni su un cluster. Queste esclusioni potrebbero 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 dovuta alla manutenzione di GKE del 10 dicembre (consentita dall'esclusione "Nessun upgrade secondario")

Scadenza dell'esclusione

Quando una regola di esclusione scade (ovvero, l'ora corrente supera l'ora di fine specificata per l'esclusione), questa non impedirà più gli aggiornamenti di GKE. Altre esclusioni ancora valide (non scadute) 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 delle versioni secondarie a causa dell'esclusione, GKE pianifica circa un upgrade della 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 cluster a una versione secondaria specifica in tempi più brevi.

Limitazioni alla configurazione delle esclusioni dalla manutenzione

Le esclusioni dalla manutenzione 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 per ogni cluster.
  • Se non specifichi un ambito nell'esclusione, l'ambito predefinito è "nessun upgrade".
  • Puoi impostare esclusioni dalla manutenzione per periodi di tempo diversi, a seconda dell'ambito. Per ulteriori dettagli, esamina la riga Durata dell'esclusione dalla manutenzione nella sezione Configurare un'esclusione dalla manutenzione.
  • Non puoi configurare un'esclusione dalla manutenzione in modo che includa o superi la data di fine del supporto della versione secondaria corrispondente alla registrazione del canale di rilascio del cluster. Vedi i seguenti esempi:
    • Un cluster esegue una versione secondaria nel canale stabile in cui 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 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.

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:

  • Esegui l'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 node pool 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.

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 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ù alto, 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 degli acquisti, 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 della 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.

Passaggi successivi