Scopri come eseguire la manutenzione dell'host su GKE

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 causano problemi. Questi eventi automatici possono verificarsi per rispondere alle decisioni di pianificazione (eventi di prerilascio) o agli aggiornamenti dei nodi, che includono gli upgrade automatici dei nodi GKE (eventi di manutenzione) o la correzione dei problemi rilevati (eventi di terminazione).

Questo documento ti aiuta a capire cosa significa l'interruzione dei nodi in GKE e a ridurre al minimo l'impatto delle interruzioni sui nodi GKE.

Per informazioni dettagliate sul monitoraggio delle notifiche e degli eventi di manutenzione, consulta Monitorare gli eventi di manutenzione.

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 tecnica 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à comuni degli utenti GKE.

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

I cluster GKE gestiscono il ciclo di vita dei nodi GKE. Questi nodi vengono sottoposti al provisioning sulle 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 controllato. 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. Questi eventi vengono attivati dalle seguenti attività di manutenzione:

    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): questi eventi 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 l'infrastruttura preemptible o spot 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 che non supportano la migrazione live richiedono la gestione delle interruzioni

Per la maggior parte delle VM Compute Engine, con alcune eccezioni, la loro 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 tipo di macchina c4a-highmem-96-metal . 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 al deployment come parte di un carico di lavoro più grande, come un job o deployment, GKE riavvia i pod sul nodo interessato.

Gestire gli eventi di manutenzione

Il resto di questo documento descrive come gestire le interruzioni MaintenanceEvent.

La gestione dell'interruzione dei nodi durante gli eventi di manutenzione dell'host segue un flusso di lavoro in tre fasi:

  1. Rileva la manutenzione dell'host pianificata: utilizza le etichette dei nodi GKE, gli endpoint dei metadati o i log.
  2. Agisci in base alla manutenzione rilevata: se è pianificata la manutenzione, valuta la tua infrastruttura e i carichi di lavoro e determina l'azione migliore per il tuo caso d'uso. Intraprendi l'azione appropriata, ad esempio lascia che il sistema gestisca automaticamente l'evento di manutenzione, avvia manualmente la manutenzione dell'host o orchestra le strategie di manutenzione.
  3. Verifica il risultato dell'evento di manutenzione: verifica che l'evento di manutenzione sia stato avviato correttamente, sia quando Compute Engine avvia l'evento di manutenzione in base alla pianificazione sia quando lo avvii manualmente.

Rilevare la manutenzione dell'host pianificata

Per monitorare e rilevare gli eventi di manutenzione imminenti, devi visualizzare le notifiche di GKE e Compute Engine.

Per informazioni dettagliate sul monitoraggio delle notifiche e degli eventi di manutenzione, consulta Monitorare gli eventi di manutenzione.

Agire in base alla manutenzione rilevata

Se visualizzi una notifica di manutenzione pianificata imminente per uno o più nodi del cluster, utilizza il seguente albero decisionale per determinare il modo migliore per gestire l'interruzione:

  1. Manutenzione automatica: lascia che Compute Engine avvii l'evento di manutenzione in base alla pianificazione. Le VM eseguiranno automaticamente la migrazione live in background con interruzioni minime o nulle.

    1. Se la VM host supporta la migrazione live, ti consigliamo di lasciare che l'evento di manutenzione si verifichi automaticamente.
    2. Se i carichi di lavoro vengono eseguiti su nodi flessibili inattivi, puoi ottimizzare la tempistica della manutenzione automaticamente configurando la manutenzione opportunistica. In questo modo, gli aggiornamenti necessari vengono attivati solo durante i periodi di inattività naturale.

  2. Avvia manualmente un evento di manutenzione dell'host: valuta le seguenti domande per determinare il modo migliore per gestire manualmente l'interruzione:

    1. I nodi interessati sono VM singole o isolate?

      • Sì (sto eseguendo una VM singola o isolata):
        • Se non hai bisogno di controlli di tempistica precisi, lascia che Compute Engine avvii l'evento di manutenzione in base alla pianificazione (impostazione predefinita automatica).
        • Se devi evitare prerilasci imprevisti, avvia manualmente l'evento di manutenzione dell'host sul singolo nodo in un momento opportuno, ad esempio, durante le finestre di traffico ridotto.
      • No (sto eseguendo un pool di nodi di acceleratori): scegli una delle opzioni nel passaggio successivo.

    2. Scegli una delle seguenti opzioni in base al tuo caso d'uso:

      • Se il pool di acceleratori esegue attività di addestramento AI/ML accoppiate: implementa la strategia parallela. Salva lo stato dell'addestramento in un checkpoint, arresta normalmente il pool ed esegui contemporaneamente gli aggiornamenti dell'host e gli upgrade del cluster GKE prima di riavviare.

      • Se il pool di acceleratori esegue endpoint di serving AI/ML ad alta disponibilità o inferenza: implementa la strategia di implementazione graduale. Coordina la manutenzione dell'host pianificata e gli upgrade di versione in batch graduali all'interno dei limiti della zona o del pool, utilizzando le repliche attive per proteggere gli SLA.

Avviare manualmente un evento di manutenzione dell'host su VM singole o isolate

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 originariamente pianificata.

Se le condizioni precedenti sono soddisfatte, imposta l'etichetta del nodo cloud.google.com/perform-maintenance su true su 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 taint al nodo.
  2. Elimina i pod in modo controllato.
  3. Richiede a Compute Engine di avviare immediatamente l'evento di manutenzione, anziché attendere l'ora pianificata.

Verificare il risultato dell'evento di manutenzione

Dopo aver rilevato un evento di manutenzione imminente e aver deciso la linea di condotta migliore, puoi verificare il risultato dell'evento di manutenzione.

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

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

Avvio 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.

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 aiutarti a capire il motivo dell'interruzione di un nodo.

Per visualizzare una suddivisione delle interruzioni e delle relative cause nei nodi TPU dei cluster del 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 in modo da filtrare il valore HW/SW Maintenance per 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}]))

Configurazioni avanzate per ridurre al minimo le interruzioni

Questa sezione descrive strumenti aggiuntivi per configurare il cluster e i carichi di lavoro in modo da ridurre al minimo le interruzioni.

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 si impegna al massimo per terminare questi pod in modo controllato ed eseguire l'azione di terminazione definita, ad esempio salvare 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 tempo 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 scoprire di più, consulta Checkpoint automatico 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 flusso di lavoro 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 il taint del nodo per impedire la pianificazione di nuovi pod sul nodo. Il taint ha la chiave cloud.google.com/impending-node-termination:NoSchedule. Ti consigliamo di non modificare i carichi di lavoro per tollerare questo taint a causa della terminata zione nota che si verifica.
  2. Il componente maintenance-handler inizia a eliminare i pod, 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 si impegna al massimo 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 i taint. Per aumentare il periodo di terminazione dei carichi di lavoro che utilizzano GPU o TPU, completa i passaggi nella sezione Avviare manualmente un evento di manutenzione dell'host.

Verificare 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 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 il taint 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 carattere s, 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 : la finestra 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 Compute Engine è diverso dai periodi di manutenzione di GKE, che determinano quando può essere eseguita la manutenzione del cluster GKE e vengono configurati separatamente.

Esempio di configurazione 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 è in fase di 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 la scalabilità automatica dei cluster perché il gestore della scalabilità automatica dei cluster 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 è supportata.
  • 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