Gestire i cluster GKE ottimizzati per l'AI

Questa pagina mostra come gestire i cluster Google Kubernetes Engine (GKE) ottimizzati per l'AI delle macchine A4X Max, A4X, A4, A3 Ultra, A3 Mega e A3 High (8 GPU), inclusi i seguenti eventi comuni pertinenti ai cluster GKE e ai carichi di lavoro AI:

• Manutenzione dell'host
• Upgrade dei cluster
• Segnalazione di host difettosi

Gestisci la manutenzione dell'host per i workload AI

I nodi GKE vengono eseguiti su istanze Compute Engine che periodicamente subiscono eventi host che possono interrompere i carichi di lavoro AI. Poiché gli eventi host si verificano nell'infrastruttura Google Cloud sottostante, ignorano i periodi di manutenzione e le esclusioni di GKE. Sebbene la maggior parte delle istanze di calcolo abbia la policy di manutenzione dell'host impostata su migrazione live, che riduce al minimo l'interruzione dei carichi di lavoro, le GPU e le TPU non supportano la migrazione live. Quando questi eventi host influiscono sui nodi GKE che eseguono carichi di lavoro AI, GKE deve terminare il nodo e i pod in esecuzione sul nodo. Se i pod vengono sottoposti a deployment nell'ambito di un workload più grande, come un job o un deployment, GKE tenta di riavviare i pod sul nodo interessato.

Per saperne di più sulla gestione della manutenzione dell'host delle istanze di calcolo sottostanti, consulta Gestire l'interruzione dei nodi GKE per GPU e TPU.

Monitora gli eventi di manutenzione dell'host

Per i cluster che eseguono GKE versione 1.31.1-gke.2008000 o successive, puoi visualizzare l'ora di inizio pianificata dell'evento di manutenzione dell'host nel seguente modo. L'ora di inizio è rappresentata dalle etichette dei nodi Kubernetes sul nodo GKE corrispondente per tutte le GPU e le TPU.

Per maggiori dettagli, vedi Monitorare le notifiche di manutenzione.

Con queste etichette dei nodi, puoi:

• Avvia manualmente un evento di manutenzione dell'host
• Utilizzare le informazioni sugli eventi di manutenzione dell'host durante la pianificazione dei workload

Avvia manualmente un evento di manutenzione dell'host

Dopo che 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. Ad esempio, puoi scegliere di eseguire la manutenzione durante i periodi di attività ridotta.

Se non avvii manualmente un evento di manutenzione dell'host, Compute Engine completerà automaticamente la manutenzione pianificata regolarmente.

Segui le istruzioni per avviare manualmente un evento di manutenzione dell'host. Continua a leggere questa sezione per scoprire quanto segue:

• Configura GKE per terminare i carichi di lavoro in modo controllato
• Procedura di arresto controllato
• Monitorare l'avanzamento di un arresto controllato attivo

Utilizzare le informazioni sulla manutenzione dell'host durante la pianificazione dei carichi di lavoro

Puoi utilizzare le informazioni sulla manutenzione visualizzate tramite le etichette dei nodi GKE insieme all'affinità e all'anti-affinità dei nodi per ridurre al minimo le interruzioni dei tuoi carichi di lavoro.

Consulta le sezioni seguenti per esempi di utilizzo di queste informazioni.

Pianifica i pod sui nodi che non hanno eventi di manutenzione pianificata futuri

Puoi indicare a GKE di pianificare i pod solo sui nodi che non hanno eventi di manutenzione pianificati futuri, ad esempio con il seguente snippet:

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/scheduled-maintenance-time
            operator: DoesNotExist

Pianifica i pod sui nodi per cui è stata pianificata la manutenzione dopo una determinata data

Puoi indicare a GKE di pianificare i pod solo sui nodi per i quali è stata pianificata la manutenzione dopo una determinata data fornendo l'ora dell'epoca Unix:

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/scheduled-maintenance-time
            operator: Gt
            values:
            - 1733296000

Gestisci gli upgrade dei cluster GKE per i carichi di lavoro di AI

I carichi di lavoro AI sono sensibili alle interruzioni.

Durante il ciclo di vita di un cluster GKE, i carichi di lavoro di AI devono essere preparati per interruzioni sia delle istanze di calcolo sottostanti sia del cluster GKE stesso:

• Manutenzione host: per gestire la manutenzione host delle istanze di calcolo sottostanti, consulta Gestire l'interruzione dei nodi GKE per GPU e TPU. Questo aspetto è descritto anche nelle sezioni precedenti.
• Upgrade dei cluster: per gestire le interruzioni dovute agli upgrade dei cluster, puoi utilizzare i seguenti strumenti:
  • Periodi di manutenzione: pianifica quando GKE può eseguire gli upgrade del cluster e altri tipi di operazioni del cluster.
  • Esclusioni della manutenzione: Impedisci gli upgrade del cluster e altri tipi di operazioni del cluster durante un periodo di tempo specifico.

Ti consigliamo di mantenere il cluster registrato in un canale di rilascio. Per impostazione predefinita, i cluster GKE sono registrati nel canale di rilascio regolare. Per scoprire di più sui vantaggi dei canali di rilascio, consulta il Confronto tra cluster registrati e non registrati in un canale di rilascio.

Con i canali di rilascio, hai accesso a più funzionalità, inclusi ambiti di esclusione della manutenzione aggiuntivi. Per i workload di AI, ti consigliamo l'ambito "Nessun upgrade secondario o dei nodi".

Segnalare host difettosi tramite GKE

Questa sezione descrive come, tramite GKE, puoi segnalare un host difettoso con istanze di calcolo di cui è stato eseguito il provisioning utilizzando il modello di provisioning vincolato alla prenotazione. Se vuoi segnalare un host difettoso per un nodo di cui è stato eseguito il provisioning utilizzando il modello di provisioning con avvio flessibile (anteprima), contatta il tuo team dell'account.

Attenzione: la segnalazione di un host difettoso è un'azione distruttiva che arresta la VM. Prima di segnalare un host, esamina a fondo il tuo ambiente utilizzando strumenti come lo scanner di integrità del cluster (CHS) per identificare la causa principale del problema. Segnala l'organizzatore come responsabile solo se non hai alternative per risolvere il problema.

Un host è una singola macchina server fisica nel data center che esegue un'istanza di computing che ospita il nodo GKE. Puoi segnalare gli host difettosi applicando un'etichetta del nodo fault-behavior al nodo GKE interessato. Dopo aver applicato l'etichetta del nodo a un nodo GKE specifico, GKE esegue i seguenti passaggi:

1. Rimuove in modo controllato i carichi di lavoro dal nodo.
2. Impedisce la pianificazione di nuovi pod sul nodo.
3. Chiama l'API sull'istanza di calcolo per contrassegnare l'host come difettoso.
4. Attende il ripristino dell'istanza di calcolo su una macchina host integra. Per le prenotazioni che utilizzano la modalità operativa di prenotazione tutta la capacità, Compute Engine ripristina l'istanza di calcolo sullo stesso nodo al termine dell'operazione di riparazione.
5. Rimuove il taint e l'etichetta fault-behavior dal nodo.

Dopodiché, il nodo sarà di nuovo pronto a gestire i workload.

Requisiti

Per segnalare un host difettoso, il nodo GKE deve soddisfare i seguenti requisiti:

• Devi eseguire la patch GKE versione 1.32.3-gke.1057001 o successiva.
• Devi utilizzare uno dei seguenti tipi di macchine GPU: A4X Max, A4X, A4, A3 Ultra, A3 Mega e A3 High (8 GPU).
• Devi eseguire i nodi GKE su un'istanza di calcolo associata a una prenotazione.
• Il nodo GKE deve essere nello stato RUNNING. Se provi a segnalare un host difettoso dopo aver eliminato l'istanza di calcolo, viene restituito un messaggio di errore e la macchina host non viene contrassegnata come difettosa.
• Potresti essere soggetto a limiti di frequenza sul numero di chiamate a questa API per prenotazione al mese in base a una valutazione dell'integrità dei tuoi blocchi. I limiti di frequenza non si applicano se la prenotazione utilizza la modalità operativa di prenotazione di tutta la capacità.

Segnala un host difettoso

Nota: i dati dell'SSD locale verranno eliminati in caso di chiamata riuscita dell'API quando l'istanza di Compute si sposta sugli host. Ti consigliamo di eseguire il backup dei dati dell'SSD locale prima di segnalare un nodo difettoso tramite GKE.

Per segnalare un host difettoso:

1. Utilizza gli strumenti di osservabilità GKE, i tuoi strumenti di monitoraggio o i log per identificare i nodi GKE che riscontrano problemi di prestazioni. Salva NODE_NAME.

2. Segnala il nodo come difettoso:

   Importante :dopo aver segnalato un host come difettoso, non inviare ulteriori richieste finché l'operazione non viene completata. GKE rifiuta le richieste aggiuntive mentre l'operazione è in corso.

     kubectl label nodes NODE_NAME cloud.google.com/fault-behavior=FAULT_REASON
   

   Sostituisci quanto segue:

   • NODE_NAME: il nome del nodo difettoso.
   • FAULT_REASON: il motivo del guasto appropriato utilizzando uno o più dei seguenti valori:
     • PERFORMANCE: utilizza questo valore se le GPU di un'istanza di calcolo hanno prestazioni inferiori rispetto ad altre GPU del cluster e non visualizzi errori XID nei log e non vengono rilevati altri pattern di errore soliti, come il danneggiamento silenzioso dei dati.
     • SDC: utilizza questo valore per il danneggiamento silenzioso dei dati, se noti un danneggiamento dei dati ma nessun arresto anomalo del sistema. Questa corruzione dei dati può essere causata da difetti della CPU, bug software come use-after-free o memory stomping, problemi del kernel o altri difetti. Il più delle volte, questo termine viene utilizzato per indicare difetti indotti dall'hardware.
     • XID: utilizza questo valore se hai identificato un errore GPU non recuperabile con un XID per un'istanza di computing.
     • unspecified: utilizza questo valore se non sai quale comportamento causa il problema con l'istanza di computing. Questo è il valore predefinito. Tuttavia, ti consigliamo di specificare uno degli altri valori, se applicabile.

Dopo aver segnalato un host difettoso per un nodo, l'ora in cui il nodo viene riavviato varia in base alla modalità operativa di prenotazione specificata nella prenotazione utilizzata dal nodo. Per verificare la modalità operativa di una prenotazione, visualizza il campo reservationOperationalMode nella prenotazione. La tabella seguente riepiloga la procedura di gestione dell'host difettoso per le due modalità operative di prenotazione disponibili: modalità tutta la capacità e modalità gestita.

	Modalità Tutta la capacità (ALL_CAPACITY)	Modalità gestita (HIGHLY_AVAILABLE_CAPACITY)
Tipi di macchine supportati	A4X Max e A4X	A4, A3 Ultra, A3 Mega e A3 High
Limitazione di frequenza delle richieste API per i report sugli host difettosi	Non si applicano limiti di frequenza.	Le chiamate all'API potrebbero essere soggette a limiti di frequenza.
Procedura di segnalazione di un host difettoso	Quando segnali un host difettoso per un nodo eseguito in modalità con tutta la capacità, si verifica quanto segue: Elimina pod: dopo che l'etichetta viene applicata al nodo difettoso, GKE contrassegna il nodo per bloccare la pianificazione di nuovi pod. GKE inizia anche a eseguire l'espulsione controllata dei pod in esecuzione sul nodo. GKE rispetta i budget di interruzione dei pod (PDB) e il campo spec.terminationGracePeriodSeconds dei manifest dei pod. Per maggiori dettagli, vedi Configurare GKE per terminare i carichi di lavoro in modo controllato. Segnala e ripara l'host difettoso: GKE segnala e ripara automaticamente l'host difettoso chiamando l'API Compute Engine, il che comporta una sequenza di operazioni che in genere richiede 10-12 minuti per segnalare l'host difettoso e poi può richiedere 3-14 giorni, o anche più a volte, per riparare l'host. Riavvia l'istanza: al termine dell'operazione di riparazione dell'host (in genere 3-14 giorni), si verifica una delle seguenti situazioni: Se l'istanza si trova nello stato REPAIRING e le risorse sono disponibili al termine della riparazione, Compute Engine riavvia automaticamente l'istanza sull'host riparato. Altrimenti, se l'istanza si trova nello stato TERMINATED o se le risorse non sono disponibili al termine della riparazione, lo stato dell'istanza rimane o cambia in TERMINATED. Devi riavviare manualmente l'istanza quando vuoi che venga eseguita. Tuttavia, il riavvio dell'istanza potrebbe non riuscire se le risorse non sono disponibili al riavvio dell'istanza. Ad esempio, questo può accadere se altre istanze stanno già utilizzando l'host riparato.	Quando segnali un host difettoso per un nodo in esecuzione in modalità gestita, si verifica quanto segue: Elimina pod: dopo che l'etichetta viene applicata al nodo difettoso, GKE contrassegna il nodo per bloccare la pianificazione di nuovi pod. GKE inizia anche a eseguire l'espulsione controllata dei pod in esecuzione sul nodo. GKE rispetta i budget di interruzione dei pod (PDB) e il campo spec.terminationGracePeriodSeconds dei manifest dei pod. Per maggiori dettagli, vedi Configurare GKE per terminare i carichi di lavoro in modo controllato. Segnala e inizia a riparare l'host difettoso: GKE segnala e ripara automaticamente l'host difettoso chiamando l'API Compute Engine, il che comporta una sequenza di operazioni che in genere richiede 10-12 minuti per segnalare l'host difettoso e poi può richiedere 3-14 giorni, o anche più a volte, per riparare l'host. Migra e riavvia l'istanza: dopo l'avvio dell'operazione di riparazione dell'host (in genere 10-12 minuti), Compute Engine tenta di riservare un altro host per sostituire l'host difettoso segnalato nella capacità riservata. Se Compute Engine trova un host integro, se sostituisce correttamente l'host difettoso o trova un host integro corrispondente nella capacità riservata, Compute Engine esegue la migrazione dell'istanza a quell'host. Il riavvio dell'istanza avviene quindi tramite uno dei seguenti metodi: Se l'istanza si trova nello stato REPAIRING e le risorse sono disponibili prima o al termine della riparazione, Compute Engine riavvia automaticamente l'istanza su un host integro. In caso contrario, se l'istanza si trova nello stato TERMINATED o se le risorse non sono disponibili prima o al termine della riparazione, lo stato dell'istanza rimane o cambia in TERMINATED. Devi riavviare manualmente l'istanza quando vuoi che venga eseguita. Tuttavia, il riavvio dell'istanza potrebbe non riuscire se le risorse non sono disponibili al riavvio dell'istanza. Ad esempio, questo può accadere se altre istanze stanno già utilizzando l'host riparato.

Monitorare l'avanzamento dell'operazione

Puoi monitorare l'avanzamento dell'operazione di GKE utilizzando l'etichetta del nodo cloud.google.com/report-and-replace-status sul nodo GKE, che ha uno dei seguenti valori:

• PodsEvicted: GKE ha terminato l'espulsione dei pod dal nodo interessato.
• OperationRUNNING: l'operazione per segnalare l'host difettoso è in corso.
• OperationDone: l'host sottostante è stato segnalato come difettoso e il nodo GKE è pronto per essere spostato su un nuovo host
• Error: chiamata API non riuscita, per motivi tra cui uno dei requisiti descritti nella sezione precedente.

Puoi anche visualizzare l'etichetta del nodo cloud.google.com/report-and-replace-operation per visualizzare l'ID operazione di Compute Engine e monitorare lo stato dell'operazione.

Puoi visualizzare entrambe queste etichette dei nodi utilizzando il seguente comando:

  kubectl get nodes NODE_NAME \
  -L cloud.google.com/report-and-replace-status,cloud.google.com/report-and-replace-operation

In caso di errori API, GKE imposta l'etichetta del nodo cloud.google.com/report-and-replace-status=ERROR. GKE cancella i taint dei nodi e rimuove l'etichetta del nodo cloud.google.com/fault-behavior.

Per scoprire come monitorare lo stato dettagliato di un'operazione di segnalazione di un host difettoso, consulta Esaminare le operazioni di segnalazione di un host difettoso.

Per riprovare l'operazione in caso di errori temporanei come i limiti di frequenza, applica di nuovo l'etichetta cloud.google.com/fault-behavior al nodo.

Passaggi successivi

• Scopri come pianificare i workload GKE con Topology Aware Scheduling.

• Scopri come ottimizzare il networking dei cluster utilizzando NCCL/gIB.

• Scopri come risolvere i problemi relativi agli errori dell'API host difettosa.