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 scoprirai i concetti di base della DRA, il suo funzionamento in GKE e i vantaggi dell'utilizzo della DRA per allocare hardware come GPU e TPU.

Questa pagina è rivolta ai seguenti ruoli:

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

Introduzione alla DRA

DRA è una funzionalità di Kubernetes integrata che ti consente di richiedere, allocare e condividere in modo flessibile l'hardware nel tuo cluster tra pod e container. La 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 di app possono richiedere configurazioni specifiche dei dispositivi all'interno di questi gruppi e poi richiederle nei loro carichi di lavoro. Kubernetes e GKE gestiscono la programmazione 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 con solo GPU NVIDIA A100. Gli operatori di app possono quindi filtrare i dispositivi di quella classe 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 con GPU A100 (80 GB) disponibili. L'operatore dell'app non deve selezionare nodi o configurazioni di dispositivi specifici nel file manifest del carico di lavoro.

Vantaggi della DRA

Senza DRA, l'allocazione dei dispositivi hardware in Kubernetes si basa su plug-in dei dispositivi. Per collegare le risorse hardware ai pod utilizzando i plug-in dei dispositivi, 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, richiedi il numero esatto di dispositivi collegati ai nodi.

Con DRA, l'esperienza di allocazione dei dispositivi ai pod è simile all'allocazione di volumi per lo spazio di archiviazione. Definisci classi di dispositivi, richiedi dispositivi all'interno di queste classi e poi assegnali ai carichi di lavoro. DRA fornisce una piattaforma molto più estensibile per filtrare i dispositivi in base al carico di lavoro e alle esigenze aziendali. L'approccio DRA che utilizza espressioni e modelli per rivendicare hardware e pianificare i pod presenta i seguenti vantaggi:

  • Allocazione dei dispositivi dichiarativa: gli amministratori della piattaforma possono definire le configurazioni dei dispositivi per tipi specifici di carichi di lavoro o team.
  • Riduzione della complessità 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 agli operatori informazioni su nodi e dispositivi specifici.
  • Complessità ridotta per gli sviluppatori: Kubernetes pianifica i pod in base alla configurazione del dispositivo a cui si fa riferimento. Gli operatori di 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 dell'infrastruttura centralizzata: gli amministratori della piattaforma possono definire centralmente le 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: la funzionalità DRA ti consente di utilizzare espressioni CEL per filtrare i dispositivi in base ad 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 volta ed eseguire il deployment del carico di lavoro su 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 carichi di lavoro che richiedono l'accesso all'hardware GPU, puoi utilizzare DRA per richiedere qualsiasi GPU disponibile nel cluster invece di dover specificare un modello di GPU. Se questi carichi di lavoro hanno requisiti specifici per la memoria GPU (VRAM), puoi richiedere qualsiasi GPU del cluster con una quantità minima di memoria. Questo tipo di richiesta flessibile espande l'insieme di nodi GPU su cui può essere eseguito un carico di lavoro, il che riduce il rischio che il carico di lavoro non venga pianificato a causa di risorse non disponibili.
  • Ottimizza la disponibilità dei nodi GPU durante la scalabilità: il numero di GPU collegate richieste da un carico di lavoro può variare in base al tipo di GPU. Puoi utilizzare una classe di calcolo GKE per eseguire il provisioning dei nodi in base alla disponibilità delle GPU, alle quote o alle prenotazioni della capacità. Puoi quindi utilizzare DRA nei tuoi carichi di lavoro per configurare i pod in modo che vengano eseguiti su qualsiasi nodo di cui 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

I provider Kubernetes open source e 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 dei dispositivi DRA su ogni nodo creano ResourceSlice. Lo scheduler di Kubernetes utilizza ResourceSlices per decidere quali dispositivi allocare per soddisfare le richieste di carico di lavoro.
DeviceClass
Un DeviceClass definisce una categoria di dispositivi, come le GPU, che è possibile richiedere per i carichi di lavoro. Alcuni driver del dispositivo forniscono DeviceClass integrati, ad esempio gpu.nvidia.com DeviceClass per le GPU NVIDIA. Gli amministratori della piattaforma possono anche creare classi Device personalizzate che definiscono configurazioni specifiche dei dispositivi.
ResourceClaim

Una richiesta di risorse consente a un pod o a un utente di richiedere risorse hardware filtrando in base a determinati parametri all'interno di una classe di dispositivi. Quando un carico di lavoro fa riferimento a una richiesta di risorse, Kubernetes assegna a questa richiesta i dispositivi corrispondenti ai parametri specificati.

Ad esempio, considera uno scenario in cui crei una rivendicazione di risorse per una GPU A100 (40 GB) e poi esegui il deployment di un workload che seleziona questa rivendicazione di risorse. Kubernetes assegna una GPU A100 (40 GB) disponibile al ResourceClaim e pianifica il pod su un nodo che può accedere alla 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, in particolare quando utilizzi un controller dei carichi di lavoro come Deployment o StatefulSets.

Gli operatori di 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 ripulisce le rivendicazioni di risorse corrispondenti.

Come funziona la DRA

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

Il seguente diagramma mostra i passaggi eseguiti dagli amministratori del cluster e dagli operatori di app per allocare i dispositivi utilizzando la DRA:

In questo diagramma, gli amministratori del cluster e gli operatori delle app eseguono le seguenti operazioni:

  1. Gli amministratori del cluster installano i driver di dispositivo che supportano la DRA nei nodi.
  2. Gli amministratori del cluster creano classi di dispositivi che filtrano l'hardware in base a 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 rivendicazione di risorse consente a più pod di condividere l'accesso allo stesso dispositivo.
    • Un ResourceClaimTemplate consente a più pod di accedere a dispositivi simili e distinti generando automaticamente ResourceClaim per pod.
  4. Gli operatori delle applicazioni aggiungono ResourceClaimTemplates o ResourceClaim ai manifest dei loro workload.
  5. Gli operatori delle applicazioni 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 le risorse nel cluster per allocare i dispositivi idonei disponibili alla richiesta di risorse di ciascun pod.
  3. Lo scheduler posiziona ogni pod su un nodo che ha accesso ai dispositivi assegnati alla richiesta di risorse del pod.
  4. Il kubelet sul nodo di destinazione chiama il driver DRA on-node per collegare l'hardware allocato al pod in modo da soddisfare la relativa richiesta di risorse.

Quando utilizzare ResourceClaims e ResourceClaimTemplates

Sia ResourceClaims che ResourceClaimTemplates ti consentono di indicare a Kubernetes che vuoi dispositivi che soddisfino requisiti specifici. Quando viene fatto riferimento a un ResourceClaim in un pod, Kubernetes alloca i dispositivi alla risorsa API corrispondenteResourceClaim nel server API Kubernetes. Questa allocazione avviene indipendentemente dal fatto che tu abbia creato la richiesta di risorsa o che Kubernetes abbia creato la richiesta di risorsa da un modello di richiesta di risorsa.

Se crei una richiesta di risorse e poi fai riferimento a più pod, tutti questi pod possono accedere ai dispositivi allocati da Kubernetes per la richiesta di risorse. 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ù procedimenti, questo accesso ai dispositivi condivisi tra i pod potrebbe comportare un comportamento indesiderato.

Un ResourceClaimTemplate consente di definire i modelli utilizzati da Kubernetes 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 un proprio dispositivo allocato anziché condividere l'accesso al dispositivo con altri pod. Questi ResourceClaim generati automaticamente sono legati al ciclo di vita del pod corrispondente e vengono eliminati al termine del pod. 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 rivendicazioni risorse e il lasciare che sia Kubernetes a crearle da un modello di rivendicazione risorse:

ResourceClaims creati 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 Legato al ciclo di vita del pod corrispondente
Ideale per più carichi di lavoro che devono condividere un dispositivo specifico Ideale per più carichi di lavoro che richiedono l'accesso indipendente ai dispositivi

Confronto della DRA con l'allocazione manuale dei dispositivi

La DRA rende l'allocazione dei dispositivi collegati un'esperienza simile al provisioning dinamico dei PersistentVolume. Kubernetes supporta anche l'allocazione dei dispositivi tramite l'utilizzo di plug-in per i 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 relativi dispositivi collegati.
  3. Un operatore del carico di lavoro richiede i dispositivi nel manifest del carico di lavoro come segue:
    • Seleziona un nodo con la configurazione del dispositivo richiesta, ad esempio il modello GPU o il tipo e la topologia TPU, utilizzando un campo nodeSelector.
    • Specifica il numero esatto di dispositivi da utilizzare dai container utilizzando il campo resources nella specifica del pod.

Questo metodo di allocazione manuale richiede che gli operatori delle applicazioni e gli amministratori dei cluster comunichino quali nodi o pool di nodi specifici hanno determinate configurazioni dei dispositivi. Devono coordinare le richieste di carico di lavoro in modo che corrispondano ai dispositivi sui nodi, altrimenti il deployment non va a buon fine. In confronto, la DRA 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 mette a confronto la DRA con i plug-in dei dispositivi:

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 file manifest del carico di lavoro
Filtri dei dispositivi centralizzati e corsi in base alle esigenze, gestiti dagli amministratori della piattaforma Filtro dei dispositivi isolati per operatori di applicazioni
Gli operatori di app non devono conoscere la capacità del nodo, le informazioni sulle etichette dei nodi o i modelli di dispositivi collegati per ogni nodo Gli operatori di app devono sapere quali nodi hanno modelli e quantità specifiche di determinati dispositivi collegati.

Dispositivi GKE supportati per DRA

Puoi utilizzare DRA per allocare GPU o TPU ai carichi di lavoro GKE. Puoi allocare qualsiasi modello GPU e TPU supportato da GKE. Per dettagli sulle GPU e sulle TPU supportate da GKE, consulta le seguenti risorse:

Limitazioni della replica dei dati 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 condivise in base al tempo.
    • GPU a più istanze.
    • Servizio multiprocesso (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 la distribuzione dinamica dei report per allocare i 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 la selezione e il filtro dei dispositivi granulari, tieni presente le seguenti indicazioni:

Migliorare la disponibilità dei nodi durante la scalabilità

Le classi Compute in GKE ti consentono di definire il comportamento di riserva basato sulla priorità seguito da GKE quando crea nuovi nodi nei cluster. Puoi utilizzare ComputeClasses per configurare una serie di configurazioni di nodi e dispositivi con priorità che GKE utilizza per creare nodi per l'esecuzione dei carichi di lavoro. Puoi quindi utilizzare la DRA per assicurarti che il tuo carico di lavoro possa essere eseguito su qualsiasi nodo all'interno della classe Compute senza dover selezionare manualmente i nodi in base all'etichetta.

Ad esempio, per funzionare in modo ottimale, un carico di lavoro potrebbe richiedere due GPU NVIDIA L4 o una GPU NVIDIA A100 (40 GB). Puoi creare una classe Compute che dà la priorità alla creazione di nodi con una GPU A100 (40 GB), ma può ricorrere alla 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 la classe Compute, GKE crea nodi con una delle configurazioni GPU specificate. Con DRA, GKE può posizionare il carico di lavoro sul primo nodo disponibile, indipendentemente dal modello di GPU, dall'etichetta del nodo o dal numero di GPU.

Per saperne di più, visita le seguenti pagine:

Passaggi successivi