Informazioni sul provisioning di GPU e TPU con la modalità di provisioning con avvio flessibile

Questa pagina descrive la modalità di provisioning con inizio flessibile in Google Kubernetes Engine (GKE). Flex-start, basato su Dynamic Workload Scheduler, offre una tecnica flessibile e conveniente per ottenere GPU e TPU quando devi eseguire carichi di lavoro AI/ML.

Flex-start ti consente di eseguire il provisioning dinamico di GPU e TPU in base alle tue esigenze, per un massimo di sette giorni, senza vincoli a un'ora di inizio specifica e senza la gestione delle prenotazioni a lungo termine. Pertanto, la funzionalità di inizio flessibile è ideale per i carichi di lavoro di piccole e medie dimensioni con requisiti di domanda variabili o brevi durate. Ad esempio, preaddestramento di piccoli modelli, ottimizzazione dei modelli o modelli di pubblicazione scalabili.

Le informazioni riportate in questa pagina possono aiutarti a:

• Scopri come funziona flex-start in GKE.
• Decidi se la pianificazione flessibile è adatta al tuo carico di lavoro.
• Decidi quale configurazione con inizio flessibile è adatta al tuo carico di lavoro.
• Gestire le interruzioni quando si utilizza la funzionalità di inizio flessibile.
• Scopri le limitazioni di flex-start in GKE.

Questa pagina è rivolta a amministratori e operatori della piattaforma e ingegneri di machine learning (ML) che vogliono ottimizzare l'infrastruttura dell'acceleratore per i propri carichi di lavoro.

Quando utilizzare flex-start

Ti consigliamo di utilizzare l'avvio flessibile se i tuoi workload soddisfano tutte le seguenti condizioni:

• I tuoi carichi di lavoro richiedono risorse GPU.
• I tuoi carichi di lavoro richiedono risorse TPU in esecuzione in node pool di slice TPU a host singolo.
• Hai una capacità GPU o TPU riservata limitata o nessuna e hai bisogno di un accesso più affidabile a questi acceleratori.
• Il tuo workload è flessibile in termini di tempo e il tuo caso d'uso può permettersi di attendere per ottenere tutta la capacità richiesta, ad esempio quando GKE alloca le risorse GPU al di fuori delle ore di punta.

Requisiti

Per utilizzare flex-start in GKE, il cluster deve soddisfare i seguenti requisiti:

• Per eseguire le GPU, utilizza la versione 1.32.2-gke.1652000 o successive di GKE.

• Per eseguire le TPU, utilizza GKE 1.33.0-gke.1712000 o versioni successive. Flex-start supporta le seguenti versioni e zone:

  • TPU Trillium (v6e) in asia-northeast1-b e us-east5-a.
  • TPU v5e in us-west4-a.
  • TPU v5p in us-east5-a.

  Le versioni TPU 3 e 4 non sono supportate.

Come funziona la modalità di provisioning con avvio flessibile

Con flex-start, specifichi la capacità GPU o TPU richiesta nei carichi di lavoro. Inoltre, con i cluster standard puoi configurare flex-start su pool di nodi specifici. GKE esegue automaticamente il provisioning delle VM completando la seguente procedura quando la capacità diventa disponibile:

1. Il carico di lavoro richiede una capacità non immediatamente disponibile. Questa richiesta può essere effettuata direttamente dalla specifica del carico di lavoro o tramite strumenti di pianificazione come le classi di calcolo personalizzate o Kueue.
2. GKE identifica che il tuo nodo ha attivato l'avvio flessibile e che il carico di lavoro può attendere per un periodo di tempo indeterminato.
3. Il gestore della scalabilità automatica dei cluster accetta la richiesta e calcola il numero di nodi necessari, trattandoli come una singola unità.
4. Il gestore della scalabilità automatica del cluster esegue il provisioning dei nodi necessari quando sono disponibili. Questi nodi vengono eseguiti per un massimo di sette giorni o per una durata inferiore se specifichi un valore nel parametro maxRunDurationSeconds. Questo parametro è disponibile con GKE versione 1.28.5-gke.1355000 o successive. Se non specifichi un valore per il parametro maxRunDurationSeconds, il valore predefinito è sette giorni.
5. Al termine del tempo di esecuzione definito nel parametro maxRunDurationSeconds, i nodi e i pod vengono prenotati.
6. Se i pod terminano prima e i nodi non vengono più utilizzati, il gestore della scalabilità automatica del cluster li rimuove in base al profilo di scalabilità automatica.

GKE conteggia la durata di ogni richiesta flex-start a livello di nodo. Il tempo a disposizione per l'esecuzione dei pod potrebbe essere leggermente inferiore a causa di ritardi durante l'avvio. I tentativi di recupero del pod condividono questa durata, il che significa che dopo il nuovo tentativo è disponibile meno tempo per i pod. GKE conteggia separatamente la durata di ogni richiesta flex-start.

Configurazioni di avvio flessibile

GKE supporta le seguenti configurazioni di inizio flessibile:

• Flex-start, in cui GKE alloca le risorse node per node. Questa configurazione richiede solo di impostare il flag --flex-start durante la creazione del nodo.

• Avvio flessibile con provisioning in coda, in cui GKE alloca tutte le risorse richieste contemporaneamente. Per utilizzare questa configurazione, devi aggiungere i flag --flex-start e enable-queued-provisioning quando crei il pool di nodi. GKE segue la procedura descritta in Come funziona la modalità di provisioning flex-start in questo documento, ma applica anche le seguenti condizioni:

  • Lo scheduler attende che tutte le risorse richieste siano disponibili in una singola zona.
  • Tutti i pod del carico di lavoro possono essere eseguiti insieme sui nodi appena provisionati.
  • I nodi di cui è stato eseguito il provisioning non vengono riutilizzati tra le esecuzioni del workload.

La seguente tabella mette a confronto le configurazioni con inizio flessibile:

Ottimizzare la configurazione di flex-start

Per creare un'infrastruttura AI/ML affidabile e ottimizzata in termini di costi, puoi combinare le configurazioni con inizio flessibile con le funzionalità GKE disponibili. Ti consigliamo di utilizzare le classi di calcolo per definire un elenco con priorità delle configurazioni dei nodi in base ai requisiti del tuo workload. GKE selezionerà la configurazione più adatta in base alla disponibilità e alla priorità che hai definito.

Gestire le interruzioni nei carichi di lavoro che utilizzano Dynamic Workload Scheduler

I carichi di lavoro che richiedono la disponibilità di tutti i nodi o della maggior parte dei nodi in un pool di nodi sono sensibili agli sfollamenti. Inoltre, i nodi di cui viene eseguito il provisioning utilizzando le richieste di pianificatore dei carichi di lavoro dinamici non supportano la riparazione automatica. La riparazione automatica rimuove tutti i carichi di lavoro da un nodo e ne impedisce l'esecuzione.

Tutti i nodi che utilizzano l'avvio flessibile, il provisioning in coda o entrambi utilizzano upgrade di breve durata quando il control plane del cluster esegue la versione minima per l'avvio flessibile, 1.32.2-gke.1652000 o successiva.

Gli upgrade di breve durata aggiornano un pool di nodi standard o un gruppo di nodi in un cluster Autopilot senza interrompere i nodi in esecuzione. I nuovi nodi vengono creati con la nuova configurazione, sostituendo gradualmente i nodi esistenti con la vecchia configurazione nel tempo. Le versioni precedenti di GKE, che non supportano gli upgrade con inizio flessibile o di breve durata, richiedono pratiche migliori diverse.

Best practice per ridurre al minimo le interruzioni del workload per i nodi che utilizzano upgrade di breve durata

I nodi con avvio flessibile e i nodi che utilizzano il provisioning in coda sono configurati automaticamente per utilizzare gli upgrade di breve durata quando il cluster esegue la versione 1.32.2-gke.1652000 o successive.

Per ridurre al minimo le interruzioni dei workload in esecuzione su nodi che utilizzano upgrade di breve durata, svolgi le seguenti attività:

• Configura periodi di manutenzione ed esclusioni per impostare quando GKE deve e non deve eseguire operazioni di aggiornamento, ad esempio gli upgrade dei nodi, assicurandoti al contempo che GKE abbia ancora il tempo di eseguire la manutenzione automatica.
• Disattiva la riparazione automatica dei nodi.

Per i nodi dei cluster che eseguono versioni precedenti alla 1.32.2-gke.1652000 e quindi non utilizzano gli upgrade di breve durata, consulta le indicazioni specifiche per questi nodi.

Best practice per ridurre al minimo l'interruzione del carico di lavoro per i nodi di provisioning in coda senza upgrade di breve durata

I nodi che utilizzano il provisioning in coda su un cluster che esegue una versione GKE precedente alla 1.32.2-gke.1652000 non utilizzano gli upgrade di breve durata. I cluster su cui è stato eseguito l'upgrade alla versione 1.32.2-gke.1652000 o successive con nodi di provisioning in coda esistenti vengono aggiornati automaticamente per utilizzare gli upgrade di breve durata.

Per i nodi che eseguono queste versioni precedenti, consulta le seguenti indicazioni:

• A seconda della registrazione al canale di rilascio del tuo cluster, segui le best practice riportate di seguito per evitare che gli upgrade automatici dei nodi interrompano i tuoi carichi di lavoro:
  • Se il tuo cluster è registrato a un canale di rilascio, utilizza le finestre di manutenzione e le esclusioni per impedire a GKE di eseguire automaticamente l'upgrade dei tuoi nodi mentre il tuo workload è in esecuzione.
  • Se il cluster non è registrato in un canale di rilascio, disattiva gli upgrade automatici dei nodi. Tuttavia, ti consigliamo di utilizzare i canali di rilascio, in cui puoi utilizzare le esclusioni di manutenzione con ambiti più granulari.
• Disattiva la riparazione automatica dei nodi.
• Utilizza periodi di manutenzione ed esclusioni per ridurre al minimo le interruzioni dei workload in esecuzione, assicurandoti al contempo che GKE abbia ancora il tempo di eseguire la manutenzione automatica. Assicurati di pianificare l'ora in cui non sono in esecuzione workload.
• Per assicurarti che il pool di nodi rimanga aggiornato, esegui l'upgrade manuale del pool di nodi quando non sono attive richieste di Dynamic Workload Scheduler e il pool di nodi è vuoto.

Considerazioni per la migrazione del cluster agli upgrade di breve durata

GKE aggiorna i nodi esistenti utilizzando il provisioning in coda per utilizzare gli upgrade di breve durata quando viene eseguito l'upgrade del cluster alla versione 1.32.2-gke.1652000 o successiva. GKE non aggiorna altre impostazioni, ad esempio l'abilitazione degli upgrade automatici dei nodi se li hai disattivati per un pool di nodi specifico.

Ora che i tuoi pool di nodi utilizzano gli upgrade di breve durata, ti consigliamo di implementare le seguenti best practice:

• Se hai disattivato gli upgrade automatici dei nodi utilizzando il flag --no-enable-autoupgrade, questa migrazione non li riattiva per il pool di nodi. Ti consigliamo di abilitare gli upgrade automatici dei nodi, poiché gli upgrade di breve durata non interrompono i nodi esistenti e i carichi di lavoro in esecuzione. Per ulteriori informazioni, consulta la sezione Upgrade di breve durata.
• Inoltre, se il tuo cluster non è ancora registrato a un canale di release, ti consigliamo di registrarlo in modo da poter utilizzare ambiti di esclusione per la manutenzione più granulari.

Riciclo dei nodi in avvio flessibile

Per contribuire a garantire una transizione fluida dei nodi e a evitare il downtime dei job in esecuzione, flex-start supporta il riciclo dei nodi. Quando un nodo raggiunge la fine della sua durata, GKE lo sostituisce automaticamente con uno nuovo per preservare i workload in esecuzione.

Per utilizzare il riciclo dei nodi, devi creare un profilo della classe di calcolo personalizzata e includere il campo nodeRecycling nella specifica flexStart con il parametro leadTimeSeconds.

Il parametro leadTimeSeconds consente di bilanciare la disponibilità delle risorse e l'efficienza in termini di costi. Questo parametro specifica quanto in anticipo (in secondi) prima che un node raggiunga la fine della sua durata di sette giorni deve iniziare il processo di provisioning di un nuovo node per sostituirlo. Un tempo di risposta più lungo aumenta la probabilità che il nuovo nodo sia pronto prima che quello vecchio venga rimosso, ma potrebbe comportare costi aggiuntivi.

Il processo di riciclo dei nodi è costituito dai seguenti passaggi:

1. Fase di riciclo: GKE convalida che un node con provisioning flex-start abbia il campo nodeRecycling con il parametro leadTimeSeconds impostato. In questo caso, GKE avvia la fase di riciclo del nodo quando la data corrente è maggiore o uguale alla differenza tra i valori dei seguenti campi:

   • creationTimestamp + maxRunDurationSeconds
   • leadTimeSeconds

   Il flag creationTimeStamp include l'ora in cui è stato creato il nodo. Il campo maxRunDurationSeconds può essere specificato nella classe di calcolo personalizzata e il valore predefinito è sette giorni.

2. Creazione del nodo:inizia il processo di creazione del nuovo nodo, che procede attraverso le fasi di coda e provisioning. La durata della fase di coda può variare dinamicamente in base alla zona e alla capacità dell'acceleratore specifico.

3. Contrassegna come non pianificabile il nodo che sta per terminare la sua durata di sette giorni: dopo l'avvio del nuovo nodo, il vecchio viene contrassegnato come non pianificabile. Questa azione impedisce la programmazione di nuovi pod. I pod esistenti in quel nodo continuano a funzionare.

4. Disattivazione del nodo:il nodo che sta per terminare la sua durata di sette giorni viene disattivato dopo un periodo adeguato, il che contribuisce ad assicurare che i carichi di lavoro in esecuzione siano stati migrati al nuovo nodo.

Il seguente esempio di configurazione di una classe di calcolo include i campi leadTimeSeconds e maxRunDuration:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: dws-model-inference-class
spec:
  priorities:
    - machineType: g2-standard-24
      spot: true
    - machineType: g2-standard-24
      maxRunDurationSeconds: 72000
      flexStart:
        enabled: true
        nodeRecycling:
          leadTimeSeconds: 3600
  nodePoolAutoCreation:
    enabled: true

Per ulteriori informazioni su come utilizzare il riciclo dei nodi, prova il tutorial su come pubblicare modelli LLM su GKE con una strategia di provisioning GPU ottimizzata in termini di costi e ad alta disponibilità.

Limitazioni

• L'anti-affinità tra pod non è supportata. Il gestore della scalabilità automatica dei cluster non prende in considerazione le regole di anti-affinità tra pod durante il provisioning dei nodi, il che potrebbe portare a carichi di lavoro non pianificabili. Questa situazione può verificarsi quando è stato eseguito il provisioning dei nodi per due o più oggetti Dynamic Workload Scheduler nello stesso pool di nodi.
• Sono supportati solo i nodi GPU.
• Le prenotazioni non sono supportate con Dynamic Workload Scheduler. Devi specificare il flag --reservation-affinity=none quando crei il pool di nodi. Dynamic Workload Scheduler richiede e supporta solo il ANY criterio di località per la scalabilità automatica del cluster.
• Una singola richiesta di Dynamic Workload Scheduler può creare fino a 1000 macchine virtuali (VM), ovvero il numero massimo di nodi per zona per un singolo pool di nodi.
• GKE utilizza la quota ACTIVE_RESIZE_REQUESTS di Compute Engine per controllare il numero di richieste di pianificatore dei carichi di lavoro dinamici in attesa in una coda. Per impostazione predefinita, questa quota ha un limite di 100 richieste per Google Cloud progetto. Se provi a creare una richiesta di pianificatore del carico di lavoro dinamico superiore a questa quota, la nuova richiesta non va a buon fine.
• I pool di nodi che utilizzano Dynamic Workload Scheduler sono sensibili alle interruzioni perché il provisioning dei nodi viene eseguito insieme. Per saperne di più, consulta Gestire le interruzioni nei carichi di lavoro che utilizzano Dynamic Workload Scheduler.
• Potresti vedere altre VM di breve durata elencate nella Google Cloud console. Questo comportamento è intenzionale perché Compute Engine potrebbe creare e poi rimuovere rapidamente le VM finché non sarà disponibile la capacità di eseguire il provisioning di tutte le macchine richieste.
• Le VM spot non sono supportate.
• Dynamic Workload Scheduler non supporta i volumi effimeri. Devi utilizzare volumi permanenti per lo spazio di archiviazione. Per selezionare il tipo di archiviazione migliore che utilizza volumi permanenti, consulta la Panoramica dell'archiviazione per i cluster GKE.
• Se il carico di lavoro utilizza il riutilizzo dei nodi ed è disegnato da un job, configura il job con la modalità di completamento impostata su Indexed.

Passaggi successivi

• Seleziona un tipo di GPU
• Esegui il deployment delle GPU con Dynamic Workload Scheduler.