Gestire l'interruzione dei nodi GKE per GPU e TPU

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 cheGoogle Cloud problemi. Questi eventi automatici possono verificarsi per rispondere a decisioni di pianificazione (eventi di preemption), aggiornamenti del control plane o dei nodi, che includono upgrade automatici dei nodi GKE (eventi di manutenzione) o correzione di problemi rilevati (eventi di terminazione).

Questa pagina ti aiuta a capire cosa significa interruzione dei nodi in GKE, a monitorare le notifiche di manutenzione e a ridurre al minimo l'impatto dell'interruzione nei nodi GKE con GPU e TPU collegate.

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 contenuti, consulta Ruoli e attività comuni degli utenti di GKE Enterprise. Google Cloud

Che cosa significa interruzione dell'infrastruttura in GKE?

I tuoi cluster GKE gestiscono il ciclo di vita dei nodi GKE. Il provisioning di questi nodi viene eseguito su VM di 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 gli upgrade automatici dei nodi, si verificano quando GKE aggiorna la versione di Kubernetes in esecuzione sul nodo.

    Per saperne di più 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 eseguire il preempt delle VM per rendere disponibile la capacità per le risorse con priorità più elevata. Gli eventi PreemptionEvent possono essere:

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

Durante il ciclo di vita di un cluster GKE a esecuzione prolungata, i nodi potrebbero subire interruzioni periodiche dei carichi di lavoro di addestramento o di pubblicazione. Quando questi disservizi interessano i nodi GKE che eseguono workload AI/ML, GKE deve riavviare sia i workload in esecuzione sia il nodo sottostante.

Perché GPU e TPU richiedono la gestione delle interruzioni

La maggior parte delle VM di Compute Engine, con alcune eccezioni, ha il criterio di manutenzione host impostato 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, incluse le VM con GPU e TPU collegate. Quando si verifica un evento host nella VM all'interno di uno slice TPU, l'intero slice viene interrotto e poi riprogrammato perché tutti gli eventi di manutenzione sono coordinati a livello di slice. Pertanto, se crei uno slice TPU con centinaia di VM, tutte riceveranno lo stesso programma di eventi di manutenzione.

Quando si verifica un evento host, GKE termina il nodo e i relativi pod. Se i pod vengono sottoposti a deployment nell'ambito di un workload più grande, come un Job o un Deployment, GKE riavvia i pod sul nodo interessato.

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

Per gestire le interruzioni sui carichi di lavoro AI/ML, puoi:

Monitorare le interruzioni dei nodi

La seguente metrica di sistema GKE riporta 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 contribuire a fornire il motivo per cui un nodo è stato interrotto.

Per ottenere una suddivisione delle interruzioni e delle relative cause nei nodi TPU nei 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 valore HW/SW Maintenance per interruption_reason. Utilizza la seguente query PromQL:

```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:

```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 relative alla manutenzione

Compute Engine invia notifiche quando i nodi e le relative VM sono pianificati per eventi host distruttivi e quando questi eventi diventano attivi. Le notifiche includono informazioni su l'ora di inizio pianificata, il tipo di evento e altri dettagli.

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

La manutenzione imminente è pianificata, ma non attiva

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

Per eseguire query su queste notifiche a livello di nodo, esegui questo 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 di ora Unix.

Per eseguire query su queste notifiche a livello di metadati del nodo, controlla le istanze per una notifica di evento di manutenzione.

Inizio della manutenzione pianificata

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 pianificata e avviata.

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 nel seguente modo:

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

GKE rimuoverà i pod e terminerà i carichi di lavoro entro il tempo massimo predefinito limitato della finestra di notifica della manutenzione.

Ridurre al minimo l'impatto delle interruzioni

Per ridurre al minimo l'impatto dell'interruzione del nodo, puoi avviare manualmente un evento di manutenzione dell'host.

Se non avvii un evento di manutenzione, Compute Engine completerà la manutenzione pianificata regolarmente.

Avvia manualmente un evento di manutenzione dell'host

Quando Compute Engine invia una notifica relativa a un evento di manutenzione pianificato, puoi avviare manualmente la manutenzione in un momento in linea con la tua pianificazione operativa, ad esempio durante i periodi di attività ridotta.

Su un nodo nel pool di nodi, imposta l'etichetta nodo cloud.google.com/perform-maintenance su true. Ad esempio:

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

GKE espelle i pod in modo controllato e termina i carichi di lavoro prima dell'inizio dell'evento di manutenzione con l'azione perform-maintenance. La durata tra l'applicazione dell'etichetta e l'inizio della manutenzione varia.

Configura 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 workload. Se non configuri un periodo di tolleranza, il valore predefinito è 30 secondi.

GKE fa del suo meglio per terminare questi pod in modo controllato ed eseguire l'azione di terminazione che definisci, ad esempio il salvataggio di uno stato di addestramento. GKE invia un segnale SIGTERM ai pod all'inizio del periodo di tolleranza. Se i pod non vengono chiusi 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 interruzione normale, imposta il periodo di tolleranza per l'interruzione (in secondi) nel campo spec.terminationGracePeriodSeconds del manifest del pod. Ad esempio, per ricevere una notifica dopo 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 per la chiusura sufficientemente lungo da consentire il completamento di eventuali attività in corso entro il periodo di tempo della notifica. Se il tuo carico di lavoro utilizza un framework ML come MaxText, Pax o JAX con Orbax, i carichi di lavoro possono acquisire il segnale di arresto SIGTERM e avviare un processo di creazione di checkpoint. Per saperne di più, consulta TPU Autocheckpoint.

Procedura di arresto controllato

Quando inizia un evento di interruzione, attivato manualmente o automaticamente dalla VM, Compute Engine segnala l'arresto imminente della macchina aggiornando la chiave di metadati maintenance-event. In entrambi i casi di arresto imminente del nodo, GKE avvierà l'arresto controllato.

Il seguente flusso di lavoro mostra come GKE esegue l'arresto normale del nodo quando è imminente un arresto del nodo:

  1. Entro 60 secondi, si verifica quanto segue:
    1. I componenti di sistema applicano il set di etichette dei nodi cloud.google.com/active-node-maintenance impostato 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 tuoi workload per tollerare questa contaminazione a causa dell'interruzione nota che si verifica.
  2. Il componente maintenance-handler inizia a eliminare i pod eliminando prima i pod del workload e poi i pod di sistema (ad esempio kube-system).
  3. GKE invia un segnale di arresto SIGTERM ai pod del workload 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'espulsione, 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. GKE cancella le etichette e i taint al termine della procedura. Per aumentare la finestra di terminazione per i tuoi 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 chiusura normale attiva

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

  • Quando la VM rileva un'interruzione dovuta a un'imminente terminazione del nodo, ad esempio l'evento di manutenzione dell'host 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 impedisce la pianificazione di nuovi workload, GKE applica il taint cloud.google.com/impending-node-termination:NoSchedule.

Passaggi successivi