云厂商将机房中服务器的计算能力进行整合，如 CPU、内存等，并把这些硬件统一抽象为资源，然后按需卖给用户，这就是云计算理念，怎么把这些资源有效的管理和调度起来，最大化资源利用率，关系着云厂商的成本和营收，也是各厂商实现差异化的一个重要切入点。本文讲讲云计算中的资源调度，或者称为 scheduler。

openstack 中，有个叫做 nova-scheduler 的模块，类似于 k8s 中的 scheduler 组件，这两个模块就是资源调度，功能类似，是我们讨论的主角。要说明的是，本文并不打算拿源码逐行分析，而只是阐述资源调度里的一些核心思想。

什么是资源调度

资源调度要解决的核心问题是，用户创建的 VM 或 pod 应该分配到集群的哪个节点上。以及当某个节点负载超过报警阈值时，自动将 VM 或 pod 调度到其他负载较低的节点，以达到整个集群中所有节点的 CPU，内存，I/O 等指标保持大致相当的水平，类似于负载均衡。毫无疑问，这样做一方面提高集群的资源利用率，另一方面降低个别节点负载过高导致 VM 或 pod 性能跟着受影响。为了方便，下文只用 VM 代表被调度对象。

怎么做资源调度

资源调度的过程就是一个筛选最优解的过程，这里的解指的是集群中最优的节点。为了找到最优解，显然需要知道节点有哪些过滤条件，影响因子，以及各影响因子的权重。只要找到这些因素，我们就可以对各节点进行过滤筛选和打分排序，直到找出最优节点，筛选过程类似于下图。 筛选过程

一般的，资源调度对节点的筛选会分为两个步骤：硬性条件筛选，软性条件筛选（需要说明下，这两个名词是我参考了文末的资料，并非原创）。在一些开源框架中，这两个步骤都有特定的叫法，如 openstack 中，这两个步骤分别称为 filter 和 weighting，在 k8s 中，分别称为 predicate 和 priority。

硬性条件筛选

硬性条件筛选，解决的是”能不能“的问题，即这个 VM 能不能建在这个节点上。那么有哪些硬性筛选条件呢？

  • 节点类型 节点类型包括节点的固有属性，包括硬件类型，软件类型等。比如用户创建的 VM 对计算性能有要求，指定了 CPU 型号为 1802，因此那些 CPU 非指定型号的节点将直接被过滤掉；再比如，某个节点当前被设置为 disable 或 maintanced，表示该节点有问题或处于维护状态，这样的节点将被过滤掉。

  • 计算容量 整个很好理解，只有容量满足需求的节点才能通过筛选。比如用户创建的 VM 是 8 核 16 G，那么那些可用 CPU 数少于 8 或者可用内存少于 16 G 的节点将被过滤掉。

  • 磁盘容量 这个类似于计算容量，用户需要一个 500 G 的本地 SSD 磁盘，那些磁盘容量少于 500 G 的节点将被过滤掉。

  • 节点配额 当一个节点计算容量和磁盘容量都满足条件，并不一定能通过筛选，还要看该节点是否满足系统配额，比如系统规定，每个节点最多只能放有 10 个 VM，那么如果某节点已经到上限，此时也会被过滤掉。

这里列举的只是一部分典型的筛选条件，还有其他的条件这里没有给出。

硬性条件筛选过滤掉了所有不满足条件的节点，剩下的节点都是满足创建 VM 的。硬性条件筛选不具有权重，筛选时，根据某一条件，节点要么能通过筛选，要么不能。任意一个条件筛选完后，发现没有可用的节点，那么就认为调度失败，要么直接返回错误，要么循环一直重新筛选，直到筛到有可用节点为止。 只有通过所有条件筛选的节点，才可以进行下一步软性条件筛选。

软性条件筛选

通过上一步的硬性条件筛选，现在可以对剩下的所有节点进行软性条件筛选了。软性条件筛选解决的是”好不好“的问题，即 VM 建在这个节点上好不好，是不是最优的。我们也看下有哪些软性条件。

  • 资源占用小 这个原则很直观：VM 最好是建在那些负载较低的节点上，这样有利于 VM 的快速启动以及性能。负载较高的节点，会导致上面的 VM 资源争抢严重。最坏的情况下，甚至导致节点宕机，因此最好不要选择负载高的节点。

  • 亲和性 亲和性是说，尽量将多个 VM 放在一个节点，或者绑定在一个节点上。例如，现在每个节点上有 500G 的磁盘空间供 VM 使用，假如 VM A 占用了 Node1 上的 300G，这时有一个创建 VM 的请求，它想要 200G 的空间，那么它可以选择节点 Node1，也可以选择其他 500G 的节点，但根据亲和性原则，它最好选择 Node1，因为这样正好可以把 Node1 上的磁盘用完，充分利用了磁盘资源。如果不这样选择，而是选择了其他有 500G 容量的节点，如 Node2，那么现在 Node1 上剩 200G，Node2 上剩 300G，如果这时再想创建一个 400G 或 500G 的 VM，Node1 和 Node2 均无法满足磁盘容量需求，这时不得不选择一个其他有 500G 的节点，如 Node3。这时 Node1 和 Node2 上剩余的磁盘资源就这么空着浪费掉了，有了亲和性，只需要使用 Node1 和 Node2 即可，这就是一个亲和性表现。

  • 打散分布 打散正好跟亲和性相反，也可以称为反亲和性。有的情况下，我们会按照某种规则，将资源尽量进行打散分布，例如，某个用户创建 5 台 VM，这里就可以将这 5 个 VM 做打散处理，将他的 VM 尽量分布在不同的节点上。这样的好处是，避免了某个节点宕机导致该用户在上面建的 VM 全挂，通俗点，不要将鸡蛋放在一个篮子里。这里是按照用户来进行打散筛选的，实际还有很多其他维度可以应用打散筛选规则，如根据标签打散，在创建 VM 时，给 VM 打上一个标签，有相同标签的多个 VM 打散分布在不同的节点上。

  • 本地基础镜像缓存 本地基础镜像是指 VM 运行时需要的 base 镜像。我们知道，KVM 使用了一种称为写时复制的技术，每个 VM 都是由一个 base 层和一个 top 层构成，base 层是只读的，里面的数据是操作系统，和一些预装程序，所有的写操作都在 top 层完成，这样的好处是，多个 VM 可以共用一个 base，而只有 top 层独立。base 一般称为基础镜像，也可以叫 backing file。这些基础镜像一般会集中放在一个镜像服务器上，当需要时，会被下载到指定节点，作为这个节点上所有相同系统的 VM 的 base。后面如果再创建了相同系统的 VM，就不用再去下载了，这样可以大大加快创建 VM 的速度。 现在假如要创建一个 CentOS7 的 VM，Node1 上已经有 CentOS7 的 base，而 Node2 上没有，那么我们应该选择 Node1，这样免去了下载 base 的时间成本。

软性条件筛选每个因素都可以有对应的权重，根据这些权重和分值，可以给通过了硬性条件筛选的所有节点计算加权分值，得分最高的节点即是最优节点。

最优节点找到后，调度的任务就完成了，剩下的就是在这节点上创建 VM 了。k8s 中，这个过程被称为 binding（pod 和 node 绑定）。

上面列出的只是一部分条件，其他的条件不一一列举，事实上，软性条件筛选灵活性很高，比硬性条件筛选更复杂，更主观，影响因子可以有很多，权重也可以动态调整，需要根据实际情况，业务情况，选择合适的条件，合理的权重。

总结下来，整个调度过程，就是一个不断过滤筛选的过程，输入 VM 的各项规格，调度器根据这些规格参数，以及集群中所有节点的属性，输出一个最合适的节点，可用下图来概括调度的作用。 调度器

另外，上面的每个筛选流程都是独立的，也就是说，可以在任意两个流程中插入自己的筛选逻辑，只要符合期望即可，甚至完全不用框架提供的调度器，完全使用自定义的调度器。事实上很多企业内部自研的调度，都是在开源框架的基础上，加入了一些定制化的调度逻辑来满足自己的需求，比如，在硬性条件筛选阶段，把过滤效率高的流程提前，一次性过滤尽可能多的不符合条件的节点；软性条件筛选阶段，在允许一定容忍度情况下，寻找一个局部最优节点而不是全局最优节点，也能加快筛选过程。但也需要考虑到，筛选逻辑并非越多越好，过多反而会使筛选效率降低，得不偿失。

资源重调度

经过上面的步骤，我们解决了如何为新创建的 VM 分配一个合理的节点。但需要注意，系统运行过程中，节点的各参数都是动态变化的，比如某节点现在负载较低，过了一会儿，该节点上面的 VM 做大量运算，或者节点执行像打快照这类比较重的操作，导致节点负载升高，超过警戒阈值，那么这时需要对节点上的 VM 做迁移操作，将部分 VM 迁到其他节点，以降低该节点的负载。迁到哪个节点上呢？这就又涉及到上面的调度过程了，还是需要经过硬性条件和软性条件筛选，这个过程就是重调度。

资源重调度是一个很重要，也很复杂的问题，最原始的方式是人肉盯监控报警，一旦出现负载高的节点，由人工手动迁移 VM，这种处理方式简单但费力，半夜被报警吵醒也是常事，相当于响应式处理。当集群节点数上去后，就需要一种能自动迁移的机制了，也就是智能调度，这种方式不仅免去人工操作的繁琐，还具有一定的预测能力，即依靠机器学习或神经网络等技术，能提前预知哪些节点可能会报警，那么就提前自动迁移该节点上的 VM，整个过程不需要人工干预。

总结

云计算完成了 CPU、内存、磁盘、网络等资源的抽象，资源调度解决的问题是如何将一个 VM，一个 pod，或者更抽象点说，一个应用，放到最合适的位置，以提高整个集群中节点的使用率，既不出现节点负载很高导致性能受影响，也不会有使用率低导致机器的浪费。本文简单介绍了资源调度的流程，包括硬性筛选和软性筛选，以及一些典型的筛选条件，实际使用的调度要比这复杂的多，基于此，智能调度也是未来资源调度领域的一个热点。

参考

https://tech.meituan.com/2019/08/22/kubernetes-cluster-management-practice.html 《容器与容器云》