Periodi di manutenzione ed esclusioni

In questa pagina vengono descritti i periodi di manutenzione e i periodi di manutenzione esclusioni, ovvero norme che consentono di controllare quando la manutenzione del cluster, come gli upgrade automatici, può e non può avvenire di Google Kubernetes Engine (GKE). Ad esempio, un'attività di vendita al dettaglio può limitare la manutenzione si verifichi solo nelle sere dei giorni feriali e potrebbe impedire durante un importante evento di vendita 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 le di manutenzione quando è presente un periodo di manutenzione e nessuna esclusione di manutenzione attiva. Per ogni cluster, è possibile configurare un periodo di manutenzione ricorrente e più le esclusioni.

Altri tipi di manutenzione non dipendono dalla manutenzione di GKE tra cui le operazioni di riparazione del piano di controllo e la manutenzione di servizi da cui dipende GKE, ad esempio Compute Engine. Per ulteriori informazioni 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 la 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 la cluster GKE di manutenzione, assicurati di comprendere quali tipi di modifiche non devono rispettare periodi di manutenzione ed esclusioni.

Altra manutenzione di Google Cloud

I periodi di manutenzione e le esclusioni di GKE non impediscono manutenzione dei servizi Google Cloud sottostanti, principalmente Compute Engine, o 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 di Compute Engine utilizzano un host eventi, 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. Questo comporta in genere tempi di inattività minimi o nulli per i nodi e, per la maggior parte dei carichi di lavoro, sono sufficienti i criteri predefiniti. Per alcune famiglie di macchine VM, puoi monitorare e pianificare un evento di manutenzione dell'host e attivare una manutenzione dell'host evento per cronometrarlo i tuoi criteri di manutenzione di 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 su controllo aerei. 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 periodi di manutenzione ed esclusioni, perché la mancata esecuzione delle riparazioni può generano 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 hanno anche 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 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 che i nodi siano viene ricreato 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 nessuna attività che impediscono 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 di GKE il pool di nodi è già in esecuzione.

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 mette in pausa le attività e tenta di riprenderle durante la manutenzione successiva finestra.

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 manutenzione puoi usare il fuso orario UTC o locale.

Quando configuri periodi di manutenzione usando il modello --maintenance-window, non puoi specificare un fuso orario. Il fuso orario UTC viene utilizzato quando utilizzando gcloud CLI o l'API e la console Google Cloud visualizza volte 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, i tuoi fuso orario locale.

Durante i periodi di manutenzione

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

  • Quando utilizzi la console Google Cloud per visualizzare le informazioni sul tuo 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, questi giorni sono nel fuso orario UTC.

Esclusioni dalla manutenzione

Con le esclusioni di manutenzione, puoi impedire che la manutenzione automatica che si verificano durante un periodo di tempo specifico. Ad esempio, molte attività di vendita al dettaglio esistono linee guida aziendali che proibiscono modifiche all'infrastruttura durante festività di fine anno. Per fare un altro esempio, se un'azienda utilizza un'API che pianificato per il ritiro, possono usare le esclusioni di manutenzione per mettere in pausa per dare loro il tempo di eseguire la migrazione delle applicazioni.

Per gli eventi noti ad alto impatto, ti consigliamo di abbinare qualsiasi modifica interna limitazioni con un'esclusione di manutenzione che inizia una settimana prima dell'evento e per tutta la durata dell'evento.

Le esclusioni non hanno ricorrenza. Crea invece ciascuna istanza di un evento periodico da escludere 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 puoi specificare quando evitare la manutenzione automatica del tuo puoi 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 la manutenzione: vuoi evitare temporaneamente qualsiasi nel cluster durante un periodo di tempo specifico. Questa è l'impostazione predefinita l'ambito di attività.
  • 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 successiva versione secondaria.
  • 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 di 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 (minore 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 l'API Kubernetes Disponibilità server, soprattutto nella topologia dei cluster di zona con un singolo controllo aereo. Per i nodi, i riavvii delle VM attivano la ripianificazione dei pod, che può temporaneamente per interrompere 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 diversi e potrebbero avere 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 per le festività di fine anno, per un cluster sono 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 sul cluster:

  • Upgrade delle patch al pool di nodi il 25 novembre (respinto da "Nessun upgrade" )
  • Upgrade di minore entità al piano di controllo il 20 dicembre (rifiutato da "Nessun upgrade" e "Nessun upgrade" )
  • Upgrade delle patch al piano di controllo il 25 dicembre (respinto dalla dicitura "Nessun upgrade" )
  • Upgrade di minore entità al pool di nodi il 1° gennaio (rifiutato da "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 dovuta alla manutenzione di GKE il 10 dicembre (consentita da "Nessun upgrade" )

Scadenza esclusione

Quando scade un'esclusione, ovvero l'ora corrente è stata spostata oltre la fine orario specificato per l'esclusione), tale esclusione non impedirà più Aggiornamenti di GKE. Altre esclusioni ancora valide (non scadute) continuerà a impedire gli aggiornamenti di GKE.

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

Se il cluster ha più versioni secondarie dietro l'attuale versione predefinita dopo la scadenza dell'esclusione, GKE pianificherà un upgrade secondario per (con l'upgrade sia del piano di controllo del cluster sia dei nodi) finché il cluster non raggiunta la versione predefinita per il canale di rilascio. Se vuoi restituire il cluster per la versione predefinita, puoi eseguire upgrade manuali.

Limitazioni alla configurazione delle esclusioni di manutenzione

Le esclusioni di manutenzione hanno le seguenti limitazioni:

  • Puoi limitare solo l'ambito di upgrade automatici in un'esclusione di manutenzione per i cluster registrati in un canale di rilascio. Per i cluster non registrati in una release canale, puoi creare un'esclusione di manutenzione solo con il valore predefinito "Nessun upgrade" ambito di archiviazione.
  • Puoi aggiungere un massimo di tre esclusioni di manutenzione che escludono tutte (ovvero, un ambito di "nessun upgrade"). Queste esclusioni devono essere configurate per consentire almeno 48 ore di disponibilità per la manutenzione in un Finestra 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à "no upgrade".
  • Puoi impostare le esclusioni di manutenzione su periodi di tempo diversi, a seconda in relazione all'ambito. Esamina la riga Lunghezza esclusione manutenzione nel Configura una manutenzione esclusione per ulteriori dettagli.
  • Non puoi configurare un'esclusione di manutenzione per includere o superare la fine di di ciclo di vita della versione secondaria. Ad esempio, con un cluster che esegue un minore personalizzata in cui La pianificazione delle release di GKE indica che la data di fine del ciclo di vita è giugno 5 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 con il volume più elevato di vendite, ovvero i quattro giorni che Black Friday fino al Cyber Monday, e dal mese di dicembre all'inizio del nuovo anno. In preparazione per durante la stagione dello shopping, l'amministratore del cluster configura le seguenti esclusioni:

  • Nessun upgrade secondario: consenti solo gli aggiornamenti delle patch sul piano di controllo e 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 di minore entità: blocca gli upgrade di minore entità per tre mesi mentre migrazione delle applicazioni del cliente 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 gestisce un database che non risponde bene a Eliminazioni e ripianificazione dei pod che si verificano durante l'upgrade di un pool di nodi. La 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, manualmente i nodi.

Passaggi successivi