Periodi di manutenzione ed esclusioni

In questa pagina vengono descritti i periodi di manutenzione ed le esclusioni di manutenzione, ovvero i criteri che consentono di controllare il momento in cui la manutenzione dei cluster, ad esempio gli upgrade automatici, può o non può avvenire sui cluster Google Kubernetes Engine (GKE). Ad esempio, un'attività di vendita al dettaglio potrebbe limitare la manutenzione in modo che avvenga solo nelle sere dei giorni feriali e potrebbe impedirne la manutenzione automatica durante un evento chiave di vendita del settore.

Informazioni sui criteri di manutenzione di GKE

I criteri di manutenzione di GKE, che includono periodi di manutenzione ed esclusioni, consentono di controllare quando è possibile eseguire determinate operazioni di manutenzione automatica dei 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 è presente un periodo di manutenzione aperto e nessuna esclusione di manutenzione attiva. 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.

Cosa fanno e non rispettano i criteri di manutenzione di GKE

Prima di configurare i criteri di manutenzione di GKE (periodi di manutenzione ed esclusioni), esamina le sezioni seguenti per capire in che modo GKE e i servizi correlati 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 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 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 VM di Compute Engine che GKE gestisce per il tuo cluster. A volte le VM di Compute Engine riscontrano 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, comporta la migrazione live. Questo in genere 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 cronometrarlo in base ai 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 GPU o TPU.

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

Riparazioni e ridimensionamenti automatici

GKE esegue riparazioni automatiche sui piani di controllo. Ciò include processi come l'aumento delle dimensioni 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ò causare cluster non funzionanti.

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

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

Patch delle vulnerabilità critiche di sicurezza

I periodi di manutenzione e le esclusioni possono causare ritardi nelle patch di sicurezza. Tuttavia, GKE si riserva il diritto di eseguire l'override dei 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 networking richiedono la creazione dei nodi per applicare la nuova configurazione, comprese alcune delle seguenti modifiche:

Queste modifiche rispettano i criteri di manutenzione di GKE, ovvero GKE attende un periodo di manutenzione aperto e nessuna esclusione di manutenzione attiva che impedisce la manutenzione dei nodi. 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 già in esecuzione del pool di nodi.

Periodi di manutenzione

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

  • Ore non 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.
  • Disponibilità: vuoi assicurarti che gli upgrade vengano eseguiti durante l'orario di lavoro, in modo che qualcuno possa monitorare gli upgrade e gestire eventuali problemi imprevisti.
  • Upgrade multi-cluster: vuoi implementare gli upgrade uno alla volta in più cluster in diverse regioni 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 tenta 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 di software deprecati o obsoleti 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, gli orari vengono visualizzati in modo diverso a seconda dello strumento utilizzato:

Durante la configurazione dei 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 periodi 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 e nella console Google Cloud gli orari vengono visualizzati 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 i periodi di manutenzione

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

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

Esclusioni dalla manutenzione

Con le esclusioni di manutenzione, puoi impedire l'esecuzione della 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. Per fare un altro esempio, se un'azienda utilizza un'API il cui ritiro è programmato, può utilizzare le esclusioni di manutenzione per mettere in pausa gli upgrade di minore entità e concedere loro il tempo di eseguire la migrazione delle applicazioni.

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

Le esclusioni non hanno ricorrenza. Crea invece ciascuna 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 di manutenzione da escludere

Non solo puoi specificare quando evitare la manutenzione automatica del tuo cluster, ma puoi anche limitare l'ambito degli aggiornamenti automatici che possono verificarsi. Gli ambiti di esclusione della 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 attuale: 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 interruzioni del pool di nodi: vuoi evitare temporaneamente l'eliminazione e la ripianificazione dei carichi di lavoro a causa degli upgrade dei nodi.

La tabella seguente elenca l'ambito degli aggiornamenti automatici che puoi limitare in un'esclusione della manutenzione. La tabella indica anche il tipo di upgrade eseguiti (minori o patch). Quando vengono eseguiti gli upgrade, le VM per il piano di controllo e i pool di nodi vengono riavviate. 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 ripianificazione 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 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 (opzione 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 delle patch, consulta Schema di controllo delle versioni.

Più esclusioni

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

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

Utilizzando il caso d'uso per le festività di fine anno, per un cluster vengono specificate le seguenti esclusioni:

  • Nessun upgrade di minore entità: 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 di minore entità 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 di minore entità al pool di nodi il 1° gennaio (rifiutato dall'esclusione "Nessun upgrade secondario" e "Nessun upgrade"

Nel cluster sarebbe consentita la seguente manutenzione:

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

Scadenza esclusione

Quando un'esclusione scade, ovvero l'ora attuale è passata oltre l'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.

Se non rimangono esclusioni che impediscono gli upgrade del cluster, il cluster eseguirà gradualmente l'upgrade alla versione predefinita attuale nel canale di rilascio del cluster (o all'impostazione predefinita statica per i cluster in nessun canale di rilascio).

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

Limitazioni alla configurazione delle esclusioni di manutenzione

Le esclusioni di manutenzione hanno 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 di manutenzione solo con l'ambito predefinito "Nessun upgrade".
  • Puoi aggiungere un massimo di tre esclusioni di manutenzione che escludono tutti gli upgrade (ovvero un ambito di tipo "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 di manutenzione per ogni cluster.
  • Se non specifichi un ambito nell'esclusione, per impostazione predefinita l'ambito sarà "nessun upgrade".
  • Puoi impostare le esclusioni di manutenzione su periodi di tempo diversi, a seconda dell'ambito. Per ulteriori dettagli, consulta la riga Lunghezza esclusione dalla manutenzione nella sezione Configurare un'esclusione della manutenzione.
  • Non puoi configurare un'esclusione di 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 precedente.

Esempi di utilizzo

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

Esempio: un 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 maggior volume di vendite, ovvero i quattro giorni che vanno dal Black Friday al Cyber Monday, e dal mese di dicembre all'inizio del nuovo anno. In preparazione per la stagione dello shopping, l'amministratore del cluster configura le seguenti esclusioni:

  • Nessun upgrade di minore entità: consenti solo gli aggiornamenti delle patch sul piano di controllo e dei 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 sono applicabili altre finestre di esclusione, viene eseguito l'upgrade del cluster a una nuova versione secondaria di GKE, se disponibile 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 apiextensions.k8s.io/v1beta1 CustomResourceDefinition, 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 di minore entità: 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: database legacy dell'azienda non resiliente agli upgrade del pool di nodi

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

Passaggi successivi