Red Hat shows how Kueue 1.4 can curb queue starvation on shared OpenShift clusters

Red Hat has published a hands-on configuration guide for admission fair sharing in Red Hat build of Kueue 1.4, aimed at platform teams running AI and high-performance computing jobs against a shared pool of scarce CPUs or GPUs.

The problem is familiar on multi-tenant clusters: a first-in, first-out queue can let one tenant dominate available quota while later workloads wait. Admission fair sharing changes the ordering decision by accounting for each tenant’s historical resource use. A queue that has consumed less over time is favored when capacity becomes available.

Fairness without evicting active jobs

The important distinction is that admission fair sharing changes which waiting workload starts next; it does not remove a workload that is already running. Red Hat contrasts that behavior with fair sharing-based preemption, which can evict active pods.

The feature operates across LocalQueue objects that feed a common ClusterQueue. Kueue combines recorded consumption with an immediate admission penalty, then adjusts the result by the local queue’s configured weight. That penalty is intended to stop one tenant from submitting a burst and taking several consecutive admission slots before usage statistics catch up.

Red Hat’s OpenShift 4.22 documentation lists admission fair sharing as an enhancement in Red Hat build of Kueue 1.4. The release is generally available on OpenShift Container Platform 4.18 and later and is based on upstream Kueue 0.18.

What platform teams configure

Administrators enable the feature in the cluster-scoped Kueue custom resource, then set UsageBasedAdmissionFairSharing on the shared ClusterQueue. The default configuration uses a 30-minute usage half-life, a five-minute sampling interval and equal resource weights. A custom mode allows teams to change those parameters and assign different weights to resources such as CPU.

The new guide walks through two local queues competing for a single CPU. After a job from the first queue consumes the quota, removing it causes the scheduler to admit a waiting job from the lower-use queue. Historical consumption then decays according to the configured half-life.

There are two operational limits to note. Usage-based ordering applies only when tenants share the same ClusterQueue; separate cluster queues do not contend with each other and therefore are not reordered by this feature. Admission fair sharing also takes precedence over Kubernetes priority classes, with priority used only as a tiebreaker when queues have equal usage.

For platform teams, that makes the feature most relevant where several groups intentionally share an expensive resource pool. It offers a way to reduce long-term starvation without disrupting active training, evaluation or batch workloads—but it also means queue topology, history decay and weights become part of the cluster’s scheduling policy and should be tested before production rollout.