Informazioni sulle TPU in GKE

Questa pagina introduce Cloud TPU e ti aiuta a pianificare la configurazione di Cloud TPU con Google Kubernetes Engine (GKE), tra cui la prenotazione di istanze TPU, la scalabilità automatica, le limitazioni delle TPU e le considerazioni sulla pianificazione dei carichi di lavoro.

Le TPU (Tensor Processing Unit) sono ASIC (Application-Specific Integrated Circuit) sviluppati appositamente da Google per accelerare i carichi di lavoro di machine learning che utilizzano framework come TensorFlow, PyTorch e JAX.

Prima di utilizzare le TPU in GKE, ti consigliamo di completare il seguente percorso di apprendimento:

  1. Scopri come funzionano gli acceleratori di machine learning con Introduzione a Cloud TPU.
  2. Scopri di più sulla disponibilità attuale della versione di TPU con l'architettura di sistema Cloud TPU.

Per scoprire come configurare Cloud TPU in GKE, consulta le risorse seguenti:

Vantaggi dell'utilizzo delle TPU in GKE

GKE offre il supporto completo per la gestione del ciclo di vita dei nodi TPU e dei pool di nodi. GKE supporta anche le VM spot e l'utilizzo di Cloud TPU prenotato. I vantaggi dell'utilizzo delle TPU in GKE includono:

  • Ambiente operativo coerente: una piattaforma unica per tutti i carichi di lavoro di machine learning e altri carichi di lavoro.
  • Upgrade automatici: GKE automatizza gli aggiornamenti delle versioni, riducendo l'overhead operativo.
  • Bilanciamento del carico: GKE distribuisce il carico riducendo la latenza e migliorando l'affidabilità.
  • Scalabilità reattiva: GKE scala automaticamente le risorse TPU per soddisfare le esigenze dei tuoi carichi di lavoro.
  • Gestione delle risorse: con Kueue, un sistema di accodamento dei job nativo di Kubernetes, puoi gestire le risorse su più tenant all'interno della tua organizzazione utilizzando accodamento, prerilascio, assegnazione delle priorità e condivisione equa.

Terminologia relativa a TPU in GKE

Questo documento utilizza la seguente terminologia relativa alle TPU:

  • Tipo TPU: il tipo di Cloud TPU, ad esempio v5e.
  • Nodo della sezione TPU:un nodo Kubernetes che contiene un insieme di VM con chip TPU interconnessi.
  • Pool di nodi della sezione TPU: un gruppo di nodi Kubernetes all'interno di un cluster che hanno tutti la stessa configurazione TPU.
  • Topologia TPU: il numero e la disposizione fisica dei chip TPU in una sezione TPU.
  • Nodi della sezione TPU con host singolo: uno o più nodi della sezione TPU indipendenti. Le VM in un nodo di sezione TPU con un host singolo non sono connesse tra loro tramite interconnessioni ad alta velocità.
  • Nodi della sezione TPU multi-host: due o più nodi della sezione TPU interconnessi. Le VM in un nodo TPU multi-host sono collegate da interconnessioni ad alta velocità. I nodi sezione TPU multi-host hanno le seguenti caratteristiche:
    • Atomico: GKE tratta tutti i nodi interconnessi come singola unità. Durante le operazioni di scalabilità, GKE scala l'intero insieme di nodi fino a 0 e ne crea di nuovi. Se una macchina nel gruppo si arresta o viene terminata, GKE ricrea l'intero set di nodi come nuova unità.
    • Immutabile: non puoi aggiungere manualmente nuovi nodi all'insieme di nodi interconnessi. Tuttavia, puoi creare un nuovo pool di nodi con la topologia TPU che preferisci e pianificare i carichi di lavoro sul nuovo pool di nodi.

Come funzionano le TPU in GKE

La gestione e la priorità delle risorse di Kubernetes tratta le VM sulle TPU come gli altri tipi di VM. Richiedi i chip TPU utilizzando il nome della risorsa google.com/tpu:

    resources:
        requests:
          google.com/tpu: 4
        limits:
          google.com/tpu: 4

Quando utilizzi le TPU in GKE, devi considerare le seguenti caratteristiche delle TPU:

  • Una VM può accedere a un massimo di 8 chip TPU.
  • Una sezione TPU contiene un numero fisso di chip TPU che dipende dal tipo di macchina TPU scelto.
  • Il numero di google.com/tpu richiesti deve essere uguale al numero totale di chip TPU disponibili nel nodo della sezione TPU. Qualsiasi container in un pod GKE che richiede TPU deve utilizzare tutti i chip TPU nel nodo. In caso contrario, il deployment ha esito negativo perché GKE non può consumare parzialmente le risorse TPU. Ad esempio, vedi i seguenti scenari:
    • Il tipo di macchina ct5l-hightpu-8t ha un singolo nodo della sezione TPU con 8 chip TPU. È possibile eseguire il deployment sul nodo di un pod GKE che richiede otto chip TPU, ma non è possibile eseguire il deployment di due pod GKE che richiedono quattro chip TPU, ognuno dei quali su un nodo.
    • Il tipo di macchina ct5lp-hightpu-4t con una topologia 2x4 contiene due nodi di sezione TPU con quattro chip TPU ciascuno, per un totale di otto chip TPU. Non è possibile eseguire il deployment di un pod GKE che richiede otto chip TPU in nessuno dei nodi in questo pool, ma è possibile eseguire il deployment di due pod che richiedono quattro chip TPU ciascuno sui due nodi del pool di nodi.
    • TPU v5e con topologia 4x4 ha 16 chip TPU in quattro nodi. Il carico di lavoro GKE Autopilot che seleziona questa configurazione deve richiedere quattro chip TPU in ogni replica, per un massimo di quattro repliche.
  • Nei cluster Standard è possibile pianificare più pod Kubernetes su una VM, ma un solo container in ciascun pod può accedere ai chip TPU.
  • Ogni cluster standard deve avere almeno un pool di nodi non TPU per creare pod kube-system, come kube-dns.
  • Per impostazione predefinita, i nodi delle sezioni TPU presentano google.com/tpu incompatibilità che impedisce la pianificazione delle sezioni non TPU. L'incompatibilità non garantisce che le risorse TPU siano completamente utilizzate. Consente di eseguire carichi di lavoro che non utilizzano TPU su nodi delle sezioni non TPU, liberando risorse di calcolo sui nodi delle sezioni TPU per il codice che utilizza TPU.
  • GKE raccoglie i log emessi dai container in esecuzione sui nodi delle sezioni TPU. Per scoprire di più, consulta Logging.
  • Le metriche di utilizzo delle TPU, ad esempio le prestazioni di runtime, sono disponibili in Cloud Monitoring. Per scoprire di più, vedi Osservabilità e metriche.

Pianifica la configurazione di TPU

Per lavorare con le TPU nei cluster GKE, devi decidere i seguenti parametri:

  • Tipo di TPU: diversi tipi di TPU hanno funzionalità diverse, ad esempio rapporto prezzo/prestazioni, velocità effettiva di addestramento e latenza di distribuzione. Le capacità di CPU e memoria variano in base al tipo di macchina utilizzata.
  • Topologia: la disposizione fisica delle TPU all'interno di una sezione TPU. Ogni tipo di TPU supporta una topologia TPU 2D o 3D. Seleziona una topologia che soddisfi i requisiti di parallelismo del modello.

  • Interconnessione TPU: il tipo e la topologia di TPU determinano se ricevere o meno TPU in più nodi con interconnessioni ad alta velocità. Questo determina se vuoi avere nodi della sezione TPU con host singolo o multi-host.

    • Per i modelli su larga scala, utilizza nodi delle sezioni TPU multi-host
    • Per i modelli su scala ridotta, utilizza nodi sezione TPU con host singolo

  • Modalità con privilegi: i container in esecuzione nei nodi GKE versione 1.28 e precedenti devono abilitare la modalità con privilegi. Per le versioni 1.28 o successive non è necessario attivare la modalità con privilegi per accedere alle TPU.

Scegli una configurazione TPU per la modalità GKE Autopilot

In Autopilot, scegli un tipo di TPU e una topologia e le specifichi nel tuo manifest Kubernetes. GKE gestisce il provisioning dei nodi con le TPU e la pianificazione dei carichi di lavoro.

Disponibilità di TPU in GKE Autopilot

Le TPU sono disponibili in regioni specifiche di Google Cloud. Per utilizzare un tipo di TPU nel carico di lavoro GKE, il cluster deve trovarsi in una regione supportata per quel tipo. Per maggiori dettagli, consulta Regioni e zone TPU nella documentazione di Cloud TPU.

Scegli un tipo di TPU in Autopilot

Tipo di TPU Numero di vCPU Memoria (GiB) Numero di nodi NUMA Numero massimo di chip TPU in una sezione
TPU v5p
tpu-v5p-slice		 208 448 2 6144
TPU v5e
tpu-v5-lite-podslice		 Da 24 a 224 Da 48 a 384 1 256
TPU v5e (solo host singolo)
tpu-v5-lite-device		 Da 24 a 224 Da 48 a 384 Da 1 a 2 8
TPU v4
tpu-v4-podslice		 240 407 2 4096

Esamina le specifiche e i prezzi del chip nella documentazione di Cloud TPU per decidere quale versione utilizzare.

Scegli una topologia per Autopilot

La topologia è il layout fisico dei chip in una sezione TPU. A seconda del tipo di TPU, la topologia è bidimensionale o tridimensionale. Dopo aver scelto un tipo di TPU, seleziona una topologia supportata da quel tipo di TPU. I requisiti di parallelismo del modello ti aiutano a decidere una topologia. Il prodotto della dimensione di ogni dimensione in una topologia è il numero di chip TPU nella sezione. Ad esempio:

  • 2x2x2 è una sezione TPU v4 multi-host a 8 chip
  • 2x2 è una sezione TPU v5e con host singolo a 4 chip

La topologia selezionata per un tipo di TPU determina se hai nodi di sezione TPU con host singolo o multi-host. Se una topologia specifica supporta sezioni con host singolo e multi-host, il numero di chip TPU richiesti dal carico di lavoro determina il tipo di host che ricevi. Ad esempio, TPU v5e (tpu-v5-lite-podslice) supporta la topologia 2x4 come host singolo e multi-host. Se richiedi 4 chip TPU nel carico di lavoro, ottieni un nodo multi-host con 4 chip TPU. Se richiedi 8 chip TPU nel carico di lavoro, ottieni un singolo nodo host con 8 chip TPU.

La tabella seguente descrive le topologie supportate in ogni tipo di TPU, nonché il numero di chip TPU, il numero di nodi e il tipo di host:

Tipo di TPU Topologia Chip TPU in una sezione Numero di nodi Tipo di host Note
TPU v5p
tpu-v5p-slice		 2x2x1 4 1 Host singolo

Sono supportate topologie personalizzate per più di 64 chip. Si applicano le seguenti condizioni:

  • Per più di 64 chip, {A}, {B} e {C} devono essere multipli di 4
  • La topologia più grande è 16x16x24
  • I valori devono essere {A}≤{B}≤{C}, ad esempio 8x12x16.
2x2x2 8 2 Multi-host
2x2x4 16 4 Multi-host
2x4x4 32 8 Multi-host
4x4x4 64 16 Multi-host
{A}x{B}x{C} A*B*C (A*B*C/4)1 Multi-host
TPU v5e
tpu-v5-lite-podslice		 1x1 1 1 Host singolo Le topologie personalizzate non sono supportate.
2x2 4 1
2x4 8 1
2x4 2 1 Multi-host
4x4 16 4
4x8 32 8
8x8 64 16
8x16 128 32
16x16 256 64
TPU v5e (solo host singolo)
tpu-v5-lite-device		 1x1 1 1 Host singolo Le topologie personalizzate non sono supportate
2x2 4 1
2x4 8 1
TPU v4
tpu-v4-podslice		 2x2x1 4 1 Host singolo

Sono supportate topologie personalizzate per più di 64 chip. Si applicano le seguenti condizioni:

  • Per più di 64 chip, {A}, {B} e {C} devono essere multipli di 4
  • La topologia più grande è 12x16x16
  • I valori devono essere {A}≤{B}≤{C}, ad esempio 8x12x16.
2x2x2 8 2 Multi-host
2x2x4 16 4 Multi-host
2x4x4 32 8 Multi-host
4x4x4 64 16 Multi-host
{A}x{B}x{C} A*B*C (A*B*C/4)1 Multi-host

  1. Viene calcolato in base al prodotto di topologia diviso per quattro. ↩

Dopo aver scelto un tipo e una topologia TPU, specificali nel manifest del carico di lavoro. Per le istruzioni, consulta Eseguire il deployment dei carichi di lavoro TPU su GKE Autopilot.

Scegli una configurazione TPU per la modalità GKE Standard

Le seguenti sezioni descrivono le caratteristiche TPU che valuti durante la pianificazione e la configurazione dei carichi di lavoro TPU in GKE. Per maggiori dettagli su versioni, tipi di macchine, topologie valide e relativo numero di chip TPU, consulta la sezione Mappatura delle configurazioni TPU in questo documento.

Disponibilità di TPU in modalità GKE Standard

La tabella seguente elenca la disponibilità delle TPU in base al tipo e alla versione di macchina:

Versione TPU Tipo di macchina che inizia con Versione GKE minima Disponibilità Zona
TPU v4 ct4p- 1.26.1-gke.1500 Generalmente disponibile us-central2-b
TPU v5e ct5l- 1.27.2-gke.2100 Generalmente disponibile europe-west4-b
us-central1-a
TPU v5e ct5lp- 1.27.2-gke.2100 Generalmente disponibile europe-west4-a1
us-central1-a1
us-east1-c
us-east5-b1
us-west1-c
us-west4-a
us-west4-b1
TPU v5p ct5p- 1.28.3-gke.1024000 Generalmente disponibile us-east1-d
us-east5-a
us-east5-c

  1. Quando crei una TPU v5e con un tipo di macchina che inizia con ct5lp- in una qualsiasi delle zone europe-west4-a, us-central1-a, us-east5-b o us-west4-b, i pool di nodi TPU v5e a host singolo non sono supportati. In altre parole, quando si crea un pool di nodi TPU v5e in una di queste zone, è supportato solo il tipo di macchina ct5lp-hightpu-4t con una topologia di almeno 2x4 o superiore. Per creare una TPU v5e con host singolo in us-central1 o europe-west4, scegli rispettivamente le zone us-central1-a o europe-west4-b e utilizza i tipi di macchina che iniziano con ct5l-, ad esempio ct5l-hightpu-1t, ct5l-hightpu-4t o ct5l-hightpu-8t. Per creare una TPU v5e con host singolo nella regione us-west4, scegli la zona us-west4-a e utilizza tipi di macchine che iniziano con ct5lp-, ad esempio ct5lp-hightpu-1t. Tieni presente che i tipi di macchine che iniziano con ct5l- richiedono una quota diversa rispetto ai tipi di macchina che iniziano con ct5lp-. ↩

Le seguenti sezioni descrivono le caratteristiche TPU che valuti durante la pianificazione e la configurazione dei carichi di lavoro TPU in GKE. Per maggiori dettagli su versioni, tipi di macchine, topologie valide e relativo numero di chip TPU, consulta la sezione Mappatura delle configurazioni TPU in questo documento.

Tipo di macchina

I tipi di macchina che supportano le risorse TPU seguono una convenzione di denominazione che include la versione di TPU e il numero di chip TPU per nodo, ad esempio ct<version>-hightpu-<node-chip-count>t. Ad esempio, il tipo di macchina ct5lp-hightpu-1t supporta TPU v5e e contiene un chip TPU in totale.

Topologia

La topologia definisce la disposizione fisica delle TPU all'interno di una sezione TPU. GKE esegue il provisioning di una sezione TPU in topologie bidimensionali o tridimensionali a seconda della versione della TPU. Puoi specificare una topologia come numero di chip TPU in ogni dimensione:

  • Per TPU v4 e v5p pianificati nei pool di nodi delle sezioni TPU multi-host, definisci la topologia in 3 tuple ({A}x{B}x{C}), ad esempio 4x4x4. Il prodotto {A}x{B}x{C} definisce il numero di chip TPU nel pool di nodi. Ad esempio, puoi definire piccole topologie più piccole di 64 chip TPU con forme di topologia come 2x2x2, 2x2x4 o 2x4x4. Se utilizzi topologie più grandi di 64 chip TPU, i valori assegnati a {A}, {B} e {C} devono soddisfare le seguenti condizioni:

    • {A}, {B} e {C} sono multipli di quattro.
    • La topologia più grande supportata per la versione 4 è 12x16x16, mentre la topologia v5p è 16x16x24.
    • I valori assegnati mantengono il pattern A ≤ B ≤ C. Ad esempio, 4x4x8 o 8x8x8.

Mappatura della configurazione TPU

Utilizza la seguente tabella per definire il tipo di macchina TPU e la topologia da utilizzare in base al tuo caso d'uso:

  • Per l'addestramento o l'inferenza di modelli su scala ridotta, utilizza TPU v4 o TPU v5e con pool di nodi di sezioni TPU a host singolo.
  • Per l'addestramento o l'inferenza di modelli su larga scala, utilizza TPU v4 o TPU v5e con pool di nodi di sezioni TPU multi-host.
Versione TPU Tipo di macchina Topologia Numero di chip TPU Numero di VM Tipo di pool di nodi
TPU v4 ct4p-hightpu-4t 2x2x1 4 1 Host singolo
2x2x2 8 2 Multi-host
2x2x4 16 4 Multi-host
2x4x4 32 8 Multi-host
{A}x{B}x{C} A*B*C (A*B*C/4)1 Multi-host
TPU v5p ct5p-hightpu-4t 2x2x1 4 1 Host singolo
2x2x2 8 2 Multi-host
2x2x4 16 4 Multi-host
2x4x4 32 8 Multi-host
{A}x{B}x{C} A*B*C (A*B*C/4)1 Multi-host
TPU v5e ct5l-hightpu-1t 1x1 1 1 Host singolo
ct5l-hightpu-4t 2x2 4 1 Host singolo
ct5l-hightpu-8t 2x4 8 1 Host singolo
ct5lp-hightpu-1t 1x1 1 1 Host singolo
ct5lp-hightpu-4t 2x2 4 1 Host singolo
ct5lp-hightpu-8t 2x4 8 1 Host singolo
ct5lp-hightpu-4t 2x4 8 2 Multi-host
4x4 16 4 Multi-host
4x8 32 8 Multi-host
8x8 64 16 Multi-host
8x16 128 32 Multi-host
16x16 256 64 Multi-host

  1. Viene calcolato in base al prodotto di topologia diviso per quattro. ↩

Caratteristiche di TPU v5e

Le macchine TPU v5e hanno le seguenti caratteristiche tecniche:

Tipo di macchina Numero di vCPU Memoria (GB) Numero di NUMA nodi Probabilità di prerilascio
ct5l-hightpu-1t 24 48 1 Superiore
ct5l-hightpu-4t 112 192 1 Medio
ct5l-hightpu-8t 224 384 2 Meno
ct5lp-hightpu-1t 24 48 1 Superiore
ct5lp-hightpu-4t 112 192 1 Medio
ct5lp-hightpu-8t 224 384 1 Basso

Caratteristiche di TPU v4 e v5p

Le macchine TPU v4p e v5p hanno le seguenti caratteristiche tecniche:

Tipo di macchina Numero di vCPU Memoria (GB) Numero di NUMA nodi
ct4p-hightpu-4t 240 407 2
ct5p-hightpu-4t 208 448 2

Prenotazione TPU

Le prenotazioni TPU sono disponibili quando acquisti un impegno. Con GKE puoi utilizzare qualsiasi prenotazione di TPU.

Quando crei un pool di nodi della sezione TPU, utilizza i flag --reservation e --reservation-affinity=specific per utilizzare un'istanza TPU prenotata.

Scalabilità automatica delle TPU in GKE

GKE supporta le TPU (Tensor Processing Unit) per accelerare i carichi di lavoro di machine learning. Sia il pool di nodi della sezione TPU con host singolo che il pool di nodi della sezione TPU multi-host supportano la scalabilità automatica e il provisioning automatico.

Con il flag --enable-autoprovisioning su un cluster GKE, GKE crea o elimina i pool di nodi della sezione TPU a host singolo o multi-host con una versione e una topologia TPU che soddisfa i requisiti dei carichi di lavoro in attesa.

Quando utilizzi --enable-autoscaling, GKE scala il pool di nodi in base al tipo, come segue:

  • Pool di nodi della sezione TPU con host singolo: GKE aggiunge o rimuove i nodi TPU nel pool di nodi esistente. Il pool di nodi può contenere un numero qualsiasi di nodi TPU compreso tra zero e la dimensione massima del pool di nodi come determinata dai flag --max-nodes e --total-max-nodes. Quando il pool di nodi viene scalato, tutti i nodi TPU nel pool hanno lo stesso tipo di macchina e la stessa topologia. Per scoprire di più su come creare un pool di nodi della sezione TPU a host singolo, consulta Creare un pool di nodi.

  • Pool di nodi della sezione TPU multi-host: GKE fa lo scale up atomico del pool di nodi da zero al numero di nodi necessario per soddisfare la topologia TPU. Ad esempio, con un pool di nodi TPU con tipo di macchina ct5lp-hightpu-4t e topologia 16x16, il pool di nodi contiene 64 nodi. Il gestore della scalabilità automatica di GKE garantisce che questo pool di nodi abbia esattamente 0 o 64 nodi. Durante lo scale down down, GKE rimuove tutti i pod pianificati e svuota l'intero pool di nodi fino a zero. Per saperne di più su come creare un pool di nodi della sezione TPU multi-host, consulta Creare un pool di nodi.

Limitazioni

  • Per le prenotazioni di capacità, devi utilizzare una prenotazione specifica.
  • L'allocazione dei costi e la misurazione dell'utilizzo di GKE non includono dati sull'utilizzo o sui costi della TPU v4 prenotata.
  • TPU v5p e v5e non supportano lo streaming di riptide/immagine in us-east5.
  • La scalabilità automatica v5p TPU è supportata sui cluster GKE con piani di controllo in esecuzione almeno 1.29.2-gke.1035000 o almeno 1.28.7-gke.1020000.

Considerazioni sulla pianificazione del carico di lavoro

Le TPU hanno caratteristiche uniche che richiedono una pianificazione e una gestione speciali dei carichi di lavoro in Kubernetes. Le seguenti sezioni descrivono le best practice di pianificazione.

CPU

Questa sezione non si applica ai cluster Autopilot perché GKE posiziona ogni sezione TPU sul proprio nodo. Per scoprire di più, consulta Come funzionano le TPU in modalità Autopilot

Per pianificare un carico di lavoro non TPU su una VM in un nodo della sezione TPU, assicurati che il pod GKE possa tollerare l'incompatibilità di google.com/tpu. Se vuoi eseguire il deployment del carico di lavoro in nodi specifici, utilizza i selettori dei nodi.

La gestione e la priorità delle risorse di Kubernetes tratta le VM nelle TPU come gli altri tipi di VM. Per assegnare la priorità ai pod che richiedono la pianificazione delle TPU rispetto ad altri pod sugli stessi nodi, richiedi la CPU o la memoria massima per queste sezioni TPU. Le sezioni TPU a bassa priorità dovrebbero eseguire queste operazioni:

  1. Imposta richieste di CPU e memoria basse per garantire che il nodo disponga di risorse allocabili sufficienti per i carichi di lavoro TPU. Per saperne di più, consulta In che modo Kubernetes applica richieste e limiti delle risorse.
  2. Non impostare alcun limite di CPU (illimitato) per garantire che i pod possano eseguire il burst per utilizzare tutti i cicli inutilizzati.
  3. Imposta un limite di memoria elevato per garantire che i pod possano utilizzare la maggior parte della memoria inutilizzata mantenendo la stabilità del nodo.

Se un pod Kubernetes non richiede CPU e memoria (anche se richiede TPU), Kubernetes lo considera un pod "best effort" e non vi è alcuna garanzia che abbia bisogno di CPU e memoria. Solo i pod che richiedono esplicitamente CPU e memoria hanno queste garanzie. Per maggiori informazioni, consulta Gestione delle risorse per pod e container.

Per saperne di più, consulta Best practice di Kubernetes: richieste e limiti delle risorse.

Riduci le interruzioni dei carichi di lavoro

Se utilizzi TPU per addestrare un modello di machine learning e il carico di lavoro viene interrotto, tutto il lavoro eseguito dall'ultimo checkpoint andrà perso. Per ridurre la probabilità che il carico di lavoro venga interrotto:

  • Imposta una priorità più alta per questo job rispetto a tutti gli altri job: se le risorse sono scarse, lo scheduler GKE prerilascia i job con priorità più bassa per pianificare un job con priorità più alta. Ciò garantisce inoltre che il carico di lavoro con priorità più elevata riceva tutte le risorse di cui ha bisogno (fino alle risorse totali disponibili nel cluster). Per scoprire di più, consulta Priorità e prerilascio dei pod.
  • Configura l'esclusione della manutenzione: un'esclusione della manutenzione è un periodo di tempo non ripetuto durante il quale è vietata la manutenzione automatica. Per scoprire di più, consulta la sezione Esclusioni dalla manutenzione.
  • Usa pod a tempo di esecuzione esteso in Autopilot: usa i pod a tempo di esecuzione esteso per un periodo di tolleranza fino a sette giorni prima che GKE termini i pod per lo scale down o gli upgrade dei nodi.

Gestisci l'interruzione dovuta alla manutenzione del nodo

Tutti i nodi GKE, inclusi quelli che contengono TPU, sono soggetti a eventi di manutenzione o altre interruzioni che potrebbero causare l'arresto del nodo. Puoi ridurre le interruzioni dei carichi di lavoro in esecuzione nei cluster GKE con il piano di controllo che esegue la versione 1.29.1-gke.1425000 o successive. GKE avvisa i nodi di un arresto imminente inviando un segnale SIGTERM al nodo fino a cinque minuti prima dell'eliminazione. Se il carico di lavoro utilizza un framework ML come MaxText, Pax o JAX con Orbax, i carichi di lavoro possono acquisire l'indicatore SIGTERM e avviare un processo di checkpoint.

Puoi configurare GKE per terminare i carichi di lavoro ML in modo controllato con il tempo di notifica massimo. Nel manifest del pod, imposta il campo spec.terminationGracePeriodSeconds su 300 secondi (cinque minuti). GKE fa il possibile per terminare questi pod in modo controllato e eseguire l'azione di terminazione che hai definito, ad esempio salvando uno stato di addestramento. GKE rispetta qualsiasi configurazione fino a cinque minuti per le impostazioni PodDisruptionBudget o terminationGracePeriodSeconds.

Il campo spec.terminationGracePeriodSeconds gestisce solo le interruzioni dovute a eventi di manutenzione e deframmentazione che si verificano sulle VM non prerilasciabili. GKE non gestisce interruzioni involontarie, come guasti hardware.

Per ulteriori informazioni, consulta Configurare la terminazione controllata dei nodi della sezione TPU.

Massimizza l'utilizzo della TPU

Per massimizzare l'investimento nelle TPU, pianifica un mix di priorità dei job e accodale per massimizzare il tempo di funzionamento delle TPU. Se vuoi la pianificazione e il prerilascio a livello di job, devi utilizzare un componente aggiuntivo a Kubernetes che orchestra i job in code. Per questo caso d'uso, ti consigliamo di utilizzare Kueue.

Passaggi successivi