现实中复杂的业务场景kubernetes原生调度功能并不能完全Cover，如缺少的Job调度、重调度等功能。为了增强Kubernetes功能，实现对各种业务场景的适配，许多的拓展调度框架应运而生，接下来本文将分析这些调度器并比较它们的异同。
Kubernetes Default Scheduler
kube-scheduler是kubernetes集群默认调度器，其会对每个尚未被调度的Pod执行调度，选择一个最优的节点运行这个Pod。由于不同Pod对计算要求不同，所以要考虑诸多不同的因素。
调度框架
K8s调度框架支持如上拓展点，可以使用默认或者自定义插件实现对一个或多个拓展点的支持，通过配置文件将调度插件组合起来形成调度器。如下创建了一个默认调度器和一个禁用所有打分插件的调度器。可以在Pod中声明调度器来指定调度策略。
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler
- schedulerName: no-scoring-scheduler
plugins:
preScore:
disabled:
- name: '*'
score:
disabled:
- name: '*'
默认调度功能
K8s默认调度插件如下:
| 调度插件名称 | 实现的扩展点 | 功能说明 |
|---|---|---|
| ImageLocality | score |
优先选择已缓存 Pod 所需容器镜像的节点 |
| TaintToleration | filter, preScore, score |
实现污点和容忍机制，过滤不容忍的节点并影响打分 |
| NodeName | filter |
检查 Pod 指定的节点名称是否与当前节点匹配 |
| NodePorts | preFilter, filter |
检查 Pod 请求的端口在节点上是否可用 |
| NodeAffinity | filter, score |
实现节点选择器 (nodeSelector) 和节点亲和性 (nodeAffinity) |
| PodTopologySpread | preFilter, filter, preScore, score |
实现 Pod 拓扑分布约束（如跨可用区/机架调度） |
| NodeUnschedulable | filter |
过滤 .spec.unschedulable=true 的节点 |
| NodeResourcesFit | preFilter, filter, score |
检查节点资源是否满足 Pod 请求，支持多种打分策略（如 LeastAllocated） |
| NodeResourcesBalancedAllocation | score |
优先选择 CPU/内存等资源使用更均衡的节点 |
| VolumeBinding | preFilter, filter, reserve, preBind, score |
检查卷绑定状态，启用 StorageCapacityScoring 时优先选择有足够存储的节点 |
| VolumeRestrictions | filter |
检查卷挂载是否符合提供商的限制（如只读卷） |
| VolumeZone | filter |
检查请求的卷是否满足区域拓扑约束 |
| NodeVolumeLimits | filter |
检查节点是否满足 CSI 卷的数量限制 |
| EBSLimits | filter |
检查节点是否满足 AWS EBS 卷限制 |
| GCEPDLimits | filter |
检查节点是否满足 GCP Persistent Disk 卷限制 |
| AzureDiskLimits | filter |
检查节点是否满足 Azure Disk 卷限制 |
| InterPodAffinity | preFilter, filter, preScore, score |
实现 Pod 间亲和性与反亲和性（如共置或隔离） |
| PrioritySort | queueSort |
提供默认的基于优先级的 Pod 排序（高优先级优先调度） |
| DefaultBinder | bind |
提供默认的 Pod-Node 绑定机制 |
| DefaultPreemption | postFilter |
实现抢占逻辑，为高优先级 Pod 腾出资源 |
Volcano
Volcano和Kubernetes默认调度器的区别在于其针对Job的多种调度算法，Volcano的核心概念：VolcanoJob、PodGroup、Queue。它们通过Kubernetes的CRD机制自定义实现，和VolcanoScheduler&VolcanoAdmission共同管理Pod调度。
VolcanoJob是Volcano自定义的Job资源类型，对外提供的核心接口。区别于Kubernetes Job，VolcanoJob提供了更多高级功能，如可指定调度器、支持最小运行pod数、 支持task、支持生命周期管理、支持指定队列、支持优先级调度等。
PodGroup是一组强关联pod的集合，主要用于批处理工作负载场景中的Gang Scheuding需求，比如Tensorflow中的一组ps和worker必须全部加载才能正常工作。
Queue是容纳一组PodGroup的队列，Queue会定义一组集群资源，其下的任务会竞争Queue中的资源，但不会超过Queue资源总量。
基本功能
Volcano支持云原生混部。拥有如下功能：
- 支持设置业务QoS等级。实现上在CPU、Memory、网络使用了隔离措施保证在线业务QoS。
- 动态资源超卖。通过SLO Agent实时计算Pod申请但未使用的资源。
Volcano实现了基于节点真实负载（CPU和memory）的重调度。调度器是通过一系列算法计算出Pod运行的最佳节点，但是Kubernetes集群环境是存在动态变化的，这会导致集群在一段时间处于不均衡状态。原生的descheduler只支持基于Pod request的负载感知调度，对利用率比较高的节点上的Pods进行驱逐，从而均衡节点间的资源利用率，避免个别节点过热，但是Pod request并不能反映节点的真实资源使用情况。
网络拓扑感知调度。通过定义节点的网络拓扑结构（作为配置文件输入调度器），Volcano能够将同一Job下所有任务调度到相近节点。这是为了满足大模型在模型并行训练时不同任务间大量数据交换的需要。统一调度。其调度器不仅支持VcJob还支持其它Kubernetes原生资源调度。调度器实现了Kubernetes schedule framework的Pre-Filter/Filter和Score阶段。
Koordinator
Koordinator 是一个基于 QoS 的 Kubernetes 混合工作负载调度系统。它旨在提高对延迟敏感的工作负载和批处理作业的运行时效率和可靠性，简化与资源相关的配置调整的复杂性，并增加 Pod 部署密度以提高资源利用率。
Koordinator Scheduler 特性：
- QoS-aware 调度，包括负载感知调度让节点间负载更佳平衡，资源超卖的方式支持运行更多的低优先级工作负载。
- 差异化 SLO，包括 CPU 精细化编排，为不同的工作负载提供不同的 QoS 隔离策略（cfs，LLC，memory 带宽，网络带宽，磁盘io）。
- 任务调度，包括弹性额度管理，Gang 调度，异构资源调度等，以支持更好的运行大数据和 AI 工作负载。
Koordlet作为DaemonSet服务部署在集群节点中，主要包括以下模块:
- 资源 Profiling，估算 Pod 资源的实际使用情况，回收已分配但未使用的资源，用于低优先级 Pod 的 overcommit。
- 资源隔离，为不同类型的 Pod 设置资源隔离参数，避免低优先级的 Pod 影响高优先级 Pod 的稳定性和性能。
- 干扰检测，对于运行中的 Pod，动态检测资源争夺，包括 CPU 调度、内存分配延迟、网络、磁盘 IO 延迟等。
- QoS 管理器，根据资源剖析、干扰检测结果和 SLO 配置，动态调整混部节点的水位，抑制影响服务质量的 Pod。
- 资源调优，针对混部场景进行容器资源调优，优化容器的 CPU Throttle、OOM 等，提高服务运行质量。
Koord-RuntimeProxy以 systemd service 的形式部署在 Kubernetes 集群的节点上，用于代理 Kubelet 与 containerd/docker 之间的 CRI 请求。这一个代理被设计来支持精细化的资源管理策略，比如为不同 QoS Pod 设置不同的 cgroup 参数，包括内核 cfs quota，resctl 等等技术特性，以改进 Pod 的运行时质量。
此外还有Koord-Manager、Koord-Descheduler等关键组件。
Koordinator 资源模型
Koordinator资源模型揭露了当前混部场景下带来的性能提升原理，并根据此制定了可行的SLO方案。
- limit：灰色，高优先级 Pod 所请求的资源量，对应于 Kubernetes 的 Pod 请求。
- usage：红色，Pod 实际使用的资源量，横轴为时间线，红线为 Pod 负载随时间变化的波动曲线。
- short-term reservation：深蓝色，这是基于过去（较短）时期内的资源使用量，对未来一段时间内其资源使用量的估计。预留和限制的区别在于，分配的未使用（未来不会使用的资源）可以用来运行短期执行的批处理 Pod。
- long-term reservation：浅蓝色，与 short-term reservation 类似，但估计的历史使用期更长。从保留到限制的资源可以用于生命周期较长的Pod，与短期的预测值相比，可用的资源较少，但更稳定。
根据模型对服务优先级进行分类，用于判断调度优先程度：
| PriorityClass | 优先级范围 | 描述 | 场景 |
|---|---|---|---|
| koord-prod | [9000, 9999] | 需要提前规划资源配额，并且保证在配额内成功。 | 典型的延迟敏感型服务，一般是指需要 “实时 “响应的服务类型，比如通过点击移动APP中的按钮调用的典型服务。 |
| koord-mid | [7000, 7999] | 需要提前规划资源配额，并且保证在配额内成功。 | 实时计算、人工智能训练任务/作业，如 tensorflow/pytorch 等。 |
| koord-batch | [5000, 5999] | 需要提前规划资源配额，一般允许借用配额。 | 典型的离线批处理作业，一般指离线分析类作业，如日级大数据报告、非交互式 SQL 查询。 |
| koord-free | [3000, 3999] | 不保证资源配额，可分配的资源总量取决于集群的总闲置资源。 | 低优先级的离线批处理作业，一般指不做资源预算，利用闲置资源尽量完成，如开发人员为测试目提交的作业。 |
QoS划分
Koordinator QoS与 Kubernetes QoS相对应，只是Koordinator划分更细致。Koordinator 调度系统支持的 QoS 有五种类型，根据不同的优先级分配CPU核心资源:
| QoS | 特点 | 说明 |
|---|---|---|
| SYSTEM | 系统进程，资源受限 | 对于 DaemonSets 等系统服务，虽然需要保证系统服务的延迟，但也需要限制节点上这些系统服务容器的资源使用，以确保其不占用过多的资源 |
| LSE(Latency Sensitive Exclusive) | 保留资源并组织同 QoS 的 pod 共享资源 | 很少使用，常见于中间件类应用，一般在独立的资源池中使用 |
| LSR(Latency Sensitive Reserved) | 预留资源以获得更好的确定性 | 类似于社区的 Guaranteed，CPU 核被绑定 |
| LS(Latency Sensitive) | 共享资源，对突发流量有更好的弹性 | 微服务工作负载的典型QoS级别，实现更好的资源弹性和更灵活的资源调整能力 |
| BE(Best Effort) | 共享不包括 LSE 的资源，资源运行质量有限，甚至在极端情况下被杀死 | 批量作业的典型 QoS 水平，在一定时期内稳定的计算吞吐量，低成本资源 |
其它调度器
Yunikorn
Apache YuniKorn is a light-weight, universal resource scheduler for container orchestrator systems. It is created to achieve fine-grained resource sharing for various workloads efficiently on a large scale, multi-tenant, and cloud-native environment. YuniKorn brings a unified, cross-platform, scheduling experience for mixed workloads that consist of stateless batch workloads and stateful services.
Kueue
Kueue is a kubernetes-native system that manages quotas and how jobs consume them. Kueue decides when a job should wait, when a job should be admitted to start (as in pods can be created) and when a job should be preempted (as in active pods should be deleted).
NVIDIA KAI‑Scheduler
KAI Scheduler is a robust, efficient, and scalable Kubernetes scheduler that optimizes GPU resource allocation for AI and machine learning workloads.
Designed to manage large-scale GPU clusters, including thousands of nodes, and high-throughput of workloads, makes the KAI Scheduler ideal for extensive and demanding environments. KAI Scheduler allows administrators of Kubernetes clusters to dynamically allocate GPU resources to workloads.
KAI Scheduler supports the entire AI lifecycle, from small, interactive jobs that require minimal resources to large training and inference, all within the same cluster. It ensures optimal resource allocation while maintaining resource fairness between the different consumers. It can run alongside other schedulers installed on the cluster.
Gödel Scheduler
kubewharf/godel-scheduler: a unified scheduler for online and offline tasks
Gödel represents a comprehensive scheduling and resource management platform designed for various business groups to efficiently operate their diverse cloud-native workloads. It features an integrated quota management system and a scheduler that administers a consolidated resource pool. The Gödel scheduling system is a critical component in the management of clusters.
Thanks to the Gödel architecture, we can realize enhanced performance in terms of resource utilization, resource elasticity, and scheduling throughput, optimizing the overall functionality and efficiency of cluster management.