When jobs keep waiting in a shared GPU cluster, GPU count is only part of the problem. Who controls team quotas, and who receives resources when they become available, can also change the outcome.

The CNCF article published on October 28, 2026 introduces NamespaceQueue and fairshare in Volcano v1.16.0. The version itself was released on October 14, 2026; these are different dates.

For operators running Kubernetes compute infrastructure for multiple teams, the starting point is deciding which problem each feature addresses. Following queue ownership, fairness over time, and physical placement reveals both the opportunities and the limits of this release.

NamespaceQueue separates pool authorization from team queue management

Cluster-scoped Queues suit deployments that allocate resource pools to individual teams. When a Namespace is the team boundary, however, teams may want to manage their own training and inference queues inside it.

NamespaceQueue provides that namespace-local resource. Administrators authorize attachment through the parent Queue's spec.allowedNamespaces; tenants manage their hierarchy within their own namespace. Pool authorization and everyday queue management can therefore belong to different people.

For a Job in team-a, references have distinct meanings:

Field	Example value	Target
Job spec.queue	training	Cluster-scoped Queue
Job spec.queue	namespace/training	NamespaceQueue in the same namespace
NamespaceQueue spec.parent	cluster/research	Parent cluster Queue

Existing unprefixed references do not automatically switch to NamespaceQueues. Tenants also need RBAC permissions for namespacequeues, and operators should verify Ready=True and Authorized=True. The v1.16.0 NamespaceQueue guide identifies the feature as Alpha and disabled by default.

It requires hierarchical capacity; custom scheduler configurations need enableHierarchy: true. It cannot run alongside proportion. Moving from weighted allocation therefore also requires reviewing the capacity model, which uses explicit resource quantities for borrowing and lending.

fairshare adds resource history to current allocation

Delegated queue management does not resolve every fairness problem. When several namespaces submit into one Queue, a team continuously submitting GPU jobs can repeatedly replace its completed jobs while a later arrival waits.

fairshare accumulates resource consumption over time for each namespace within a queue and gives lower historical consumers earlier consideration. It complements DRF's view of current allocation; it does not replace resource balancing across queues.

History decays exponentially, with a default half-life of four hours. The design document gives the formula usage × 2^(-elapsed / halfLife). Without additional consumption, the contribution of existing history halves after four hours and falls to one quarter after eight. This is a calculation from the formula, not a prediction of job waiting time.

fairshare changes pending-job ordering and can optionally gate enqueue admission. It cannot take GPUs away from running jobs. A cluster occupied by long-running jobs therefore offers no immediate-start guarantee to later arrivals.

Configuration order matters: the first plugin that returns a nonzero comparison decides the ordering. Put fairshare before drf to let history influence that decision, and keep priority earlier when PriorityClass should take precedence. The v1.16.0 fairshare guide explains this behavior.

fairshare.persistState, which preserves history across restarts using a ConfigMap, defaults to false. For an operational trial, narrow the target queues and resource type, then compare ordering before and after a restart with the intended persistence configuration.

HyperNode separates execution order from failure-domain placement

Choosing the next job does not prevent inference instances from sharing a supernode and its potential failures. PodGroup topology anti-affinity in v1.16 separates different PodGroups across domains represented by HyperNode.

required makes separation mandatory; preferred favors it while allowing a shared domain. Required rules can leave Pods Pending when suitable domains or resources are unavailable, so operators must choose between mandatory separation and placement flexibility. Selectors match PodGroup labels, not Pod labels. See the PodGroup Anti-Affinity guide.

Enforcement applies to allocate. BestEffort Pods placed through backfill do not receive the same isolation guarantee, and running Pods are not automatically relocated. An inference deployment therefore needs a review of its members' scheduling paths as well as its PodGroup policy.

Platforms using another scheduler can also use the standalone HyperNode controller for topology discovery and management without running the rest of Volcano. The consuming scheduler must implement placement integration. When migrating from the integrated controller, switch through disabled, wait for rollout completion, and then enable standalone to avoid competing reconciliation owners.

Validate allocation and placement policies when upgrading to v1.16

Update CRDs and RBAC alongside the components before using NamespaceQueue or the new PodGroup fields. The new NamespaceQueue CRD lacks the Helm uninstall retention annotation in v1.16.0. If your upgrade procedure includes reinstalling, inspect retention and ownership first. These details appear in the official upgrade notes.

Performance improvements also depend on allocation settings. The new Unschedulable Job Cache records rejection reasons to avoid unnecessary retries, but is Alpha and disabled by default. It does not cache hierarchical capacity rejections—the mode NamespaceQueue requires. The cache guide explains that safely tracking resource releases through parent and sibling queues requires additional information.

Fixes also affect the upgrade decision. GHSA-j38h-7pfq-cxmw, involving DRA capacity accounting that can block scheduling, affects v1.15.0 and v1.15.1; the fix is included in v1.15.2 and v1.16.0. Operators of affected deployments should check the advisory's prerequisites and assess a patched-version upgrade separately from adopting new features.

The practical starting point is identifying whether waiting stems from team resource management, ordering within a shared queue, or eligible placement domains. NamespaceQueue addresses delegated management, fairshare brings historical consumption into ordering, and PodGroup policies address instance separation. Testing the change that matches the actual reason jobs wait gives a concrete basis for adopting v1.16.

Source

• Title: Volcano v1.16 Released: NamespaceQueue, fairshare, and a broader HyperNode ecosystem
• URL: https://www.cncf.io/blog/2026/10/28/volcano-v1-16-released-namespacequeue-fairshare-and-a-broader-hypernode-ecosystem/