Gestire i cluster GKE ottimizzati per l'AI

Questa pagina mostra come gestire i cluster Google Kubernetes Engine (GKE) ottimizzati per l'AI di 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 di 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 di Compute Engine che periodicamente subiscono eventi dell'host che possono essere dannosi per i workload di AI. Poiché gli eventi host si verificano nell'infrastruttura Google Cloud sottostante, bypassano 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 su migrazione live, che riduce al minimo l'interruzione dei workload, le GPU e le TPU non supportano la migrazione live. Quando questi eventi host interessano i nodi GKE che eseguono workload di AI, GKE deve terminare il nodo e i pod in esecuzione sul nodo. Se il deployment dei pod viene eseguito nell'ambito di un workload più grande, ad esempio un job o un deployment, GKE tenta di riavviare i pod sul nodo interessato.

Per scoprire di più sulla gestione della manutenzione dell'host delle istanze di computing sottostanti, consulta Gestisci 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, consulta Monitora le notifiche di manutenzione.

Con queste etichette dei nodi, puoi:

Avvia manualmente un evento di manutenzione dell'host

Dopo che Compute Engine ha inviato una notifica relativa a un evento di manutenzione pianificata, 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 programmata regolarmente.

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

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

Puoi utilizzare le informazioni sulla manutenzione mostrate tramite le etichette dei nodi GKE insieme all'affinità e all'anti-affinità dei nodi per ridurre al minimo le interruzioni dei workload.

Consulta le sezioni seguenti per esempi di come utilizzare queste informazioni.

Pianifica 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 per il futuro, 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 è pianificata la manutenzione dopo una determinata data

Puoi indicare a GKE di pianificare i pod solo sui nodi per i quali è 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

Gestisci gli upgrade dei cluster GKE per i workload di AI

I workload di AI sono sensibili alle interruzioni.

Durante il ciclo di vita di un cluster GKE, i workload AI devono essere preparati per l'interruzione 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 regolare. Per scoprire di più sui vantaggi dei canali di rilascio, consulta il confronto tra i cluster registrati e non registrati in un canale di rilascio.

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

Segnala host difettosi tramite GKE

Questa sezione descrive come, tramite GKE, puoi segnalare un host difettoso su cui è stato eseguito il provisioning di istanze di computing utilizzando il modello di provisioning con 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.

Se osservi errori di memoria GPU o Xid su un nodo e vuoi verificare se misure di recupero manuali come l'attivazione di un riavvio del sistema operativo guest (kubectl label nodes <NODE_NAME> cloud.google.com/perform-reboot=true) possono risolvere il problema prima di segnalare l'host come difettoso, consulta Esamina i messaggi Xid.

Un host è un singolo server fisico nel data center che esegue un'istanza di computing che ospita il tuo nodo GKE. Puoi segnalare host difettosi applicando un'etichetta del nodo fault-behavior al nodo GKE interessato. Dopo aver applicato l'etichetta del nodo a un determinato nodo GKE, 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 Tutta la capacità, Compute Engine ripristina l'istanza di computing sullo stesso nodo al termine dell'operazione di riparazione.
  5. Rimuove il taint e l'etichetta fault-behavior dal nodo.

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

Requisiti

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

  • Devi eseguire la versione patch di GKE 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 computing vincolata alla prenotazione.
  • Il nodo GKE deve essere in 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.
  • Il numero di chiamate a questa API per prenotazione al mese potrebbe essere limitato in base a una valutazione dello stato dei tuoi blocchi. I limiti di frequenza non si applicano se la prenotazione utilizza la modalità operativa di prenotazione Tutta la capacità.

Segnala 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 file 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 dell'errore appropriato utilizzando uno o più dei seguenti valori:
      • PERFORMANCE: utilizza questo valore se le GPU di un'istanza di computing hanno prestazioni più lente rispetto ad altre GPU nel cluster e non vedi errori XID nei log, né vengono rilevati altri pattern di errore comuni, come il danneggiamento silenzioso dei dati.
      • SDC Questo danneggiamento dei dati può essere causato da difetti della CPU, bug del software come use-after-free o memory stomping, problemi del kernel o altri difetti. Nella maggior parte dei casi, questo termine viene utilizzato per fare riferimento a difetti indotti dall'hardware.
      • XID: utilizza questo valore se hai identificato un errore della GPU non recuperabile con un XID per un'istanza di computing.
      • unspecified: utilizza questo valore se non sai con certezza 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 control plane del tuo 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 dell'errore 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 e viene 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 dal 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 dell'errore.
Dopo aver segnalato un host difettoso per un nodo, il momento in cui il nodo viene riavviato varia in base alla modalità operativa della prenotazione specificata nella prenotazione utilizzata dal nodo. Per verificare la modalità operativa di una prenotazione, visualizza il campo reservationOperationalMode nella prenotazione. La tabella seguente riassume la procedura per l'host difettoso per le due modalità operative di prenotazione disponibili: modalità di capacità totale 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 (8 GPU)
Limitazione di frequenza dell'API per la segnalazione di host difettosi Non si applicano limiti di frequenza. Le chiamate API potrebbero essere soggette a limitazione di frequenza.
Procedura di segnalazione di un host difettoso

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

  1. Espelli i pod: dopo l'applicazione dell'etichetta al nodo difettoso, GKE applica un taint al nodo per bloccare la pianificazione di nuovi pod. GKE inizia anche a espellere in modo controllato i pod in esecuzione sul nodo. GKE rispetta i budget di interruzione dei pod (PDB) e il campo spec.terminationGracePeriodSeconds dei manifest dei pod. Per saperne di più, consulta Configura GKE per terminare i workload in modo controllato.
  2. Segnala e ripara l'host difettoso: GKE chiama l'API Compute Engine per segnalare e riparare l'host difettoso. Questa sequenza di operazioni richiede in genere tra i 10 e i 12 minuti per segnalare l'host difettoso e da 3 a 14 giorni, o a volte anche di più, per ripararlo.

  3. Riavvia il nodo: al termine dell'operazione di riparazione dell'host, si verifica uno dei seguenti eventi:

    • Se il nodo è nello stato REPAIRING e le risorse sono disponibili al termine della riparazione, Compute Engine riavvia automaticamente il nodo sull'host riparato.
    • In caso contrario, se il nodo è nello stato TERMINATED o se le risorse non sono disponibili al termine della riparazione, lo stato del nodo rimane o cambia in TERMINATED. Devi riavviare manualmente il nodo quando vuoi che venga eseguito. Tuttavia, se le risorse non sono disponibili quando riavvii il nodo, ad esempio se altre istanze di computing utilizzano già l'host riparato, il riavvio potrebbe non riuscire.

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

  1. Espelli i pod: dopo l'applicazione dell'etichetta al nodo difettoso, GKE contamina il nodo per bloccare la pianificazione di nuovi pod. GKE inizia anche a rimuovere correttamente i pod in esecuzione sul nodo. GKE rispetta i budget di interruzione dei pod (PDB) e il campo spec.terminationGracePeriodSeconds dei manifest dei pod. Per saperne di più, consulta Configura GKE per terminare i workload in modo controllato.

  2. Segnala e avvia la riparazione dell'host difettoso: GKE chiama l'API Compute Engine per segnalare e riparare l'host difettoso. Questa sequenza di operazioni richiede in genere tra i 10 e i 12 minuti per segnalare l'host difettoso.

    Il comportamento del nodo all'avvio dell'operazione di riparazione dell'host varia in base alla serie di macchine:

    • A4 e A3 Ultra: GKE tenta di eseguire la migrazione live del nodo a un host diverso. Se non hai una capacità riservata sufficiente o se la capacità non è disponibile nella zona del nodo, il nodo si arresta.
    • A3 Mega e A3 High: GKE arresta il nodo e lo riavvia su un host integro.

    La riparazione dell'host difettoso originale può richiedere da 3 a 14 giorni o, a volte, anche di più.

  3. Esegui la migrazione o riavvia il nodo: dopo l'avvio dell'operazione di riparazione dell'host, Compute Engine tenta di prenotare un host integro per sostituire l'host difettoso segnalato nella capacità prenotata. Se Compute Engine trova un host sostitutivo, si verifica quanto segue:

    • A4 e A3 Ultra: se nel passaggio precedente è stata eseguita la migrazione live del nodo, questo continua a essere eseguito sull'host sostitutivo. Se il nodo è stato arrestato, viene riavviato sull'host sostitutivo.
    • A3 Mega e A3 High: il nodo viene riavviato sull'host sostitutivo.

    Se Compute Engine non riesce a trovare immediatamente un host sostitutivo, il nodo viene riavviato come segue:

    • Se il nodo è nello stato REPAIRING e le risorse sono disponibili prima o al termine della riparazione, Compute Engine riavvia automaticamente il nodo su un host integro.
    • In caso contrario, se il nodo è nello stato TERMINATED o se le risorse non sono disponibili prima o al termine della riparazione, lo stato del nodo rimane o cambia in TERMINATED. Devi riavviare manualmente il nodo quando vuoi che venga eseguito.

    A differenza della modalità di capacità totale, non devi attendere che l'host difettoso originale venga riparato prima che il workload possa riprendere.

Monitora 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 tuo nodo GKE, che ha uno dei seguenti valori:

  • PodsEvicted: GKE ha terminato l'eliminazione dei pod dal nodo interessato.
  • OperationRUNNING: l'operazione per segnalare l'host con errori è in esecuzione.
  • OperationDONE: l'host sottostante è stato segnalato come difettoso e il nodo GKE è pronto per essere spostato su un nuovo host.
  • OperationFAILED: l'API nell'istanza di computing non è riuscita a causa di limiti di quota o altri problemi dell'infrastruttura. Per comprendere l'errore, consulta Risolvi gli errori dell'API per la segnalazione di host difettosi. Per scoprire come eseguire il recupero, consulta Gestisci gli errori di segnalazione e sostituzione.
  • Error: la chiamata API non è riuscita perché la richiesta non soddisfaceva uno dei requisiti descritti nella sezione precedente.

Puoi anche visualizzare l'etichetta del nodo node.gke.io/report-and-replace-operation per visualizzare l'ID operazione di Compute Engine per monitorare lo stato dell'operazione.

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

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

Se si verifica un errore dell'API, GKE imposta l'etichetta del nodo cloud.google.com/report-and-replace-status su Error. Se si verifica un errore dell'operazione, GKE imposta l'etichetta su OperationFAILED. In entrambi i casi, GKE rimuove l'etichetta del nodo cloud.google.com/fault-behavior. Inoltre, in GKE versione 1.35.6-gke.1256000 o successiva o 1.36.0-gke.4060000 o successiva, GKE applica un taint cloud.google.com/report-and-replace-failed:NoSchedule al nodo. Questa incompatibilità impedisce la pianificazione di nuovi pod sul nodo, garantendo che i workload non vengano posizionati su un nodo con un host potenzialmente difettoso. Per scoprire di più, consulta Gestisci gli errori di segnalazione e sostituzione.

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

Gestisci gli errori di segnalazione e sostituzione

Quando un'operazione di segnalazione e sostituzione non va a buon fine, GKE applica il taint cloud.google.com/report-and-replace-failed:NoSchedule al nodo interessato. Questo taint mantiene il nodo isolato in modo che non vengano pianificati nuovi workload mentre l'host sottostante potrebbe essere ancora difettoso.

Verifica la presenza del taint di errore

Per verificare se un nodo ha il taint di errore report-and-replace, esegui questo comando:

  kubectl describe node NODE_NAME | grep "report-and-replace-failed"

Risolvere un errore di segnalazione e sostituzione

Per eseguire il recupero da un errore di segnalazione e sostituzione, esegui una delle seguenti operazioni:

  • Riprova l'operazione applicando nuovamente l'etichetta cloud.google.com/fault-behavior al nodo. Se il nuovo tentativo va a buon fine, GKE rimuove automaticamente il taint cloud.google.com/report-and-replace-failed:NoSchedule:

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

  • Rimuovi manualmente il taint se hai stabilito che il nodo è integro o se vuoi rimetterlo in servizio:

      kubectl taint nodes NODE_NAME cloud.google.com/report-and-replace-failed:NoSchedule-

Passaggi successivi