4、多队列设计动机：为什么需要多队列？单队列瓶颈、公平性与吞吐量权衡
在 Kubernetes 调度器的演进过程中，从单队列到多队列的转变并非偶然。单队列模型在集群规模较小、负载类型单一的场景下表现尚可，但随着集群节点数增长、Pod 类型多样化（批处理、在线服务、AI 训练等），单队列的瓶颈逐渐暴露。多队列设计的核心动机在于：打破单队列的串行瓶颈，在公平性与吞吐量之间找到可配置的平衡点。
4.1 单队列模型的三大瓶颈
单队列（Single Queue）调度器将所有待调度的 Pod 放入一个全局 FIFO 队列，调度线程依次取出并执行调度周期。这种设计在以下三个维度存在严重问题：
| 瓶颈维度 | 具体表现 | 影响后果 |
|---|---|---|
| 锁竞争 | 所有 goroutine（调度器、缓存更新、Pod 添加）竞争同一把全局锁 | 高并发下锁等待占比超过 40%，调度吞吐量断崖式下降 |
| 头部阻塞 | 队首 Pod 若因资源不足、亲和性不满足而无法调度，会阻塞后续所有 Pod | 低优先级或简单 Pod 被高复杂度 Pod 拖慢，调度延迟从毫秒级恶化到秒级 |
| 优先级反转 | 高优先级 Pod 入队后必须等待前面所有低优先级 Pod 出队 | 紧急任务无法快速抢占调度机会，违反 QoS 承诺 |
关键指标： 在 5000 节点、每秒 100 Pod 提交的压测场景下，单队列调度器的 P99 调度延迟从 200ms 飙升到 8s，吞吐量从 50 Pod/s 跌至 12 Pod/s。
4.2 多队列设计动机：从串行到并行
多队列（Multi-Queue）模型将 Pod 按优先级、QoS 类别、用户分组或自定义标签分散到多个独立队列中。每个队列拥有独立的调度循环和锁，调度器可以并行处理不同队列的 Pod。其设计动机可归纳为以下四点：
- 消除全局锁竞争：每个队列持有自己的锁，调度器线程仅锁定当前操作的队列，其他队列可继续调度。
- 隔离头部阻塞：一个队列的队首 Pod 阻塞不会影响其他队列的调度进度。
- 实现优先级抢占：高优先级队列可配置更短的调度周期或更高的权重，确保紧急任务快速通过。
- 支持公平性配额：通过队列权重或速率限制，防止某个用户或应用的 Pod 洪泛挤占全部调度资源。
设计原则： 多队列不是简单的“队列数量增加”，而是将调度资源从“全局共享”变为“分区隔离”，每个分区内部仍可保持 FIFO 或优先级排序，分区之间通过调度策略实现公平调度。
4.3 公平性与吞吐量的权衡模型
多队列调度器必须在公平性（Fairness）和吞吐量（Throughput）之间做出权衡。下图展示了不同队列配置下的权衡曲线：
4.4 多队列架构设计
Kubernetes 调度器（kube-scheduler）在 v1.19 之后引入了多队列调度框架（Scheduling Framework），其核心组件包括：
- QueueSet：管理多个队列的集合，每个队列对应一个 PriorityClass 或一个 QueueHint。
- QueueSort：定义队列间的排序策略（如按优先级、按权重、按时间戳）。
- PreEnqueue：在 Pod 入队前执行检查（如资源预检、准入控制），避免无效 Pod 进入队列。
- PostFilter：在调度失败后尝试抢占或回退，防止队列头部阻塞。
常见误区： 多队列不是越多越好。队列数量过多会导致调度器线程数膨胀、上下文切换开销增大、内存占用上升。生产环境建议队列数不超过 CPU 核心数的 2 倍，且每个队列的 Pod 积压量应保持稳定。
4.5 单队列 vs 多队列对比总结
| 对比维度 | 单队列 | 多队列 |
|---|---|---|
| 锁粒度 | 全局锁，所有操作串行 | 队列级锁，支持并行调度 |
| 头部阻塞 | 队首阻塞影响全部 Pod | 阻塞仅影响本队列 |
| 优先级支持 | 仅 FIFO，优先级反转严重 | 支持优先级队列、抢占、权重 |
| 公平性 | 无公平性保障 | 可配置加权公平或严格公平 |
| 吞吐量（高并发） | 低（锁竞争 + 阻塞） | 高（并行 + 隔离） |
| 实现复杂度 | 低 | 中高（需管理队列状态、调度策略） |
4.6 多队列调度流程
下图展示了一个典型的多队列调度器内部流程，包含队列选择、调度周期、失败回退三个核心阶段：
4.7 生产实践建议
推荐配置：
- 集群规模 < 100 节点：2~4 个队列（按优先级划分）
- 集群规模 100~1000 节点：4~8 个队列（按优先级 + 用户组）
- 集群规模 > 1000 节点：8~16 个队列（按优先级 + 用户组 + 应用类型）