Gestire l'interruzione dei nodi GKE per GPU e TPU

Questa pagina ti aiuta a comprendere, configurare e monitorare gli eventi di interruzione che possono verificarsi sui nodi Google Kubernetes Engine (GKE) che eseguono carichi di lavoro di intelligenza artificiale (AI) o machine learning (ML), tra cui:

Durante il ciclo di vita di un cluster GKE di lunga durata, si verificano interruzioni periodiche dei carichi di lavoro a causa di eventi di manutenzione automatica emessi da Google Cloud per le risorse Compute Engine alla base dell'infrastruttura GKE. Quando queste interruzioni interessano i nodi GKE che eseguono carichi di lavoro AI/ML, GKE deve riavviare sia i carichi di lavoro in esecuzione sia il nodo sottostante.

Perché le GPU e le TPU richiedono la gestione delle interruzioni

I cluster GKE gestiscono il ciclo di vita dei nodi GKE. Il provisioning di questi nodi viene eseguito sulle VM di Compute Engine. Le VM Compute Engine presentano periodicamente eventi host causati da diversi motivi, come aggiornamenti hardware o software, manutenzione e guasti hardware. Gli eventi host vengono emessi per l'infrastruttura Google Cloud sottostante e aggirano i criteri e le esclusioni di manutenzione di GKE.

Per la maggior parte delle VM Compute Engine, con alcune eccezioni, il criterio di manutenzione dell'host è impostato su migrazione live, il che significa che l'interruzione dei carichi di lavoro in esecuzione è minima o nulla. Tuttavia, alcune classi di VM non supportano la migrazione live, tra cui le VM con GPU e TPU collegate in cui vengono eseguiti i workload AI/ML. Inoltre, GKE potrebbe anche riavviare le TPU riservate e on demand utilizzando la preemption, che consente a GKE di eseguire il provisioning di TPU più grandi per motivi di defragmentazione.

Quando si verifica un evento host, GKE termina il nodo e i relativi pod. Se i pod vengono di cui vengono eseguiti il deployment come parte di un carico di lavoro più grande, come un job o un deployment, GKE li riavvia sul nodo interessato. Sta a te o ai framework che utilizzi per gestire i workload o i job reagire in modo appropriato all'interruzione. Ad esempio, puoi salvare lo stato del job di addestramento dell'AI per ridurre la perdita di dati.

Procedura di arresto controllato

Il seguente flusso di lavoro mostra come GKE esegue il ritiro graduale dei nodi dopo che Compute Engine ha emesso un'interruzione:

  1. Compute Engine emette un valore aggiornato di TERMINATE_ON_HOST_MAINTENANCE per la chiave metadati VM maintenance-event.

  2. Entro 60 secondi si verifica quanto segue:

    1. I componenti di sistema applicano la seguente nuova etichetta del nodo impostata su true per indicare che la manutenzione è in corso: cloud.google.com/active-node-maintenance

    2. GKE applica l'incompatibilità del nodo per impedire la pianificazione di nuovi pod sul nodo: cloud.google.com/impending-node-termination:NoSchedule. Ti consigliamo di modificare i carichi di lavoro per tollerare questo stato indesiderato a causa della terminazione nota che si verifica.

  3. Il componente maintenance-handler inizia a rimuovere i pod in ordine di carico di lavoro, prima i pod di lavoro e poi i pod di sistema (ad esempio kube-system).

  4. GKE invia un segnale di arresto SIGTERM per avvisare i pod di workload in esecuzione sul nodo di un arresto imminente. I pod possono utilizzare questo avviso per completare tutte le attività in corso. GKE fa del suo meglio per terminare questi Pods in modo corretto.

Le notifiche maintenance-event si verificano quando la VM Compute Engine di base di un nodo GKE subisce un evento dell'host che causa l'interruzione del nodo. In questo caso, Compute Engine aggiorna la maintenance-event chiave dei metadati. La finestra di notifica di manutenzione avanzata prima dell'interruzione del nodo è la seguente:

  • GPU: 60 minuti.
  • TPU: 5 minuti.

Successivamente, il nodo viene terminato e viene allocato un nodo sostitutivo. GKE cancella le etichette e gli elementi con tag al termine del processo. Per aumentare la finestra di interruzione per i carichi di lavoro che utilizzano GPU o TPU, completa i passaggi descritti nella sezione Configurare GKE per terminare i carichi di lavoro in modo corretto.

Gestire l'interruzione del workload in GKE

Per gestire gli eventi di interruzione di GKE e ridurre le interruzioni dei carichi di lavoro nei tuoi cluster, GKE monitora queste notifiche per te ed esegue le seguenti operazioni:

  • GKE avvisa in anticipo i carichi di lavoro di un imminente scollegamento: quando un nodo GKE deve essere interrotto per un evento di manutenzione dell'host, GKE invia un segnale SIGTERM ai pod in esecuzione sul nodo all'inizio del periodo di preavviso. Gli indicatori del sistema operativo come SIGTERM possono essere gestiti in modo nativo dalla maggior parte delle librerie standard, ad esempio Python e Go. I framework che possono acquisire SIGTERM includono MaxText, Pax e JAX con Orbax.
  • GKE termina i carichi di lavoro in modo corretto: puoi configurare GKE per terminare i carichi di lavoro in modo corretto con un periodo di tolleranza per la terminazione del pod. I pod possono reagire all'indicatore SIGTERM per completare le attività in corso ed eseguire qualsiasi azione di interruzione che definisci, ad esempio il salvataggio di uno stato di addestramento. Durante l'interruzione controllata, GKE fa del suo meglio per interrompere i pod in modo corretto ed eseguire le procedure di pulizia o l'azione di interruzione che definisci nella tua applicazione, ad esempio memorizzando i dati del carico di lavoro per ridurre la perdita di dati o salvare uno stato di addestramento.

Configura GKE per terminare i carichi di lavoro in modo corretto

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 è 30 secondi.

GKE fa del suo meglio per terminare questi pod in modo corretto 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 escono entro il termine del periodo di tolleranza, GKE invia un segnale di follow-up SIGKILL a tutti i processi ancora in esecuzione in qualsiasi contenitore del pod.

Per configurare il periodo di interruzione graduale per i carichi di lavoro, segui le istruzioni per le GPU o le TPU.

GPU

Nel manifest del pod, imposta il campo spec.terminationGracePeriodSeconds su un valore fino a un massimo di 3600 secondi (60 minuti). Ad esempio, per ottenere un tempo di notifica di 10 minuti, nel manifest del pod imposta il campo spec.terminationGracePeriodSeconds su 600 secondi, come segue:

    spec:
      terminationGracePeriodSeconds: 600

Ti consigliamo di impostare un periodo di tolleranza per la risoluzione sufficientemente lungo da consentire il completamento di eventuali attività in corso entro il periodo di tempo della notifica.

TPU

Per allocare il tempo massimo per eseguire le procedure di pulizia, imposta il campo spec.terminationGracePeriodSeconds su 300 secondi (cinque minuti) nel manifest del pod. Ad esempio:

    spec:
      terminationGracePeriodSeconds: 300

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 l'indicatore SIGTERM di arresto e avviare un processo di checkpointing. Per saperne di più, consulta Controllo automatico TPU.

Monitorare l'avanzamento di un'interruzione controllata attiva

Nei cluster GKE con il piano di controllo che esegue 1.29.1-gke.1425000 o versioni successive, GKE esegue il deployment di un componente a livello di nodo chiamato gpu-maintenance-handler. Questo componente viene eseguito su tutti i nodi GPU e TPU insieme a un componente del piano di controllo corrispondente. Questi componenti svolgono le seguenti attività:

  • Elabora gli eventi di arresto controllato.
  • Rispondere a eventi di interruzione imminente sulla VM GKE inoltrando un segnale SIGTERM ai carichi di lavoro in esecuzione di un nodo. Queste interruzioni vengono registrate come richieste di espulsione e eliminazione dei pod.

GKE aggiunge un'etichetta e un'incompatibilità ai nodi con stato di spegnimento imminente. GKE monitora le notifiche degli eventi host, come la manutenzione, utilizzando il componente di sistema maintenance-handler in esecuzione su ogni nodo GPU e TPU.

GKE registra i seguenti eventi di interruzione controllata:

  • Quando rileva un'interruzione a causa di un'imminente interruzione del nodo, ad esempio un evento di manutenzione dell'host GCE: GKE aggiunge le seguenti etichette dei nodi:cloud.google.com/active-node-maintenance impostato sutrue.
  • Quando impedisci la pianificazione di nuovi carichi di lavoro: GKE applica il taint cloud.google.com/impending-node-termination:NoSchedule.

Quando GKE termina l'interruzione in modo corretto, le etichette e le contaminazioni vengono cancellate.

Per monitorare lo stato di un'interruzione attiva causata da un'interruzione, puoi visualizzare i log gpu-maintenance-handler utilizzando la console o Google Cloud CLI.

gcloud

  1. Individua i nomi dei nodi e dei pod in cui sono in esecuzione istanze di gpu-maintenance-handler eseguendo il seguente comando:

    kubectl get pods -l name=maintenance-handler -A -o wide

    Ogni riga dell'output include Nome nodo, Nome pod e stato.

  2. Controlla i log:

    kubectl logs -n=kube-system MAINTENANCE_HANDLER_POD_NAME

    Sostituisci MAINTENANCE_HANDLER_POD_NAME con il nome dell'istanza dell'handler.

    Se viene rilevato un evento di manutenzione, il pod registra un messaggio, applica le etichette e iniziano le espulsioni.

  3. Controlla le etichette e gli elementi dannosi del nodo:

    kubectl describe node NODE_NAME

    Sostituisci NODE_NAME con il nome del nodo che vuoi visualizzare.

    L'output mostra l'elenco delle etichette e delle contaminazioni dei nodi da monitorare.

Console

  1. Vai alla pagina Esplora log nella console Google Cloud:

    Vai a Esplora log

  2. Nel campo Query, specifica la seguente query:

    resource.type="k8s_container"
resource.labels.namespace_name="kube-system"
resource.labels.container_name="maintenance-handler"
resource.labels.cluster_name="CLUSTER_NAME"

    Sostituisci CLUSTER_NAME: il nome del tuo cluster.

Passaggi successivi