Volcano 1.16.0 introduces a set of scheduling enhancements that directly affect how multi‑tenant clusters are managed. The release adds NamespaceQueue for per‑namespace queue hierarchies, a fairshare plugin that decays historical usage, an UnschedulableJobCache to skip redundant checks, and broader HyperNode integration, while also supporting Kubernetes 1.36 and tightening node‑scoring paths.
Namespace‑scoped queues and fairshare
Traditional Volcano deployments rely on cluster‑scoped queues to allocate resources. NamespaceQueue creates a namespaced resource that mirrors the queue model (capability, deserved, guarantee, reclaimable) but lives inside a namespace. Administrators must list allowed namespaces in spec.allowedNamespaces, after which tenants can build their own hierarchy and quotas within that boundary. This isolates queue management to the tenant’s domain while still tying it to an authorized cluster‑wide pool.
The new fairshare plugin brings a Slurm‑inspired decay algorithm. It records each namespace’s past consumption and reduces its weight over time, allowing teams that have previously used more resources to be scheduled less aggressively when they share a queue. The effect is a smoother long‑term balance without manual quota adjustments.
Unschedulable Job Cache and performance gains
Large pending backlogs often cause the scheduler to repeatedly evaluate jobs that cannot run because of full queues, missing resources, or placement constraints. The UnschedulableJobCache records the rejection reason and, when plugins provide safe hints, skips the full evaluation in subsequent cycles. Cache entries are cleared on scheduler restart and expire after a configurable maximum skip duration (default five minutes). A watchdog forces a retry after expiration.
Additional refinements reduce object copying during node scoring and queue lookups, and allow multiple scoring plugins to share a traversal. The combined effect is lower CPU usage and faster turnaround for both new and cached jobs.
HyperNode ecosystem and topology anti‑affinity
Volcano now ships a standalone HyperNode controller that discovers cluster topology, builds supernode hierarchies, and exposes them via the HyperNode API. Schedulers other than Volcano can reuse this information, enabling a common view of failure domains.
For inference workloads that use Volcano, new PodGroup topology anti‑affinity rules let you require or prefer spreading pods across distinct supernodes. This reduces the risk that a single hardware or network failure takes down an entire model serving deployment.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
Teams should evaluate whether their tenancy model aligns with NamespaceQueue and, if so, enable the feature (it is disabled by default) and configure spec.allowedNamespaces to delegate queue control. Activating the fairshare plugin can improve fairness without revisiting static quotas.
Clusters with persistent pending jobs will benefit from turning on the UnschedulableJobCache via the scheduler feature gate. Monitor cache metrics for skips, wake‑ups, and watchdog expirations to tune the maximum skip duration.
Deploy the HyperNode controller if you run mixed‑scheduler environments or need explicit supernode awareness for high‑availability inference services. Define required or preferred PodGroup anti‑affinity rules to spread critical workloads.
Finally, verify compatibility with Kubernetes 1.36 and test the updated node‑scoring path in a staging environment before rolling out to production, as the internal traversal changes may affect custom scoring plugins.
