Progettare per l'ottenimento delle risorse su GKE con Gemini

Questo documento spiega come progettare cluster Google Kubernetes Engine (GKE) resilienti e strategie di pianificazione dei workload che ti aiutano a ottenere risorse, come GPU, TPU e CPU ad alte prestazioni. Sfruttando Gemini in Google Cloud e Compute Advisor (anteprima), puoi impedire i pod in attesa e migliorare la pianificazione affidabile per i workload di AI.

Questo documento è destinato agli architetti cloud, agli amministratori e agli operatori di piattaforme che gestiscono l'infrastruttura GKE e vogliono ottimizzare la pianificazione e la programmazione della capacità.

Panoramica della disponibilità delle risorse su GKE

La pianificazione di Kubernetes si basa sulle richieste di risorse dichiarate. Quando pianifichi acceleratori su larga scala, come GPU o TPU, le richieste di risorse rigorose possono impedire ai cluster di fare lo scale up se hardware specifici non sono disponibili. Puoi ottimizzare la disponibilità della capacità su GKE utilizzando le seguenti funzionalità:

  • Creazione automatica dei node pool: creazione di pool di nodi dinamici e multi-famiglia.
  • Fallback a livello di workload: tolleranze e selettori di nodi configurati per accettare hardware alternativo.
  • Pianificazione geografica e regionale: funzionalità multi-zona e multi-regione di GKE.
  • Gestione delle prenotazioni: utilizzo della capacità pre-acquistata prima di richiedere risorse on demand.

Best practice per la disponibilità delle risorse su GKE

Questa sezione fornisce suggerimenti per aumentare la disponibilità della capacità durante la pianificazione dei workload su GKE. Queste best practice riguardano strategie come la progettazione di requisiti hardware flessibili, la configurazione della creazione automatica dei node pool e l'utilizzo della distribuzione geografica per adattarsi ai vincoli delle risorse. La creazione automatica dei node pool gestisce automaticamente i node pool in base alle specifiche dei pod. Anziché predefinire i node pool, specifica i requisiti delle risorse nei manifest dei pod e lascia che GKE crei dinamicamente i nodi.

Puoi anche scoprire e implementare le seguenti best practice utilizzando Compute Advisor. Per saperne di più, consulta Utilizzare Compute Advisor.

Opzioni di flessibilità hardware

Per ottimizzare la disponibilità della capacità, puoi indicare a GKE di evitare di associare i workload a una singola famiglia di macchine statiche o a un tipo di acceleratore. Di seguito sono riportati alcuni esempi di come configurare node pool flessibili e regole di affinità dei pod per diverse classi di workload. Le alternative specifiche che scegli dipendono dalle richieste di risorse della tua applicazione:

  • Node pool CPU per uso generico:

    • Esempio principale: N2 (per uso generico basato su Intel).
    • Alternative di esempio: N2D (AMD EPYC), C2 o C2D (ottimizzato per il calcolo) o E2 (ottimizzato per i costi).
    • Pattern di implementazione: configura le specifiche dei pod con affinità dei nodi o tolleranze che consentono la pianificazione su più etichette di famiglie di macchine, ad esempio cloud.google.com/machine-family in ["n2", "n2d", "c2d"]. Questa configurazione consente a GKE di eseguire il provisioning del pool con capacità disponibile.

  • Node pool GPU:

    • Esempio principale: serie A2 (GPU NVIDIA A100).
    • Alternative di esempio: L4 (AI/ML universale) o T4 (inferenza).
    • Pattern di implementazione: configura node pool o ComputeClass separati per diversi livelli di GPU. Per i workload che possono essere eseguiti senza funzionalità specifiche di A100, consenti ai pod di eseguire il fallback ai pool L4 o T4 se il provisioning di A2 è limitato.

  • Node pool TPU:

    • Esempio principale: TPU Ironwood (TPU7x).
    • Alternative di esempio: TPU v6 (Trillium) o TPU v5 (v5e o v5p).
    • Pattern di implementazione: il provisioning degli slice TPU può essere molto limitato. Progetta workload di addestramento con flessibilità a livello di framework (ad esempio, configurazioni JAX o PyTorch che supportano topologie di slice variabili) per il deployment su slice v6 o v5 quando la capacità di TPU Ironwood (TPU7x) non è disponibile.

La tabella seguente riassume le selezioni principali e le alternative hardware per diversi tipi di workload:

Tipo di workload Esempio di selezione principale Alternative di esempio Considerazioni sull'architettura
Workload di sistema o core N2 N2D, C2D, E2 Si estende ai pool hardware Intel e AMD per la creazione automatica dei pool di nodi.
Inferenza ed elaborazione GPU A2 (A100) L4, T4 Target flessibile per node pool GPU a costi inferiori o con maggiore disponibilità.
Addestramento del modello TPU TPU Ironwood (TPU7x) TPU v6, TPU v5 (v5e o v5p) Utilizza topologie flessibili per la pianificazione basata su slice.

Implementare la creazione automatica pool di nodi e ComputeClass

Per ottimizzare la disponibilità della capacità, combina la creazione automatica pool di nodi con ComputeClasses. Il seguente elenco include le best practice:

  • Definisci ComputeClass: crea risorse ComputeClass che specificano un elenco prioritario di famiglie di macchine, tipi di GPU o modelli di provisioning. GKE tenta di eseguire il provisioning dei nodi utilizzando la configurazione con la priorità più alta disponibile nella classe. Un elenco di fallback con priorità ti aiuta in modo significativo a ottenere le risorse richieste dai tuoi workload. Ad esempio, per impedire a GKE di eseguire il fallback alle macchine per uso generico quando un acceleratore specializzato preferito non è disponibile, aggiungi l'impostazione whenUnsatisfiable: DoNotScaleUp alla configurazione di ComputeClass. Per saperne di più, consulta Controllare gli attributi dei nodi con scalabilità automatica con ComputeClass personalizzate.

  • Fai riferimento a ComputeClass nelle specifiche dei pod: nelle specifiche dei pod del workload, utilizza l'etichetta cloud.google.com/compute-class per scegliere come target la ComputeClass personalizzata anziché una famiglia di macchine o un tipo di GPU specifico. Per saperne di più, consulta Richiedere una ComputeClass in un workload.

  • Definisci più tolleranze: se non utilizzi ComputeClass, utilizza le regole di affinità dei nodi nelle specifiche dei pod che consentono una serie di famiglie di macchine (ad esempio, cloud.google.com/machine-family in ["n2", "n2d"]). Per saperne di più, consulta Configurare la creazione automatica dei node pool.

Flessibilità geografica e multi-regione su GKE

Per aumentare la disponibilità della capacità, esegui il deployment di cluster GKE che si estendono su più zone o esegui architetture multi-cluster:

  • Cluster multi-zona: assicurati che i node pool siano configurati per la scalabilità automatica in tutte le zone disponibili in una regione.

  • Federazione di cluster multi-regione: per job asincroni di grandi dimensioni (come l'inferenza batch offline o l'addestramento distribuito), esegui il deployment di un orchestratore multi-cluster (come Kueue o Cluster Director) per mettere in coda i workload a livello globale e inviarli a una regione con capacità disponibile.

  • Pod in esecuzione su VM spot: esegui workload interrompibili su VM spot aggiungendo tolleranze e indicando a GKE di distribuire la capacità in eccesso in zone diverse.

Best practice aggiuntive per la disponibilità di GKE

Oltre alla diversificazione dell'hardware, incorpora queste best practice di GKE per ottimizzare la scalabilità dei cluster:

  • Implementa il provisioning eccessivo dei pod (buffer di capacità): esegui il deployment di pod "pausa" a bassa priorità che riservano in anticipo la capacità dei nodi. Quando vengono inviati workload di AI ad alta priorità e la capacità regionale è limitata, Kubernetes esegue immediatamente il preemption dei pod di pausa, consentendo l'avvio dei container senza attendere il provisioning di nuovi nodi. Per saperne di più, consulta Informazioni sui buffer di capacità.
  • Utilizza l'avvio flessibile con provisioning in coda: per job di addestramento di modelli AI e batch di grandi dimensioni, utilizza l'avvio flessibile con provisioning in coda, che si integra con Kueue e Dynamic Workload Scheduler. L'avvio flessibile con provisioning in coda esegue l'allocazione atomica dei nodi all-or-nothing, il che impedisce errori di scalabilità parziale dei cluster. Per saperne di più, consulta Eseguire un workload su larga scala con l'avvio flessibile con provisioning in coda.
  • Abilita lo streaming di immagini e il precaricamento delle immagini container: per le immagini container AI di grandi dimensioni (ad esempio, immagini PyTorch o TensorFlow superiori a 10 GB), abilita lo streaming di immagini GKE o utilizza dischi di avvio secondari per il precaricamento delle immagini. Questa configurazione riduce il tempo di riscaldamento dei nodi, consentendo ai nodi di cui è stato appena eseguito il provisioning di iniziare a eseguire i workload in pochi secondi. Per saperne di più, consulta Utilizzare lo streaming di immagini per eseguire il pull delle immagini container e Utilizzare i dischi di avvio secondari per precaricare dati o immagini container.
  • Imposta la policy di località del gestore della scalabilità automatica del cluster su ANY: configura i node pool (soprattutto per le VM spot o l'avvio flessibile) con la ANY policy di località. Questa impostazione indica al gestore della scalabilità automatica del cluster di cercare la capacità richiesta in tutte le zone specificate. Il gestore della scalabilità automatica del cluster trova la capacità bilanciando il numero di nodi. Per saperne di più, consulta Panoramica del gestore della scalabilità automatica del cluster.
  • Ottimizza l'utilizzo degli acceleratori con la condivisione della GPU: per i workload che non richiedono una GPU dedicata, utilizza la condivisione del tempo della GPU, le GPU multi-istanza (MIG) o NVIDIA MPS per consentire a più container di condividere un singolo acceleratore. Questo approccio ottimizza la capacità effettiva nei node pool. Per saperne di più, consulta Informazioni sulle strategie di condivisione della GPU in GKE.

Utilizzare Compute Advisor

Compute Advisor è un'interfaccia basata sull'AI nella Google Cloud console, basata su Gemini, che ti aiuta a progettare architetture resilienti per GKE. Compute Advisor fornisce indicazioni sulla disponibilità delle VM con avvio flessibile e delle VM spot in tempo quasi reale, verificando al contempo le policy dell'organizzazione e le quote delle risorse prima del deployment. Compute Advisor non fornisce indicazioni sulla disponibilità per i workload che richiedono risorse on demand.

Per accedere a Gemini nella Google Cloud console, completa i seguenti passaggi:

  1. Nella Google Cloud console, vai alla pagina Panoramica.

    Vai alla panoramica

  2. Nella sezione Progetta la tua infrastruttura con Compute Advisor, invia un prompt. Gemini inizia a generare una risposta.

  3. Per generare consigli sull'architettura, esegui uno dei seguenti prompt di esempio in Compute Advisor. Quando fai clic sui pulsanti Esegui prompt in Compute Advisor, il caricamento della Google Cloud console potrebbe richiedere più di 15 secondi:

    • Strategia generale per gli acceleratori:

      Caso d'uso: utilizza questo prompt per analizzare gli indicatori di capacità regionali e ricevere consigli su tipi di macchine, zone e strategie di pianificazione di fallback durante la progettazione delle configurazioni dei cluster.

      Configure a GKE cluster to improve chances of obtaining scarce GPU or TPU capacity.

      Esegui prompt in Compute Advisor

    • Flessibilità geografica e fallback:

      Caso d'uso: utilizza questo prompt quando progetti architetture multi-cluster o sistemi di accodamento dei job globali (ad esempio, con Kueue) per spostare l'esecuzione dei workload tra le regioni a seconda della disponibilità delle risorse.

      Configure multi-region fallbacks and geographic scheduling on GKE to increase GPU availability.

      Esegui prompt in Compute Advisor

    • Consumo delle prenotazioni con priorità:

      Caso d'uso: utilizza questo prompt per generare pattern di configurazione YAML per le regole di affinità dei pod e di scalabilità automatica che danno la priorità alla capacità di prenotazione.

      Configure GKE autoscaling rules and Pod specs to prioritize consuming active reservations before scaling into on-demand pools.

      Esegui prompt in Compute Advisor

    • ComputeClass per la definizione delle priorità di fallback:

      Caso d'uso: utilizza questo prompt per generare il manifest YAML per una definizione di risorsa personalizzata ComputeClass che dà la priorità alle GPU ad alte prestazioni, ma include fallback di livello inferiore per garantire la pianificazione dei workload.

      Define a ComputeClass manifest for GKE to prioritize A2 GPU nodes with automatic fallbacks to L4 or T4 GPUs.

      Esegui prompt in Compute Advisor

    • Creazione automatica dei node pool per la diversificazione:

      Caso d'uso: utilizza questo prompt per scrivere il manifest YAML per i limiti delle risorse del gestore della scalabilità automatica del cluster GKE e le regole di affinità dei pod che consentono a NAP di eseguire automaticamente il provisioning di nodi GPU o CPU alternativi.

      Configure GKE node pool auto-creation to diversify machine families and prevent pending pods when regional accelerator capacity is constrained.

      Esegui prompt in Compute Advisor

Passaggi successivi