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 ed evitare 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 le esclusioni, ti permettono di controllare quando eseguire determinate operazioni di manutenzione sui cluster, inclusi gli upgrade dei cluster e altre modifiche ai nodi o la topologia di rete del cluster.

Una finestra di manutenzione è una finestra ricorrente durante il quale è consentita la manutenzione automatica di GKE.

Un'esclusione di manutenzione è una finestra non ripetuta di 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 un'esclusione di manutenzione attiva. Per ogni cluster, è possibile configurare un periodo di manutenzione ricorrente e più le esclusioni.

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 apprendere vedi Manutenzione automatica che non rispetta la 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: consulta le sezioni seguenti per capire 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 di GKE, puoi controllare le tempistiche i seguenti tipi di eventi, che causano un'interruzione temporanea 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 e la manutenzione automatica. 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, GKE nodi sono VM di Compute Engine utilizzate 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 dall'host della VM criterio di manutenzione, che per impostazione predefinita per la maggior parte delle VM comporta l'attivazione eseguire la migrazione. 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, incluse quelle con GPU e TPU, non possono eseguire la migrazione live. Se usando questi acceleratori, scopri come gestire le interruzioni dovute alla manutenzione dei nodi della GPU o TPU.

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

Riparazioni e ridimensionamenti automatici

GKE esegue riparazioni automatiche sui piani di controllo. Sono inclusi processi come l'upscaling del piano di controllo a una dimensione appropriata o riavviando il 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 la formazione di cluster non funzionali.

Non puoi disabilitare le riparazioni del piano di controllo. Tuttavia, la maggior parte dei tipi di cluster incluso Autopilot cluster e Regionale standard cluster Avere più repliche dei piani di controllo, per un'alta disponibilità del server API Kubernetes anche durante gli eventi di manutenzione. Standard a livello di zona cluster, che hanno un solo piano di controllo, non possono essere modificati durante il piano modifiche alla configurazione e manutenzione del cluster. Ciò include il deployment carichi di lavoro con scale out impegnativi.

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 e le esclusioni possono causare ritardi nelle patch di sicurezza. Tuttavia, GKE riserva a destra per eseguire l'override di manutenzione per la sicurezza critica le vulnerabilità.

Modifiche manuali che rispettano i criteri di manutenzione di GKE

Alcune modifiche ai nodi o alla configurazione di rete richiedono la loro rievocazione 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 siano esclusioni di manutenzione attive che impediscano la manutenzione dei nodi. Per applicare manualmente le modifiche ai nodi, utilizza l'interfaccia a riga di comando Google Cloud 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.

Periodi di manutenzione

Le finestre di manutenzione ti consentono di controllare quando upgrade automatici del controllo e nodi al fine di mitigare le potenziali interruzioni carichi di lavoro con scale out impegnativi. Le finestre 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à programmando 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 in modo che qualcuno possa monitorare gli upgrade e gestire eventuali problemi imprevisti.
  • Upgrade multi-cluster: vuoi implementare gli upgrade in più in regioni diverse uno alla volta a intervalli specificati.

Oltre agli upgrade automatici, Google potrebbe avere bisogno di 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 o software obsoleto potrebbe 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 utilizzato:

Durante la configurazione dei periodi di manutenzione

Gli orari sono 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, i tuoi 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 che la manutenzione automatica venga eseguita durante un determinato periodo di tempo. Ad esempio, molte attività di vendita al dettaglio esistono linee guida aziendali che proibiscono modifiche all'infrastruttura durante 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 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 di manutenzione.

Ambito di manutenzione da escludere

Non solo potrai specificare quando evitare la manutenzione automatica del tuo puoi 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 nel 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, Autopilot e Standard regionali mantengono la disponibilità del server API Kubernetes. Nei cluster di zona, che hanno un singolo nodo del piano di controllo, i riavvii delle 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 su un cluster. Queste esclusioni possono avere scopi diversi e intervalli di tempo sovrapposti. La caso d'uso per le festività di fine anno è un esempio esclusioni sovrapposte, in cui sia l'opzione "Nessun upgrade" e "Nessun upgrade di minore entità" gli ambiti in uso.

Quando le esclusioni si sovrappongono, sono presenti esclusioni attive (ossia l'ora corrente è entro il periodo di tempo di esclusione) blocca un upgrade, l'upgrade verrà rinviate.

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 sul cluster:

  • Upgrade delle patch al pool di nodi il 25 novembre (respinto da "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 (respinto dalla dicitura "Nessun upgrade" )
  • Upgrade secondario 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 dalla richiesta " upgrade" )
  • Interruzione della VM a causa della manutenzione di GKE il 10 dicembre (consentita dall'esclusione "Nessun upgrade minore")

Scadenza 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.

Se non rimangono esclusioni o altri fattori che impediscono gli upgrade del cluster, GKE esegue gradualmente l'upgrade del cluster a un upgrade automatico idoneo target.

Se il cluster ha perso più upgrade della versione secondaria 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 assicurare che il cluster esegue 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 di manutenzione

Le esclusioni dalla manutenzione presentano le seguenti limitazioni:

  • Puoi limitare l'ambito degli upgrade automatici in un'esclusione della 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 per la 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 di manutenzione su periodi di tempo diversi, a seconda in relazione all'ambito. Per ulteriori dettagli, consulta la riga Lunghezza esclusione per manutenzione nella sezione Configurare un'esclusione per manutenzione.
  • Non puoi configurare un'esclusione per la 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 quanto segue: esempi:
    • In un cluster è in esecuzione una versione minore nel canale stabile, dove la programmazione delle release di GKE indica che la data di fine del supporto 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 esteso in cui La pianificazione delle release di GKE indica 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 apprendere vedi Cambiare il cluster dalla di destinazione.

Esempi di utilizzo

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

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 con il volume più elevato di vendite, ovvero i quattro giorni che Black Friday fino 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: 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 di manutenzione, di un cluster a una nuova versione secondaria di GKE, se ne è stata resa disponibile una 30 settembre e 6 gennaio.

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

In questo esempio, un'azienda utilizza CustomResourceDefinition l'API apiextensions.k8s.io/v1beta1, che verranno rimosse nella versione 1.22. Mentre l'azienda esegue versioni precedenti alla 1.22, il cluster l'amministratore 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 gestisce un database che non risponde bene a Eliminazioni e 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 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