Kubernetes voor GPU-orchestratie: Beheer van clusters met duizenden GPU's

Bijgewerkt 8 december 2025

Update december 2025: Kubernetes 1.31+ Dynamic Resource Allocation (DRA) is nu GA, wat fijnmazige GPU-partitionering en time-slicing mogelijk maakt. NVIDIA GPU Operator 24.6+ voegt Blackwell-ondersteuning en verbeterd MIG-beheer toe. Kueue (Kubernetes-native job queueing) bereikt productievolwassenheid voor AI-workloads. Run:ai en CoreWeave demonstreren 50.000+ GPU-clusters op Kubernetes. Multi-cluster federatietools (Liqo, Admiralty) maken cross-cloud GPU-orchestratie mogelijk. vGPU-ondersteuning verbetert voor multi-tenant inference-deployments.

OpenAI orkestreert 25.000 GPU's over meerdere Kubernetes-clusters om GPT-modellen te trainen, met behulp van aangepaste operators die automatisch GPU-storingen afhandelen, workloads in realtime herbalanceren en 97% benutting handhaven ondanks hardwarestoringen die gemiddeld elke 2,5 uur optreden.¹ Het infrastructuurteam van het bedrijf ontdekte dat standaard Kubernetes instort bij ongeveer 5.000 nodes zonder uitgebreide aanpassingen, waardoor ze hiërarchische clusterfederatie, aangepaste scheduling-algoritmen en GPU-bewuste autoscaling moesten implementeren die elke H100 van $30.000 behandelt als een kostbare bron die individuele tracking vereist. Het beheren van GPU's op schaal verschilt fundamenteel van CPU-orchestratie—een defecte GPU tijdens gedistribueerde training kan miljoenen aan rekentijd verspillen, terwijl slechte scheduling die GPU's scheidt die via NVLink zijn verbonden een 8x prestatieverslechtering veroorzaakt. De organisaties die succesvol duizenden GPU's op Kubernetes orchestreren, rapporteren 35% betere benutting, 60% snellere deploytijden en 90% reductie in operationele overhead vergeleken met bare-metal beheer.²

Kubernetes domineert containerorchestratie met 88% marktaandeel, maar GPU-ondersteuning kwam laat en blijft uitdagend op schaal.³ De NVIDIA GPU Operator, gelanceerd in 2019, bracht eindelijk enterprise-grade GPU-beheer naar Kubernetes, met functies zoals dynamische driverinstallatie, automatische device plugin deployment en GPU-gezondheidsmonitoring. Organisaties die AI-workloads op Kubernetes draaien moeten navigeren door device plugin-configuraties, node affinity-regels, topologiebewuste scheduling en resource quota's die voorkomen dat enkele teams GPU-bronnen monopoliseren. Toch krijgen degenen die Kubernetes voor GPU-orchestratie beheersen de mogelijkheid om duizenden GPU's als één programmeerbare resource pool te behandelen, met benuttingsgraden en operationele efficiëntie die onmogelijk zijn met traditionele HPC-schedulers.

GPU device plugin-architectuur

Het Kubernetes device plugin-framework maakt GPU-ontdekking, -toewijzing en -gezondheidsmonitoring over clusters mogelijk:

NVIDIA GPU Device Plugin fungeert als de primaire interface tussen Kubernetes en NVIDIA GPU's.⁴ De plugin draait als een DaemonSet op elke GPU-node en registreert GPU's als schedulable resources bij de kubelet. Tijdens initialisatie bevraagt de plugin de NVIDIA Management Library (NVML) om beschikbare GPU's, hun geheugencapaciteit, rekencapabiliteit en interconnect-topologie te ontdekken. De plugin adverteert GPU's naar de Kubernetes-scheduler met de nvidia.com/gpu resourcenaam, waardoor pods GPU's kunnen aanvragen via standaard resourcespecificaties.

Device Plugin-registratiestroom: 1. Plugin start en ontdekt lokale GPU's via NVML 2. Registreert bij kubelet via Unix socket op /var/lib/kubelet/device-plugins/ 3. Adverteert beschikbare GPU's met unieke device-ID's 4. Implementeert Allocate() RPC voor container GPU-toewijzing 5. Monitort GPU-gezondheid en rapporteert storingen aan kubelet 6. Handelt GPU-opruiming af tijdens pod-terminatie

Multi-Instance GPU (MIG) Support maakt partitionering van A100 en H100 GPU's in geïsoleerde instances mogelijk.⁵ Elke MIG-instance verschijnt als een aparte GPU voor Kubernetes, wat fijnmazige resourcetoewijzing mogelijk maakt. De device plugin beheert MIG-profielen en handelt creatie, verwijdering en toewijzing van instances af. Organisaties bereiken 7x betere GPU-benutting door onderbenutte GPU's te partitioneren voor kleinere workloads. MIG-configuratie vereist zorgvuldige planning omdat partitioneringsmodi niet kunnen worden gewijzigd zonder nodes te draineren.

Alternatieve Device Plugins bieden leveranciersdiversiteit: - AMD Device Plugin ondersteunt ROCm-enabled GPU's zoals MI250X - Intel Device Plugin beheert Intel GPU's en Gaudi-accelerators - Xilinx FPGA Device Plugin orkestreert FPGA-resources - Google TPU Device Plugin voor GKE-clusters

Schedulingstrategieën voor GPU-workloads

Effectieve GPU-scheduling maximaliseert benutting terwijl prestaties behouden blijven:

Gang Scheduling zorgt ervoor dat gedistribueerde trainingsjobs alle gevraagde GPU's tegelijkertijd ontvangen. Zonder gang scheduling veroorzaakt gedeeltelijke resourcetoewijzing deadlock—jobs wachten eeuwig op resterende GPU's die nooit beschikbaar komen. Kubernetes scheduler plugins zoals Volcano en Apache YuniKorn implementeren gang scheduling via PodGroups.⁶ Jobs specificeren minimale GPU-vereisten, en de scheduler wijst ofwel alle resources toe of zet de hele job in de wachtrij. Gang scheduling vermindert clusterbenutting met 10-15% maar voorkomt uitgehongerde trainingsjobs.

Topologiebewuste Scheduling optimaliseert GPU-plaatsing op basis van hardware-interconnects. GPU's verbonden via NVLink bereiken 600GB/s bandbreedte versus 32GB/s over PCIe.⁷ De scheduler onderzoekt nodetopologie om gerelateerde pods te plaatsen op GPU's met snelle interconnects. NVIDIA GPU Feature Discovery labelt nodes met topologie-informatie voor affiniteitsregels. Slechte topologiebeslissingen veroorzaken 3-8x prestatieverslechtering voor communicatie-intensieve workloads. Topologiebewustzijn wordt kritiek bij meer dan 8 GPU's per job.

Bin Packing vs Spreading: Bin packing consolideert workloads op minder nodes, verbetert cache-lokaliteit en vermindert netwerkverkeer. Spreading verdeelt werk over nodes voor betere fouttolerantie en thermisch beheer. De optimale strategie hangt af van workloadkenmerken—trainingsjobs profiteren van bin packing terwijl inference spreading verkiest. Dynamische strategieën passen zich aan op basis van clusterbenutting en workloadmix.

Prioriteit en Preemptie: Productieworkloads krijgen hogere prioriteit dan ontwikkeljobs. De scheduler preëmpt pods met lagere prioriteit wanneer resources schaars worden. Zorgvuldige prioriteitsconfiguratie voorkomt dat onderzoeksjobs productie-inference blokkeren. Preemptie-checkpointing zorgt ervoor dat trainingsvoortgang niet verloren gaat. Prioriteitsklassen variëren van systeemkritisch (1000000) tot ontwikkeling (100).

Fair Sharing en Quota's: Resource quota's voorkomen dat enkele teams GPU's monopoliseren. Hiërarchische quota's maken organisatiebrede limieten mogelijk met teamspecifieke sub-quota's. Fair share scheduling zorgt voor billijke resourcedistributie over tijd. Gebruikers die minder resources verbruiken accumuleren credits voor toekomstige burst-capaciteit. Wachtrijsystemen zoals Kueue bieden job queueing met geavanceerde admission control.

Schaalbaarheidsoverwegingen

Het schalen van Kubernetes naar duizenden GPU's vereist architecturale aanpassingen:

Clustergroottebeperkingen: Enkele Kubernetes-clusters ondersteunen maximaal 5.000 nodes voordat etcd-prestaties verslechteren.⁸ API-serverbelasting neemt kwadratisch toe met het aantal nodes door watch-mechanismen. Controller manager-reconciliatie-loops vertragen bij meer dan 1.000 nodes. Netwerkbeleid wordt onhandelbaar op schaal. De meeste organisaties beperken clusters tot 500-1.000 GPU-nodes voor operationele stabiliteit.

Multi-Cluster Federatie: Grote deployments gebruiken meerdere Kubernetes-clusters beheerd via federatie. Admiralty of Virtual Kubelet maken cross-cluster scheduling mogelijk. GitOps-tools zoals Flux of ArgoCD synchroniseren configuraties over clusters. Service mesh-technologieën bieden cross-cluster networking. Federatie voegt complexiteit toe maar maakt horizontale schaling voorbij single-cluster limieten mogelijk.

Hiërarchisch Resourcebeheer: Organiseer clusters hiërarchisch met managementclusters die workloadclusters aansturen. Managementclusters draaien control plane-componenten en schedulinglogica. Workloadclusters hosten GPU-pods zonder complexe controllers. Hiërarchisch ontwerp vermindert de blast radius van storingen. Duidelijke scheiding van verantwoordelijkheden vereenvoudigt troubleshooting.

Custom Resource Definitions (CRDs) voor AI-workloads: - TrainingJob: Definieert gedistribueerde trainingsspecificaties - InferenceService: Beheert model serving deployments - GPUPool: Representeert logische GPU-groeperingen - Checkpoint: Handelt trainingsstatus-persistentie af - ModelVersion: Volgt modeliteraties en lineage

Prestatie-optimalisaties voor schaal: - Schakel ongebruikte admission webhooks uit om API-latentie te verminderen - Implementeer pod topology spread constraints voor gelijkmatige distributie - Gebruik lokale SSD voor containerimages om netwerkbottleneck te vermijden - Schakel CPU manager in voor gegarandeerde CPU-toewijzing - Configureer huge pages voor grote model-geheugenvereisten

Monitoring en observability

Uitgebreide monitoring voorkomt miljoenenverspilling door idle GPU-tijd:

NVIDIA Data Center GPU Manager (DCGM) biedt GPU-specifieke metrics die niet beschikbaar zijn via standaard Kubernetes-monitoring.⁹ DCGM exporteert 100+ metrics inclusief SM-benutting, geheugenbandbreedte, temperatuur, stroomverbruik en ECC-fouten. Prometheus-integratie maakt langetermijnmetriekopslag en alerting mogelijk. Grafana-dashboards visualiseren GPU-prestaties over de hele vloot. Aangepaste alerts detecteren onderbenutte GPU's, thermische throttling en hardwaredegradatie voordat storingen optreden.

Belangrijke GPU-metrics voor Kubernetes-monitoring: - GPU-benutting: Percentage actieve SM's (doel >90%) - Geheugenbenutting: Toegewezen GPU-geheugen versus beschikbaar - Stroomverbruik: Werkelijk versus TDP, indicatie van throttling - Temperatuur: GPU- en geheugentemperaturen - PCIe-bandbreedte: Datatransfersnelheden van/naar GPU - NVLink-verkeer: Inter-GPU communicatiebandbreedte - Trainingsmetrics: Loss-curves, gradiëntnormen, learning rates - Inference-metrics: Requests per seconde, P99-latentie, batchgroottes

Distributed Tracing volgt requests over meerdere GPU's en nodes. OpenTelemetry-instrumentatie legt trainingsstaptijden, data loading-latentie en checkpoint-duur vast. Jaeger of Tempo bieden gedistribueerde trace-opslag en analyse. Correlatie tussen traces en metrics identificeert prestatiebottlenecks. End-to-end zichtbaarheid vermindert gemiddelde oplostijd met 70%.

Log-aggregatie centraliseert logs van duizenden GPU-pods. Fluentd of Fluent Bit verzamelen containerlogs met minimale overhead. Elasticsearch slaat logs op met automatische indexering en retentiebeleid. Kibana maakt logzoeken en analyse over het hele cluster mogelijk. Gestructureerde logging met consistente formaten vereenvoudigt troubleshooting. Alert op foutpatronen die systemische problemen aangeven.

Introl deployt en beheert Kubernetes-clusters voor GPU-orchestratie in ons wereldwijde dekkingsgebied, met expertise in schaling naar 10.000+ GPU-deployments.¹⁰ Onze platform engineering-teams hebben aangepaste operators en scheduling-verbeteringen geïmplementeerd voor optimale GPU-benutting.

Productie-deploymentpatronen

Trainingsclusterarchitectuur bij Anthropic: - Schaal: 4.000 GPU's over 8 Kubernetes-clusters - Topologie: Hiërarchische federatie met centrale scheduler - Opslag: Gedistribueerd Lustre-bestandssysteem voor trainingsdata - Netwerk: RoCE v2-fabric met 200Gbps per node - Scheduling: Aangepaste gang scheduler met topologiebewustzijn - Monitoring: DCGM + Prometheus met 15-seconde scrape-intervallen - Resultaat: 94% GPU-benutting, 50% reductie in trainingstijd

Inferenceplatform bij Uber: - Workload: 500 miljoen voorspellingen dagelijks - Infrastructuur: 2.000 T4 GPU's over 20 regio's - Orchestratie: Kubernetes met Knative voor serverless - Autoscaling: Voorspellende schaling op basis van verkeerspatronen - Load Balancing: Envoy proxy met lowest-latency routing - Optimalisatie: Model caching vermindert cold start tot 2 seconden - Uitkomst: 65% kostenreductie versus vorige architectuur

Hybride Training-Inference bij Spotify: - GPU's: 3.000 gemengde V100/A100/T4-vloot - Scheduling: Time-sliced sharing voor ontwikkeling - Isolatie: Kata containers voor multi-tenant beveiliging - Cos

[Inhoud ingekort voor vertaling]