Informazioni sull'allocazione dinamica delle risorse in GKE

Standard

Puoi utilizzare l'allocazione dinamica delle risorse (DRA) per allocare GPU ai tuoi carichi di lavoro Google Kubernetes Engine (GKE). Questo documento spiega i concetti fondamentali di DRA, come utilizzare DRA in GKE e i vantaggi del suo utilizzo.

Questo documento è destinato ai seguenti ruoli:

Amministratori della piattaforma che vogliono ridurre la complessità e i costi generali della configurazione dell'infrastruttura con dispositivi hardware specializzati.
Operatori di app e data engineer che eseguono workload come AI/ML o computing ad alte prestazioni (HPC).

Dovresti già avere familiarità con quanto segue:

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, ad esempio 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 workload. Kubernetes e GKE gestiscono la pianificazione dei pod, le assegnazioni dei nodi e l'allocazione dei dispositivi in base alle richieste del workload.

Ad esempio, un amministratore della piattaforma potrebbe definire una classe di dispositivi che ha solo 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 workload 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 manifest del workload.

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'assegnazione di dispositivi ai pod è simile all'assegnazione di volumi per lo spazio di archiviazione. Definisci le classi di dispositivi, richiedi i dispositivi all'interno di queste classi e poi assegna i dispositivi richiesti ai workload. DRA offre una superficie 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 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 workload o team.
Complessità ridotta tra i team: quando gli amministratori della piattaforma eseguono il provisioning dei 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: puoi utilizzare le espressioni CEL per filtrare i dispositivi con attributi specifici. L'utilizzo di espressioni offre la flessibilità di filtrare i dispositivi ottimali per workload specifici.

Quando utilizzare DRA

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 workload a cluster diversi con tipi di dispositivi diversi senza dover modificare il manifest. Questa flessibilità è ideale per casi d'uso come i seguenti:

Migliora l'ottenimento della 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 durante lo scaling: la quantità di dispositivi richiesta da un carico di lavoro potrebbe variare a seconda di fattori quali il tipo di dispositivo e le sue funzionalità. Puoi utilizzare ComputeClasses di GKE per posizionare i pod accelerati su node pool specifici in base alla disponibilità dei dispositivi. Puoi quindi configurare i pod in modo che rivendichino i dispositivi in qualsiasi nodo in cui GKE posiziona i pod.

L'utilizzo di DRA con ComputeClass consente di ridurre al minimo il rischio di carichi di lavoro non pianificati, aiutandoti al contempo a eseguire i carichi di lavoro su hardware ottimizzato.

Terminologia

Kubernetes open source e i provider Kubernetes gestiti come GKE utilizzano i seguenti tipi di API DRA di base:

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 workload. Alcuni driver di dispositivo forniscono DeviceClass integrate, ad esempio la DeviceClass gpu.nvidia.com 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 workload 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 che può 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.

Per saperne di più sui tipi di API DRA, consulta Terminologia DRA.

Come funziona DRA

L'utilizzo di DRA nei cluster e nei workload è un processo 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:

Gli amministratori del cluster installano i driver del dispositivo che supportano DRA nei nodi.
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.
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 separati e simili generando automaticamente ResourceClaim per pod.
Gli operatori dell'applicazione aggiungono ResourceClaimTemplates o ResourceClaims ai manifest del workload.
Gli operatori dell'applicazione eseguono il deployment del carico di lavoro.

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

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

Quando utilizzare ResourceClaim e ResourceClaimTemplate

Puoi utilizzare ResourceClaim o ResourceClaimTemplate per 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 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 la 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.

Per allocare dispositivi separati ai pod, puoi utilizzare un ResourceClaimTemplate, ovvero un modello che Kubernetes utilizza per creare automaticamente singoli ResourceClaim. 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 ottiene il proprio dispositivo allocato anziché condividere l'accesso al dispositivo con altri pod. Queste ResourceClaim generate automaticamente sono associate alla durata del pod corrispondente e vengono eliminate quando il pod viene terminato. Se hai pod indipendenti che devono accedere a configurazioni di dispositivi simili, utilizza un ResourceClaimTemplate per allocare i dispositivi a ogni 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:

**Tabella 1.** Confronto tra ResourceClaim e 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ù workload che devono condividere un dispositivo specifico	Ideale per più workload che richiedono l'accesso indipendente ai dispositivi

Confronto tra la registrazione automatica dei dispositivi e l'assegnazione 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 utilizzando i plug-in per dispositivi. Questo metodo prevede i seguenti passaggi:

Un amministratore del cluster crea nodi con dispositivi collegati, come le GPU.
L'amministratore del cluster comunica agli operatori dei carichi di lavoro informazioni su nodi specifici e sui dispositivi collegati.
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, utilizzando un campo nodeSelector.
- Specifica il numero esatto di dispositivi da utilizzare per i container 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 node pool 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 workload di conoscere la configurazione esatta dei nodi nel cluster.

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

**Tabella 2.** Confronto tra la registrazione automatica dei dispositivi e l'allocazione manuale 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 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 dispositivo collegati per ogni nodo	Gli operatori dell'app devono sapere quali nodi hanno modelli e quantità specifici di determinati dispositivi collegati.

Scalabilità automatica di DRA e dell'infrastruttura

Per regolare automaticamente il numero di nodi all'interno di un node pool in modalità Standard, utilizza il gestore della scalabilità automatica dei cluster. Puoi abilitare la scalabilità automatica del cluster in qualsiasi node pool creato manualmente, inclusi i node pool con driver DRA.

Per i node pool che utilizzano DRA, l'utilizzo dei dispositivi influisce sul modo in cui il gestore della scalabilità automatica dei cluster aggiunge e rimuove nodi in un pool di nodi. Per calcolare l'utilizzo del dispositivo in unpool di nodil, il gestore della scalabilità automatica dei cluster prende in considerazione i seguenti fattori:

Tutti i dispositivi in un pool di risorse devono essere locali a un nodo specifico. Se una ResourceSlice ha un pool di dispositivi collegati a più nodi, il gestore della scalabilità automatica del cluster ignora questi dispositivi.
Tutti i dispositivi nel pool di nodi sono ugualmente importanti e identici.
I dispositivi DRA hanno una priorità più alta rispetto a CPU o memoria. Nei node pool DRA, il gestore della scalabilità automatica del cluster ignora l'utilizzo di CPU e memoria.

Questi fattori potrebbero significare che noti un comportamento di riduzione diverso nei node pool DRA rispetto ad altri node pool.

Dispositivi GKE supportati per DRA

La tabella seguente descrive i dispositivi che puoi allocare ai workload con DRA in GKE:

**Tabella 3.** Dispositivi supportati per DRA in GKE
Dispositivi supportati per DRA
GPU	Qualsiasi tipo di GPU disponibile nella tua località. Per saperne di più, vedi Località delle GPU.
Interfacce di rete	Più tipi di interfacce di rete, come le interfacce compatibili con RDMA, installando il driver DRANET gestito. Per ulteriori informazioni, consulta Allocare risorse di rete utilizzando GKE Managed DRANET.

Limitazioni

Quando utilizzi DRA, si applicano le seguenti limitazioni:

Modalità di funzionamento: DRA è disponibile solo nei cluster in modalità standard.
Tipo di acceleratore: durante l'anteprima, DRA in GKE supporta solo le GPU.
GPU:
- Non puoi utilizzare GPU in time-sharing, GPU multi-istanza o MPS (Multi-Process Service).
- Per i nodi che utilizzano i driver GPU DRA, non puoi utilizzare il pacchetto di metriche NVIDIA Data Center GPU Manager (DCGM) gestito per inviare le metriche DCGM a Cloud Monitoring.
- Il driver GPU per DRA è di proprietà di NVIDIA, non di GKE. Per saperne di più, consulta la documentazione NVIDIA.
Interfacce di rete (anteprima): vedi Limitazioni in "Allocare risorse di rete utilizzando DRANET gestito da GKE".
Scalabilità automatica:
- Per i driver DRA di terze parti che installi, lo strumento di scalabilità automatica del cluster richiede che i node pool abbiano almeno un nodo. Per impedire che i node pool che utilizzano driver di terze parti vengano scalati a zero nodi, imposta il numero minimo di nodi su almeno 1.
- Il gestore della scalabilità automatica dei cluster potrebbe non funzionare correttamente con i driver DRA di terze parti. Se utilizzi driver di terze parti, verifica che pubblichino informazioni solo per i dispositivi locali di nodi specifici.
- Per i DaemonSet nei node pool con scalabilità automatica che utilizzano un ResourceClaim statico per condividere l'accesso ai dispositivi tra i pod, la scalabilità automatica supporta fino a 128 pod DaemonSet. Per evitare questo limite, procedi in uno dei seguenti modi:
  - Impedisci al pool di nodi di scalare a più di 128 nodi impostando il numero massimo di nodi.
  - Utilizza il campo adminAccess (beta) in ResourceClaim, che consente a DaemonSet di accedere ai dispositivi in uso.
- Se i tuoi pod fanno riferimento a ResourceClaim e hanno una PriorityClass che imposta il criterio di preemptive su PreemptLowerPriority, la latenza della scalabilità automatica potrebbe aumentare. PreemptLowerPriority è la norma di preemption predefinita per PriorityClass, quindi assicurati che le tue PriorityClass impostino esplicitamente il campo preemptionPolicy su Never. Per ulteriori informazioni, consulta PriorityClass non preemptive.

Competenze consigliate per comprendere e utilizzare i diritti digitali

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 granulare dei dispositivi, segui queste indicazioni:

Scopri CEL: con DRA, puoi utilizzare le espressioni CEL per eseguire un filtraggio granulare dei dispositivi nelle richieste di allocazione delle risorse e in DeviceClasses. Le seguenti risorse potrebbero aiutarti a imparare CEL:
Scopri di più su ComputeClass in GKE: puoi utilizzare ComputeClass con DRA per soddisfare le esigenze aziendali, ad esempio il provisioning di VM spot per eseguire carichi di lavoro di inferenza che richiedono GPU economiche. Le seguenti risorse ti aiutano a scoprire di più su ComputeClasses: