Informazioni sull'allocazione dinamica delle risorse in GKE

Questa pagina fornisce informazioni sull'allocazione dinamica delle risorse (DRA) in Google Kubernetes Engine (GKE). In questa pagina, scopri le nozioni di base di DRA, come funziona in GKE e i vantaggi dell'utilizzo di DRA per allocare hardware come GPU e TPU.

Questa pagina è destinata ai seguenti ruoli:

Prima di leggere questa pagina, assicurati di conoscere le seguenti risorse:

Introduzione a DRA

DRA è una funzionalità integrata di Kubernetes che ti consente di richiedere, allocare e condividere in modo flessibile l'hardware nel tuo cluster tra pod e container. DRA migliora l'esperienza di allocazione dell'hardware collegato, come gli acceleratori, consentendo ai fornitori di dispositivi e agli amministratori della piattaforma di dichiarare classi di dispositivi che possono essere richiesti e allocati. Gli operatori delle app possono richiedere configurazioni specifiche dei dispositivi all'interno di queste classi e poi richiedere queste configurazioni nei loro carichi di lavoro. Kubernetes e GKE gestiscono la pianificazione dei pod, le assegnazioni dei nodi e l'allocazione dei dispositivi in base alle richieste dei carichi di lavoro.

Ad esempio, un amministratore della piattaforma potrebbe definire una classe di dispositivi che dispongono solo di GPU NVIDIA A100. Gli operatori delle app possono quindi filtrare i dispositivi in quella classe di dispositivi in base ai requisiti del carico di lavoro, ad esempio filtrando per un minimo di 80 GB di memoria GPU. Quando l'operatore dell'app esegue il deployment di un carico di lavoro che richiede la configurazione filtrata, GKE posiziona i pod sui nodi che soddisfano i criteri selezionati. In questo esempio, GKE trova i nodi che hanno GPU A100 (80 GB) disponibili. L'operatore dell'app non deve selezionare nodi o configurazioni di dispositivi specifici nel manifest del carico di lavoro.

Vantaggi di DRA

Senza DRA, l'allocazione di dispositivi hardware in Kubernetes si basa sui plug-in del dispositivo. Per collegare risorse hardware ai pod utilizzando i plug-in del dispositivo, utilizzi le etichette dei nodi per posizionare i pod su nodi specifici. Inoltre, per dedicare le risorse di un intero nodo a un singolo pod, devi richiedere il numero esatto di dispositivi collegati ai nodi.

Con DRA, l'esperienza di assegnazione dei dispositivi ai pod è simile all'assegnazione dei volumi per l'archiviazione. Definisci le classi di dispositivi, richiedi i dispositivi all'interno di queste classi e poi assegna i dispositivi richiesti ai carichi di lavoro. DRA offre una superficie molto più estensibile per filtrare i dispositivi in base al carico di lavoro e alle esigenze aziendali. L'approccio DRA di utilizzo di espressioni e modelli per rivendicare l'hardware e pianificare i pod presenta i seguenti vantaggi:

  • Allocazione dichiarativa dei dispositivi: gli amministratori della piattaforma possono definire configurazioni dei dispositivi per tipi specifici di carichi di lavoro o team.
  • Complessità ridotta tra i team: quando gli amministratori della piattaforma eseguono il provisioning di nodi con configurazioni hardware specializzate, gli operatori delle app non devono sapere quali nodi hanno configurazioni specifiche. Gli amministratori della piattaforma non devono etichettare i nodi o comunicare informazioni su nodi e dispositivi specifici agli operatori.
  • Complessità ridotta per gli sviluppatori: Kubernetes pianifica i pod in base alla configurazione del dispositivo a cui viene fatto riferimento. Gli operatori delle app non devono selezionare nodi specifici nei loro carichi di lavoro e non devono assicurarsi che ogni pod richieda esattamente il numero di dispositivi collegati a questi nodi.
  • Gestione centralizzata dell'infrastruttura: gli amministratori della piattaforma possono definire centralmente configurazioni hardware che soddisfano requisiti aziendali specifici. Ad esempio, un amministratore della piattaforma potrebbe dichiarare una configurazione ad alte prestazioni con GPU H100 insieme a una piccola configurazione di inferenza con GPU Tesla T4.
  • Selezione flessibile dell'hardware: DRA ti consente di utilizzare le espressioni CEL per filtrare i dispositivi con attributi specifici. L'utilizzo di espressioni offre la flessibilità di filtrare i dispositivi ottimali per carichi di lavoro specifici.

Quando utilizzare DRA

Durante l'anteprima, il motivo principale per utilizzare DRA in GKE è la flessibilità con cui puoi richiedere dispositivi per i carichi di lavoro. Puoi scrivere un manifest una sola volta e distribuire il carico di lavoro a cluster diversi con tipi di dispositivi diversi senza dover modificare il manifest. Questa flessibilità è ideale per casi d'uso come i seguenti:

  • Migliora la disponibilità delle GPU: per i workload che richiedono l'accesso all'hardware GPU, puoi utilizzare DRA per richiedere qualsiasi GPU disponibile nel cluster anziché dover specificare un modello di GPU. Se questi carichi di lavoro hanno requisiti specifici di memoria GPU (VRAM), puoi richiedere qualsiasi GPU nel cluster che abbia una quantità minima di memoria. Questo tipo di richiesta flessibile espande l'insieme di nodi GPU su cui può essere eseguito un workload, il che riduce il rischio che il workload non venga pianificato a causa di risorse non disponibili.
  • Ottimizza la disponibilità dei nodi GPU durante lo scaling: il numero di GPU collegate richieste da un carico di lavoro potrebbe variare a seconda del tipo di GPU. Puoi utilizzare una classe di calcolo GKE per eseguire il provisioning dei nodi in base alla disponibilità, alla quota o alle prenotazioni di capacità della GPU. Puoi quindi utilizzare DRA nei tuoi carichi di lavoro per configurare i pod in modo che vengano eseguiti su qualsiasi nodo che GKE esegue il provisioning per la classe di calcolo. L'utilizzo di DRA con le classi di calcolo consente di ridurre al minimo il rischio di carichi di lavoro non pianificati, garantendo al contempo che i carichi di lavoro vengano eseguiti su hardware ottimizzato.

Terminologia

Kubernetes open source e i provider Kubernetes gestiti come GKE utilizzano i seguenti termini DRA:

ResourceSlice
Un ResourceSlice elenca uno o più dispositivi hardware nel cluster a cui i nodi possono accedere. Ad esempio, in un nodo che può accedere a una singola GPU, ResourceSlice elenca la GPU e il nome del nodo. I driver del dispositivo DRA su ogni nodo creano ResourceSlice. Lo scheduler Kubernetes utilizza ResourceSlice per decidere quali dispositivi allocare per soddisfare le richieste dei carichi di lavoro.
DeviceClass
Una DeviceClass definisce una categoria di dispositivi, ad esempio le GPU, disponibili per le richieste per i carichi di lavoro. Alcuni driver di dispositivo forniscono DeviceClass integrate, ad esempio gpu.nvidia.com DeviceClass per le GPU NVIDIA. Gli amministratori della piattaforma possono anche creare DeviceClass personalizzate che definiscono configurazioni specifiche dei dispositivi.
ResourceClaim

Una ResourceClaim consente a un pod o a un utente di richiedere risorse hardware filtrando determinati parametri all'interno di una DeviceClass. Quando un carico di lavoro fa riferimento a una ResourceClaim, Kubernetes assegna a questa ResourceClaim i dispositivi che corrispondono ai parametri specificati.

Ad esempio, considera uno scenario in cui crei un ResourceClaim per una GPU A100 (40 GB) e poi esegui il deployment di un workload che seleziona questo ResourceClaim. Kubernetes assegna una GPU A100 (40 GB) disponibile a ResourceClaim e pianifica il pod su un nodo in grado di accedere a questa GPU.

ResourceClaimTemplate

Un ResourceClaimTemplate definisce un modello che i pod possono utilizzare per creare automaticamente nuovi ResourceClaim per pod. I ResourceClaimTemplates sono utili quando hai più carichi di lavoro che devono accedere a configurazioni di dispositivi simili, soprattutto quando utilizzi un controller del carico di lavoro come Deployment o StatefulSet.

Gli operatori delle app eseguono il deployment di ResourceClaimTemplates e poi fanno riferimento ai modelli nei workload. Kubernetes crea ResourceClaim per ogni pod in base al modello specificato, alloca i dispositivi e pianifica i pod. Quando i pod terminano, Kubernetes pulisce i ResourceClaim corrispondenti.

Come funziona DRA

L'utilizzo di DRA nei cluster e nei carichi di lavoro è simile all'utilizzo di StorageClass, PersistentVolumeClaim e PersistentVolume per eseguire il provisioning dinamico dei volumi per i pod.

Il seguente diagramma mostra i passaggi che gli amministratori del cluster e gli operatori delle app eseguono per allocare i dispositivi utilizzando DRA:

In questo diagramma, gli amministratori del cluster e gli operatori delle app:

  1. Gli amministratori del cluster installano i driver del dispositivo che supportano DRA nei nodi.
  2. Gli amministratori del cluster creano DeviceClass che filtrano l'hardware che soddisfa requisiti specifici, ad esempio tutte le GPU con più di 40 GB di memoria. Alcuni dispositivi potrebbero includere anche DeviceClasses integrati.
  3. Gli operatori delle applicazioni creano ResourceClaimTemplates o ResourceClaims che richiedono configurazioni del dispositivo. Il caso d'uso principale per ogni tipo di rivendicazione è il seguente:
    • Una ResourceClaim consente a più pod di condividere l'accesso allo stesso dispositivo.
    • Un ResourceClaimTemplate consente a più pod di accedere a dispositivi simili separati generando automaticamente ResourceClaim per pod.
  4. Gli operatori delle applicazioni aggiungono ResourceClaimTemplates o ResourceClaims ai manifest dei workload.
  5. Gli operatori dell'applicazione eseguono il deployment del carico di lavoro.

Quando esegui il deployment di un carico di lavoro che fa riferimento a un ResourceClaimTemplate o a un ResourceClaim, Kubernetes esegue i seguenti passaggi di pianificazione:

  1. Se il carico di lavoro fa riferimento a un ResourceClaimTemplate, Kubernetes crea un nuovo oggetto ResourceClaim per ogni istanza del carico di lavoro (ad esempio ogni replica in un deployment).
  2. Lo scheduler Kubernetes utilizza ResourceSlice nel cluster per allocare i dispositivi disponibili e idonei a ResourceClaim di ogni pod.
  3. Lo scheduler posiziona ogni pod su un nodo che ha accesso ai dispositivi allocati a ResourceClaim del pod.
  4. Kubelet sul nodo di destinazione chiama il driver DRA on-node per collegare l'hardware allocato al pod per soddisfare la richiesta di risorse.

Quando utilizzare ResourceClaim e ResourceClaimTemplate

ResourceClaim e ResourceClaimTemplates consentono di indicare a Kubernetes che vuoi dispositivi che soddisfino requisiti specifici. Quando viene fatto riferimento a una ResourceClaim in un pod, Kubernetes alloca i dispositivi alla risorsa API ResourceClaim corrispondente nel server API Kubernetes. Questa allocazione avviene indipendentemente dal fatto che tu abbia creato ResourceClaim o che Kubernetes abbia creato ResourceClaim da un ResourceClaimTemplate.

Se crei una ResourceClaim e poi la fai riferimento in più pod, tutti questi pod possono accedere ai dispositivi che Kubernetes alloca per quella ResourceClaim. Ad esempio, questo accesso condiviso potrebbe verificarsi se fai riferimento a un ResourceClaim specifico in un manifest di Deployment con più repliche. Tuttavia, se i dispositivi allocati non sono configurati per essere condivisi da più processi, questo accesso condiviso ai dispositivi tra i pod potrebbe comportare un comportamento imprevisto.

Un ResourceClaimTemplate consente di definire i modelli che Kubernetes utilizza per creare automaticamente singoli ResourceClaim per i pod. Ad esempio, se fai riferimento a un ResourceClaimTemplate in un deployment con più repliche, Kubernetes crea un ResourceClaim separato per ogni pod replicato. Di conseguenza, ogni pod riceve il proprio dispositivo allocato anziché condividere l'accesso al dispositivo con altri pod. Questi ResourceClaim generati automaticamente sono associati alla durata del pod corrispondente e vengono eliminati quando il pod termina. Se hai pod indipendenti che devono accedere a configurazioni di dispositivi simili, utilizza un ResourceClaimTemplate per allocare i dispositivi a ciascun pod separatamente.

La tabella seguente descrive alcune differenze tra la creazione manuale di ResourceClaim e la creazione di ResourceClaim da parte di Kubernetes da un ResourceClaimTemplate:

ResourceClaim create manualmente ResourceClaim creati automaticamente
Gestito da te Gestiti da Kubernetes
Fornisce l'accesso agli stessi dispositivi da più pod Fornisce l'accesso ai dispositivi da un singolo pod
Esiste nel cluster indipendentemente dai pod Vincolato al ciclo di vita del pod corrispondente
Ideale per più carichi di lavoro che devono condividere un dispositivo specifico Ideale per più workload che richiedono l'accesso indipendente ai dispositivi

Confronto tra DRA e allocazione manuale dei dispositivi

DRA rende l'allocazione dei dispositivi collegati un'esperienza simile al provisioning dinamico di PersistentVolumes. Kubernetes supporta anche l'allocazione dei dispositivi tramite l'utilizzo di plug-in per dispositivi. Questo metodo prevede i seguenti passaggi:

  1. Un amministratore del cluster crea nodi con dispositivi collegati, come le GPU.
  2. L'amministratore del cluster comunica agli operatori dei carichi di lavoro informazioni su nodi specifici e sui dispositivi collegati.
  3. Un operatore del workload richiede i dispositivi nel manifest del workload nel seguente modo:
    • Seleziona un nodo con la configurazione del dispositivo richiesta, ad esempio il modello di GPU o il tipo e la topologia di TPU, utilizzando un campo nodeSelector.
    • Specifica il numero esatto di dispositivi che i container devono utilizzare utilizzando il campo resources nella specifica del pod.

Questo metodo di allocazione manuale richiede che gli operatori dell'applicazione e gli amministratori del cluster comunichino quali nodi o pool di nodi specifici hanno determinate configurazioni dei dispositivi. Devono coordinare le richieste di workload in modo che corrispondano ai dispositivi sui nodi, altrimenti il deployment non va a buon fine. Al contrario, DRA ti consente di utilizzare espressioni per filtrare in modo flessibile i dispositivi in base agli attributi e non richiede agli operatori dei carichi di lavoro di conoscere la configurazione esatta dei nodi nel cluster.

La seguente tabella confronta DRA con i plug-in del dispositivo:

DRA Allocazione manuale
Selezione flessibile dei dispositivi utilizzando le espressioni CEL Selezione di nodi specifici utilizzando selettori e richieste di risorse
Decisioni di pianificazione prese da Kubernetes Decisioni di pianificazione prese dall'operatore utilizzando i selettori di nodi
Il filtro dei dispositivi è separato dalla creazione del workload Il filtro dei dispositivi deve essere eseguito nel manifest del carico di lavoro
Filtro dei dispositivi centralizzato e classi basate sulle esigenze, gestite dagli amministratori della piattaforma Filtro dei dispositivi isolati per operatori di applicazioni
Gli operatori delle app non devono conoscere la capacità dei nodi, le informazioni sulle etichette dei nodi o i modelli di dispositivi collegati per ogni nodo Gli operatori dell'app devono sapere quali nodi hanno modelli e quantità specifici di determinati dispositivi collegati.

Dispositivi GKE supportati per DRA

Puoi utilizzare DRA per allocare GPU o TPU ai carichi di lavoro GKE. Puoi allocare uno qualsiasi dei modelli di GPU e TPU supportati da GKE. Per informazioni dettagliate sulle GPU e sulle TPU supportate da GKE, consulta le seguenti risorse:

Limitazioni di DRA in GKE

DRA presenta le seguenti limitazioni nei cluster GKE:

  • Non puoi utilizzare DRA con il provisioning automatico dei nodi.
  • Non puoi utilizzare DRA con le seguenti funzionalità di condivisione della GPU:
    • GPU in time-sharing.
    • GPU multi-istanza.
    • Servizio multi-processo (MPS).
  • Non puoi utilizzare DRA nei cluster Autopilot.
  • Devi utilizzare GKE 1.32.1-gke.1489001 o versioni successive.

Questa sezione fornisce consigli per gli amministratori della piattaforma o gli operatori di app che vogliono utilizzare DRA per allocare dispositivi ai carichi di lavoro. DRA modifica in modo significativo il metodo con cui richiedi i dispositivi collegati, sia in GKE sia in Kubernetes. Per usufruire di casi d'uso più avanzati, come il fallback cross-device o il filtraggio e la selezione dei dispositivi granulari, considera le seguenti indicazioni:

Migliorare la disponibilità dei nodi durante lo scaling

ComputeClasses in GKE ti consente di definire il comportamento di fallback basato sulla priorità che GKE segue quando crea nuovi nodi nei cluster. Puoi utilizzare ComputeClasses per configurare una serie di configurazioni di nodi e dispositivi con priorità che GKE utilizza quando crea nodi per eseguire i carichi di lavoro. Puoi quindi utilizzare DRA per assicurarti che il tuo workload possa essere eseguito su qualsiasi nodo all'interno di ComputeClass senza dover selezionare manualmente i nodi in base all'etichetta.

Ad esempio, un workload potrebbe richiedere due GPU NVIDIA L4 o una GPU NVIDIA A100 (40 GB) per essere eseguito in modo ottimale. Potresti creare una ComputeClass che assegna la priorità alla creazione di nodi con una GPU A100 (40 GB), ma può ripiegare sulla creazione di nodi con due GPU L4 per nodo. Potresti quindi utilizzare DRA per richiedere qualsiasi GPU disponibile per il tuo carico di lavoro. Quando esegui il deployment del carico di lavoro e selezioni ComputeClass, GKE crea nodi con una delle configurazioni GPU specificate. Con DRA, GKE può posizionare il workload sul primo nodo disponibile, indipendentemente dal modello di GPU, dall'etichetta del nodo o dal numero di GPU.

Per saperne di più, consulta le seguenti pagine:

Passaggi successivi