Kueue

What it is

Kueue is a Kubernetes-native job queueing controller. It sits on top of the standard scheduler and adds what Kubernetes doesn't have out of the box: quota management, job admission control, and fair-share scheduling across teams and workloads. Instead of pods getting scheduled the moment they're created, Kueue holds jobs in a queue and only admits them when there's enough quota and capacity — which is exactly what you need for batch, HPC, and AI/ML training jobs where you can't afford partial admission or resource starvation between teams.

It works with existing job APIs (Kubernetes Job, JobSet, and integrations for Kubeflow, Ray, MPI, Spark) rather than replacing them. You define ClusterQueues and LocalQueues, set resource flavors and borrowing/lending policies, and Kueue handles the admission logic.

Who builds it and why

Kueue is a Kubernetes SIG project (sig-scheduling), not a vendor product. It grew out of a real gap: Kubernetes' default scheduler assumes "run this pod now if there's room," which doesn't work for multi-tenant batch clusters where you need to enforce quotas, prevent one team from starving another, and queue jobs until resources free up. The 299 contributors and active commit history point to a genuinely community-driven project rather than one company's open-core play with a thin OSS layer.

Production readiness signal

CNCF maturity level is not publicly available in the data provided — check the CNCF landscape directly for current sandbox/incubating/graduated status. That said, the operational signals are solid: 299 contributors is a large base for an infra project this specific, commit activity is current, and it's on release v0.18.2, indicating it's past the "0.1 experimental" stage and has gone through multiple iterations of API stabilization (CRDs like ClusterQueue and LocalQueue have matured across versions). Apache-2.0 licensing is standard and unencumbered. Star count (2657) is modest compared to general-purpose tools, which tracks — Kueue solves a narrow, deep problem for platform teams running batch/ML workloads, not a broad developer-facing concern.

Who should use this

• Platform teams running shared Kubernetes clusters for ML training or HPC workloads where multiple teams compete for GPU/CPU quota.
• Anyone currently hacking quota enforcement together with ResourceQuotas + custom controllers or admission webhooks — Kueue formalizes this.
• Teams already using Kubeflow, Ray, Spark on Kubernetes, or JobSet who need queueing and fair-share on top.
• Organizations that need cost/capacity accountability across teams (borrowing/lending quota between ClusterQueues) without building it themselves.

Who should NOT use this

• Single-tenant clusters or small teams with one workload type — Kueue adds operational overhead (CRDs, controller, queue config) with no payoff if you don't have contention.
• Teams needing full HPC schedulers with gang scheduling, backfilling, and topology-aware placement at the level of Slurm — Kueue's scheduling logic is simpler and newer; it's not a Slurm replacement for tightly-coupled MPI workloads with strict co-scheduling needs.
• Anyone expecting a managed, supported product with an SLA — this is a community project; you own the operational burden.
• Workloads that are purely stateless services or web apps — Kueue is built for batch semantics (start/complete/queue), not long-running services.

Alternatives

• Volcano — CNCF batch scheduling project with gang scheduling and more HPC-oriented features; more mature in some scheduling algorithms but heavier to operate.
• Apache YuniKorn — Kubernetes scheduler focused on big data/batch workloads (Spark, Flink) with hierarchical queues, competes directly in the batch scheduling space.
• Slurm-on-Kubernetes hybrids (e.g., Slinky) — for teams unwilling to give up Slurm semantics but wanting Kubernetes as the substrate.

Pricing

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