Volcano v1.16 发布：NamespaceQueue、fairshare 与更广泛的 HyperNode 生态
内容提要
Volcano v1.16.0 发布，新增 NamespaceQueue，支持租户在命名空间内管理队列层级与配额；fairshare 插件按命名空间追踪历史资源消耗，提升共享队列的长期公平性。调度器引入不可调度 Job 缓存以减少重复检查，并优化节点打分与队列查询。HyperNode 控制器可独立部署，供其他调度器复用拓扑发现；新增 PodGroup 拓扑反亲和，用于分散推理实例。此外支持 Kubernetes 1.36 与 DRA 打分。
延伸解读
NamespaceQueue 与 fairshare 的互补关系
NamespaceQueue 让租户在命名空间内管理队列层级与配额，而 fairshare 则按命名空间追踪历史资源消耗，在共享队列中提升长期公平性。两者都面向以命名空间为管理边界的场景，但前者解决配额与层级组织，后者解决时间维度上的公平。文章指出 fairshare 不影响已运行作业，只影响待调度作业排序，且需放在 drf 之前以发挥历史使用量的作用。
不可调度 Job 缓存的实际收益与边界
该缓存记录 Job 无法调度的原因，并在相关条件变化前跳过重复检查，从而减少大规模积压下的无效重试。文章强调它默认关闭，且仅当所有拒绝插件都提供安全提示时才缓存；分层容量拒绝和缺少提示的插件仍每次评估。缓存有默认五分钟的看门狗重试，调度器重启后清空，因此它优化的是重复检查开销，而非改变调度语义。
PodGroup 拓扑反亲和解决的是实例间隔离
文章指出，仅让每个实例满足自身拓扑约束，并不能保证不同实例落在不同域，多个推理副本仍可能挤在同一超节点，共享故障域风险。新增的 required 和 preferred 反亲和规则按 PodGroup 标签选择对等组，可与 networkTopology 组合使用。需注意规则匹配的是 PodGroup 标签而非 Pod 标签，且仅对 allocate 生效，BestEffort 回填的 Pod 不获得该隔离保证。
独立 HyperNode 控制器扩大了复用范围
此前复用 HyperNode 需要运行 Volcano 的聚合控制器管理器，v1.16.0 允许单独部署 HyperNode 控制器，其他调度器可通过 HyperNode API 读取拓扑与超节点层级，自行实现拓扑感知放置。文章提醒迁移时先切换到 disabled 模式并等待控制器管理器滚动完成，再启用 standalone，以确保只有一个协调者。该模式与集成模式共享发现和协调实现，便于后续能力共用。
Q&A
Volcano v1.16 的 NamespaceQueue 是什么，租户怎么用？
NamespaceQueue 是命名空间级别的队列资源，让租户在自己的命名空间内管理队列层级和配额。管理员通过集群 Queue 的 spec.allowedNamespaces 授权命名空间，租户即可在该边界内创建 NamespaceQueue，设置 capability、deserved、guarantee、reclaimable 等资源治理字段，并通过 parent 字段挂到集群 Queue 下。不同命名空间可以使用相同队列名而互不共享身份。该功能默认关闭，需通过 Helm 参数 custom.namespace_queue_enable=true 启用。
fairshare 插件如何提升共享队列的长期公平性？
fairshare 插件按命名空间识别租户，在共享队列内追踪每个命名空间累计的资源秒消耗，并让消耗按指数衰减（半衰期默认 4 小时）。历史消耗较低的命名空间会获得更早的调度考虑，旧使用量逐渐失去影响。它补充 DRF 的当前资源公平性，影响待调度 Job 的排序，可选地控制入队准入，但不会抢占已运行的 Job。可通过参数指定目标队列、资源类型，并可选将状态持久化到 ConfigMap。
Unschedulable Job Cache 是怎么减少重复调度检查的？
当 Job 因队列满、资源不足或放置约束无法调度时，调度器会在每次会话重复相同检查。UnschedulableJobCache 记录 Job 不可调度的原因，插件提供事件提示标识可能使其可调度的事件变化；后续会话跳过缓存结果覆盖的检查，直到相关变化触发重试。它支持选择性跳过、事件驱动唤醒（如节点标签更新、资源释放、队列变化）、安全回退（仅当所有拒绝插件都提供安全提示时才缓存），并保留调度语义。默认关闭，需启用特性门控 UnschedulableJobCache=true。
PodGroup 拓扑反亲和能解决什么问题，怎么配置？
它解决多个工作负载实例各自满足网络局部性却仍落在同一 HyperNode 域、导致共享故障域风险的问题。group-topology-affinity 插件为 PodGroup 增加跨 HyperNode 域的必需和首选反亲和规则，规则按 PodGroup 标签（可选命名空间）选择对等组，并与 networkTopology 组合，使每组保持在一起而不同组使用不同域。配置时在 PodGroup 的 spec.topologyAffinity.podGroupAntiAffinity 下设置 required 或 preferred 规则，指定 topologyTierName 或 topologyTier；成员 Pod 需使用 schedulerName: volcano 和 group-name 注解。
HyperNode 控制器可以独立部署吗，对其他调度器有什么好处？
可以。v1.16.0 使 HyperNode 控制器可独立部署，提供专用的 vc-hypernode-controller-manager 二进制、镜像和 Helm Deployment。使用其他调度器的平台可以只部署该控制器，复用现有发现方式（如 UFM 和节点标签）来发现拓扑、管理超级节点及其层级，再通过 HyperNode API 读取信息并实现拓扑感知放置，而无需运行 Volcano 调度器或其他控制器。独立与集成部署共享发现和协调实现。
升级到 Volcano v1.16.0 需要注意哪些事项？
通过 Helm 或 release manifest 升级，并在使用 NamespaceQueue 或新 PodGroup、Numatopology 字段前更新 CRD 和 RBAC。NamespaceQueue 和 UnschedulableJobCache 默认关闭；NamespaceQueue 需要分层容量，且该缓存版本不缓存分层容量的拒绝。启用 fairshare 和拓扑反亲和前需检查插件顺序与执行范围。自定义拓扑插件需针对 HyperNodeGradientResult 重新构建，并审查 Kubernetes 1.36 集成变更。源码构建需要 Go 1.26。将 HyperNode 协调迁移到独立控制器时，先滚动到 disabled 模式再启用 standalone。
