Informazioni sull'allocazione dinamica delle risorse in GKE

Puoi utilizzare l'allocazione dinamica delle risorse (DRA) per allocare le GPU ai carichi di lavoro di 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:

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 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 di dispositivi specifici 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 include 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 carico di lavoro che richiede la configurazione filtrata, GKE inserisce 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 configurazioni di nodi o dispositivi specifici nel manifest del carico di lavoro.

Vantaggi di DRA

Senza DRA, l'allocazione dei dispositivi hardware in Kubernetes si basa sui plug-in dei dispositivi. Per collegare le risorse hardware ai pod utilizzando i plug-in dei dispositivi, devi utilizzare le etichette dei nodi per inserire 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'allocazione dei dispositivi ai pod è simile all'allocazione dei 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 carichi di lavoro. DRA fornisce una superficie notevolmente più estensibile per filtrare i dispositivi in base alle esigenze aziendali e dei carichi di lavoro. L'approccio DRA di utilizzo di espressioni e modelli per richiedere l'hardware e pianificare i pod presenta i seguenti vantaggi:

  • Allocazione dichiarativa dei dispositivi: 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 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.
  • Riduzione della complessità 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 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 hardware flessibile: puoi utilizzare le espressioni CEL per filtrare i dispositivi con attributi specifici. L'utilizzo delle espressioni offre la flessibilità di filtrare i dispositivi ottimali per carichi di lavoro specifici.

Quando utilizzare DRA

Il motivo principale per utilizzare DRA in GKE è la flessibilità con cui puoi richiedere i dispositivi per i carichi di lavoro. Puoi scrivere un manifest una sola 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:

  • Migliorare 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 anziché dover specificare un modello di GPU. Se questi carichi di lavoro hanno requisiti specifici per la 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 carico di lavoro, il che riduce il rischio che il carico di lavoro non venga pianificato a causa di risorse non disponibili.

  • Ottimizzare la disponibilità dei nodi durante la scalabilità: la quantità di dispositivi richiesta da un carico di lavoro potrebbe variare a seconda di fattori come il tipo di dispositivo e le sue funzionalità. Puoi utilizzare le ComputeClasses di GKE per inserire i pod accelerati in pool di nodi specifici in base alla disponibilità dei dispositivi. Puoi quindi configurare i pod in modo che richiedano i dispositivi in qualsiasi nodo su cui GKE inserisce i pod.

    L'utilizzo di DRA con ComputeClass ti consente di ridurre al minimo il rischio di carichi di lavoro non pianificati e di eseguire i carichi di lavoro su hardware ottimizzato.

Terminologia

Kubernetes open source e i provider di 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 dei dispositivi 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 dispositivi 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 di dispositivi specifici.
ResourceClaim

Un 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 un ResourceClaim, Kubernetes assegna a quel 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 carico di lavoro che seleziona quel ResourceClaim. Kubernetes assegna una GPU A100 (40 GB) disponibile al ResourceClaim e pianifica il pod su un nodo che può accedere a quella GPU.

ResourceClaimTemplate

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

Gli operatori delle app eseguono il deployment di ResourceClaimTemplate e poi fanno riferimento ai modelli nei carichi di lavoro. 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 ulteriori informazioni sui tipi di API DRA, consulta la terminologia DRA.

Come funziona DRA

L'utilizzo di DRA nei cluster e nei carichi di lavoro è 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 dei cluster e gli operatori delle app eseguono per allocare i dispositivi utilizzando DRA:

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

  1. Gli amministratori dei cluster installano i driver dei dispositivi che supportano DRA nei nodi.
  2. Gli amministratori dei 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 DeviceClass integrate.
  3. Gli operatori delle applicazioni creano ResourceClaimTemplate o ResourceClaim che richiedono configurazioni di dispositivi. Il caso d'uso principale per ogni tipo di richiesta è il seguente:
    • Un 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.
  4. Gli operatori delle applicazioni aggiungono i ResourceClaimTemplate o i ResourceClaim ai manifest dei carichi di lavoro.
  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 i ResourceSlice nel cluster per allocare i dispositivi disponibili e idonei al ResourceClaim di ogni pod.
  3. Lo scheduler inserisce ogni pod su un nodo che ha accesso ai dispositivi allocati al ResourceClaim del pod.
  4. Il 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

Puoi utilizzare ResourceClaim o ResourceClaimTemplate per indicare a Kubernetes che vuoi dispositivi che soddisfano 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 il ResourceClaim o che Kubernetes abbia creato il ResourceClaim da un ResourceClaimTemplate.

Se crei un ResourceClaim e poi fai riferimento a esso in più pod, tutti questi pod possono accedere ai dispositivi allocati da Kubernetes per quel 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 riceve il proprio dispositivo allocato anziché condividere l'accesso al dispositivo con altri pod. Questi ResourceClaim generati automaticamente sono vincolati alla durata del pod corrispondente e vengono eliminati quando il pod termina. Se hai pod indipendenti che richiedono l'accesso a configurazioni di dispositivi simili, utilizza un ResourceClaimTemplate per allocare i dispositivi a ogni pod separatamente.

La seguente tabella 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 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 Vincolato 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 tra DRA e allocazione manuale dei dispositivi

DRA rende l'allocazione dei dispositivi collegati un'esperienza simile al provisioning dinamico di PersistentVolume. Kubernetes supporta anche l'allocazione dei dispositivi utilizzando i plug-in dei 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 informazioni su nodi specifici e sui relativi dispositivi collegati agli operatori dei carichi di lavoro.
  3. Un operatore di carichi 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 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 delle applicazioni e gli amministratori dei cluster comunichino quali nodi o pool di nodi specifici hanno determinate configurazioni di dispositivi. Devono coordinare le richieste dei carichi di lavoro in modo che corrispondano ai dispositivi sui nodi, altrimenti il deployment non riesce. Al contrario, DRA ti consente di utilizzare le espressioni per filtrare in modo flessibile i dispositivi in base agli attributi e non richiede che gli operatori dei carichi di lavoro conoscano la configurazione esatta dei nodi nel cluster.

La seguente tabella confronta DRA con i plug-in dei dispositivi:

Tabella 2. Confronto tra DRA e allocazione manuale dei dispositivi
DRA Allocazione manuale
Selezione flessibile dei dispositivi utilizzando le espressioni CEL Selezione di nodi specifici utilizzando i selettori e le 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 dei carichi di lavoro 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 isolato da parte degli operatori delle 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 delle app devono sapere quali nodi hanno modelli e quantità specifici di determinati dispositivi collegati.

DRA e scalabilità automatica dell'infrastruttura

Per regolare automaticamente il numero di nodi all'interno di un pool di nodi in modalità Standard, devi utilizzare il gestore della scalabilità automatica dei cluster. Puoi abilitare il gestore della scalabilità automatica dei cluster in tutti i pool di nodi creati manualmente, inclusi i pool di nodi con driver DRA.

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

  • Tutti i dispositivi in un pool di risorse devono essere locali a un nodo specifico. Se un ResourceSlice ha un pool di dispositivi collegati a più nodi, il gestore della scalabilità automatica dei 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 pool di nodi DRA, il gestore della scalabilità automatica dei cluster ignora l'utilizzo di CPU e memoria.

Questi fattori potrebbero significare che noti un comportamento di scale down diverso nei pool di nodi DRA rispetto ad altri pool di nodi.

Dispositivi GKE supportati per DRA

La seguente tabella descrive i dispositivi che puoi allocare ai carichi di lavoro 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 ulteriori informazioni, consulta Località delle GPU.
Interfacce di rete Più tipi di interfacce di rete, ad esempio interfacce compatibili con RDMA, installando il driver DRANET gestito. Per ulteriori informazioni, consulta Allocare risorse di rete utilizzando DRANET gestito da GKE.

Limitazioni

Quando utilizzi DRA, si applicano le seguenti limitazioni:

  • Modalità operativa: DRA è disponibile solo nei cluster in modalità Standard.

  • Tipo di acceleratore: durante l'anteprima, DRA in GKE supporta solo le GPU.

  • GPU:

  • Interfacce di rete (anteprima): consulta Limitazioni in "Allocare risorse di rete utilizzando DRANET gestito da GKE".

  • Scalabilità automatica:

    • Per i driver DRA di terze parti che installi, il gestore della scalabilità automatica dei cluster richiede che i pool di nodi abbiano almeno un nodo. Per impedire che i pool di nodi 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 i driver pubblichino informazioni solo per i dispositivi locali a nodi specifici.
    • Per i DaemonSet nei pool di nodi 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 questa limitazione, esegui una delle seguenti operazioni:
    • Se i pod fanno riferimento a ResourceClaim e hanno una PriorityClass che imposta il criterio di prelazione su PreemptLowerPriority, la latenza della scalabilità automatica potrebbe aumentare. PreemptLowerPriority è il criterio di prelazione predefinito per PriorityClass, quindi assicurati che le tue PriorityClass impostino esplicitamente il campo preemptionPolicy su Never. Per ulteriori informazioni, consulta PriorityClass non preempting.

Questa sezione fornisce suggerimenti per gli amministratori della piattaforma o gli operatori delle app che vogliono utilizzare DRA 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 il filtro e la selezione dei dispositivi granulari, prendi in considerazione le seguenti indicazioni:

Passaggi successivi