Periodi di manutenzione ed esclusioni

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questa pagina descrive i periodi di manutenzione e le esclusioni di manutenzione, che forniscono un controllo su quando la manutenzione del cluster, ad esempio gli upgrade automatici, può avvenire o meno sui cluster di Google Kubernetes Engine (GKE). Ad esempio, un'attività di vendita al dettaglio potrebbe limitare la manutenzione solo le sere dei giorni feriali e potrebbe impedire la manutenzione automatica durante un evento di vendita chiave del settore.

Panoramica

I periodi di manutenzione e le esclusioni ti consentono di controllare in modo granulare quando può essere eseguita la manutenzione automatica sui tuoi cluster.

Un periodo di manutenzione è un periodo di tempo ricorrente in cui è consentita la manutenzione automatica.

Un'esclusione di manutenzione è un periodo di tempo non ripetuto durante il quale è vietata la manutenzione automatica.

Puoi configurare i periodi di manutenzione e le esclusioni dalla manutenzione separatamente e in modo indipendente. Puoi configurare più esclusioni dalla manutenzione.

Esempi di manutenzione automatica

Google esegue attività di manutenzione sui cluster in base alle esigenze o quando apporti una modifica alla configurazione che ricrea i nodi o le reti nel cluster, come ad esempio:

I cluster di zona non possono essere modificati durante le modifiche alla configurazione del piano di controllo e la manutenzione del cluster. incluso il deployment di carichi di lavoro.

Tutti gli altri tipi di modifiche elencati sopra possono causare interruzioni temporanee durante la migrazione dei carichi di lavoro ai nodi aggiornati.

Avvertenze

I periodi di manutenzione e le esclusioni possono causare ritardi nelle patch di sicurezza. GKE si riserva il diritto di ignorare i criteri di manutenzione per le vulnerabilità di sicurezza critiche. Prima di attivare i periodi di manutenzione e le esclusioni, assicurati di aver compreso le seguenti avvertenze.

Altra manutenzione Google Cloud

I cluster e i carichi di lavoro GKE possono anche essere interessati dalla manutenzione automatica su altri servizi dipendenti, ad esempio Compute Engine. I periodi di manutenzione e le esclusioni di GKE non impediscono la manutenzione automatica da altri servizi Google o dai servizi che installano applicazioni nel cluster, ad esempio Google Cloud Deploy.

Riparazioni e ridimensionamenti automatici

GKE esegue riparazioni automatiche sui piani di controllo. Sono inclusi processi come l'aumento del numero di piani 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é il mancato esecuzione delle riparazioni può causare cluster non funzionanti. La riparazione dei piani di controllo non può essere disabilitata.

I nodi hanno anche la funzionalità di riparazione automatica, ma possono essere disabilitati.

Finestre di ricreazione e manutenzione dei nodi

Quando abiliti o modifichi funzionalità o opzioni come quelle che influiscono sulla rete tra i piani di controllo e i nodi, i nodi vengono ricreati per applicare la nuova configurazione. Ecco alcuni esempi di funzionalità che causano la ricreazione dei nodi:

Se utilizzi periodi di manutenzione o esclusioni e abiliti o modifichi una funzionalità o un'opzione che richiede la ricreazione dei nodi, la nuova configurazione viene applicata ai nodi solo quando è consentita la manutenzione dei nodi. Se preferisci non aspettare, puoi applicare manualmente le modifiche ai nodi chiamando il comando gcloud container clusters upgrade e passando il flag --cluster-version con la stessa versione GKE del pool di nodi già in esecuzione. Per questa soluzione alternativa devi utilizzare Google Cloud CLI.

Periodi di manutenzione

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

  • Orari di punta: vuoi ridurre al minimo le probabilità di inattività pianificando gli upgrade automatici durante le 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 monitorare gli upgrade 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, Google potrebbe occasionalmente 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 ripristinarle 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 deprecati o obsoleti potrebbero avvenire automaticamente al di fuori dei periodi di manutenzione.

Per informazioni su come configurare un periodo di manutenzione per un cluster nuovo o esistente, consulta la sezione Configurare un periodo di manutenzione.

Limitazioni

I periodi di manutenzione presentano le seguenti restrizioni:

Un periodo di manutenzione per cluster

Puoi configurare un solo periodo di manutenzione per cluster. La configurazione di un nuovo periodo di manutenzione sovrascrive la precedente.

Fusi orari per i periodi di manutenzione

Quando configuri e visualizzi i periodi di manutenzione, i tempi sono mostrati in modo diverso a seconda dello strumento utilizzato:

Quando configuri i periodi di manutenzione

Quando configuri i periodi di manutenzione utilizzando il flag --maintenance-window più generico, non puoi specificare un fuso orario. Il fuso orario UTC viene utilizzato quando utilizzi l'interfaccia a riga di comando gcloud o l'API e Google Cloud Console visualizza 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 fuso orario locale. Gli orari sono sempre memorizzati nel fuso orario UTC.

Quando visualizzi i periodi di manutenzione

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

  • Quando utilizzi Google Cloud Console per visualizzare informazioni sul tuo cluster, gli orari sono sempre visualizzati nel fuso orario locale.
  • Quando utilizzi l'interfaccia a riga di comando gcloud per visualizzare le informazioni sul cluster, le ore sono sempre mostrate nel fuso orario UTC.

In entrambi i casi, il valore del campo RRULE è sempre 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 la manutenzione automatica durante un periodo di tempo specifico. Ad esempio, molte attività di vendita al dettaglio hanno linee guida aziendali che vietano i cambiamenti di infrastrutture durante le festività di fine anno. Per fare un altro esempio, se un'azienda utilizza un'API di cui è previsto il ritiro, può utilizzare le esclusioni dalla manutenzione per mettere in pausa gli upgrade secondari per concedere loro il tempo di eseguire la migrazione delle applicazioni.

Per gli eventi di forte impatto noti, ti consigliamo di far corrispondere eventuali restrizioni interne alle modifiche con un'esclusione di manutenzione che inizia una settimana prima dell'evento e dura per tutta la 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 dalla manutenzione per un cluster nuovo o esistente, consulta la pagina Configurare un'esclusione di manutenzione.

Ambito della manutenzione da escludere

Non solo puoi specificare quando impedire la manutenzione automatica nel 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.
  • 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 - Impedisci le 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 di manutenzione. La tabella indica anche il tipo di upgrade che si verificano (piccoli e/o patch). Quando vengono eseguiti gli upgrade, le VM del piano di controllo e/o del pool di nodi vengono riavviate. Per i piani di controllo, i riavvii delle VM possono ridurre temporaneamente la disponibilità del server API Kubernetes, in particolare 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 dei carichi di lavoro utilizzando un budget per l'interruzione dei pod (PDB).

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

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

Più esclusioni

Puoi impostare più esclusioni su un cluster. Queste esclusioni possono avere ambiti diversi e possono avere intervalli di tempo sovrapposti. Il caso d'uso del periodo natalizio di fine anno è un esempio di esclusioni sovrapposte, in cui vengono utilizzati sia l'ambito "Nessun upgrade" sia l'ambito "Nessun upgrade secondario".

Quando le esclusioni si sovrappongono, se un'esclusione attiva (ovvero l'ora corrente è nel periodo di esclusione) blocca un upgrade, l'upgrade viene posticipato.

Utilizzando il caso d'uso 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

In seguito a queste esclusioni sovrapposte, i seguenti upgrade verranno bloccati sul cluster:

  • Patch di upgrade al pool di nodi il 25 novembre (rifiutato dall'esclusione "Nessun upgrade")
  • Upgrade di minore entità al piano di controllo il 20 dicembre (rifiutato da "Nessun upgrade secondario" ed "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 da "Nessun upgrade secondario" e "Nessun upgrade")

Nel cluster sarà consentita la seguente manutenzione:

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

Scadenza esclusione

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

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

Se il tuo cluster è in più versioni secondarie rispetto alla versione predefinita corrente dopo la scadenza dell'esclusione, GKE programmerà un upgrade secondario al mese (aggiornando sia il piano di controllo del cluster che i nodi) fino a quando il cluster non avrà raggiunto la versione predefinita per il canale di rilascio. Se vuoi ripristinare la versione predefinita del cluster prima, puoi eseguire upgrade manuali.

Limitazioni

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 impostazione predefinita, l'esclusione dalla manutenzione è l'ambito "Nessun upgrade".
  • Puoi aggiungere un massimo di tre esclusioni per manutenzione che escludono tutti gli upgrade (ovvero l'ambito "nessun upgrade"). Le esclusioni devono essere configurate per consentire almeno 48 ore di disponibilità per la manutenzione in un periodo di rotazione di 32 giorni.
  • Puoi avere un massimo di 20 esclusioni dalla manutenzione in totale.
  • Se non specifichi un ambito nell'esclusione, per impostazione predefinita l'ambito sarà impostato su "Nessun upgrade".
  • La durata di un'esclusione di manutenzione è soggetta a limitazioni basate sull'ambito di esclusione specificato:

Esempi di utilizzo

Ecco 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à di vendita al dettaglio non vuole interruzioni durante i periodi di vendita con il volume più elevato, 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 al periodo degli acquisti, l'amministratore del cluster configura 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 non si applicano altre finestre di esclusione alla scadenza dell'esclusione per la manutenzione, viene eseguito l'upgrade del cluster a una nuova versione secondaria di GKE se una di esse è stata resa disponibile tra il 30 settembre e il 6 gennaio.

Esempio: azienda che utilizza un'API beta in Kubernetes che viene 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 eseguendo 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 dei pool di nodi

In questo esempio, una società esegue un database che non risponde bene agli sgomberi e alla ripianificazione dei pod che si verificano durante un upgrade del 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 un tempo di inattività per il database, attiva l'upgrade manuale del nodo.

Passaggi successivi