Ku­ber­netes GPU Sche­du­ling: DRA, Device Plugins und CDI ver­ständ­lich erklärt

Ku­ber­netes GPU Sche­du­ling be­zeich­net die de­kla­ra­ti­ve Zuweisung von Gra­fik­pro­zes­so­ren und anderen Be­schleu­ni­gern an Pods. Dabei ent­schei­det der Scheduler nicht nur, welcher Node technisch passt, sondern auch, wie GPUs per Bin-Packing aus­ge­las­tet, über Re­source­Claims an­ge­for­dert und un­ab­hän­gig von her­stel­ler­spe­zi­fi­schen Container-Details be­reit­ge­stellt werden.

Was ist Ku­ber­netes GPU Sche­du­ling?

Ein Ku­ber­netes-Cluster besteht aus mehreren Servern, die als Nodes be­zeich­net werden. Auf diesen Nodes führt Ku­ber­netes An­wen­dun­gen in so­ge­nann­ten Pods aus. Benötigt eine Anwendung eine GPU, muss Ku­ber­netes einen Node auswählen, auf dem eine passende und noch ver­füg­ba­re GPU vorhanden ist. Diese Ent­schei­dung übernimmt der Ku­ber­netes Scheduler. Er prüft zunächst, welche Nodes die An­for­de­run­gen des Pods erfüllen. An­schlie­ßend bewertet er die ge­eig­ne­ten Nodes und wählt den am besten passenden aus.

Beim klas­si­schen GPU Sche­du­ling sieht Ku­ber­netes eine GPU im We­sent­li­chen als zählbare Ressource. Ein Pod fordert bei­spiels­wei­se eine Einheit der Ressource nvidia.com/gpu an. Ku­ber­netes weiß dann zwar, dass der Pod eine NVIDIA-GPU benötigt, kann über diesen einfachen Me­cha­nis­mus aber nur begrenzt aus­drü­cken, welches Modell oder welche Kon­fi­gu­ra­ti­on benötigt wird.

Dynamic Resource Al­lo­ca­ti­on, kurz DRA, erweitert dieses Modell. Statt lediglich „eine GPU“ an­zu­for­dern, kann eine Anwendung bei­spiels­wei­se eine GPU der Blackwell-Ge­ne­ra­ti­on, eine bestimmte Spei­cher­ka­pa­zi­tät oder eine bestimmte MIG-Kon­fi­gu­ra­ti­on verlangen.

Device Plugin, MIG und DRA im Vergleich

Für die Zuweisung von GPUs stehen mehrere Verfahren zur Verfügung. Sie schließen sich nicht grund­sätz­lich ge­gen­sei­tig aus: MIG be­schreibt bei­spiels­wei­se eine Auf­tei­lung der Hardware, während Device Plugins und DRA bestimmen, wie Ku­ber­netes diese Hardware verwaltet und Pods zuweist.

DRA arbeitet mit drei zentralen Ku­ber­netes-Objekten. Sie be­schrei­ben, welche Geräte im Cluster vorhanden sind und welche Hardware ein Pod benötigt:

Der NVIDIA-DRA-Treiber erstellt die Re­sour­ceS­li­ces au­to­ma­tisch und in­stal­liert bei ak­ti­vier­tem GPU-Support auch die Stan­dard­klas­sen gpu.nvidia.com und mig.nvidia.com. Zu­sätz­li­che, genauer zu­ge­schnit­te­ne De­vice­Clas­ses, bei­spiels­wei­se für eine B200, kann die Cluster-Ad­mi­nis­tra­ti­on selbst de­fi­nie­ren. An­wen­dun­gen fordern die ge­wünsch­te GPU an­schlie­ßend über Re­source­Claims an.

So trifft Ku­ber­netes eine GPU-Sche­du­ling-Ent­schei­dung

Eine Sche­du­ling-Ent­schei­dung besteht ver­ein­facht aus zwei Phasen: Filtern und Bewerten.

Beim Filtern entfernt Ku­ber­netes alle Nodes, die den Pod nicht ausführen können. Gründe können fehlender Ar­beits­spei­cher, eine nicht ver­füg­ba­re GPU, ein un­pas­sen­des GPU-Modell, Node Taints oder nicht erfüllte Affinity-Regeln sein. Danach bewertet der Scheduler die ver­blei­ben­den Nodes. Der Node mit der höchsten Bewertung wird aus­ge­wählt. Diese Bewertung kann bei­spiels­wei­se darauf aus­ge­rich­tet werden, An­wen­dun­gen möglichst gleich­mä­ßig zu verteilen oder vor­han­de­ne Nodes möglichst stark zu füllen.

Bei DRA kommt zu­sätz­lich die Ge­rä­te­aus­wahl hinzu:

1. Der NVIDIA-DRA-Treiber erkennt die GPUs auf jedem Node.
2. Er ver­öf­fent­licht die ver­füg­ba­ren Geräte als Re­sour­ceS­li­ces.
3. Eine De­vice­Class be­schreibt, welche Geräte zu einer be­stimm­ten Kategorie gehören.
4. Ein Re­source­Cla­im be­schreibt, welches Gerät eine Anwendung benötigt.
5. Der Scheduler sucht nach einer passenden GPU und einem Node, auf dem diese GPU er­reich­bar ist.
6. Der DRA-Treiber bereitet das aus­ge­wähl­te Gerät für den Pod vor.
7. Die Container-Runtime stellt die GPU über CDI im Container bereit.

Was bedeutet Bin-Packing bei GPU-Clustern?

Beim Bin-Packing versucht Ku­ber­netes, GPU-Workloads möglichst kompakt auf vor­han­de­nen Nodes un­ter­zu­brin­gen. Dadurch können einzelne Server besser aus­ge­las­tet und andere Nodes für größere Jobs frei­ge­hal­ten oder ab­ge­schal­tet werden. Der Scheduler bewertet dabei jedoch die an­ge­for­der­ten Res­sour­cen und nicht die tat­säch­li­che GPU-Aus­las­tung. Für deren Über­wa­chung ist zu­sätz­li­ches Mo­ni­to­ring er­for­der­lich. Bei Multi-GPU-Workloads sollten außerdem NVLink-, PCIe- und NUMA-To­po­lo­gien be­rück­sich­tigt werden, da eine möglichst dichte Ver­tei­lung nicht au­to­ma­tisch die beste Leistung bietet.

Welche Rolle spielt CDI bei NVIDIA Blackwell?

CDI steht für Container Device Interface und stan­dar­di­siert, wie eine aus­ge­wähl­te GPU in einen Container ein­ge­bun­den wird. DRA ent­schei­det dabei, welche GPU ein Pod erhält. CDI sorgt an­schlie­ßend dafür, dass das Gerät samt be­nö­tig­ter Zugänge, Bi­blio­the­ken und Ein­stel­lun­gen im Container verfügbar ist.

Beim NVIDIA GPU Operator ist CDI stan­dard­mä­ßig aktiviert und arbeitet mit Container-Runtimes wie con­tai­nerd oder CRI-O zusammen. Für Blackwell-Systeme ist das besonders hilfreich, weil un­ter­schied­li­che GPU-Modelle und MIG-Kon­fi­gu­ra­tio­nen ein­heit­lich be­reit­ge­stellt werden können.

Tutorial: NVIDIA-GPUs mit DRA in Ku­ber­netes zuweisen

Das folgende Tutorial zeigt eine voll­stän­di­ge DRA-Zuweisung für eine NVIDIA B200. Sie in­stal­lie­ren zunächst den GPU Operator ohne klas­si­sches Device Plugin, richten an­schlie­ßend den DRA-Treiber ein und erstellen dann eine eigene De­vice­Class sowie einen Re­source­Cla­im.

Vor­aus­set­zun­gen

Für den be­schrie­be­nen Aufbau empfiehlt sich Ku­ber­netes 1.34 oder neuer.

Zu­sätz­lich benötigen Sie:

• min­des­tens einen Ku­ber­netes-Node mit un­ter­stütz­ter NVIDIA-GPU,
• Ad­mi­nis­tra­tor­rech­te im Cluster,
• ein kon­fi­gu­rier­tes kubectl,
• Helm 3,
• con­tai­nerd oder CRI-O als Container-Runtime und
• Zugriff auf die NVIDIA-Helm-Charts.

Schritt 1: GPU Operator und DRA-Treiber mit Helm in­stal­lie­ren

Zunächst müssen Sie festlegen, auf welchen Nodes der DRA-Kubelet-Plugin-Pod aus­ge­führt werden soll. Lassen Sie sich die Namen Ihrer Nodes anzeigen:

kubectl get nodes

Kenn­zeich­nen Sie an­schlie­ßend jeden GPU-Node. Ersetzen Sie <GPU-NODE> durch den tat­säch­li­chen Namen:

kubectl label node <GPU-NODE> nvidia.com/dra-kubelet-plugin=true

Die Kenn­zeich­nung ist er­for­der­lich, damit der NVIDIA Driver Manager den DRA-Kubelet-Plugin-Pod bei Trei­ber­ak­tua­li­sie­run­gen korrekt behandeln kann.

Fügen Sie danach das NVIDIA-Helm-Re­po­si­to­ry hinzu:

helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update

In­stal­lie­ren Sie nun den GPU Operator. Der ent­schei­den­de Parameter ist devicePlugin.enabled=false. Damit de­ak­ti­vie­ren Sie das klas­si­sche NVIDIA Ku­ber­netes Device Plugin und vermeiden, dass Device Plugin und DRA-Treiber dieselben GPUs gleich­zei­tig verwalten.

helm upgrade --install gpu-operator nvidia/gpu-operator \
    --version=v26.3.3 \
    --create-namespace \
    --namespace gpu-operator \
    --set devicePlugin.enabled=false \
    --set 'driver.manager.env[0].name=NODE_LABEL_FOR_GPU_POD_EVICTION' \
    --set 'driver.manager.env[0].value=nvidia.com/dra-kubelet-plugin'

Das De­ak­ti­vie­ren des Device Plugins allein aktiviert DRA noch nicht. Der DRA-Treiber wird weiterhin über ein eigenes Helm-Chart in­stal­liert.

Erstellen Sie dafür die Datei dra-values.yaml mit folgendem Inhalt:

image:
    pullPolicy: IfNotPresent
kubeletPlugin:
    nodeSelector:
        nvidia.com/dra-kubelet-plugin: "true"

In­stal­lie­ren Sie an­schlie­ßend den NVIDIA-DRA-Treiber:

helm upgrade --install dra-driver-nvidia-gpu \
    nvidia/dra-driver-nvidia-gpu \
    --version=0.4.1 \
    --namespace nvidia-dra-driver-gpu \
    --create-namespace \
    --set nvidiaDriverRoot=/run/nvidia/driver \
    --set gpuResourcesEnabledOverride=true \
    -f dra-values.yaml

Prüfen Sie danach, ob die Pods des Treibers laufen:

kubectl get pods -n nvidia-dra-driver-gpu

Abhängig von der ak­ti­vier­ten Kon­fi­gu­ra­ti­on sollte die Ausgabe ungefähr so aussehen:

NAME                                             READY   STATUS
dra-driver-nvidia-gpu-controller-...             1/1     Running
dra-driver-nvidia-gpu-kubelet-plugin-...         2/2     Running

Kon­trol­lie­ren Sie außerdem die au­to­ma­tisch an­ge­leg­ten De­vice­Clas­ses:

kubectl get deviceclass

Für die GPU-Zuweisung sollten min­des­tens die folgenden Klassen vorhanden sein:

gpu.nvidia.com
mig.nvidia.com

Bei ak­ti­vier­tem Com­pu­te­Do­main-Support er­schei­nen zu­sätz­li­che Klassen für Multi-Node NVLink. Prüfen Sie ab­schlie­ßend, ob der Treiber die GPUs als Re­sour­ceS­li­ces ver­öf­fent­licht:

kubectl get resourceslice -o wide

Wenn keine Re­sour­ceS­li­ces für gpu.nvidia.com er­schei­nen, kann Ku­ber­netes noch keine GPU über DRA zuweisen.

Schritt 2: De­vice­Class für NVIDIA B200 de­fi­nie­ren

Der NVIDIA-DRA-Treiber legt bereits die all­ge­mei­ne De­vice­Class gpu.nvidia.com an. Diese umfasst voll­stän­di­ge NVIDIA-GPUs un­ter­schied­li­cher Modelle. Für einen he­te­ro­ge­nen Cluster können Sie zu­sätz­lich eine eigene Klasse erstellen, die aus­schließ­lich B200-GPUs auswählt.

Sehen Sie sich zunächst die vom Treiber ge­mel­de­ten Pro­dukt­na­men an:

kubectl get resourceslice -o yaml

Suchen Sie in der Ausgabe nach productName. Die genaue Be­zeich­nung hängt von Hardware, Treiber und Sys­tem­va­ri­an­te ab. Der folgende reguläre Ausdruck sucht deshalb nicht nach einer voll­stän­dig iden­ti­schen Zei­chen­fol­ge, sondern nach dem Be­stand­teil B200.

Erstellen Sie die Datei b200-deviceclass.yaml:

apiVersion: resource.k8s.io/v1
kind: DeviceClass
metadata:
    name: b200.gpu.nvidia.com
spec:
    selectors:
    - cel:
            expression: |
                device.driver == 'gpu.nvidia.com' &&
                device.attributes['gpu.nvidia.com'].type == 'gpu' &&
                device.attributes['gpu.nvidia.com'].productName
                    .lowerAscii()
                    .matches('^.*b200.*$')

Der Ausdruck enthält drei Be­din­gun­gen:

• Das Gerät muss vom NVIDIA-GPU-DRA-Treiber stammen.
• Es muss sich um eine voll­stän­di­ge GPU und nicht um eine MIG-Instanz handeln.
• Der gemeldete Pro­dukt­na­me muss B200 enthalten.

Wenden Sie die Datei an:

kubectl apply -f b200-deviceclass.yaml

Kon­trol­lie­ren Sie die De­vice­Class:

kubectl describe deviceclass b200.gpu.nvidia.com

Eine De­vice­Class re­ser­viert noch keine GPU. Sie definiert lediglich den Ge­rä­te­pool, aus dem spätere Claims auswählen dürfen.

Schritt 3: Re­source­Cla­im und Pod erstellen

Erstellen Sie zunächst einen eigenen Namespace für den Test:

kubectl create namespace gpu-example

Danach erstellen Sie einen Re­source­Cla­im. Speichern Sie den folgenden Inhalt als b200-resourceclaim.yaml:

apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
    name: b200-claim
    namespace: gpu-example
spec:
    devices:
        requests:
        - name: b200
            exactly:
                deviceClassName: b200.gpu.nvidia.com

Ohne weitere Men­gen­an­ga­be fordert dieser Claim genau ein passendes Gerät an.

Erstellen Sie den Re­source­Cla­im:

kubectl apply -f b200-resourceclaim.yaml

Der Claim wird nor­ma­ler­wei­se erst voll­stän­dig zu­ge­wie­sen, wenn ein Pod ihn verwendet. Ku­ber­netes muss schließ­lich nicht nur eine freie GPU, sondern auch einen dazu passenden Node auswählen.

Erstellen Sie nun die Datei b200-pod.yaml:

apiVersion: v1
kind: Pod
metadata:
    name: b200-test
    namespace: gpu-example
spec:
    restartPolicy: Never
    containers:
    - name: gpu-test
        image: ubuntu:22.04
        command:
        - bash
        - -c
        - |
            nvidia-smi -L
            sleep 3600
        resources:
            claims:
            - name: gpu
    resourceClaims:
    - name: gpu
        resourceClaimName: b200-claim
    tolerations:
    - key: nvidia.com/gpu
        operator: Exists
        effect: NoSchedule

Im Pod taucht der Claim an zwei Stellen auf:

1. Unter spec.resourceClaims wird der vor­han­de­ne Re­source­Cla­im für den Pod verfügbar gemacht:

resourceClaims:
- name: gpu
    resourceClaimName: b200-claim

2. Unter containers[].resources.claims wird fest­ge­legt, welcher Container das Gerät verwenden darf:

resources:
    claims:
    - name: gpu

Diese Trennung er­mög­licht es, einen Claim gezielt einem oder mehreren Con­tai­nern im Pod be­reit­zu­stel­len. Mehrere Container können denselben Claim re­fe­ren­zie­ren und dadurch dieselbe GPU sehen.

Erstellen Sie den Pod:

kubectl apply -f b200-pod.yaml

Schritt 4: GPU-Zuweisung mit kubectl va­li­die­ren

Prüfen Sie zunächst den all­ge­mei­nen Pod-Status:

kubectl get pod b200-test -n gpu-example -o wide

Der Pod sollte nach er­folg­rei­cher Zuweisung den Status Running erhalten. In der Spalte NODE sehen Sie, auf welchem GPU-Node er aus­ge­führt wird.

Rufen Sie an­schlie­ßend die aus­führ­li­che Be­schrei­bung ab:

kubectl describe pod b200-test -n gpu-example

Achten Sie ins­be­son­de­re auf folgende Bereiche:

• Node: Zeigt den aus­ge­wähl­ten GPU-Node.
• Resource Claims: Zeigt den vom Pod ver­wen­de­ten Claim.
• Con­tai­ners: Zeigt, welcher Container auf den Claim zugreift.
• Events: Enthält Feh­ler­mel­dun­gen, falls kein passendes Gerät gefunden wurde.

Bleibt der Pod im Status Pending, finden Sie unter Events in aller Regel einen Hinweis auf die Ursache, etwa einen nicht zu­weis­ba­re Re­source­Cla­im oder ein fehlendes passendes Gerät.

Prüfen Sie an­schlie­ßend den Re­source­Cla­im:

kubectl get resourceclaim b200-claim \
    -n gpu-example \
    -o yaml

Unter status.allocation.devices.results sollte die zu­ge­wie­se­ne GPU er­schei­nen. Kon­trol­lie­ren Sie ab­schlie­ßend, ob die GPU im Container verfügbar ist:

kubectl exec -n gpu-example b200-test -- nvidia-smi -L

Eine er­folg­rei­che Ausgabe kann bei­spiels­wei­se so aussehen:

GPU 0: NVIDIA B200 (UUID: GPU-...)

Damit ist bestätigt, dass Ku­ber­netes eine passende B200 aus­ge­wählt und über CDI im Container be­reit­ge­stellt hat.

Häufige Fehler beim Ku­ber­netes GPU Sche­du­ling mit DRA

Der Pod bleibt im Status Pending

Prüfen Sie zunächst die Pod-Events und den Re­source­Cla­im:

kubectl describe pod b200-test -n gpu-example
kubectl describe resourceclaim b200-claim -n gpu-example

Fehlt eine passende GPU, kon­trol­lie­ren Sie die ver­öf­fent­lich­ten Geräte und deren Pro­dukt­na­men:

kubectl get resourceslice -o yaml

Es werden keine Re­sour­ceS­li­ces angezeigt

Prüfen Sie, ob die Pods des DRA-Treibers laufen:

kubectl get pods -n nvidia-dra-driver-gpu

Bei Fehlern helfen die Logs des Kubelet-Plugins:

kubectl logs \
    -n nvidia-dra-driver-gpu \
    <NAME-DES-KUBELET-PLUGIN-PODS> \
    -c gpus

Häufige Ursachen sind ein falscher nvidiaDriverRoot, fehlende Node Labels oder nicht erkannte GPUs.

Der B200-Selektor findet kein Gerät

Ver­glei­chen Sie den ver­wen­de­ten productName mit dem Eintrag in der Re­sour­ceS­li­ce. Zum Test können Sie den Selektor vor­über­ge­hend auf alle voll­stän­di­gen NVIDIA-GPUs erweitern:

expression: |
    device.driver == 'gpu.nvidia.com' &&
    device.attributes['gpu.nvidia.com'].type == 'gpu'

Funk­tio­niert die Zuweisung damit, liegt der Fehler wahr­schein­lich im Mo­dell­se­lek­tor.

Best Practices für GPU-Cluster

Verwenden Sie De­vice­Clas­ses als Schnitt­stel­le zwischen An­wen­dun­gen und Hardware. So müssen Workloads keinen be­stimm­ten Node kennen, sondern können bei­spiels­wei­se eine B200-GPU oder eine GPU mit besonders viel Speicher anfordern. Filtern Sie außerdem nur dann nach einem konkreten Modell, wenn es technisch notwendig ist. Eine An­for­de­rung wie „min­des­tens 80 GiB GPU-Speicher“ ist oft flexibler als die feste Auswahl eines be­stimm­ten GPU-Modells.

Nutzen Sie Re­source­Claim­Tem­pla­tes für De­ploy­ments und Jobs mit mehreren Pods. Direkte Re­source­Claims eignen sich dagegen für einzelne Pods oder Res­sour­cen, die bewusst wei­ter­ver­wen­det werden sollen. Beachten Sie, dass Ku­ber­netes re­ser­vier­te Res­sour­cen bewertet, nicht die tat­säch­li­che GPU-Aus­las­tung. Für deren Über­wa­chung benötigen Sie zu­sätz­li­ches Mo­ni­to­ring, bei­spiels­wei­se mit dem NVIDIA DCGM Exporter.

Fazit

Ku­ber­netes GPU Sche­du­ling ent­wi­ckelt sich von einfachen, ganz­zah­li­gen GPU-An­for­de­run­gen zu einer de­kla­ra­ti­ven Ge­rä­te­ver­wal­tung. Das klas­si­sche NVIDIA Device Plugin bleibt für be­stehen­de und homogene Cluster eine einfache Lösung. MIG ver­bes­sert die Aus­las­tung großer GPUs, indem eine physische GPU in kleinere Instanzen auf­ge­teilt wird.

Für neue, he­te­ro­ge­ne GPU-Platt­for­men bietet DRA jedoch das fle­xi­ble­re Modell. De­vice­Clas­ses abs­tra­hie­ren die Hardware, Re­source­Claims be­schrei­ben den konkreten Bedarf und Re­sour­ceS­li­ces liefern dem Scheduler die not­wen­di­gen Ge­rä­te­in­for­ma­tio­nen. CDI sorgt an­schlie­ßend dafür, dass die aus­ge­wähl­te GPU zu­ver­läs­sig im Container erscheint.

Besonders für NVIDIA-Blackwell-Systeme ist diese Trennung sinnvoll: Eine Anwendung kann gezielt eine B200 anfordern, ohne einen be­stimm­ten Node fest­zu­le­gen.