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,组织前两个部分,进行调度

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

扫码关注云+社区