5.4 KiB
调度器框架
前言
在上一篇文档中，我们找到了sheduler调度功能主逻辑的入口:
那么在本篇，我们基于找到的入口，来进入调度器框架内部，看一看整体的逻辑流程,本篇先跳过调度的算法(Predicates断言选择、Priority优先级排序)，只关注pkg/scheduler目录内的scheduler框架相关的逻辑流向，摸清scheduler框架本身的代码结构，调度算法留在后面的文章再谈
框架流程
让回到我们上一篇篇末找到的调度逻辑入口位置，pkg/scheduler/scheduler.go:435, scheduleOne()函数内部，定位在pkg/scheduler/scheduler.go:457位置,是通过这个sched.schedule(pod)方法来获取与pod匹配的node的，我们直接跳转2次,来到了这里pkg/scheduler/core/generic_scheduler.go:107
通过注释可以知道，ScheduleAlgorithm interface中的Schedule方法就是用来为pod筛选node的，但这是个接口方法，并不是实际调用的，我们稍微往下,在pkg/scheduler/core/generic_scheduler.go:162这个位置，就可以找到实际调用的Schedule方法:
本篇我们不看Schedule方法内的具体调度算法细节，先来逆向回溯代码结构，找到哪里创建了scheduler，调度器的默认初始化配置，默认的调度算法来源等等框架相关的东西。Schedule()方法属于genericScheduler结构体，先查看genericScheduler结构体，再选中结构体名称，crtl + b组合键查看它在哪些地方被引用，找出创建结构体的位置:
通过缩略代码框，排除test相关的测试文件，很容易找出创建结构体的地方位于pkg/scheduler/core/generic_scheduler.go:1189，点击图中红框圈中位置，跳转过去，果然找到了NewGenericScheduler()方法，这个方法是用来创建一个genericScheduler对象的，那么我们再次crtl + b组合键查看NewGenericScheduler再什么地方被调用：
找出了在pkg/scheduler/factory/factory.go:441这个位置上找到了调用入口，这里位于CreateFromKeys()方法中，继续crtl + b查看它的引用,跳转到pkg/scheduler/factory/factory.go:336这个位置：
这里找到了algorithmProviderMap这个变量，顾名思义，这个变量里面包含的应该就是调度算法的来源,点击进去查看,跳转到了pkg/scheduler/factory/plugins.go:86这个位置,组合键查看引用，一眼就可以看出哪个引用为这个map添加了元素：
跳转过去，来到了pkg/scheduler/factory/plugins.go:391这个位置，这个函数的作用是为scheduler的配置指定调度算法，即FitPredicate、Priority这两个算法需要用到的metric或者方法,再次请出组合键，查找哪个地方调用了这个方法：
来到了pkg/scheduler/algorithmprovider/defaults/defaults.go:99，继续组合键向上查找引用,这次引用只有一个，没有弹窗直接跳转过去了pkg/scheduler/algorithmprovider/defaults/defaults.go:36:
我们来看看defaultPredicates(), defaultPriorities()这两个函数具体的内容:
我们随便点击进去一个predicates选项查看其内容:
CheckNodeMemoryPressure这个词相应熟悉kubernetes pod的朋友一定不会陌生，在node内存压力大无法调度的pod时，kubectl describe pod xxx就会在状态信息里面看到这个关键词。同时，该变量的定义位于pkg/scheduler/algorithm/predicates/predicates.go:102，pkg/scheduler/algorithm/这个目录在调度器的总览中已经讲过是调度算法相关的目录，defaultPredicates(), defaultPriorities()里面的内容都是位于这个目录中，具体调度器的断言过滤、优先级排序算法详情将在下篇中详解，本篇调度器框架结构梳理到此结束！