Periodi di manutenzione ed esclusioni

In questa pagina vengono descritti i periodi di manutenzione e le esclusioni di manutenzione, che sono criteri che consentono di controllare quando alcune operazioni di manutenzione dei cluster, ad esempio gli upgrade automatici, possono e non possono essere eseguite nei cluster Google Kubernetes Engine (GKE). Ad esempio, un'attività di vendita al dettaglio potrebbe limitare la manutenzione solo nelle sere dei giorni feriali e potrebbe impedire la manutenzione automatica durante un evento di vendita chiave 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ò verificarsi 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 ripetuto durante il quale è vietata la manutenzione automatica di GKE.

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

Altri tipi di manutenzione non dipendono dai criteri di manutenzione di GKE, tra cui le operazioni di riparazione del piano di controllo e la manutenzione dei servizi da cui dipende GKE, ad esempio Compute Engine. Per scoprire di più, consulta Manutenzione automatica che non rispetta i criteri di manutenzione.

Quali modifiche rispettano e non rispettano i criteri di manutenzione di GKE

Prima di configurare i criteri di manutenzione di GKE (periodi di manutenzione ed esclusioni), rivedi le sezioni seguenti per capire in che modo GKE e i relativi servizi li rispettano e come non li rispettano.

Manutenzione automatica che rispetta i criteri di manutenzione di GKE

Con i criteri di manutenzione di GKE, puoi controllare la tempistica dei seguenti tipi di eventi, che causano interruzioni temporanee del tuo 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 e le esclusioni di GKE non bloccano tutti i tipi di manutenzione automatica. Prima di configurare i criteri di manutenzione del tuo cluster GKE, assicurati di comprendere quali tipi di modifiche non rispettano periodi di manutenzione ed esclusioni.

Altra manutenzione di Google Cloud

I periodi 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 di GKE sono le VM di Compute Engine che GKE gestisce per il tuo cluster. A volte le VM di Compute Engine si verificano eventi host, che possono includere eventi di manutenzione o errori dell'host. Il comportamento delle VM durante questi eventi è determinato dal criterio di manutenzione dell'host della VM, che, per impostazione predefinita per la maggior parte delle VM, prevede la migrazione live. Questo di solito comporta 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 i criteri di manutenzione di GKE.

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

Ti consigliamo di esaminare le informazioni sugli eventi host, sui criteri di manutenzione dell'host e di verificare che i carichi di lavoro siano pronti per l'interruzione, soprattutto se vengono eseguiti su nodi che non possono eseguire una migrazione live.

Riparazioni e ridimensionamento automatici

GKE esegue riparazioni automatiche sui piani di controllo. Sono inclusi processi come l'upscaling del piano di controllo a una dimensione appropriata o il riavvio del piano per risolvere i problemi. La maggior parte delle riparazioni ignora i periodi di manutenzione e le esclusioni, in quanto la mancata esecuzione delle riparazioni può causare cluster non funzionanti.

Non puoi disattivare le riparazioni del piano di controllo. Tuttavia, la maggior parte dei tipi di cluster, inclusi i cluster Autopilot e i cluster a livello di regione 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 di zona standard, che hanno un solo piano di controllo, non possono essere modificati durante le modifiche alla configurazione del piano di controllo e la manutenzione dei cluster. Ciò include il deployment dei carichi di lavoro.

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

Patch delle vulnerabilità di sicurezza critiche

I periodi di manutenzione e le esclusioni possono causare ritardi nelle patch di sicurezza. Tuttavia, GKE si riserva il diritto di sostituire i criteri di manutenzione per le vulnerabilità di sicurezza critiche.

Modifiche manuali che rispettano i criteri di manutenzione di GKE

Alcune modifiche ai nodi o alla configurazione di rete richiedono di ricreare i nodi per applicare la nuova configurazione, incluse alcune delle seguenti modifiche:

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

Periodi di manutenzione

I periodi di manutenzione consentono di controllare quando possono essere eseguiti upgrade automatici dei piani di controllo e dei nodi, al fine di mitigare le potenziali interruzioni temporanee dei carichi di lavoro. I periodi di manutenzione sono utili, tra gli altri, per i seguenti tipi di scenari:

  • Ore di punta: vuoi ridurre al minimo la possibilità di tempi di inattività pianificando upgrade automatici al di fuori delle ore di punta quando il traffico è ridotto.
  • On-call: 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 diverse regioni uno alla volta a intervalli specificati.

Oltre agli upgrade automatici, a volte Google potrebbe dover eseguire altre attività di manutenzione e rispettare 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 di software deprecato 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 a seconda dello strumento che stai utilizzando:

Quando configuri i periodi di manutenzione

Gli orari sono sempre memorizzati nel fuso orario UTC. Tuttavia, quando configuri il periodo di manutenzione, puoi utilizzare il fuso orario UTC o locale.

Quando configuri i periodi di manutenzione utilizzando il flag più generico --maintenance-window, non puoi specificare un fuso orario. Il fuso orario UTC viene utilizzato quando si utilizza gcloud CLI o l'API e la console Google Cloud mostra gli orari nel 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.

Durante la visualizzazione dei periodi di manutenzione

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

  • Quando utilizzi la console Google Cloud per visualizzare le informazioni sul cluster, gli orari sono sempre visualizzati nel fuso orario locale.
  • Quando utilizzi gcloud CLI per visualizzare le informazioni sul 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, giorni della settimana, quei giorni sono in UTC.

Esclusioni dalla manutenzione

Con le esclusioni di manutenzione, puoi impedire che venga eseguita la manutenzione automatica durante un periodo di tempo specifico. Ad esempio, molte attività di vendita al dettaglio hanno linee guida che vietano modifiche all'infrastruttura durante le festività di fine anno. Come ulteriore esempio, se un'azienda utilizza un'API di cui è prevista la deprecazione, può utilizzare le esclusioni dalla manutenzione per mettere in pausa gli upgrade minori e dare il tempo di eseguire la migrazione delle applicazioni.

Per gli eventi noti ad alto impatto, ti consigliamo di applicare a tutte le limitazioni relative alle modifiche interne un'esclusione di manutenzione che inizia una settimana prima dell'evento e dura per l'intera durata dell'evento.

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 di manutenzione per un cluster nuovo o esistente, consulta Configurare un'esclusione della manutenzione.

Ambito della manutenzione da escludere

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

  • 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 all'API o convalidare la versione secondaria successiva.
  • Nessun upgrade secondario o dei nodi: evita l'interruzione del pool di nodi: vuoi evitare temporaneamente l'eliminazione e la ripianificazione dei carichi di lavoro a causa degli upgrade dei nodi.

La seguente tabella elenca l'ambito degli aggiornamenti automatici che puoi limitare in un'esclusione dalla manutenzione. La tabella indica anche il tipo di upgrade verificati (minor o patch). Quando si verificano upgrade, le VM per il piano di controllo e i pool di nodi si riavviano. Per i piani di controllo, i riavvii delle VM possono ridurre temporaneamente la disponibilità del server API Kubernetes, soprattutto nella topologia dei cluster di zona con un singolo 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 dei carichi di lavoro utilizzando un budget di interruzione dei pod (PDB).

Ambito Piano di controllo Pool di nodi
Upgrade di minore entità Upgrade delle patch Interruzione della VM
a causa della manutenzione
di GKE		 Upgrade di minore entità Upgrade delle patch Interruzione della VM
a causa della manutenzione
di GKE
Nessun upgrade (impostazione predefinita) No No No No No No
Nessun upgrade secondario No Sì Sì No Sì Sì
Nessun upgrade secondario o di nodi No Sì Sì No No No

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

Più esclusioni

Puoi impostare più esclusioni su un cluster. Queste esclusioni possono avere ambiti diversi e avere intervalli di tempo sovrapposti. Il caso d'uso per le festività di fine anno è un esempio di esclusioni sovrapposte, in cui sono in uso entrambi gli ambiti "Nessun upgrade" e "Nessun upgrade secondario".

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

Utilizzando il caso d'uso durante le 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 sul cluster:

  • Upgrade delle patch al pool di nodi il 25 novembre (rifiutato dall'esclusione "Nessun upgrade")
  • Upgrade di minore entità al piano di controllo il 20 dicembre (rifiutato dall'esclusione "Nessun upgrade secondario" e "Nessun upgrade")
  • Upgrade della patch al piano di controllo il 25 dicembre (rifiutato dall'esclusione "Nessun upgrade")
  • Upgrade di minore entità al pool di nodi il 1° gennaio (rifiutato dall'esclusione "Nessun upgrade secondario" e "Nessun upgrade")

Sarà consentita la seguente manutenzione sul cluster:

  • Upgrade della 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 secondario")

Scadenza esclusione

Quando un'esclusione scade (ossia, l'ora attuale è stata spostata oltre l'ora di fine specificata per l'esclusione), l'esclusione non impedirà più gli aggiornamenti di GKE. Le altre esclusioni ancora valide (non scadute) continueranno a impedire gli aggiornamenti di GKE.

Se non rimangono esclusioni che impediscono gli upgrade del cluster, viene eseguito gradualmente l'upgrade del cluster alla versione predefinita attuale nel canale di rilascio del cluster (o al valore predefinito statico per i cluster in nessun canale di rilascio).

Se il cluster ha più versioni secondarie indietro rispetto all'attuale versione predefinita dopo la scadenza dell'esclusione, GKE pianificherà un upgrade secondario al mese (eseguendo l'upgrade sia del piano di controllo che dei nodi del cluster) finché il cluster non raggiunge la versione predefinita per il canale di rilascio. Se vuoi ripristinare prima il cluster alla versione predefinita, puoi eseguire upgrade manuali.

Limitazioni sulla configurazione delle esclusioni dalla manutenzione

Le esclusioni dalla manutenzione presentano le seguenti limitazioni:

  • Puoi limitare l'ambito degli upgrade automatici in un'esclusione dalla manutenzione solo per i cluster registrati in un canale di rilascio. Per i cluster non registrati in un canale di rilascio, puoi creare solo un'esclusione di manutenzione con l'ambito predefinito "Nessun upgrade".
  • Puoi aggiungere un massimo di tre esclusioni di manutenzione che escludono tutti gli upgrade (ossia un ambito di "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 impostare un massimo di 20 esclusioni dalla manutenzione per ogni cluster.
  • Se non specifichi un ambito nell'esclusione, per impostazione predefinita l'ambito è "Nessun upgrade".
  • Puoi impostare le esclusioni dalla manutenzione su durate diverse, a seconda dell'ambito. Per ulteriori dettagli, consulta la riga Lunghezza dell'esclusione della manutenzione nella sezione Configurare un'esclusione della manutenzione per ulteriori dettagli.
  • Non puoi configurare un'esclusione dalla manutenzione per includere o superare la data di fine del ciclo di vita della versione secondaria. Ad esempio, con un cluster che esegue una versione secondaria in cui la pianificazione delle release di GKE indica che la data di fine del ciclo di vita è il 5 giugno 2023, devi impostare l'ora di fine dell'esclusione della manutenzione su 2023-06-05T00:00:00Z o su una data precedente.

Esempi di utilizzo

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

Esempio: un rivenditore che si sta preparando per le festività di fine anno

In questo esempio, l'attività retail non vuole interruzioni durante i periodi di vendita con i volumi più alti, ovvero i quattro giorni del Black Friday e il Cyber Monday, e il mese di dicembre fino all'inizio del nuovo anno. In preparazione alla stagione degli acquisti, l'amministratore del cluster imposta le seguenti esclusioni:

  • Nessun upgrade secondario: consenti solo gli aggiornamenti delle patch sul piano di controllo 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 alla scadenza dell'esclusione di manutenzione non si applicano altri periodi di esclusione, verrà eseguito l'upgrade del cluster a una nuova versione secondaria di GKE, se resa disponibile tra il 30 settembre e il 6 gennaio.

Esempio: azienda che utilizza un'API beta in Kubernetes che è in fase di rimozione

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 di minore entità per tre mesi durante la migrazione delle applicazioni dei clienti da apiextensions.k8s.io/v1beta1 a apiextensions.k8s.io/v1.

Esempio: database legacy dell'azienda non resiliente agli upgrade dei pool di nodi

In questo esempio, un'azienda sta eseguendo un database che non risponde bene alle eliminazioni dei pod e alla ripianificazione che si verifica 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 tempi di inattività per il database, attiva un upgrade manuale del nodo.

Passaggi successivi