Volcano Agent Scheduler 设计解析面向 AI Agent 负载的 Kubernetes 快速路径调度器【免费下载链接】volcanoA Cloud Native Batch System (Project under CNCF)项目地址: https://gitcode.com/GitHub_Trending/vol/volcano本文以 Volcano 项目设计文档 docs/design/agent-scheduler.md 为主体结合 pkg/agentscheduler、cmd/agent-scheduler 等仓库源码展开。读者将完整理解 Agent Scheduler 的提出动机、总体架构、调度队列、多 Worker 并行调度与 Binder 冲突解决机制、NodeShard 分片同步机制以及 none/soft/hard 三种分片模式的配置方法并掌握从 Helm 部署到启动参数调优的完整实操路径。一、背景与问题为什么 Volcano 需要一个 Agent SchedulerVolcano Scheduler 是为大数据、HPC、ML、AI 框架等批量和弹性负载设计和优化的调度器提供高性能调度以及丰富的调度策略与算法。但并非所有负载都需要批式调度特性——有些负载的调度诉求恰恰是 Volcano 现有模型难以满足的。文档以AI Agent 负载为例指出两个核心矛盾延迟敏感与高频建任务Agent 负载延迟敏感、任务创建频繁。调度器必须处理海量任务并做到超快调度在保证高吞吐的同时维持单任务低调度延迟当 Agent 负载与其他负载混部在同一集群时延迟同样需要被保障。而 Volcano 调度器在每个调度会话内按固定时间间隔批量处理负载Pod 无法被立即调度存在其他负载时任务必须按序排队调度延迟无法得到保证。调度策略差异化Agent 的调度策略可能与其他负载不同。Agent 负载可能不需要拓扑打散topology spread或 Pod 亲和pod affinity反而可以调度到资源较小或碎片化的节点上从而更好地利用资源碎片、提升集群整体效率。这要求不同负载能够配置不同的调度策略。从源码结构看Agent Scheduler 的入口位于 cmd/agent-scheduler/main.go其核心调度逻辑集中在 pkg/agentscheduler/scheduler.go 中定义的AgentScheduler它是一个独立的调度器进程通过--scheduler-name默认agent-scheduler识别并接管spec.schedulerName与其一致的 Pod见 cmd/agent-scheduler/app/options/options.go。二、设计目标与总体架构设计目标文档明确了两个设计目标能快速调度海量 Pod 的调度器通过工作流优化与策略简化提升调度效率。能与 Volcano 调度器协作、处理不同类型负载的调度器通过基于分片shard的并行调度实现调度器之间的协作与资源管理。架构总览系统引入一个独立的Agent Scheduler来识别并对 Agent 负载做快速调度。它通过优化调度策略与即时调度in-time scheduling提升单个 Pod 的调度速率并通过多 Worker 并行调度进一步提升整体调度吞吐。当 Agent 负载与其他负载共存时Sharding Controller根据资源阈值、节点类型等策略动态将节点划分为分片各调度器通过分片同步获得可调度节点并选择/优选出对应节点进行调度从而实现多调度器基于不同分片的并行调度。分片控制器设计与分片策略详见 sharding controller design and shard strategy。架构中的三个核心组件Sharding Controller根据集群节点资源状态与分片策略动态将集群节点分配到不同分片。Agent Fast-Path Scheduler对对应分片内的 Pod或优先在分片内执行快速调度。它使用并发调度多 Worker提升任务吞吐并优化调度流程与策略以提高调度效率。Volcano Scheduler支持与 Agent Scheduler 对不同类型负载做协同调度。引入 Sharding Coordinator 从 NodeShard 同步节点一旦启用分片调度Volcano Scheduler 也在对应分片内或优先在分片内调度 Pod。三、调度框架Scheduler、Worker、Framework、Snapshot、Action 与 PluginAgent Scheduler 的调度框架包含完整的调度工作流、调度队列以及 Plugin/Action 机制设计。组件层次结构系统架构依赖严格的层次关系与初始化顺序Scheduler顶层组件管理整个调度系统的生命周期拥有 Cache、配置Configurations和 Worker Pool。Worker并发调度单元。每个 Worker 相互独立各自持有独立的 Framework 实例。多个 Worker 会同时从中央调度队列取出 Pod 进行调度采用乐观并行调度optimistic parallel scheduling。FrameworkWorker 内插件的运行环境持有 Plugin 与 Action 的注册表并维护该 Worker 当前调度周期专属的集群状态Snapshot。Snapshot由全局 Cache 派生的集群状态节点、Pod 等的时间点视图。每个 Worker 在调度周期开始时更新自己的 Snapshot 以保证一致性。Action定义高层调度逻辑如 Allocate按照既定顺序编排多个 Plugin 的执行。Plugin实现具体调度算法如 Predicates、NodeOrder注册在 Framework 中并由 Action 调用。初始化序列初始化过程从Scheduler开始首先建立全局Cache与 Kubernetes API server 同步然后加载调度配置以确定启用的 Action 与 Plugin随后初始化Worker Pool。每个Worker被创建时都会实例化一个独立的Framework。运行时Worker 在开始一个调度周期前先从全局 Cache 更新其 Framework 的Snapshot为后续 Action 与 Plugin 的执行提供一致视图。这段设计与源码完全对应在 pkg/agentscheduler/scheduler.go 的Run中调度器先loadSchedulerConf()加载配置随后sched.cache.Run(stopCh)启动 Cache再循环创建workerCount个Worker每个 Worker 通过framework.NewFramework(...)创建独立的 Framework 实例并启动独立的 goroutine 循环执行worker.runOnce()。而 runOnce 中先执行worker.framework.Cache.UpdateSnapshot(snapshot)更新 Snapshot再依次执行各 Action——这正是周期开始时更新 Snapshot的直接实现。SchedulingContext中携带了Task、QueuedPodInfo与NodesInShard分片内节点集合见 pkg/agentscheduler/api/types.go。四、调度队列activeQ、backoffQ 与不可调度 Pod 池设计渊源调度队列的设计大量借鉴并直接参考了成熟的 kube-scheduler 队列架构。由于 Volcano 快速路径调度器的设计目标与 kube-scheduler 的队列管理原则高度一致选择在这一成熟架构之上快速构建面向 Agent 负载的健壮、高效的调度框架。队列架构调度队列管理 Pod 的执行顺序由三个组件构成ActiveQ存放立即可调度的 Pod。BackoffQ存放潜在可调度如被集群事件触发但需等待 backoff 周期结束的 Pod。这防止调度器被频繁重试淹没保证调度吞吐。Unschedulable Pods Pool存放调度失败、在当前集群条件下判定为不可调度的 Pod。绑定冲突的紧急重试机制相对标准队列逻辑的一个关键增强是绑定冲突紧急重试机制Urgent Retry Mechanism。当Conflict-Aware Binder检测到冲突即多个 Worker 尝试绑定到同一节点时会将 Pod 以更高的内部优先级如SchedulingPriorityUrgent重新推回ActiveQ确保冲突 Pod 优先于其他待调度 Pod 被立即重调度最小化乐观并发碰撞带来的延迟影响。队列工作流监听到新的未调度 Pod 时将其加入activeQ随后从 activeQ 弹出并尝试调度。若调度失败Pod 被加入unschedulable pods pool。当集群事件发生如节点更新、Pod 删除等时调度器检查 unschedulable pods pool 中的 Pod若事件使 Pod 变为潜在可调度且仍处于 backoff 周期内则移入backoffQ等待 backoff 到期若 backoff 周期已过则直接移入activeQ。发生绑定冲突时Pod 被标记高优先级标签并立即重新加入activeQ队首绕过 backoff 周期快速重试调度。五、多 Worker 并行调度与 Binder 冲突处理单个调度进程在处理海量 Pod 时存在性能瓶颈。为提升调度吞吐可启用多个 Worker 并行调度。Worker 数量可通过启动参数--scheduler-worker-countx配置该参数在 Helm values 中的对应键为agent_scheduler_worker_count。并行调度在集群资源不足时可能带来调度冲突因此引入Binder组件在实际绑定前解决冲突。调度与绑定流程Worker 从调度队列弹出 Pod 并执行调度。经过谓词过滤predicates与节点排序node ordering后将多个候选节点数量可配置存入调度结果用于分配。调度结果随后交给Binder做最终绑定。Binder 处理来自多个 Worker 的分配结果使用乐观并发控制解决调度冲突对无冲突的结果执行 Bind。具体流程分五步每个调度结果记录不止一个可分配节点数量可配置并记录每个节点在分配时的绑定版本binding version。Binder 按顺序检查调度结果中的节点。若该节点的绑定版本在之前的 Bind 中未被使用过则 Binder 对该 Pod如 Pod A在该节点执行 Bind并更新该节点的绑定版本。若某节点上的绑定版本已被之前的 Bind 使用过Binder 检查分配结果中的下一个可用节点若无冲突则在该节点执行 Bind 并更新绑定版本。例如node1(v1) 在上一次绑定中分配给了 Pod AWorker 2 在为 Pod B 分配 node1 时未考虑 Pod A因此若 Pod B 仍绑定到 node1 可能冲突此时 Binder 为 Pod B 选择 node2。若结果中所有节点都不可用Pod 以高优先级被推回调度队列重调度。例如为 Pod C 分配的两个节点都基于此前绑定已使用过的 v1两个节点均被 Binder 拒绝Pod C 被推回队列。若新分配基于节点更新后的绑定版本Binder 认为该分配基于节点的最新资源视图允许绑定。例如node1(v2) 在已包含之前绑定 Pod 信息的基础上分配给 Pod D不视为冲突。从源码看候选节点数由 allocate Action 的candidateNodeCount参数控制默认值为 3DefaultCandidateNodeCount 3可通过配置项candidateNodeCount调整见 pkg/agentscheduler/actions/allocate/allocate.go。调度结果通过PodScheduleResult含SuggestedNodes候选节点列表传递给 Binder见 pkg/agentscheduler/api/types.go。六、分片同步机制NodeShard 与协调器分片内的节点保存在NodeShard自定义资源中且可能动态变化因此调度器需要感知这些变化以确定可用于调度的节点。调度器还需要与其他调度器协调确保同一节点不会同时出现在不同调度器的调度缓存中——因为调度器缓存中使用的节点与 Shard 定义中的节点可能不一致。NodeShard 示例apiVersion: shard.volcano.sh/v1alpha1 kind: NodeShard metadata: name: volcano spec: nodesDesired: #Nodes should be used within this shard. - node1 - node2 - node3 status lastUpdateTime: 2025-12-08T06:00:00Z nodesInUse: #Node being used by scheduler. - node0 - node1 - node2 nodesToRemove: #Node should be remove from scheduler. (nodes is being used by scheduler, so they cannot be removed from InUse list immediately) - node0 nodesToAdd: #Node should be added to scheduler. (nodes is being used by other schedulers, so they cannot be add into InUse list immediately) - node3 --- apiVersion: shard.volcano.sh/v1alpha1 kind: NodeShard metadata: name: agent-scheduler spec: nodesDesired: #Nodes should be used within this shard. - node0 - node4 - node5 status lastUpdateTime: 2025-12-08T06:00:00Z nodesInUse: #Node being used by scheduler. - node4 - node5 nodesToAdd: #Node should be added to scheduler. (nodes is being used by other schedulers, so they cannot be add into InUse list immediately) - node0NodeShard 中几个关键字段的含义spec.nodesDesired该分片期望使用的节点集合分片策略的计算结果。status.nodesInUse当前正被调度器使用的节点。status.nodesToRemove应从调度器移除的节点。由于节点正被调度器使用不能立刻从 InUse 列表中删除。status.nodesToAdd应加入调度器的节点。由于节点正被其他调度器使用不能立刻加入 InUse 列表。调度器如何消费分片信息Agent Scheduler调度前Worker 从 Sharding Coordinator 获取当前调度周期可用的节点。Coordinator 与 NodeShard 保持同步计算当前 Scheduler 可用的节点集合。Volcano SchedulerSession 打开后调度器从 Snapshot 获取当前会话可用节点。Sharding Coordinator 与 NodeShard 保持同步并计算可用节点可用节点被缓存在调度器 Cache 中并通过 Snapshot 传入 Session。在 Agent Scheduler 中分片内节点集合随调度上下文传递SchedulingContext.NodesInShard记录了当前调度器的分片节点集合allocate Action 在谓词过滤与节点排序时都会结合NodesInShard进行见 pkg/agentscheduler/actions/allocate/allocate.go。分片协调器Sharding Coordinator每个调度器内部都需要一个协调器coordinator用于检测 NodeShard 的变化并计算下一调度周期可用的节点。基于不同分片中节点的 in-use 状态以及分配给本调度器分片的节点协调器计算本调度器下一轮调度可用的节点并更新 NodeShard 以告知其他调度器哪些节点正在被使用。Agent Scheduler 中的协调器监听 NodeShard 变化并计算可用节点。在所有调度 Worker 完成可用节点同步后协调器更新 NodeShard 的NodesInUse/NodesToRemove/NodesToAdd字段若 NodeShard 变化时没有 Worker 正在调度协调器直接计算可调度节点并用新列表更新上述三个字段。若 NodeShard 变化时有 Worker 正在调度协调器不能立即更新字段因为 Worker 当前使用的节点可能包含其他节点。只有当某个 Worker 完成一个调度周期、且没有其他 Worker 正在调度、或所有 Worker 都已开始使用协调器在变化后计算出的节点时协调器才用新计算的可用节点更新字段。Volcano Scheduler 中的协调器同样监听 NodeShard 变化并计算可用节点。若没有 Session 运行协调器立即更新NodesInUse/NodesToRemove/NodesToAdd字段若有 Session 运行为避免 NodeShard 中的节点与 Session 中的节点不一致协调器阻塞更新直到 Session 关闭Session 关闭后唤醒更新流程。七、分片模式配置none / soft / hard分片模式通过启动参数--scheduler-sharding-modexxx配置可选值为none、soft、hard调度行为随配置不同而不同默认值为none对应常量util.NoneShardingMode见 cmd/agent-scheduler/app/options/options.gonone默认不应用分片。调度器可在整个集群范围调度。soft软隔离调度器感知集群全部节点但优先将 Pod 调度到自身分片内的节点以避免冲突仅当分片内没有满足 Pod 需求的节点时才考虑其他分片的节点此时调度冲突交由 kubelet 处理。由于节点在分片内被优先排序调度的全局最优性可能略有下降。hard硬隔离调度器只能将 Pod 调度到自身分片内的节点与其他调度器完全避免冲突。但由于调度范围受限调度的全局最优性可能进一步下降。默认情况下调度器读取与调度器同名scheduler name的 NodeShard 获取分片信息。也可通过启动参数--scheduler-sharding-namexxx指定分片名调度器将读取指定名称的 NodeShard该参数在 Helm values 中的对应键为agent_scheduler_sharding_name。从源码确认Agent Scheduler 的默认调度器名与默认分片名均为agent-scheduler见 cmd/agent-scheduler/app/options/options.go。八、Agent Scheduler 的部署与启动参数文档中Agent Scheduler Configuration章节标注为 TBD但仓库中已具备完整的部署与配置实现可整理如下。Helm 部署Agent Scheduler 作为 Volcano Helm Chart 的可选组件部署。在 installer/helm/chart/volcano/values.yaml 中设置custom.agent_scheduler_enable: true即可启用相关模板见 installer/helm/chart/volcano/templates/agent_scheduler.yaml。默认调度配置ConfigMap 中的agent-scheduler.conf极为精简体现了策略简化的设计目标actions: allocate tiers: - plugins: - name: predicates - name: nodeorder即默认只启用allocate一个 Action 与predicates、nodeorder两个 Plugin可通过custom.scheduler_config_override覆盖见 installer/helm/chart/volcano/templates/agent_scheduler.yaml。常用启动参数以当前仓库源码为准根据 cmd/agent-scheduler/app/options/options.goAgent Scheduler 的核心启动参数如下参数默认值说明--scheduler-nameagent-scheduler该调度器接管spec.schedulerName与之相同的 Pod--scheduler-conf空调度配置文件绝对路径配置 Action 与 Plugin--scheduler-worker-count1并行调度 Worker 线程数Helm values 对应键agent_scheduler_worker_count--scheduler-sharding-modenone分片模式none/soft/hard--scheduler-sharding-nameagent-scheduler本调度器使用的分片名Helm values 对应键agent_scheduler_sharding_name--minimum-feasible-nodes100需查找与评分的最少可行节点数--minimum-percentage-nodes-to-find5需查找与评分的节点最小百分比--percentage-nodes-to-find0每调度周期评分的节点百分比0时按集群规模自适应计算--node-worker-threads20同步节点操作的线程数--kube-api-qps/--kube-api-burst2000/2000与 Kubernetes API server 通信的 QPS 与 Burst--enable-healthz/--enable-metricsfalse是否启用健康检查 / 指标--resource-sync-timeout60s启动调度前等待初始资源同步的超时时间0表示跳过等待--leader-elect见 Helm 值是否启用 leader election 高可用--cache-dump-dir/tmpCache dump 输出的 json 文件目录--scheduler-sharding-nameagent-scheduler指定 NodeShard 名称其中--scheduler-worker-count对应文档中的agent_scheduler_worker_countx表述——后者实际是 Helm values.yaml 中的键名最终通过模板渲染为启动参数--scheduler-worker-count见 installer/helm/chart/volcano/templates/agent_scheduler.yaml。同理文档中的--agent_scheduler_sharding_namexxx对应实际启动参数--scheduler-sharding-name。使用前请以当前仓库 cmd/agent-scheduler/app/options/options.go 为准。另外--scheduler-worker-count必须大于 0否则启动校验失败见 cmd/agent-scheduler/app/options/options.go。调度配置热更新Agent Scheduler 支持调度配置热更新指定--scheduler-conf后调度器会通过文件监听pkg/filewatcher/filewatcher.go监控配置文件检测到写入或创建事件时重新加载配置并更新 metrics 配置见 pkg/agentscheduler/scheduler.go。若未提供配置文件且未禁用默认配置回退则使用内置默认配置--disable-default-scheduler-config可禁用默认配置回退见 pkg/agentscheduler/scheduler.go。九、总结Agent Scheduler 通过独立进程 简化策略 即时调度 多 Worker 并发 Binder 乐观并发控制的组合为 AI Agent 这类延迟敏感、任务高频创建的负载提供了快速路径调度能力又通过与 Sharding Controller、NodeShard 的联动实现了与 Volcano Scheduler 基于分片的并行协同调度使不同特性的负载可以各得其所。本文涉及的调度队列、Binder 冲突处理与分片协调机制均有对应的源码实现pkg/agentscheduler、pkg/controllers/sharding与部署模板installer/helm/chart/volcano可供进一步深入研读文档中标注 TBD 的 Snapshot 快速更新机制与 Agent Scheduler 详细配置部分可关注仓库后续更新。【免费下载链接】volcanoA Cloud Native Batch System (Project under CNCF)项目地址: https://gitcode.com/GitHub_Trending/vol/volcano创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Volcano Agent Scheduler 设计解析：面向 AI Agent 负载的 Kubernetes 快速路径调度器
Volcano Agent Scheduler 设计解析面向 AI Agent 负载的 Kubernetes 快速路径调度器【免费下载链接】volcanoA Cloud Native Batch System (Project under CNCF)项目地址: https://gitcode.com/GitHub_Trending/vol/volcano本文以 Volcano 项目设计文档 docs/design/agent-scheduler.md 为主体结合 pkg/agentscheduler、cmd/agent-scheduler 等仓库源码展开。读者将完整理解 Agent Scheduler 的提出动机、总体架构、调度队列、多 Worker 并行调度与 Binder 冲突解决机制、NodeShard 分片同步机制以及 none/soft/hard 三种分片模式的配置方法并掌握从 Helm 部署到启动参数调优的完整实操路径。一、背景与问题为什么 Volcano 需要一个 Agent SchedulerVolcano Scheduler 是为大数据、HPC、ML、AI 框架等批量和弹性负载设计和优化的调度器提供高性能调度以及丰富的调度策略与算法。但并非所有负载都需要批式调度特性——有些负载的调度诉求恰恰是 Volcano 现有模型难以满足的。文档以AI Agent 负载为例指出两个核心矛盾延迟敏感与高频建任务Agent 负载延迟敏感、任务创建频繁。调度器必须处理海量任务并做到超快调度在保证高吞吐的同时维持单任务低调度延迟当 Agent 负载与其他负载混部在同一集群时延迟同样需要被保障。而 Volcano 调度器在每个调度会话内按固定时间间隔批量处理负载Pod 无法被立即调度存在其他负载时任务必须按序排队调度延迟无法得到保证。调度策略差异化Agent 的调度策略可能与其他负载不同。Agent 负载可能不需要拓扑打散topology spread或 Pod 亲和pod affinity反而可以调度到资源较小或碎片化的节点上从而更好地利用资源碎片、提升集群整体效率。这要求不同负载能够配置不同的调度策略。从源码结构看Agent Scheduler 的入口位于 cmd/agent-scheduler/main.go其核心调度逻辑集中在 pkg/agentscheduler/scheduler.go 中定义的AgentScheduler它是一个独立的调度器进程通过--scheduler-name默认agent-scheduler识别并接管spec.schedulerName与其一致的 Pod见 cmd/agent-scheduler/app/options/options.go。二、设计目标与总体架构设计目标文档明确了两个设计目标能快速调度海量 Pod 的调度器通过工作流优化与策略简化提升调度效率。能与 Volcano 调度器协作、处理不同类型负载的调度器通过基于分片shard的并行调度实现调度器之间的协作与资源管理。架构总览系统引入一个独立的Agent Scheduler来识别并对 Agent 负载做快速调度。它通过优化调度策略与即时调度in-time scheduling提升单个 Pod 的调度速率并通过多 Worker 并行调度进一步提升整体调度吞吐。当 Agent 负载与其他负载共存时Sharding Controller根据资源阈值、节点类型等策略动态将节点划分为分片各调度器通过分片同步获得可调度节点并选择/优选出对应节点进行调度从而实现多调度器基于不同分片的并行调度。分片控制器设计与分片策略详见 sharding controller design and shard strategy。架构中的三个核心组件Sharding Controller根据集群节点资源状态与分片策略动态将集群节点分配到不同分片。Agent Fast-Path Scheduler对对应分片内的 Pod或优先在分片内执行快速调度。它使用并发调度多 Worker提升任务吞吐并优化调度流程与策略以提高调度效率。Volcano Scheduler支持与 Agent Scheduler 对不同类型负载做协同调度。引入 Sharding Coordinator 从 NodeShard 同步节点一旦启用分片调度Volcano Scheduler 也在对应分片内或优先在分片内调度 Pod。三、调度框架Scheduler、Worker、Framework、Snapshot、Action 与 PluginAgent Scheduler 的调度框架包含完整的调度工作流、调度队列以及 Plugin/Action 机制设计。组件层次结构系统架构依赖严格的层次关系与初始化顺序Scheduler顶层组件管理整个调度系统的生命周期拥有 Cache、配置Configurations和 Worker Pool。Worker并发调度单元。每个 Worker 相互独立各自持有独立的 Framework 实例。多个 Worker 会同时从中央调度队列取出 Pod 进行调度采用乐观并行调度optimistic parallel scheduling。FrameworkWorker 内插件的运行环境持有 Plugin 与 Action 的注册表并维护该 Worker 当前调度周期专属的集群状态Snapshot。Snapshot由全局 Cache 派生的集群状态节点、Pod 等的时间点视图。每个 Worker 在调度周期开始时更新自己的 Snapshot 以保证一致性。Action定义高层调度逻辑如 Allocate按照既定顺序编排多个 Plugin 的执行。Plugin实现具体调度算法如 Predicates、NodeOrder注册在 Framework 中并由 Action 调用。初始化序列初始化过程从Scheduler开始首先建立全局Cache与 Kubernetes API server 同步然后加载调度配置以确定启用的 Action 与 Plugin随后初始化Worker Pool。每个Worker被创建时都会实例化一个独立的Framework。运行时Worker 在开始一个调度周期前先从全局 Cache 更新其 Framework 的Snapshot为后续 Action 与 Plugin 的执行提供一致视图。这段设计与源码完全对应在 pkg/agentscheduler/scheduler.go 的Run中调度器先loadSchedulerConf()加载配置随后sched.cache.Run(stopCh)启动 Cache再循环创建workerCount个Worker每个 Worker 通过framework.NewFramework(...)创建独立的 Framework 实例并启动独立的 goroutine 循环执行worker.runOnce()。而 runOnce 中先执行worker.framework.Cache.UpdateSnapshot(snapshot)更新 Snapshot再依次执行各 Action——这正是周期开始时更新 Snapshot的直接实现。SchedulingContext中携带了Task、QueuedPodInfo与NodesInShard分片内节点集合见 pkg/agentscheduler/api/types.go。四、调度队列activeQ、backoffQ 与不可调度 Pod 池设计渊源调度队列的设计大量借鉴并直接参考了成熟的 kube-scheduler 队列架构。由于 Volcano 快速路径调度器的设计目标与 kube-scheduler 的队列管理原则高度一致选择在这一成熟架构之上快速构建面向 Agent 负载的健壮、高效的调度框架。队列架构调度队列管理 Pod 的执行顺序由三个组件构成ActiveQ存放立即可调度的 Pod。BackoffQ存放潜在可调度如被集群事件触发但需等待 backoff 周期结束的 Pod。这防止调度器被频繁重试淹没保证调度吞吐。Unschedulable Pods Pool存放调度失败、在当前集群条件下判定为不可调度的 Pod。绑定冲突的紧急重试机制相对标准队列逻辑的一个关键增强是绑定冲突紧急重试机制Urgent Retry Mechanism。当Conflict-Aware Binder检测到冲突即多个 Worker 尝试绑定到同一节点时会将 Pod 以更高的内部优先级如SchedulingPriorityUrgent重新推回ActiveQ确保冲突 Pod 优先于其他待调度 Pod 被立即重调度最小化乐观并发碰撞带来的延迟影响。队列工作流监听到新的未调度 Pod 时将其加入activeQ随后从 activeQ 弹出并尝试调度。若调度失败Pod 被加入unschedulable pods pool。当集群事件发生如节点更新、Pod 删除等时调度器检查 unschedulable pods pool 中的 Pod若事件使 Pod 变为潜在可调度且仍处于 backoff 周期内则移入backoffQ等待 backoff 到期若 backoff 周期已过则直接移入activeQ。发生绑定冲突时Pod 被标记高优先级标签并立即重新加入activeQ队首绕过 backoff 周期快速重试调度。五、多 Worker 并行调度与 Binder 冲突处理单个调度进程在处理海量 Pod 时存在性能瓶颈。为提升调度吞吐可启用多个 Worker 并行调度。Worker 数量可通过启动参数--scheduler-worker-countx配置该参数在 Helm values 中的对应键为agent_scheduler_worker_count。并行调度在集群资源不足时可能带来调度冲突因此引入Binder组件在实际绑定前解决冲突。调度与绑定流程Worker 从调度队列弹出 Pod 并执行调度。经过谓词过滤predicates与节点排序node ordering后将多个候选节点数量可配置存入调度结果用于分配。调度结果随后交给Binder做最终绑定。Binder 处理来自多个 Worker 的分配结果使用乐观并发控制解决调度冲突对无冲突的结果执行 Bind。具体流程分五步每个调度结果记录不止一个可分配节点数量可配置并记录每个节点在分配时的绑定版本binding version。Binder 按顺序检查调度结果中的节点。若该节点的绑定版本在之前的 Bind 中未被使用过则 Binder 对该 Pod如 Pod A在该节点执行 Bind并更新该节点的绑定版本。若某节点上的绑定版本已被之前的 Bind 使用过Binder 检查分配结果中的下一个可用节点若无冲突则在该节点执行 Bind 并更新绑定版本。例如node1(v1) 在上一次绑定中分配给了 Pod AWorker 2 在为 Pod B 分配 node1 时未考虑 Pod A因此若 Pod B 仍绑定到 node1 可能冲突此时 Binder 为 Pod B 选择 node2。若结果中所有节点都不可用Pod 以高优先级被推回调度队列重调度。例如为 Pod C 分配的两个节点都基于此前绑定已使用过的 v1两个节点均被 Binder 拒绝Pod C 被推回队列。若新分配基于节点更新后的绑定版本Binder 认为该分配基于节点的最新资源视图允许绑定。例如node1(v2) 在已包含之前绑定 Pod 信息的基础上分配给 Pod D不视为冲突。从源码看候选节点数由 allocate Action 的candidateNodeCount参数控制默认值为 3DefaultCandidateNodeCount 3可通过配置项candidateNodeCount调整见 pkg/agentscheduler/actions/allocate/allocate.go。调度结果通过PodScheduleResult含SuggestedNodes候选节点列表传递给 Binder见 pkg/agentscheduler/api/types.go。六、分片同步机制NodeShard 与协调器分片内的节点保存在NodeShard自定义资源中且可能动态变化因此调度器需要感知这些变化以确定可用于调度的节点。调度器还需要与其他调度器协调确保同一节点不会同时出现在不同调度器的调度缓存中——因为调度器缓存中使用的节点与 Shard 定义中的节点可能不一致。NodeShard 示例apiVersion: shard.volcano.sh/v1alpha1 kind: NodeShard metadata: name: volcano spec: nodesDesired: #Nodes should be used within this shard. - node1 - node2 - node3 status lastUpdateTime: 2025-12-08T06:00:00Z nodesInUse: #Node being used by scheduler. - node0 - node1 - node2 nodesToRemove: #Node should be remove from scheduler. (nodes is being used by scheduler, so they cannot be removed from InUse list immediately) - node0 nodesToAdd: #Node should be added to scheduler. (nodes is being used by other schedulers, so they cannot be add into InUse list immediately) - node3 --- apiVersion: shard.volcano.sh/v1alpha1 kind: NodeShard metadata: name: agent-scheduler spec: nodesDesired: #Nodes should be used within this shard. - node0 - node4 - node5 status lastUpdateTime: 2025-12-08T06:00:00Z nodesInUse: #Node being used by scheduler. - node4 - node5 nodesToAdd: #Node should be added to scheduler. (nodes is being used by other schedulers, so they cannot be add into InUse list immediately) - node0NodeShard 中几个关键字段的含义spec.nodesDesired该分片期望使用的节点集合分片策略的计算结果。status.nodesInUse当前正被调度器使用的节点。status.nodesToRemove应从调度器移除的节点。由于节点正被调度器使用不能立刻从 InUse 列表中删除。status.nodesToAdd应加入调度器的节点。由于节点正被其他调度器使用不能立刻加入 InUse 列表。调度器如何消费分片信息Agent Scheduler调度前Worker 从 Sharding Coordinator 获取当前调度周期可用的节点。Coordinator 与 NodeShard 保持同步计算当前 Scheduler 可用的节点集合。Volcano SchedulerSession 打开后调度器从 Snapshot 获取当前会话可用节点。Sharding Coordinator 与 NodeShard 保持同步并计算可用节点可用节点被缓存在调度器 Cache 中并通过 Snapshot 传入 Session。在 Agent Scheduler 中分片内节点集合随调度上下文传递SchedulingContext.NodesInShard记录了当前调度器的分片节点集合allocate Action 在谓词过滤与节点排序时都会结合NodesInShard进行见 pkg/agentscheduler/actions/allocate/allocate.go。分片协调器Sharding Coordinator每个调度器内部都需要一个协调器coordinator用于检测 NodeShard 的变化并计算下一调度周期可用的节点。基于不同分片中节点的 in-use 状态以及分配给本调度器分片的节点协调器计算本调度器下一轮调度可用的节点并更新 NodeShard 以告知其他调度器哪些节点正在被使用。Agent Scheduler 中的协调器监听 NodeShard 变化并计算可用节点。在所有调度 Worker 完成可用节点同步后协调器更新 NodeShard 的NodesInUse/NodesToRemove/NodesToAdd字段若 NodeShard 变化时没有 Worker 正在调度协调器直接计算可调度节点并用新列表更新上述三个字段。若 NodeShard 变化时有 Worker 正在调度协调器不能立即更新字段因为 Worker 当前使用的节点可能包含其他节点。只有当某个 Worker 完成一个调度周期、且没有其他 Worker 正在调度、或所有 Worker 都已开始使用协调器在变化后计算出的节点时协调器才用新计算的可用节点更新字段。Volcano Scheduler 中的协调器同样监听 NodeShard 变化并计算可用节点。若没有 Session 运行协调器立即更新NodesInUse/NodesToRemove/NodesToAdd字段若有 Session 运行为避免 NodeShard 中的节点与 Session 中的节点不一致协调器阻塞更新直到 Session 关闭Session 关闭后唤醒更新流程。七、分片模式配置none / soft / hard分片模式通过启动参数--scheduler-sharding-modexxx配置可选值为none、soft、hard调度行为随配置不同而不同默认值为none对应常量util.NoneShardingMode见 cmd/agent-scheduler/app/options/options.gonone默认不应用分片。调度器可在整个集群范围调度。soft软隔离调度器感知集群全部节点但优先将 Pod 调度到自身分片内的节点以避免冲突仅当分片内没有满足 Pod 需求的节点时才考虑其他分片的节点此时调度冲突交由 kubelet 处理。由于节点在分片内被优先排序调度的全局最优性可能略有下降。hard硬隔离调度器只能将 Pod 调度到自身分片内的节点与其他调度器完全避免冲突。但由于调度范围受限调度的全局最优性可能进一步下降。默认情况下调度器读取与调度器同名scheduler name的 NodeShard 获取分片信息。也可通过启动参数--scheduler-sharding-namexxx指定分片名调度器将读取指定名称的 NodeShard该参数在 Helm values 中的对应键为agent_scheduler_sharding_name。从源码确认Agent Scheduler 的默认调度器名与默认分片名均为agent-scheduler见 cmd/agent-scheduler/app/options/options.go。八、Agent Scheduler 的部署与启动参数文档中Agent Scheduler Configuration章节标注为 TBD但仓库中已具备完整的部署与配置实现可整理如下。Helm 部署Agent Scheduler 作为 Volcano Helm Chart 的可选组件部署。在 installer/helm/chart/volcano/values.yaml 中设置custom.agent_scheduler_enable: true即可启用相关模板见 installer/helm/chart/volcano/templates/agent_scheduler.yaml。默认调度配置ConfigMap 中的agent-scheduler.conf极为精简体现了策略简化的设计目标actions: allocate tiers: - plugins: - name: predicates - name: nodeorder即默认只启用allocate一个 Action 与predicates、nodeorder两个 Plugin可通过custom.scheduler_config_override覆盖见 installer/helm/chart/volcano/templates/agent_scheduler.yaml。常用启动参数以当前仓库源码为准根据 cmd/agent-scheduler/app/options/options.goAgent Scheduler 的核心启动参数如下参数默认值说明--scheduler-nameagent-scheduler该调度器接管spec.schedulerName与之相同的 Pod--scheduler-conf空调度配置文件绝对路径配置 Action 与 Plugin--scheduler-worker-count1并行调度 Worker 线程数Helm values 对应键agent_scheduler_worker_count--scheduler-sharding-modenone分片模式none/soft/hard--scheduler-sharding-nameagent-scheduler本调度器使用的分片名Helm values 对应键agent_scheduler_sharding_name--minimum-feasible-nodes100需查找与评分的最少可行节点数--minimum-percentage-nodes-to-find5需查找与评分的节点最小百分比--percentage-nodes-to-find0每调度周期评分的节点百分比0时按集群规模自适应计算--node-worker-threads20同步节点操作的线程数--kube-api-qps/--kube-api-burst2000/2000与 Kubernetes API server 通信的 QPS 与 Burst--enable-healthz/--enable-metricsfalse是否启用健康检查 / 指标--resource-sync-timeout60s启动调度前等待初始资源同步的超时时间0表示跳过等待--leader-elect见 Helm 值是否启用 leader election 高可用--cache-dump-dir/tmpCache dump 输出的 json 文件目录--scheduler-sharding-nameagent-scheduler指定 NodeShard 名称其中--scheduler-worker-count对应文档中的agent_scheduler_worker_countx表述——后者实际是 Helm values.yaml 中的键名最终通过模板渲染为启动参数--scheduler-worker-count见 installer/helm/chart/volcano/templates/agent_scheduler.yaml。同理文档中的--agent_scheduler_sharding_namexxx对应实际启动参数--scheduler-sharding-name。使用前请以当前仓库 cmd/agent-scheduler/app/options/options.go 为准。另外--scheduler-worker-count必须大于 0否则启动校验失败见 cmd/agent-scheduler/app/options/options.go。调度配置热更新Agent Scheduler 支持调度配置热更新指定--scheduler-conf后调度器会通过文件监听pkg/filewatcher/filewatcher.go监控配置文件检测到写入或创建事件时重新加载配置并更新 metrics 配置见 pkg/agentscheduler/scheduler.go。若未提供配置文件且未禁用默认配置回退则使用内置默认配置--disable-default-scheduler-config可禁用默认配置回退见 pkg/agentscheduler/scheduler.go。九、总结Agent Scheduler 通过独立进程 简化策略 即时调度 多 Worker 并发 Binder 乐观并发控制的组合为 AI Agent 这类延迟敏感、任务高频创建的负载提供了快速路径调度能力又通过与 Sharding Controller、NodeShard 的联动实现了与 Volcano Scheduler 基于分片的并行协同调度使不同特性的负载可以各得其所。本文涉及的调度队列、Binder 冲突处理与分片协调机制均有对应的源码实现pkg/agentscheduler、pkg/controllers/sharding与部署模板installer/helm/chart/volcano可供进一步深入研读文档中标注 TBD 的 Snapshot 快速更新机制与 Agent Scheduler 详细配置部分可关注仓库后续更新。【免费下载链接】volcanoA Cloud Native Batch System (Project under CNCF)项目地址: https://gitcode.com/GitHub_Trending/vol/volcano创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考