Go语言kube-scheduler深度剖析开发之scheduler初始化（go语言培训）不看后悔

为了深入学习 kube-scheduler，本系从源码和实战角度深度学 习kube-scheduler，该系列一共分6篇文章，如下：

kube-scheduler 整体架构本文 ：初始化一个 scheduler一个 Pod 是如何调度的如何开发一个属于自己的scheduler插件开发一个 prefilter 扩展点的插件开发一个 socre 扩展点的插件

上一篇，我们说了 kube-scheduler 的整体架构，是从整体的架构方面来考虑的，本文我们说说 kube-scheduler 是如何初始化出来的，kube-scheduler 里面都有些什么东西。

因为 kube-scheduler 源码内容比较多，对于那些不是关键的东西，就忽略不做讨论。

下面我们先看下 Scheduler 的结构

上一篇我们说过，为一个 Pod 选择一个 Node 是按照固定顺序运行扩展点的；在扩展点内，是按照插件注册的顺序运行插件，如下图

上面的这些扩展点在 kube-scheduler 中是固定的，而且也不支持增加扩展点（实际上有这些扩展点已经足够了），而且扩展点顺序也是固定执行的。

下图是插件（以preFilter为例）运行的顺序，扩展点内的插件，你既可以调整插件的执行顺序（实际很少会修改默认的插件执行顺序），可以关闭某个内置插件，还可以增加自己开发的插件。

那么这些插件是怎么注册的，注册在哪里呢，自己开发的插件又是怎么加进去的呢？

我们来看下 Scheduler 里面最重要的一个成员：Profiles profile.Map

Profiles 是一个 key 为 scheduler name，value 是 framework.Framework 的map，表示根据 scheduler name 来获取 framework.Framework 类型的值，所以可以有多个scheduler。或许你在使用 k8s 的时候没有关注过 pod 或 deploment 里面的 scheduler，因为你没有指定的话，k8s 就会自动设置为默认的调度器，下图是 deployment 中未指定 schedulerName 被设置了默认调度器的一个deployment

假设现在我想要使用自己开发的一个名叫 my-scheduler-1 的调度器，这个调度器在 preFilter 扩展点中增加了 zoneLabel 插件，怎么做？

使用 kubeadm 部署的 k8s 集群，会在 /etc/kubernetes/manifests 目录下创建 kube-scheduler.yaml 文件，kubelet 会根据这个文件自动拉起来一个静态 Pod，一个 kube-scheduler pod就被创建了，而且这个 kube-scheduler 运行的参数是直接在命令行上指定的。

其实 kube-scheduler 运行的时候可以指定配置文件，而不直接把参数写在启动命令上,如下形式。

于是乎，我们就可以在配置文件中配置我们调度器的插件了

我们可以使用 enabled，disabled 开关来关闭或打开某个插件。 通过配置文件，还可以控制扩展点的调用顺序，规则如下：

如果某个扩展点没有配置对应的扩展，调度框架将使用默认插件中的扩展如果为某个扩展点配置且激活了扩展，则调度框架将先调用默认插件的扩展，再调用配置中的扩展默认插件的扩展始终被最先调用，然后按照 KubeSchedulerConfiguration 中扩展的激活 enabled 顺序逐个调用扩展点的扩展可以先禁用默认插件的扩展，然后在 enabled 列表中的某个位置激活默认插件的扩展，这种做法可以改变默认插件的扩展被调用时的顺序

还可以添加多个调度器，在 deployment 等控制器中指定自己想要使用的调度器即可：

当然了，现在我们在配置文件中定义的 mySort，zoneLabel 这样的插件还不能使用，我们需要开发具体的插件注册进去，才能正常运行，后面的文章会详细讲。

好了，现在 Profiles 成员（一个map）已经包含了两个元素，{“my-scheduler-1″: framework.Framework ,”my-scheduler-2”: framework.Framework}。当一个 Pod 需要被调度的时候，kube-scheduler 会先取出 Pod 的 schedulerName 字段的值，然后通过 Profiles[schedulerName]，拿到 framework.Framework 对象，进而使用这个对象开始调度，我们可以用下面这种张图总结下上面描述的各个对象的关系。

那么重点就来到了 framework.Framework ，下面是 framework.Framework 的定义：

Framework 是一个接口，需要实现的方法大部分形式为：Run***Plugins，也就是运行某个扩展点的插件，那么只要实现这个 Framework 接口就可以对 Pod 进行调度了。那么需要用户自己实现么？答案是不用，kube-scheduler 已经有一个该接口的实现：frameworkImpl

frameworkImpl 这个结构体里面包含了每个扩展点插件数组，所以某个扩展点要被执行的时候，只要遍历这个数组里面的所有插件，然后执行这些插件就可以了。我们看看 framework.FilterPlugin 是怎么定义的（其他的也类似）：

插件数组的类型是一个接口，那么某个插件只要实现了这个接口就可以被运行。实际上，我们前面说的那些默认插件，都实现了这个接口，在目录 pkg/scheduler/framework/plugins 目录下面包含了所有内置插件的实现，主要就是对上面说的这个插件接口的实现。我们可以简单用图描述下 Pod被调度的时候执行插件的流程

那么这些默认插件是怎么加到framework里面的，自定义插件又是怎么加进来的呢？

分三步：

根据配置文件（–config指定的）、系统默认的插件，按照扩展点生成需要被加载的插件数组（包括插件名字，权重信息），也就是初始化 KubeSchedulerConfiguration 中的 Profiles 成员。

创建 registry 集合，这个集合内是每个插件实例化函数，也就是 插件名字->插件实例化函数的映射，通俗一点说就是告诉系统：1.我叫王二； 2. 你应该怎么把我创建出来。那么张三、李四、王五分别告诉系统怎么创建自己，就组成了这个集合。

这个集合是内置（叫inTree）默认的插件映射和用户自定义（outOfTree）的插件映射的并集，内置的映射通过下面函数创建：

那么用户自定义的插件怎么来的呢？这里咱们先不展开，在后面插件开发的时候再详细讲，不影响我们理解。我们假设用户自定义的也已经生成了 registry，下面的代码就是把他们合并在一起

现在内置插件和系统默认插件的实例化函数映射已经创建好了

将（1）中每个扩展点的每个插件（就是插件名字）拿出来，去（2）的映射（map）中获取实例化函数，然后运行这个实例化函数，最后把这个实例化出来的插件（可以被运行的）追加到上面提到过的 frameworkImpl 中对应扩展点数组中，这样后面要运行某个扩展点插件的时候就可以遍历运行就可以了。我们可以把上述过程用下图表示

上面我们介绍了 Scheduler 第一个关键成员 Profiles 的初始化和作用，下面我们来谈谈第二个关键成员：SchedulingQueue。

SchedulingQueue 是一个 internalqueue.SchedulingQueue 的接口类型，PriorityQueue 对这个接口进行了实现，创建 Scheduler 的时候 SchedulingQueue 会被 PriorityQueue 类型对象赋值。

PriorityQueue 中有关键的3个成员：activeQ、podBackoffQ、unschedulablePods。

activeQ 是一个优先队列，用来存放待调度的 Pod，Pod 按照优先级存放在队列中podBackoffQ 用来存放异常的 Pod， 该队列里面的 Pod 会等待一定时间后被移动到 activeQ 里面重新被调度unschedulablePods 中会存放调度失败的 Pod，它不是队列，而是使用 map 来存放的，这个 map 里面的 Pod 在一定条件下会被移动到 activeQ 或 podBackoffQ 中

PriorityQueue 还有两个方法：flushUnschedulablePodsLeftover 和 flushBackoffQCompleted

flushUnschedulablePodsLeftover：调度失败的 Pod 如果满足一定条件，这个函数会将这种 Pod 移动到 activeQ 或 podBackoffQflushBackoffQCompleted：运行异常的 Pod 等待时间完成后，flushBackoffQCompleted 将该 Pod 移动到 activeQ

Scheduler 在启动的时候，会创建2个协程来定期运行这两个函数

上面是定期对 Pod 在这些队列之间的转换，那么除了定期刷新的方式，还有下面情况也会触发队列转换：

有新节点加入集群节点配置或状态发生变化已经存在的 Pod 发生变化集群内有Pod被删除

至于他们之间是如何转换的，我们在下一篇文章里面详细介绍

要说 cache 最大的作用就是提升 Scheduler 的效率，降低 kube-apiserver(本质是 etcd)的压力，在调用各个插件计算的时候所需要的 Node 信息和其他 Pod 信息都缓存在本地，在需要使用的时候直接从缓存获取即可，而不需要调用 api 从 kube-apiserver 获取。cache 类型是 internalcache.Cache 的接口，cacheImpl 实现了这个接口。

下面是 cacheImpl 的结构

cacheImpl 中的 nodes 存放集群内所有 Node 信息；podStates 存放所有 Pod 信息；，assumedPods 存放已经调度成功但是还没调用 kube-apiserver 的进行绑定的（也就是还没有执行 bind 插件）的Pod，需要这个缓存的原因也是为了提升调度效率，将绑定和调度分开，因为绑定需要调用 kube-apiserver，这是一个重操作会消耗比较多的时间，所以 Scheduler 乐观的假设调度已经成功，然后返回去调度其他 Pod，而这个 Pod 就会放入 assumedPods 中，并且也会放入到 podStates 中，后续其他 Pod 在进行调度的时候，这个 Pod 也会在插件的计算范围内（如亲和性）， 然后会新起协程进行最后的绑定，要是最后绑定失败了，那么这个 Pod 的信息会从 assumedPods 和 podStates 移除，并且把这个 Pod 重新放入 activeQ 中，重新被调度。

Scheduler 在启动时首先会 list 一份全量的 Pod 和 Node 数据到上述的缓存中，后续通过 watch 的方式发现变化的 Node 和 Pod，然后将变化的 Node 或 Pod 更新到上述缓存中。

到了这里，调度框架 framework 和调度队列 SchedulingQueue 都已经创建出来了，现在是时候开始调度Pod了。

Scheduler 中有个成员 NextPod 会从 activeQ 队列中尝试获取一个待调度的 Pod，该函数在 SchedulePod 中被调用，如下：

NextPod 它被赋予如下函数：

Pop 会一直阻塞，直到 activeQ 长度大于0，然后去取出一个 Pod 返回

到了这里我们就介绍完了 Scheduler 中最重要的几个成员，简单总结下：

Profiles: 存放插件对象，在运行时可以遍历扩展点内的所有插件运行SchedulerQueue：用来存放待调度 Pod，异常 Pod，调度失败 Pod，他们相互可以转换cache：存放 Pod 和 Node 的信息，提升调度效率NextPod 和 ScheduleOne：尝试从 activeQ 获取一个 Pod，开始调度。

本文就到这，下一篇，我们会讲一讲一个 Pod 提交后的调度流程。

以上就是Go语言kube-scheduler深度剖析开发之scheduler初始化的详细内容，更多关于go scheduler初始化的资料请关注脚本之家其它相关文章！