本系列《云原生批调度实战：Volcano 深度解析》计划分为以下几篇，点击查看其它内容。
云原生批调度实战：Volcano 深度解析（一）批处理背景需求与Volcano特点
云原生批调度实战：Volcano 深度解析（二）Volcano调度流程与调度状态
云原生批调度实战：Volcano 安装与初试
云原生批调度实战：调度器测试与监控工具 kube-scheduling-perf
云原生批调度实战：调度器测试监控结果

💡简介

在Kubernetes生态系统中，调度器是集群资源管理的核心组件。随着云原生应用的快速发展，传统的默认调度器已经无法满足大规模、高并发的调度需求。
本文整理自Apple工程师Wei Huang与DaoCloud工程师Shiming Zhang在KubeCon上的技术分享^[1]，聚焦Kubernetes生态中三大主流批处理调度器（Kueue, Volcano, YuniKorn）的性能对比实验。通过分析测试方法论、关键指标和实际数据，揭示各调度器在不同负载场景下的表现差异。
在上一篇博客中所介绍的性能测试与监控工具，也就是这次技术分享中的shiming Zhang 及相关成员所设计的，测试监控工具结果也在这次技术分享中有所体现。

🖼️背景

背景参数

API QPS 限制是一个重要的参数，而本次测试所涉及的调度器间、该参数存在差异，有可能导致部分测试不公平，因此在此提前说明。
K8s 下，调度器默认使用的 API QPS（--kube-api-qps）限制为 50，而 YuniKorn 为 1000。而前者暂时没找到修改的方法。
除该参数外，在测试中已尽量保持其它参数的一致，尽可能保证了测试的公平性。

数据收集方法优化

传统方法使用 Prometheus，会造成很大的误差。
- 以前看到过的博客也有类似的观点：
  十分不建议在大规模压测时通过 grafana 看板进行调度时间的统计。因为调度器暴露的调度时间指标是通过 histogram 直方图的方式，而 histogram 是假定位于每个 bucket 的样本在该 bucket 内满足均匀分布。当压测进行时，短时间大量创建 Pod，必定有部分 Pod 的调度时长达到分钟级别，此时其所属的 bucket 范围更广，均匀分布的条件就越不可能成立，从 metrics 这统计的调度时间会产生很大的误差(https://hulining.gitbook.io/prometheus/practices/histograms#errors-of-quantile-estimation)。
本方法基于 audit-exporter，从 kube-apiserver 中收集信息并记录在 audit.log 来准确地记录具体性能。

🧠环境说明

测试软件环境

本次性能测试软件版本如下图：

测试参数配置

本次测试benchmark如下图，在10k总Pod量下，分别在启用/不启用Gang Scheduling的情况下（个人理解，即分别在更偏向在线服务/离线作业特征的场景下），调整Job数量和每Job的Pod数量。

注意：在测试中没有使用很多Queue，因为发现Queue的数量对测试结果影响不大。

🔨结果

对于不要求Gang调度的benchmark，Volcano表现较差；对于要求Gang调度的benchmark，Volcano的性能都是最佳的。

我们对于不要求Gang调度的四种benchmark结果进行具体介绍。其中第二种测试中的现象很有意思。

第一种benchmark下，每个Job只有1个Pod，共10K个Job，共10kPod。有以下现象：
- YuniKorn吞吐量比另外两种调度器更高，主要是因为 Kueue 和 Volcano 的 Job 受 K8s Webhook QPS限制，还没有找到可以调整这个限制的方法。
- CREATED和SCHEDULED事件之间的差距很小，说明没有调度阶段不为瓶颈、没有排队，此时性能瓶颈为创建阶段。

2. 第二种benchmark下，每个Job有20个Pod，共500个Job，共10kPod。有以下现象：

Volcano的调度速度慢于另外两种调度器；
SCHEDULED明显滞后于CREATED，说明调度速度较慢，此时性能瓶颈为调度（且根据斜率，前期调度速度快、后期逐渐变慢）；
CREATED阶段性突变现象（正常情况下CREATED应该匀速增加，这里的现象说明controller会间歇性卡住一会儿）。
- 可能的原因是Volcano会分批处理Job，在视频中的用词是“create pod in Batch”，当一批Job处理完后才会继续处理下一批Job。
- 此外，还有一个可能的影响因素是 Volcano 需要更多的webhook来创建Pod，而受限于webhook QPS（如前文所述），所以出现排队阻塞和卡顿。前期阻塞情况比后期更严重，可能是因为后期部分webhook可以复用。
- 后续还需验证该猜想。

3. 第三种benchmark下，每个Job有500Pod，共20个Job，共10kPod。有以下现象：

Volcano的调度速度仍然慢于另外两种调度器；
SCHEDULED仍然明显滞后于CREATED，说明调度速度较慢，此时性能瓶颈为调度（且根据斜率，前期调度速度比第二种benchmark下更慢、后期逐渐加速）；
不存在CREATED阶段性突变现象。
- 和第二种benchmark的区别是Job只有20个，说明Volcano分批处理Job的粒度应该在[20,500]区间内（根据第二、三种benchmark的Job数量推断）。

4. 第四种benchmark下，每个Job有10kPod，共1个Job，共10kPod。

现象与第三种benchmark类似；根据斜率，调度速度整体比较平稳。
有意思的是四种情况下Volcano的总调度时间似乎都是差不多的。

🏥疑问及解答

K8s参数中的--kube-api-qps是什么意思？
- 总结：--kube-api-qps是Kubernetes调度器向API服务器发送请求的速率限制参数，控制调度器每秒可以向kube-apiserver发送的最大请求数量。
- 参数含义：QPS（Queries Per Second）表示每秒查询次数，默认值为50，意味着调度器每秒最多可以向API服务器发送50个请求。这个限制包括所有类型的API请求，如获取节点信息、创建Pod、更新Pod状态等。
- 原因说明：设置QPS限制是为了防止调度器过度占用API服务器资源，避免API服务器过载。在大规模集群中，如果调度器不受限制地向API服务器发送请求，可能会导致API服务器响应变慢或崩溃。YuniKorn设置为1000是因为它针对高吞吐量场景进行了优化，而Kueue和Volcano使用默认值50，在大量Job创建时容易达到限制。
视频中图表的含义是什么？
- 纵轴是事件数量，横轴是测试过程时间点。
- 斜率表示吞吐量（每秒事件数量），斜率越大说明速度越快、效率越高。
图中Created、Scheduled 代表着什么？
- 总结：Created事件表示Pod被成功创建并提交到API服务器的时间点，Scheduled事件表示Pod被调度器成功调度到某个节点的时间点。两者之间的时间差反映了调度延迟。
- 事件含义：
  - CREATED事件：当Job Controller成功创建Pod并提交到kube-apiserver时触发，表示Pod已进入待调度队列。
  - SCHEDULED事件：当调度器完成Pod的节点选择并成功绑定到节点时触发，表示Pod已获得运行位置。
- 原因说明：在正常情况下，CREATED和SCHEDULED事件应该紧密跟随，时间差很小。如果SCHEDULED明显滞后于CREATED，说明调度器处理能力不足，存在调度瓶颈。如果两者差距很小但整体斜率较低，说明瓶颈在Pod创建阶段而非调度阶段。
视频中频繁提到的 webhook 是什么？webhook QPS是什么？为什么关注这个点？
- 总结：Webhook是Kubernetes的准入控制器机制，用于在资源创建/更新时进行验证和修改。Webhook QPS限制影响调度器创建Pod的速度，可能成为性能瓶颈。
- 含义：
  - Webhook：Kubernetes准入控制器的一种实现方式，当API服务器接收到资源请求时，会调用配置的webhook服务进行验证、修改或拒绝操作。调度器（如Volcano、Kueue）通常使用webhook来实现自定义的调度逻辑，如PodGroup验证、资源配额检查等。
  - Webhook QPS：API服务器向webhook服务发送请求的速率限制，默认通常为50 QPS，与--kube-api-qps类似。
- 原因说明：调度器需要通过webhook来验证和创建Pod，当大量Job同时提交时，webhook QPS限制会导致请求排队等待，从而影响整体调度性能。Volcano需要更多的webhook调用（如PodGroup验证、资源分配等），因此更容易受到webhook QPS限制的影响，出现阶段性阻塞现象。