# Volcano v1.16.0 Is Here: Smarter Scheduling, Better Fairness, and a Broader Ecosystem
The Volcano project has announced the release of version 1.16.0, a significant update packed with new scheduling capabilities, performance optimizations, and expanded support for diverse platform architectures. This release is designed to help organizations running Kubernetes at scale manage resources more efficiently and fairly across teams and workloads.
## What’s New in This Release?
### Hierarchical Queues Within Namespaces
One of the headline features is **NamespaceQueue**, which brings queue hierarchies directly into Kubernetes namespaces. This means that tenants—teams or projects—can now organize their own quota structures and queue hierarchies within resource pools that administrators have explicitly approved. Rather than relying solely on cluster-wide queues, teams gain ownership over their scheduling boundaries while still operating within the guardrails set by platform administrators. Each namespace can use its own queue names independently, so different teams can have identically named queues without any conflict.
### Smarter Fairness with Historical Usage Tracking
The new **fairshare** plugin introduces a Slurm-inspired approach to long-term fairness. Instead of looking only at current resource allocation, fairshare tracks cumulative resource consumption over time for each namespace sharing a queue. Usage gradually decays with a configurable half-life (defaulting to four hours), so namespaces that have consumed fewer resources in the past get prioritized. This prevents a single team from dominating shared resources simply because they keep submitting work, while still ensuring that teams who haven’t used much recently aren’t unfairly disadvantaged. Fairshare can influence how pending jobs are ordered and can optionally control whether new jobs are admitted into a queue.
### Faster Scheduling with Smart Caching
Clusters with large numbers of unschedulable jobs often waste significant scheduling cycles rechecking the same impossible conditions. The **Unschedulable Job Cache** solves this by recording exactly why a job could not be scheduled and skipping redundant checks until something changes—such as a node label update, a resource release, or a queue capacity change. This feature reduces workload on the scheduler and frees up capacity for newly submitted jobs that are ready to run. It is designed with safe fallbacks, so jobs that don’t meet the caching criteria continue through normal evaluation without any risk.
### Spreading Workloads Across Failure Domains
For inference and other replicated workloads, it’s critical that multiple instances don’t end up on the same physical or logical hardware. The **PodGroup topology anti-affinity** feature adds required and preferred rules that spread PodGroup instances across HyperNode domains. This ensures that if one supernode fails, other replicas remain healthy and available. The rules work alongside existing network topology settings, so groups stay together locally while different groups occupy separate failure domains.
### HyperNode Controller Goes Independent
Volcano’s HyperNode technology, which helps platforms discover and manage supernode topologies, now has a **standalone controller** that can be deployed independently. Platforms using non-Volcano schedulers can deploy just this controller to discover cluster topology, manage supernode hierarchies, and expose that information through a standard API. This opens the door for a wider range of scheduling systems to take advantage of HyperNode’s topology awareness without needing to run the entire Volcano stack.
### Broader Compatibility and Performance
The release also adds support for **Kubernetes 1.36**, introduces load estimation for bulk pod dispatch, improves DRA (Dynamic Resource Allocation) scoring, enhances accelerator support, and delivers various stability and correctness fixes. Node scoring, cache updates, and queue lookups have all been made more efficient, contributing to better overall scheduler performance in large clusters.
—
## Frequently Asked Questions
**Q: Is NamespaceQueue available by default after upgrading?**
A: No. NamespaceQueue is disabled by default and must be explicitly enabled through the Helm configuration using the `custom.namespace_queue_enable` flag.
**Q: How does the fairshare plugin differ from the existing DRF (Dominant Resource Fairness) plugin?**
A: DRF makes fairness decisions based on current resource allocation snapshots. Fairshare goes further by incorporating historical usage over time, giving long-term consumption patterns a voice in scheduling decisions. They complement each other and can be used together.
**Q: Can I use the Unschedulable Job Cache with all queue types?**
A: The cache works with native Resource Fit, proportion, and non-hierarchical capacity. Hierarchical capacity rejections and rejections from plugins that don’t provide hinting are still evaluated every session and are not cached.
**Q: Does the PodGroup topology anti-affinity feature work with all pod types?**
A: It applies during the allocation phase. BestEffort pods that are placed through backfill do not receive the isolation guarantee. It also does not handle running pod relocation or cross-PodGroup affinity rules.
**Q: Can I use the standalone HyperNode controller alongside an existing Volcano deployment?**
A: Yes, but the recommended migration path is to first switch the HyperNode mode to `disabled`, wait for the controller-manager rollout to complete, and then enable `standalone` mode. This ensures a clean handoff with a single reconciliation owner.
**Q: What Go version is required if I want to build from source?**
A: Go 1.26 is required for source builds in this release.
—
## Final Thoughts
Volcano v1.16.0 represents a meaningful step forward in making Kubernetes batch scheduling more intelligent, equitable, and adaptable. Whether you’re a platform operator looking to give tenants more control over their resources, a team needing fairer access to shared GPU clusters, or an infrastructure provider wanting to extend topology-aware scheduling to a different scheduler ecosystem—this release has features that address real-world multi-tenancy challenges head-on.
The performance improvements alone make it worth upgrading for clusters that regularly deal with large backlogs of pending work. Combined with the new fairness mechanisms and broader HyperNode support, v1.16.0 strengthens Volcano’s position as a leading scheduling solution for high-performance and batch workloads on Kubernetes.
Thank you for reading
