kube-scheduler 架构概述

本文主要介绍一下kube-scheduler的架构,简要说明一下各个模块的作用,后面会单独详细分析每个模块。架构图如下
在这里插入图片描述

监听资源
kube-scheduler会通过client-go提供的informer机制监听如下几种k8s的资源变化,相关代码可参考: //pkg/scheduler/eventhandlers.go:addAllEventHandlers
a. Node资源
kube-scheduler的主要目的是给未调度的pod找到合适的node,所以kube-scheduler必须得知道所有的node信息,这里通过监听node资源的增删改事件将node信息保存到cache中

b. Pod资源
kube-scheduler的主要目的是给未调度的pod找到合适的node,所以kube-scheduler必须得监听pod资源,未调度的pod指的是pod.Spec.NodeName字段为空的pod,监听到此种pod后,将根据queueSort提供的排序方法进行排序后(按照pod优先级和创建时间),插入ActiveQ中,等待被调度。对于pod.Spec.NodeName字段不为空的pod,又分为两种情况,一种是在创建pod时,显式指定了此pod所在node,另一种情况是调度成功并且bind node成功的pod,对于这种pod将其加入cache中

c. PV/PVC等资源
这里主要是监听影响pod调度的资源,比如PV等pod需要的资源。如果这些资源有变化可能导致之前调度失败的pod成功,所以需要调用MoveAllToActiveOrBackoffQueue将不可调度队列中的pod移动到ActiveO或者BackoffQueue队列

cache
cache主要用来缓存从apiserver监听到的所有的node信息,及node上所有的pod,可参考代码://pkg/scheduler/internal/cache/cache.go。
之前看informer机制源码时,其内部也有cache,缓存的是监听的所有资源信息,包括node和pod,为什么这里要再搞一个cache?我想有两个原因:
a. informer里的cache保存的资源都是分开的,比如想获取某个node上的所有pod,必须遍历所有的pod找到属于这个node的pod。而这里的cache在资源变化时已经将pod按node保存了,所以查找速率更快
b. 这里的cache中node上的信息不仅包括已经成功运行的pod的资源,也包括那些调度成功,但正在bind阶段的pod资源,因为bind过程是异步进行的,schedule调度时必须考虑这些pod所占用的node资源

queue
主要包括三个队列,可参考代码://pkg/scheduler/internal/queue/scheduling_queue.go
a. activeQ
此队列中的pod是正在等待被调度的pod,并且是有序队列,pod优先级高(如果优先级相同,则先创建的pod)的在队列头
b. podBackoffQ
pod退避队列,此队列中的pod是调度失败的pod,等到退避时间到后就会被移动到activeQ,也是有序队列,根据退避时间排序
c. unschedulableQ
此队列保存的是尝试调度但失败的pod

framework
framework是一个调度框架,里面保存着每个扩展点上的插件。

schedulealgorithm
调度算法的目的是根据输入的node列表和pod信息,找到适合pod的node并返回,此过程中会调用framework的prefilter,filter,postfilter,prescore和score五个扩展点上的插件。

下图为调度器数据结构,Scheduler为调度器,其中包括了cache,queue,调度算法和framework等几个接口,每个接口都有其对应的实现
在这里插入图片描述