k8s源码分析-----kube-scheduler
说明：此文章为腾讯云机器自动从本人csdn博客搬迁过来。是本人授权操作。
申明：无本人授权，不可转载本文。如有转载，本人保留追究其法律责任的权利。
龚浩华，QQ 29185807，月牙寂 道长
第一时间获取文章，可以关注本人公众号 月牙寂道长 yueyajidaozhang
源码为k8s v1.1.1稳定版本
一、主要流程
1、main入口
源码在k8s.io/kubernetes/plugin/cmd/kube-scheduler
这种封装是k8s里面一贯的封装风格，就不再多说了
源码在k8s.io/kubernetes/plugin/cmd/kube-scheduler/app
继续往下
真正的入口
下面有个ratelimiter
在factory.NewConfigFactory之后调用了func (s *SchedulerServer) createConfig
2、configFactory
源码k8s.io/kubernetes/plugin/pkg/scheduler/factory
先看下结构体
1、client 与apiserver的接口
2、podqueue，ScheduledPodLister，scheduledPodPopulator 这个是关键数据，稍后分析
3、PodLister ，NodeLister，ServiceLister，ControllerLister 调度的时候需要用到的数据
4、BindPodsRateLimiter，在入口初始化的ratelimiter
5、modeler，pod信息处理部分
我们继续
以下代码，做了简单的初始化。其中重要的初始化有modeler
继续流程
继续
3、Scheduler流程
二、modeler分析
源码在k8s.io\kubernetes\plugin\pkg\scheduler\modeler.go
在modeler中，有三个list
1、queuedPods: a PodLister that will return pods that have not been scheduled yet.
即将被调度，还未被调度的
2、scheduledPods: a PodLister that will return pods that we know for sure have been scheduled.
已经调度的
3、assumedPods： holds the pods that we think we've scheduled, but that haven't yet shown up in the scheduledPods variable. 正在调度中，还未确认以上三个队列我们看看三个队列的前世与今生
1、queuedPods
在k8s.io\kubernetes\plugin\pkg\scheduler\factory\factory.go中（上文中已经有）
很明显podqueue初始化了modeler
k8s.io\kubernetes\plugin\pkg\scheduler\modeler.go
ConfigFactory中的podqueue就是modeler中的queuedpods
func (f *ConfigFactory) CreateFromKeys 函数中，在这里生成了一个生产者，用于获取那些需要调度的pod，保存在podqueue中
func (f *ConfigFactory) CreateFromKeys函数末尾，在函数尾部，提供了一个借口用于Scheduler获取需要调度的pod
在k8s.io\kubernetes\plugin\pkg\scheduler中的scheduleOne，获取需要调度的pod，然后进行调度
2、assumedPods
在k8s.io\kubernetes\plugin\pkg\scheduler中的scheduleOne，调度需要调度的pod，然后将其调度放到assumedpods中
在modeler中，添加到assumepods队列
然后我们看看在什么时候将assumepods消费掉
在NewConfigFactory函数中，我们看到，生成了一个生产者，获取到所有被调度的pod，然后在两个接口中，将在assumepods中的，已经被调度的pod删除
3、scheduledPods
这个已经被调度的则是在NewConfigFactory函数中，定时获取到的已经被调度的pod
总结
1、在ConfigFactory中，调用与apiserver的接口，定期获取需要调度的pod，将其保存在modeler中的queuedPods中
2、在ConfigFactory中，像Scheduler提供获取需要调度pod的接口，然后在Scheduler中进行调度处理，（通过genericScheduler获取调度需要的host），然后将其放入modeler中的assumepods中
3、在ConfigFactory中，定期获取已经调度的pod信息，然后刷新assumepod和scheduledPods
三、genericScheduler分析
我们看看k8s.io\kubernetes\plugin\pkg\scheduler\factory中
GenericScheduler需要什么
func (f *ConfigFactory) CreateFromKeys中
准备数据
func (f *ConfigFactory) CreateFromKeys
1、podlister为modeler的podlister
2、ServiceLister
func (f *ConfigFactory) CreateFromKeys中
3、ControllerLister
func (f *ConfigFactory) CreateFromKeys中
4、NodeLister
那么我们看scheduler工作流程。初始化中nodelister和genericScheduler
调度的时候，获取到需要调度的pod，然后genericScheduler进行调度获取host
我们看genericScheduler中的调度
四、调度算法
k8s.io\kubernetes\plugin\pkg\scheduler\algorithmprovider中
具体算法就不做探讨了
五、总结
在此系统中，3个部分功能清晰，各司其责
modeler，主要负责pod 信息管理（需要调度的，已经调度的，正在调度中的）
genericScheduler，主要负责pod，计算出host的工作
Scheduler，组织前两个部分，进行调度