1 调度职责

    调度系统其实就是调度器（Scheduler），我们在很多系统中都能见到调度器的身影，就像我们在上面说的，不止操作系统中存在调度器，编程语言、容器编排以及很多业务系统中都会存在调度系统或者调度模块。这些调度模块的核心作用就是对有限的资源进行分配以实现最大化资源的利用率或者降低系统的尾延迟，调度系统面对的就是资源的需求和供给不平衡的问题。

2 开源调度器

2.1 大数据/AI生态调度器

• YARN

Yarn，大数据资源调度框架，大数据组件和服务均可以由YARN进行调度和管理，架构如下图所示：

主要劣势：

1）单级调度架构，不够灵活

2）服务器集群资源调度管理和MapReduce执行过程耦合度高

3）技术栈

• Mesos

Mesos是一个具有两级调度架构的框架，一块是基于DRF算法的资源分配，由特定的Framework实现任务资源管控和分配

主要劣势：功能较单一，生态不足

2.2 Kubernetes原生调度器

• kube-schduler

Kubernetes原生调度器在微服务、无状态应用等领域具有得天独厚的优势，而在统一云原生基础架构背景下，Kubernetes原生调度器所显露出的能力不足则被不断放大；

Kubernetes原生调度器采用共享状态（Shared State）的双循环调度机制，如下：

主要不足：

1）不支持多租户模型下的资源调度

2）不支持应用感知调度

3）不支持资源共享和弹性调度

4）调度排序算法单一

2.3 kubernetes生态调度器

• Volcano

主要特性：

1）支持批处理任务，支持资源队列、资源共享和弹性调度

2）支持组调度、公平调度等多种调度策略

存在的一些限制：

1）可能出现和原生调度器的资源调度冲突问题

2）不支持多级层次化的资源队列，在企业多租户场景下不能够很好的进行映射

• YuniKorn

YuniKorn的其中一个设计亮点是将调度程序与下面的资源管理系统分离，为此定义了一个通用调度程序接口，通过该接口实现scheduler-core和shim一起处理调度请求。

由于其shim层为适配各个底层平台需要不断补齐这一层的能力，以此来跟上社区的节奏，因此也不能算是完全兼容Kubernetes原生的调度器

• Koordinator

基于阿里巴巴在容器调度经验孵化诞生，通过混部、资源画像、调度优化等技术优化集群资源使用效率，降低集群资源成本；

支持了节点资源预留功能

• 集群联邦

Karmada：是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。兼容Kubernetes原生API的能力，可以平滑迁移单集群工作负载，并且仍可保持与Kubernetes周边生态工具链协同

KubeAdmiral：基于 K8s 的新一代多集群编排调度引擎，支持 Kubernetes 原生 API，提供丰富的、可扩展的调度框架，继承了字节对调度算法、分发过程进行了细致的打磨。KubeAdmiral 参考 kube-scheduler 的设计，提供了可拓展的调度框架，将调度逻辑抽象成 Filter, Score, Select 和 Replica 四个步骤，并由多个相对独立的插件各自实现其在每个步骤的逻辑；

• Scheduling Framework v2

核心思想是将Pod调度过程中的每个环节都尽可能插件化，并把原有的调度算法/策略全部用插件的形式重写；目前已实现了如GangScheduling、ElasticQuota、CapacityScheduling、LoadAwareScheduling等插件；

扩展点如下图所示：

3 小结

    很多的业务调度器也需要从多个选项中选出最优的选择，无论是成本最低还是质量最优，我们可以考虑将调度的过程分成过滤和打分两个阶段为调度器建立合适的抽象，过滤阶段会按照需求过滤掉不满足需求的选项，打分阶段可能会按照质量、成本和权重对多个选项进行排序，遵循这种设计思路可以解决很多类似问题。