Gestire l'interruzione dei nodi GKE che non vengono migrati live

Durante il ciclo di vita di un cluster GKE a lunga esecuzione, si verificano interruzioni periodiche dei carichi di lavoro a causa di interruzioni dell'infrastruttura che Google Cloud problemi. Questi eventi automatici possono verificarsi in risposta a decisioni di pianificazione (eventi di prerilascio) o aggiornamenti dei nodi, che includono upgrade automatici dei nodi GKE (eventi di manutenzione) o correzione di problemi rilevati (eventi di terminazione).

Questo documento ti aiuta a capire cosa significa interruzione dei nodi in GKE, a monitorare le notifiche di manutenzione di Compute Engine e a ridurre al minimo l'impatto delle interruzioni sui nodi GKE.

Questo documento si applica ai seguenti tipi di macchine:

Questo documento è rivolto agli amministratori e agli operatori della piattaforma che gestiscono il ciclo di vita dell'infrastruttura tecnologica sottostante. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei Google Cloud contenuti, consulta Ruoli e attività utente GKE comuni.

Che cosa si intende per interruzione dell'infrastruttura in GKE?

I cluster GKE gestiscono il ciclo di vita dei nodi GKE. Il provisioning di questi nodi viene eseguito su VM Compute Engine, che periodicamente subiscono le seguenti interruzioni:

  • Correzione dei problemi rilevati (TerminationEvent): questi eventi si verificano perché Google Cloud rileva un problema e interrompe l'infrastruttura del cluster. Gli eventi TerminationEvent non supportano l'arresto normale. Gli eventi TerminationEvent vengono attivati dai seguenti problemi:

    • La riparazione automatica si verifica quando GKE ripara un nodo dopo ripetuti controlli di integrità non riusciti.
    • HostError si verifica quando un errore hardware o software sulla macchina fisica causa l' arresto della VM.

  • Eventi di manutenzione o upgrade (MaintenanceEvent): questi eventi si verificano quando Google Cloud deve interrompere una VM per eseguire la manutenzione. Gli eventi MaintenanceEvent vengono attivati dalle seguenti attività di manutenzione:

    • Gli eventi di manutenzione si verificano quando Google Cloud esegue l'upgrade dell'host sottostante.
    • Gli aggiornamenti dei nodi, che includono node auto-upgrades, si verificano quando GKE aggiorna la configurazione del nodo, ad esempio la versione di GKE.

    Per ulteriori informazioni su come tu e GKE gestite le modifiche durante il ciclo di vita di un cluster, consulta Tipi di modifiche.

  • Risposta alle decisioni di pianificazione (PreemptionEvent): si verificano quando Google Cloud deve prerilasciare le VM per rendere disponibile la capacità per le risorse con priorità più alta. Gli eventi PreemptionEvent possono essere uno dei seguenti:

    • Eliminazione: si verifica quando preemptible o spot l'infrastruttura viene prerilasciata per ospitare una VM con priorità più alta.
    • Defragmentazione: si verifica quando GKE prerilascia una slice TPU più piccola per ospitare una slice TPU più grande. La deframmentazione si verifica solo sulle slice TPU.

Durante il ciclo di vita di un cluster GKE a lunga esecuzione, i nodi potrebbero subire interruzioni periodiche dei carichi di lavoro. Quando queste interruzioni interessano i nodi GKE che eseguono i carichi di lavoro, GKE deve riavviare sia i carichi di lavoro in esecuzione sia il nodo sottostante.

Perché i nodi senza migrazione live richiedono la gestione delle interruzioni

La maggior parte delle VM Compute Engine, con alcune eccezioni, ha la policy di manutenzione dell'host impostata su migrazione live, il che significa che i carichi di lavoro in esecuzione in genere subiscono interruzioni minime o nulle. Tuttavia, alcune classi di VM non supportano la migrazione live, tra cui le VM con GPU e TPU collegate, i tipi di macchine Z3 con più di 18 TiB di SSD, i tipi di macchine H4D e il c4a-highmem-96-metal (anteprima) tipo di macchina. Ad esempio, quando si verifica un evento host nella VM all'interno di una slice TPU, l'intera slice viene interrotta e poi ripianificata perché tutti gli eventi di manutenzione vengono coordinati a livello di slice. Pertanto, se crei una slice TPU con centinaia di VM, tutte queste VM riceveranno la stessa pianificazione degli eventi di manutenzione.

Quando si verifica un evento host, GKE termina il nodo e i relativi pod. Se i pod vengono sottoposti a deployment come parte di un carico di lavoro più grande, ad esempio un job o deployment, GKE riavvia i pod sul nodo interessato.

Spetta a te o ai framework che utilizzi gestire la configurazione del carico di lavoro per reagire in modo appropriato agli eventi di manutenzione. Ad esempio, puoi salvare lo stato del job di addestramento AI per ridurre la perdita di dati.

Per gestire le interruzioni dei carichi di lavoro, puoi:

Monitorare le interruzioni dei nodi

La seguente metrica di sistema GKE segnala il conteggio delle interruzioni per un nodo GKE dall' ultimo campione (la metrica viene campionata ogni 60 secondi):

  • kubernetes.io/node/interruption_count

I campi interruption_type (ad esempio TerminationEvent, MaintenanceEvent o PreemptionEvent) e interruption_reason (ad esempio HostError, Eviction o AutoRepair) possono aiutarti a capire il motivo per cui un nodo è stato interrotto.

Per ottenere una suddivisione delle interruzioni e delle relative cause nei nodi TPU dei cluster del tuo progetto, utilizza la seguente query PromQL:

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node"}[${__interval}]))

Per visualizzare solo gli eventi di manutenzione dell'host, aggiorna la query per filtrare il HW/SW Maintenance valore per il interruption_reason. Utilizza la seguente query PromQL:

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node", interruption_reason="HW/SW Maintenance"}[${__interval}]))

Per visualizzare il conteggio delle interruzioni aggregato per pool di nodi, utilizza la seguente query PromQL:

  sum by (node_pool_name,interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_pool_interruption_count{monitored_resource="k8s_node_pool", interruption_reason="HW/SW Maintenance", node_pool_name=NODE_POOL_NAME }[${__interval}]))

Monitorare le notifiche di manutenzione

Compute Engine issues notifiche quando i nodi e le relative VM sottostanti sono pianificati per eventi host che causano interruzioni , e quando questi eventi diventano attivi. Le notifiche includono informazioni sull'ora di inizio pianificata, sul tipo di evento e altri dettagli.

In GKE versione 1.31.1-gke.2008000 e successive, puoi monitorare gli eventi di manutenzione imminenti, inclusi quelli descritti in questa sezione.

Puoi monitorare gli eventi imminenti con i seguenti tipi di macchine e versioni di GKE:

  • Per i tipi di macchine con GPU o TPU collegate, 1.31.1-gke.2008000 o versioni successive
  • Per i tipi di macchine Z3 con più di 18 TiB di SSD, 1.32.4-gke.1376000 o versioni successive
  • Per i tipi di macchine H4D, 1.32.6-gke.1060000 o versioni successive
  • Per c4a-highmem-96-metal (anteprima), 1.35.0-gke.2232000 o versioni successive

La manutenzione imminente è pianificata, ma non è attiva

Prima che una VM abbia un evento di manutenzione pianificato, Compute Engine invia notifiche a tutte le VM. Queste notifiche segnalano l'inizio del periodo di manutenzione di Compute Engine. Quando una manutenzione imminente viene pianificata dalla VM, ma non è attiva, GKE aggiunge scheduled-maintenance-time all'etichetta del nodo.

Per eseguire una query su queste notifiche a livello di nodo, esegui il seguente comando:

kubectl get nodes -l cloud.google.com/scheduled-maintenance-time \
    -L cloud.google.com/scheduled-maintenance-time

L'output è simile al seguente:

NAME                         STATUS    SCHEDULED-MAINTENANCE-TIME
<gke-accelerator-node-name>  Ready     1733083200
<gke-accelerator-node-name>  Ready     1733083200
[...]

La colonna SCHEDULED-MAINTENANCE-TIME rappresenta i secondi, visualizzati nel formato ora epoca di Unix.

Per eseguire una query su queste notifiche a livello di metadati del nodo, verifica la presenza di una notifica di evento di manutenzione nelle istanze.

Per le famiglie di macchine ottimizzate per l'acceleratore che supportano la manutenzione avanzata, puoi accedere all'endpoint upcoming-maintenance che fornisce informazioni sugli eventi di manutenzione pianificati e avviati.

Ridurre al minimo l'impatto delle interruzioni

Compute Engine invia notifiche relative agli eventi di manutenzione imminenti e pianifica un periodo di manutenzione. Tra l'ora della notifica e l'ora di inizio del periodo di manutenzione, puoi decidere di:

  • Avviare manualmente un evento di manutenzione dell'host.
  • Consentire a Compute Engine di avviare l'evento di manutenzione in base alla pianificazione.

GKE supporta la terminazione controllata dei pod durante gli eventi di manutenzione dell'host. Nelle versioni recenti di GKE, questa funzionalità è disattivata per impostazione predefinita. Per utilizzare questa funzionalità, devi abilitare manualmente la gestione delle interruzioni. Per ulteriori informazioni, consulta Abilitare la gestione delle interruzioni.

Avviare manualmente un evento di manutenzione dell'host

Puoi avviare manualmente la manutenzione ripianificabile quando si adatta alla tua pianificazione, ad esempio durante i periodi di bassa attività. Per farlo, applica l'etichetta cloud.google.com/perform-maintenance=true se sono soddisfatte le seguenti condizioni:

  • Compute Engine invia una notifica relativa a un evento di manutenzione pianificato.
  • L'evento di manutenzione di Compute Engine sottostante è ripianificabile. Per verificare se l'evento è ripianificabile, cerca la notifica can_reschedule=TRUE nei metadati dell'evento. Se l'evento non è ripianificabile, l'impostazione dell'etichetta cloud.google.com/perform-maintenance=true non ha alcun effetto e la manutenzione viene eseguita all'ora pianificata originariamente.

Se le condizioni precedenti sono soddisfatte, imposta l'etichetta del nodo cloud.google.com/perform-maintenance su true in un nodo del pool di nodi. Ad esempio:

kubectl label nodes <node-name> cloud.google.com/perform-maintenance=true

Se avvii un evento di manutenzione, GKE esegue le seguenti operazioni:

  1. Applica un'incompatibilità al nodo.
  2. Esegue l'eliminazione controllata dei pod.
  3. Richiede a Compute Engine di avviare immediatamente l'evento di manutenzione, anziché attendere l'ora pianificata.

Compute Engine avvia l'evento di manutenzione in base alla pianificazione

Se non avvii un evento di manutenzione dell'host, Compute Engine avvia l'evento di manutenzione pianificato autonomamente. A partire dalla versione 1.33 di GKE, il nodo non è incompatibile e i pod non vengono eliminati all'inizio del periodo di manutenzione.

Quando inizia l'evento di manutenzione, un nodo potrebbe essere arrestato una o più volte con un breve periodo di notifica prima della sua terminazione imminente. In questi casi, GKE fa del suo meglio per terminare i carichi di lavoro ed eliminare i pod in modo controllato.

Inizio della manutenzione pianificata

Quando inizia la manutenzione pianificata, Compute Engine aggiorna i metadati nella directory http://metadata.google.internal/computeMetadata/v1/instance/attributes/. Compute Engine aggiorna le etichette dei metadati come segue:

  • Imposta maintenance-event su TERMINATE_ON_HOST_MAINTENANCE.
  • In upcoming-maintenance, imposta maintenance_status su ONGOING.

GKE rileva e gestisce l'evento di manutenzione dell'host pianificato, sia che tu lo attivi manualmente sia che lasci che GKE proceda automaticamente.

Abilitare la gestione delle interruzioni

apiVersion: v1
kind: ConfigMap
metadata:
  name: gke-disruption-handling
  namespace: kube-system
data:
  maintenance-experience.yaml: |
    gracefulTermination: true

Per abilitare la gestione delle interruzioni, crea un file denominato maintenance-config.yaml con questo ConfigMap. Applica il ConfigMap al cluster con il seguente comando: 

kubectl apply -f my-configmap.yaml

Configurare GKE per terminare i carichi di lavoro in modo controllato

In questa sezione configurerai GKE per gestire il ciclo di vita dell'applicazione e ridurre al minimo l'interruzione del carico di lavoro. Se non configuri un periodo di tolleranza, il valore predefinito è di 30 secondi.

GKE fa del suo meglio per terminare questi pod in modo controllato ed eseguire l'azione di terminazione che definisci, ad esempio salvando uno stato di addestramento. GKE invia un segnale SIGTERM ai pod all'inizio del periodo di tolleranza. Se i pod non escono entro la fine del periodo di tolleranza, GKE invia un segnale SIGKILL di follow-up a tutti i processi ancora in esecuzione in qualsiasi container del pod.

Per configurare il periodo di terminazione controllata, imposta il periodo di tolleranza della terminazione (in secondi) nel campo spec.terminationGracePeriodSeconds del manifest del pod. Ad esempio, per ottenere un periodo di notifica di 10 minuti, imposta il campo spec.terminationGracePeriodSeconds nel manifest del pod su 600 secondi, come segue:

    spec:
      terminationGracePeriodSeconds: 600

Ti consigliamo di impostare un periodo di tolleranza della terminazione sufficientemente lungo da consentire il completamento di tutte le attività in corso entro il periodo di notifica. Se il carico di lavoro utilizza un framework ML come MaxText, Pax o JAX con Orbax, i carichi di lavoro possono acquisire il segnale SIGTERM di arresto e avviare un processo di checkpoint. Per saperne di più, consulta Autocheckpoint TPU.

Processo di terminazione controllata

Quando inizia un evento di manutenzione avviato manualmente, Compute Engine segnala l'arresto imminente della macchina aggiornando la chiave dei metadati maintenance-event. GKE avvia la terminazione controllata.

Il seguente workflow mostra come GKE esegue la terminazione controllata dei nodi quando è imminente l'arresto di un nodo:

  1. Entro 60 secondi si verifica quanto segue:
    1. I componenti di sistema applicano l'etichetta del nodo cloud.google.com/active-node-maintenance impostata su ONGOING per indicare che i carichi di lavoro vengono arrestati.
    2. GKE applica l'incompatibilità del nodo per impedire la pianificazione di nuovi pod sul nodo. L'incompatibilità ha la chiave cloud.google.com/impending-node-termination:NoSchedule. Ti consigliamo di non modificare i carichi di lavoro per tollerare questa incompatibilità a causa della terminazione nota che si verifica.
  2. Il componente maintenance-handler inizia a eliminare i pod eliminando prima i pod del carico di lavoro e poi i pod di sistema (ad esempio, kube-system).
  3. GKE invia un segnale di arresto SIGTERM ai pod del carico di lavoro in esecuzione sul nodo per avvisarli di un arresto imminente. I pod possono utilizzare questo avviso per completare le attività in corso. GKE fa del suo meglio per terminare questi pod in modo controllato.
  4. Al termine dell'eliminazione, GKE aggiorna il valore dell'etichetta cloud.google.com/active-node-maintenance a terminating per indicare che il nodo è pronto per la terminazione.

Successivamente, si verifica la terminazione del nodo e viene allocato un nodo di sostituzione. Al termine della procedura, GKE cancella le etichette e le incompatibilità. Per aumentare il periodo di terminazione dei carichi di lavoro che utilizzano GPU o TPU, completa i passaggi descritti nella sezione Avviare manualmente un evento di manutenzione dell'host.

Monitorare l'avanzamento di una terminazione controllata attiva

Puoi filtrare i log GKE in base ai seguenti eventi di terminazione controllata:

  • Quando la VM rileva un'interruzione dovuta a una terminazione imminente del nodo, ad esempio un evento di manutenzione dell'host di Compute Engine, GKE imposta cloud.google.com/active-node-maintenance su ONGOING quando i carichi di lavoro vengono arrestati e su terminating quando i carichi di lavoro sono terminati e il nodo è pronto per la terminazione.
  • Quando limita la pianificazione di nuovi carichi di lavoro, GKE applica l'incompatibilità cloud.google.com/impending-node-termination:NoSchedule.

Ridurre al minimo l'interruzione dei carichi di lavoro in esecuzione con la manutenzione opportunistica

Puoi ridurre al minimo l'interruzione dei carichi di lavoro in esecuzione attivando automaticamente la manutenzione quando GKE rileva che i nodi con GPU o TPU sono inattivi. Per abilitare questa funzionalità, crea un nuovo pool di nodi. Non puoi abilitare la manutenzione opportunistica su un pool di nodi esistente.

Creare un nuovo pool di nodi con la manutenzione opportunistica

Il seguente comando mostra come creare un pool di nodi con la manutenzione opportunistica abilitata:

gcloud beta container node-pools create NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --accelerator ACCELERATOR_ARG \
    --machine-type MACHINE_TYPE \
    --num-nodes NODE_COUNT \
    --zone ZONE \
    --project=PROJECT_ID \
    --opportunistic-maintenance=node-idle-time=NODE_IDLE_TIME,min-nodes=MIN_NODES,window=WINDOW

Sostituisci i seguenti valori:

  • NODE_POOL_NAME: il nome del pool di nodi GKE.
  • CLUSTER_NAME : il nome del cluster GKE.
  • NODE_IDLE_TIME : il periodo di tempo in cui un nodo può rimanere inattivo (ovvero non sono in esecuzione carichi di lavoro che consumano acceleratori) prima che venga attivata la manutenzione. Il valore rappresenta la durata in secondi, con un massimo di nove cifre frazionarie, e termina con il s carattere, ad esempio: 80000s.
  • MIN_NODES : il numero minimo di nodi che devono essere disponibili in un pool di nodi. Questa opzione blocca la manutenzione se il numero di nodi in esecuzione scende al di sotto di questo valore, ad esempio: 10.
  • WINDOW : il periodo di tempo, in secondi, in cui può essere eseguita la manutenzione opportunistica. Il valore termina con il carattere s. Ad esempio, un valore di 14 giorni, ovvero 1209600s, implica che la manutenzione opportunistica può essere eseguita solo nelle due settimane precedenti la data di manutenzione pianificata. Un valore di 28 giorni, ovvero 2419200s, consente di eseguire la manutenzione opportunistica in qualsiasi momento durante il periodo di manutenzione pianificato. Questo periodo per la manutenzione dell'host di Compute Engine è distinto dai periodi di manutenzione di GKE, che determinano quando può essere eseguita la manutenzione del cluster GKE e vengono configurati separatamente.

Configurazione di esempio per la manutenzione opportunistica

Considera l'esempio seguente. Hai un pool di nodi con quattro nodi e la configurazione della manutenzione opportunistica è impostata su --opportunistic-maintenance=node-idle-time=600s,window=2419200s,min-nodes=3. In questo scenario, si verifica quanto segue:

  • node1 ha un carico di lavoro GPU in esecuzione. Questo nodo non è inattivo, quindi viene ignorato.
  • node2 è inattivo da 60 secondi. Questo nodo non è inattivo da tempo sufficiente, quindi viene ignorato.
  • node3 è inattivo da 600 secondi. Questo nodo soddisfa il requisito di inattività.
  • node4 è inattivo da 600 secondi. Questo nodo soddisfa il requisito di inattività.

Sia node3 che node4 soddisfano il requisito di inattività. Tuttavia, solo uno di questi nodi attiverà la manutenzione opportunistica perché il valore dell'opzione min-nodes è impostato su 3.

Controllare la configurazione e lo stato dei nodi con la manutenzione opportunistica

Controlla se la manutenzione opportunistica è configurata per un nodo eseguendo il seguente comando:

kubectl describe node NODE_NAME | grep node.gke.io/opportunistic-config

Sostituisci NODE_NAME con il nome del nodo che vuoi controllare.

Controlla se un nodo configurato con la manutenzione opportunistica è attualmente in manutenzione:

kubectl describe node NODE_NAME | grep node.gke.io/maintenance-state

Se il nodo viene attivato dalla manutenzione opportunistica, l'annotazione maintenance-state mostra opportunistic-triggered come true.

Limitazioni

Tieni presente le seguenti limitazioni della manutenzione opportunistica:

  • Questa funzionalità può essere utilizzata solo con i node pool GPU e TPU.
  • La manutenzione opportunistica non è compatibile con il gestore della scalabilità automatica dei cluster perché questo gestore esegue già lo scale down dei nodi inattivi.
  • Per i node pool TPU multi-host, il valore dell'impostazione min-nodes-per-pool deve essere 0 perché questi node pool sono atomici.
  • La versione minima supportata di GKE è la 1.33.3-gke.1118000.
  • È supportata solo la manutenzione pianificata che include la can_reschedule=TRUE notifica.
  • Per disabilitare questa funzionalità, devi ricreare il pool di nodi senza i rispettivi flag. In alternativa, puoi disabilitare manualmente la funzionalità su nodi specifici con cloud.google.com/opportunistic-disable=true.
  • In rari casi, il completamento della manutenzione su un nodo potrebbe richiedere più tempo. I clienti che utilizzano questa funzionalità potrebbero avere a disposizione un numero inferiore di nodi, fino al valore dell'impostazione min-nodes-per-pool, per un periodo di tempo.

Passaggi successivi