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 workload AI:

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

Gestire la manutenzione dell'host per i workload AI

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

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

Monitorare 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, consulta Monitorare le notifiche di manutenzione.

Con queste etichette dei nodi, puoi:

Avviare 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 che si adatta alla 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. Inoltre, continua a leggere questa sezione per scoprire quanto segue:

Utilizzare le informazioni sulla manutenzione dell'host durante la pianificazione dei workload

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 l'interruzione dei workload.

Nelle sezioni seguenti sono riportati esempi di come utilizzare queste informazioni.

Pianificare i pod sui nodi che non hanno eventi di manutenzione pianificati 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

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

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

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

Gestire gli upgrade dei cluster GKE per i workload AI

I workload AI sono sensibili alle interruzioni.

Durante il ciclo di vita di un cluster GKE, i workload AI devono essere preparati per le interruzioni sia delle istanze di computing sottostanti sia del cluster GKE stesso:

Ti consigliamo di mantenere il cluster registrato in un canale di rilascio. Per impostazione predefinita, i cluster GKE sono registrati nel canale di rilascio Regular. Per saperne 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. Ti consigliamo l'ambito "Nessun upgrade secondario o dei nodi" per i workload AI.

Segnalare host difettosi tramite GKE

Questa sezione descrive come, tramite GKE, puoi segnalare un host difettoso per cui sono state sottoposte a provisioning istanze di computing utilizzando il modello di provisioning associato 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 team dedicato all'account.

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 workload dal nodo.
  2. Impedisce la pianificazione di nuovi pod sul nodo.
  3. Chiama l'API sull'istanza di computing per contrassegnare l'host come difettoso.
  4. Attende che l'istanza di computing venga ripristinata su una macchina host integra. Per le prenotazioni che utilizzano la modalità operativa di prenotazione all capacity, Compute Engine ripristina l'istanza di computing sullo stesso nodo al termine dell'operazione di riparazione.
  5. Rimuove l'incompatibilità e l'etichetta fault-behavior dal nodo.

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

Requisiti

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

  • Devi eseguire la versione patch 1.32.3-gke.1057001 di GKE o versioni successive.
  • Devi eseguire 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 computing che è associata alla prenotazione.
  • Il nodo GKE deve essere nello stato RUNNING. Se provi a segnalare un host difettoso dopo aver eliminato l'istanza di computing, viene restituito un messaggio di errore e la macchina host non viene contrassegnata come difettosa.
  • Potresti essere soggetto a limiti di frequenza per il 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 prenotazioneall capacity.

Segnalare un host difettoso

Per segnalare un host difettoso:

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

  2. Segnala il nodo come difettoso utilizzando il seguente comando. Puoi fornire un motivo e, con le versioni successive, una descrizione:

      kubectl patch node NODE_NAME --type merge -p '{
    "metadata": {
      "labels": {
        "cloud.google.com/fault-behavior": "FAULT_REASON"
      },
      "annotations": {
        "cloud.google.com/fault-description": "FAULT_DESCRIPTION"
      }
    }
  }'

    Modifica il comando come segue:

    • Sostituisci NODE_NAME con il nome del nodo difettoso.
    • Sostituisci FAULT_REASON con il motivo del guasto appropriato utilizzando uno o più dei seguenti valori:
      • PERFORMANCE: utilizza questo valore se le GPU su un'istanza di computing hanno prestazioni inferiori rispetto ad altre GPU nel cluster e non vedi errori XID nei log e non viene rilevato nessuno degli altri pattern di errore comuni, ad esempio il danneggiamento silenzioso dei dati.
      • SDC: utilizza questo valore per il danneggiamento silenzioso dei dati, se vedi il danneggiamento dei dati ma nessun arresto anomalo del sistema. Questo danneggiamento dei dati può essere causato 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 fare riferimento a 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 sta causando il problema con l'istanza di computing. Questo è il valore predefinito. Tuttavia, ti consigliamo di specificare uno degli altri valori, se applicabile.
    • Modifica il blocco annotations in base alla versione del piano di controllo del cluster GKE :
      • 1.35.6-gke.1017000 o versioni successive oppure 1.36.0-gke.3251000 o versioni successive: mantieni il blocco delle annotazioni e sostituisci FAULT_DESCRIPTION con una descrizione testuale del guasto osservato. Può includere il codice di errore XID, i sintomi o i timestamp. Questa descrizione viene inoltrata a Compute Engine per facilitare la diagnostica della riparazione ed è rimossa automaticamente dal nodo al termine dell'operazione. Ad esempio: GPU XID 48 observed on device nvidia0 at 2026-06-10T10:30:00Z.
      • Versioni precedenti: rimuovi l'intero blocco annotations da il comando. Il campo fault-description non viene inoltrato a Compute Engine in queste versioni e non viene rimosso automaticamente dal nodo. Contatta invece il team dedicato all'account o l'assistenza clienti Google Cloud per fornire i dettagli del guasto.
Dopo aver segnalato un host difettoso per un nodo, il tempo di riavvio del nodo varia in base alla modalità operativa di prenotazione specificata nella prenotazione utilizzata dal nodo. Per verificare la modalità operativa di prenotazione per una prenotazione, visualizza il reservationOperationalMode campo nella prenotazione. La tabella seguente riassume la procedura per l'host difettoso per le due modalità operative di prenotazione disponibili: modalità all capacity e modalità gestita.
Modalità All capacity (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 dell'API di segnalazione dell'host difettoso Non si applicano limiti di frequenza. Le chiamate all'API potrebbero essere soggette a limiti di frequenza.
Procedura di segnalazione dell'host difettoso

Quando segnali un host difettoso per un nodo in esecuzione in modalità all capacity, si verifica quanto segue: quanto segue:

  1. Rimuovi i pod: dopo che l'etichetta viene applicata al nodo difettoso, GKE lo contrassegna per bloccare la pianificazione di nuovi pod. GKE inizia anche a rimuovere in modo controllato i pod in esecuzione sul nodo. GKE respects the Pod Disruption Budgets (PDBs) and the spec.terminationGracePeriodSeconds field of your Pod manifests. Per maggiori dettagli, consulta Configurare GKE per terminare i workload in modo controllato.
  2. 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 di più per riparare l'host.

  3. Riavvia l'istanza: al termine dell'operazione di riparazione dell'host completa (in genere 3-14 giorni), si verifica una delle seguenti situazioni:

    • Se l'istanza è nello stato REPAIRING e le risorse sono disponibili al termine della riparazione, Compute Engine riavvia automaticamente l'istanza sull'host riparato.
    • In caso contrario, se l'istanza è 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 momento del riavvio; ad esempio, questo può accadere se altre istanze utilizzano già l'host riparato.

Quando segnali un host difettoso per un nodo in esecuzione in modalità gestita, si verifica quanto segue:

  1. Rimuovi i pod: dopo che l'etichetta viene applicata al nodo difettoso, GKE lo contrassegna per bloccare la pianificazione di nuovi pod. GKE inizia anche a rimuovere in modo controllato i pod in esecuzione sul nodo. GKE respects the budget di interruzione dei pod (PDB) e il spec.terminationGracePeriodSeconds campo dei manifest dei pod. Per maggiori dettagli, consulta Configurare GKE per terminare i workload in modo controllato.
  2. Segnala e avvia la riparazione dell'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 di più per riparare l'host.

  3. Esegui la migrazione e riavvia l'istanza: dopo l'avvio dell'operazione di riparazione dell'host (in genere 10-12 minuti), Compute Engine tenta di prenotare un altro host per sostituire l'host difettoso segnalato nella capacità riservata. Se Compute Engine trova un host integro, ovvero se sostituisce correttamente l'host difettoso o trova un host integro corrispondente nella capacità riservata, esegue la migrazione dell'istanza a quell'host. Il riavvio dell'istanza avviene quindi in uno dei seguenti modi:

    • Se l'istanza è 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 è 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 momento del riavvio; ad esempio, questo può accadere se altre istanze utilizzano già 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 la rimozione dei pod dal nodo interessato.
  • OperationRUNNING: è in corso l'operazione per segnalare l'host difettoso.
  • OperationDONE: l'host sottostante è stato segnalato come difettoso e il nodo GKE è pronto per essere spostato su un nuovo host.
  • OperationFAILED: l'API sull'istanza di computing non è riuscita a causa di limiti di quota o altri problemi dell'infrastruttura. Consulta Risolvere i problemi relativi agli errori dell'API di segnalazione dell'host difettoso. GKE rimuove l'etichetta del nodo cloud.google.com/fault-behavior e cancella le incompatibilità dei nodi. Puoi applicare di nuovo l'etichetta per riprovare l'operazione.
  • Error: la chiamata API per segnalare l'host difettoso non è riuscita perché la richiesta non soddisfaceva 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 dell'operazione Compute Engine per 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

Se si verifica un errore di chiamata API, GKE imposta l'etichetta del nodo su cloud.google.com/report-and-replace-status=ERROR. Se l'API sull'istanza di computing non riesce, GKE imposta l'etichetta del nodo su cloud.google.com/report-and-replace-status=OperationFAILED. In entrambi i casi, GKE cancella le incompatibilità 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 dell'host difettoso, consulta Esaminare le operazioni di segnalazione dell'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