Yunikorn

What it is

Apache YuniKorn is a resource scheduler for Kubernetes built specifically to handle batch, data processing, and ML workloads — the stuff the default kube-scheduler wasn't designed for. It replaces or augments the default scheduler with features like hierarchical resource queues, gang scheduling (all-or-nothing pod placement for distributed jobs like Spark or TensorFlow), fair/capacity-based resource sharing across tenants, and preemption policies. If you've used YARN's capacity scheduler and wondered why Kubernetes doesn't have an equivalent for multi-tenant batch workloads, YuniKorn is that answer.

Who builds it and why

YuniKorn is an Apache Software Foundation project (top-level, not incubating), originally seeded by engineers who came out of the Hadoop/YARN ecosystem and wanted YARN-style scheduling semantics on Kubernetes as organizations moved big-data and ML workloads off legacy clusters. It's maintained as a community project under Apache governance rather than a single vendor. 106 contributors on GitHub is a healthy number for a scheduler-class project — this is infrastructure-critical code, and broad contribution reduces single-vendor risk. CNCF maturity level is not publicly available (it lives under Apache, not CNCF, so this distinction matters if you're checking a CNCF landscape checklist).

Production readiness signal

Latest release is v1.8.0 — an actively iterating major version line, not a 0.x experiment. Last commit dated 2026-07-01 (per provided data) and 1,016 GitHub stars suggests a maintained but relatively niche project — stars are modest compared to broadly-adopted CNCF projects, but scheduler tooling tends to have a smaller, more specialized user base than, say, ingress controllers or service meshes. Written in Go, Apache-2.0 licensed, no vendor lock-in on the license side. 106 contributors is a solid signal of real-world usage beyond a single company's internal fork. What's missing from public data: founding date, adoption case studies at scale, and CNCF maturity tier — if you need due-diligence-grade proof for a procurement process, you'll have to go get user references directly rather than relying on badges.

Who should use this

• Platform teams running Spark, Flink, Ray, or distributed ML training (Kubeflow, PyTorchJob) on Kubernetes who need gang scheduling — without it, distributed jobs can deadlock waiting for partial pod placement.
• Multi-tenant clusters where you need queue-based resource guarantees (team A gets 40% of cluster capacity, team B gets 30%, etc.) rather than best-effort scheduling.
• Teams migrating batch workloads off YARN/Hadoop who want familiar capacity-scheduler semantics.
• Organizations running mixed batch + long-running service workloads on the same cluster and needing the scheduler to differentiate between them.

Who should NOT use this

• Small clusters running mostly stateless web services — you don't need gang scheduling or hierarchical queues for a fleet of microservices; the default kube-scheduler is simpler and has less operational overhead.
• Teams without dedicated platform engineering capacity — YuniKorn requires understanding queue configuration, scheduling policies, and how it interacts with cluster autoscalers. It's not a drop-in.
• Shops already deeply invested in Kueue (the newer, more Kubernetes-native batch queueing project gaining SIG-backing) — running two competing batch schedulers is asking for conflicts.
• Anyone expecting a managed/hosted offering with SLAs — this is self-operated OSS; you own the upgrade path and the failure modes.

Alternatives

• Kueue — Kubernetes SIG-batch's own job-queueing system, increasingly seen as the "native" answer and gaining more momentum inside the K8s ecosystem itself.
• Volcano — CNCF-hosted batch scheduler with similar gang-scheduling and queue features, more explicitly tied to the CNCF landscape.
• Default kube-scheduler + scheduler plugins — viable if your batch needs are minimal and you don't want to operate a second scheduler.

Pricing

Fully open source, Apache-2.0. No paid tier, no vendor. You run it, you maintain it.