Kube-scheduler 源码分析（一）：调度器设计

原文链接： 调度器设计

前言

我们先整体了解一下 Scheduler 的设计原理，然后再看这些过程是如何用代码实现的。 关于调度器的设计在官网有介绍，我下面结合官网给的说明，简化掉不影响理解的复杂部分，和大家介绍一下 Scheduler 的工作过程。

英文还可以的小伙伴们可以看一下官网的介绍先：

官网有一段描述如下：

The Kubernetes scheduler runs as a process alongside the other master components such as the API server. Its interface to the API server is to watch for Pods with an empty PodSpec.NodeName, and for each Pod, it posts a binding indicating where the Pod should be scheduled.

简单翻译一下，也就是说 Scheduler 是一个跑在其他组件边上的独立程序，对接Apiserver寻找  PodSpec.NodeName  为空的 Pod，然后用  post  的方式发送一个 api 调用，指定这些 pod 应该跑在哪个 node 上。

通俗地说，就是 scheduler 是相对独立的一个组件，主动访问 api server，寻找等待调度的 pod，然后通过一系列调度算法寻找哪个 node 适合跑这个 pod，然后将这个 pod 和 node 的绑定关系发给 api server，从而完成了调度的过程。

源码层级

从高 level 看，scheduler 的源码可以分为 3 层：

• cmd/kube-scheduler/scheduler.go : main() 函数入口位置，在 scheduler 过程开始被调用前的一系列初始化工作。

• pkg/scheduler/scheduler.go : 调度框架的整体逻辑，在具体的调度算法之上的框架性的代码。

• pkg/scheduler/core/generic_scheduler.go : 具体的计算哪些 node 适合跑哪些 pod 的算法。

调度算法

调度过程整体如下图所示（官文里这个图没对齐，逼疯强迫症了！ ！ ！ 当然由于中文显示的问题，下图有中文的行也没法完全对齐，这个地方让我很抓狂。 。 。 ）：

对于一个给定的pod
+---------------------------------------------+
|             可用于调度的nodes如下：           |
|  +--------+     +--------+     +--------+   |
|  | node 1 |     | node 2 |     | node 3 |   |
|  +--------+     +--------+     +--------+   |
+----------------------+----------------------+
                       |
                       v
+----------------------+----------------------+
             初步过滤: node 3 资源不足
+----------------------+----------------------+
                       |
                       v
+----------------------+----------------------+
|                 剩下的nodes:                 |
|     +--------+               +--------+     |
|     | node 1 |               | node 2 |     |
|     +--------+               +--------+     |
+----------------------+----------------------+
                       |
                       v
+----------------------+----------------------+
优先级算法计算结果:    node 1: 分数=2
                    node 2: 分数=5
+----------------------+----------------------+
                       |
                       v
            选择分值最高的节点 = node 2

Scheduler 为每个 pod 寻找一个适合其运行的 node，大体分成三步：

1. 通过一系列的  predicates  过滤掉不能运行 pod 的 node，比如一个 pod 需要 500M 的内存，有些节点剩余内存只有 100M 了，就会被剔除；

2. 通过一系列的  priority functions  给剩下的 node 排一个等级，分出三六九等，寻找能够运行 pod 的若干 node 中最合适的一个 node；

3. 得分最高的一个 node，也就是被  priority functions  选中的 node 胜出了，获得了跑对应 pod 的资格。

Predicates 和 priorities 策略

Predicates 是一些用于过滤不合适 node 的策略。 Priorities 是一些用于区分 node 排名（分数）的策略（作用在通过 predicates 过滤的 node 上）. K8s 默认内建了一些 predicates 和 priorities 策略，官方文档介绍地址：   scheduler_algorithm.md 。 Predicates 和 priorities 的代码分别在：

• pkg/scheduler/algorithm/predicates/predicates.go

• pkg/scheduler/algorithm/priorities

Scheduler 的拓展性

我们可以选择哪些预置策略生效，也可以添加自己的策略。 几个月前我司有个奇葩调度需求，当时我就是通过增加一个 priorities 策略，然后重新编译了一个 Scheduler 来实现的需求。

调度策略的修改

默认调度策略是通过  defaultPredicates()  和  defaultPriorities()  函数定义的，源码在  pkg/scheduler/algorithmprovider/defaults/defaults.go ，我们可以通过命令行 flag  --policy-config-file  来覆盖默认行为。 所以我们可以通过配置文件的方式或者修改  pkg/scheduler/algorithm/predicates/predicates.go  和  /pkg/scheduler/algorithm/priorities ，然后注册到  defaultPredicates() / defaultPriorities()  来实现。 配置文件类似下面这个样子：

{
"kind" : "Policy",
"apiVersion" : "v1",
"predicates" : [
    {"name" : "PodFitsHostPorts"},
    {"name" : "PodFitsResources"},
    {"name" : "NoDiskConflict"},
    {"name" : "NoVolumeZoneConflict"},
    {"name" : "MatchNodeSelector"},
    {"name" : "HostName"}
    ],
"priorities" : [
    {"name" : "LeastRequestedPriority", "weight" : 1},
    {"name" : "BalancedResourceAllocation", "weight" : 1},
    {"name" : "ServiceSpreadingPriority", "weight" : 1},
    {"name" : "EqualPriority", "weight" : 1}
    ],
"hardPodAffinitySymmetricWeight" : 10,
"alwaysCheckAllPredicates" : false
}

ok，看到这里大伙应该在流程上对 Scheduler 的原理有个感性的认识了，下一节我们就开始看一下 Scheduler 源码是怎么写的。