Kubernetes pro AI workloady: GPU, DRA a plánování úloh v praxi

Proč se o GPU v Kubernetes mluví právě teď

Podle výročního průzkumu CNCF za rok 2025 provozuje Kubernetes v produkci 82 % uživatelů kontejnerů a 66 % organizací, které hostují generativní modely, na něm řídí část nebo veškerou inferenci. Stejný průzkum ale ukazuje i druhou stranu: 44 % respondentů AI/ML workloady na Kubernetes zatím nespouští a modely denně nasazuje jen 7 % organizací.

Jinými slovy: cluster s GPU node poolem dnes postaví skoro každý, ale provozovat na něm AI úlohy efektivně a opakovatelně umí málokdo. Důvod je z velké části technický. Kubernetes byl navržený pro CPU a paměť, tedy zdroje, které se dají dělit a přeplánovat. GPU je drahé, nedělitelné (pokud to výslovně nezařídíte) a úlohy nad ním mají jiné nároky na plánování než webová služba.

Za poslední rok se upstream v této oblasti posunul víc než za několik let předtím. Následující text shrnuje, co je k říjnu 2026 skutečně stabilní, co je beta a co z toho plyne pro AKS a EKS.

DRA: co je stabilní a co ne

Klasický device plugin inzeruje GPU jako celé číslo: uzel má čtyři kusy nvidia.com/gpu, pod si řekne o jeden. Scheduler neví, jaký model karty to je, kolik má paměti ani jak je zapojená. Všechno ostatní se dohání přes labely uzlů, node selectory a oddělené node pooly.

DRA tento model nahrazuje. Driver publikuje zařízení i s atributy do objektů ResourceSlice, administrátor definuje DeviceClass a workload si o zařízení žádá přes ResourceClaim nebo ResourceClaimTemplate s výběrem pomocí výrazů CEL. Jádro tohoto API je v GA od verze 1.34 (srpen 2025); další rozšiřování DRA má podle projektu probíhat bez zpětně nekompatibilních změn.

Aktuální verze 1.37 podle oficiálního shrnutí DRA novinek přinesla do GA podporu „DRA Extended Resource“. To je pro migraci zásadní: DRA driver umí obsloužit i pod, který žádá postaru o nvidia.com/gpu, aniž by vedle něj musel běžet device plugin. Stávající manifesty a Helm charty tak není nutné přepisovat najednou.

Jak vypadá žádost o GPU s alespoň 20 GiB paměti (názvy atributů určuje konkrétní driver, příklad odpovídá NVIDIA driveru):

apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: gpu-20g
spec:
  spec:
    devices:
      requests:
      - name: gpu
        exactly:
          deviceClassName: gpu.nvidia.com
          selectors:
          - cel:
              expression: device.capacity["gpu.nvidia.com"].memory.isGreaterThan(quantity("20Gi"))
---
apiVersion: v1
kind: Pod
metadata:
  name: inference
spec:
  resourceClaims:
  - name: gpu
    resourceClaimTemplateName: gpu-20g
  containers:
  - name: server
    image: registry.example.com/llm-server:1.0
    resources:
      claims:
      - name: gpu

Sdílení GPU: time-slicing, MPS, MIG a co DRA neřeší

Celá karta pro každý pod je nejjednodušší a nejdražší varianta. Pro menší modely, notebooky a vývojová prostředí se GPU sdílí. Příručka osvědčených postupů pro AI/ML na EKS popisuje tři mechanismy:

• Time-slicing – úlohy se na GPU střídají v čase. Nevyžaduje fyzické dělení, ale podle dokumentace „může postrádat izolaci paměti“.
• MPS (Multi-Process Service) – souběžný běh více CUDA procesů na jedné kartě s lepší izolací než time-slicing.
• MIG (Multi-Instance GPU) – fyzické rozdělení karty na izolované instance s vyhrazeným výpočetním výkonem i pamětí. Podporují ho jen některé generace karet (dokumentace jmenuje Ampere, Hopper a Blackwell, tedy např. A100 a H100).

DRA umí část karty popsat a přidělit. Neumí ale vynutit, aby se kontejner přidělení držel. Srpnový článek na blogu CNCF to shrnuje větou, že DRA je „promise tracker“: zaručí, že scheduler neslíbí víc, než zařízení má, ale s kontejnerem, který slib za běhu poruší, nic neudělá. Vynucení limitu paměti musí dodat jiná vrstva – MIG na úrovni hardwaru, nebo softwarové řešení typu HAMi, které zachytává volání CUDA.

Plánování úloh: Kueue, gang scheduling a nativní Workload API

Distribuovaný trénink potřebuje všechny workery najednou. Když scheduler umístí šest z osmi podů a zbylé dva čekají na GPU, šest karet stojí a platí se za ně. Tomu brání gang scheduling – buď se naplánuje celá skupina, nebo nic.

Druhý problém je organizační: kdo smí kolik GPU spotřebovat a kdo čeká ve frontě. Na to výchozí scheduler odpověď nemá. Kueue ji řeší jako nadstavba: rozhoduje, kdy job čeká, kdy je připuštěn a kdy je preemptován. Nabízí kvóty, kohorty s půjčováním nevyužité kapacity mezi týmy, fair sharing a topology-aware scheduling. Integruje se s batch Joby, JobSetem, LeaderWorkerSetem, RayJobem i tréninkovými joby Kubeflow, takže fronta funguje jednotně pro trénink i vícenodovou inferenci.

Novinkou roku 2026 je, že se část této logiky stěhuje přímo do kube-scheduleru. Podle shrnutí k verzi 1.37 se Workload a PodGroup API dostala do bety, stejně jako workload-aware preemption a sdílené DRA ResourceClaimy pro PodGroup. Nově přibylo CompositePodGroup API pro hierarchické skupiny, které má dát nativní podporu strukturám jako JobSet a LeaderWorkerSet.

Co z toho plyne prakticky

• Nativní gang scheduling nahrazuje jen část toho, co dělá Kueue. Kvóty, fronty a půjčování kapacity mezi týmy zůstávají na Kueue nebo jiném batch systému.
• Beta API se může do GA ještě změnit. Pro produkční trénink je dnes bezpečnější sázet na Kueue a nativní API zkoušet v neprodukčním clusteru.
• Pokud máte jeden tým a pár karet, fronta může být zbytečná režie. Smysl dává od chvíle, kdy o GPU soutěží víc týmů nebo víc typů úloh.

EKS a AKS: kde upstream naráží na realitu

Amazon EKS

Dokumentace EKS doporučuje NVIDIA DRA driver pro nová nasazení na Kubernetes 1.34 a novějším, ale s důležitými výjimkami. DRA driver není podporován v EKS Auto Mode a v Karpenteru jen se staticky provisionovanou kapacitou; pro dynamický provisioning v Karpenteru zůstává device plugin. Sdílení GPU (dynamický MIG, MPS, time-slicing) je u DRA driveru označené jako alpha, u device pluginu jako GA.

Dokumentace také varuje, že DRA driver a device plugin nesmí běžet na stejném uzlu – může dojít k tichému přidělení téhož zařízení více podům. Na Bottlerocket AMI je proto nutné vestavěný device plugin vypnout.

Azure AKS

Inženýrský blog AKS popisuje MIG s DRA na clusteru s Kubernetes 1.34 a vyšším. Postup: node pool se vytvoří s volbou --gpu-driver none, aby driver stack spravoval NVIDIA GPU Operator, v operátoru se vypne device plugin a NVIDIA DRA driver se nainstaluje samostatně. Je to funkční cesta, ale celý stack si spravujete sami – včetně kompatibility verzí při upgradu clusteru.

Node pooly, autoscaling a náklady

Největší položkou účtu nebývá špatně zvolený typ instance, ale GPU, které běží naprázdno. Několik pravidel, která platí bez ohledu na cloud:

• Oddělené GPU pooly s taintem. Běžné workloady na ně nesmí zabloudit; systémové DaemonSety potřebují tolerance.
• Šetrná konsolidace. AWS pro úlohy citlivé na přerušení doporučuje v Karpenteru politiku WhenEmpty s delším consolidateAfter; politika WhenEmptyOrUnderutilized může uzly ukončit předčasně a běh úloh prodloužit.
• Spot jen tam, kde přerušení nevadí. AWS uvádí slevu až 90 % proti On-Demand, ale výslovně upozorňuje, že spot není vhodný pro stavové úlohy netolerantní k výpadku. Trénink na spotu tedy vyžaduje checkpointing.
• Rezervace kapacity. Pro instance řady P (a Trainium) nabízí AWS Capacity Blocks for ML, pro řadu G On-Demand Capacity Reservations. U nedostatkových typů je rezervace často jediný způsob, jak kapacitu vůbec získat.
• Více typů instancí. Pool omezený na jediný typ dřív narazí na nedostatek kapacity v regionu.
• Škálování na nulu. Verze 1.37 má HPA scale-to-zero v betě a ve výchozím stavu zapnuté (vyžaduje metriku typu Object nebo External); pro občasně využívané inferenční endpointy stojí za vyzkoušení. Počítejte ale se studeným startem – stažení image a načtení velkého modelu může trvat minuty.

Měřte využití, ne počet přidělených karet. Metriky z GPU (vytížení, obsazená paměť) patří do stejného monitoringu jako zbytek platformy; bez nich nepoznáte, jestli se sdílení vyplatí.

AI Conformance jako kontrolní seznam

CNCF provozuje program Kubernetes AI Conformance, jehož požadavky se verzují spolu s Kubernetes. Seznam pro verzi 1.37 je užitečný i pro firmy, které žádnou certifikaci neplánují: popisuje, co má platforma pro AI umět.

Mezi povinné (MUST) požadavky patří podpora Gateway API pro řízení provozu inferenčních služeb, možnost provozovat alespoň jedno řešení pro gang scheduling, cluster autoscaling node poolů s akcelerátory, funkční HPA pro pody s akcelerátory, metriky akcelerátorů a workloadů, izolovaný přístup ke kartám a spolehlivý běh alespoň jednoho složitého AI operátoru. Mezi doporučené (SHOULD) patří sdílení GPU, Gateway API Inference Extension pro směrování požadavků na modely a sandboxing workloadů.

Poslední bod se podceňuje nejčastěji. GPU stack přidává k upgradu Kubernetes další matici kompatibility; kdo upgrade odkládá, přichází o funkce popsané výše. Přehled podporovaných verzí je na stránce Kubernetes EOL, postup upgradu popisuje upgrade Kubernetes.

Kdy to celé nedává smysl

Vlastní GPU vrstva v Kubernetes není povinná výbava. Pokud firma volá modely přes API poskytovatele a nic sama nehostuje, GPU node pool nepotřebuje. Totéž platí pro jednotky experimentálních úloh měsíčně – spravovaná ML služba cloudu vyjde levněji než provoz operátorů, driverů a front.

Opačný extrém jsou velké tréninkové clustery, kde tradiční HPC plánovače stále nabízejí zralejší nástroje pro dávky. Kubernetes dává největší smysl uprostřed: inference vlastních nebo otevřených modelů, fine-tuning a dávkové zpracování v organizaci, která už Kubernetes provozuje a chce mít AI workloady pod stejnou správou, bezpečnostními pravidly a deployment pipeline jako zbytek aplikací.

A nespěchejte s DRA jen proto, že je GA. Device plugin zůstává podporovaný a v kombinaci s dynamickým autoscalingem je dnes často jedinou podporovanou volbou. Migrace má smysl ve chvíli, kdy potřebujete něco, co celočíselný model neumí: výběr podle atributů karty, jemnější sdílení nebo topologii zařízení.

Klíčové poznatky

• DRA je stabilní API, ne hotové řešení. Jádro je GA od 1.34, extended resource přes DRA od 1.37; zralost driverů a podpora v autoscalerech se liší podle cloudu.
• DRA přiděluje, nevynucuje. Izolaci paměti mezi úlohami na jedné kartě dodá MIG nebo další vrstva, ne scheduler.
• Na EKS rozhoduje způsob provisioningu. Auto Mode a dynamický Karpenter znamenají device plugin; DRA patří na statickou kapacitu.
• Fronty a kvóty řeší Kueue. Nativní Workload a PodGroup API je v 1.37 v betě a pokrývá jen gang scheduling a preempci.
• Náklady určuje nevyužitá karta. Šetrná konsolidace, spot s checkpointingem, rezervace kapacity a měření skutečného využití mají větší efekt než ladění typu instance.
• Seznam AI Conformance poslouží jako audit. I bez certifikace ukazuje, co má platforma pro AI workloady umět.