kube-scheduler的Configurator解析

前言

调度器配置中解析了kube-scheduler的各种配置，但是自始至终都没有看到如何根据配置构造调度器。虽然调度器文章中提到了构造函数，但是其核心实现是Configurator，本文将解析Configurator构造调度器的过程。虽然意义远没有调度队列、调度框架、调度插件等重大，但是对于了解调度器从生到死整个过程来说是必要一环，况且确实能学到点东西。

Configurator

Configurator定义

Configurator类似于Scheduler的工厂，但是一般的工厂类很少会有这么多的配置，所以Configurator这个名字比Factroy更合适。源码链接：https://github.com/kubernetes/kubernetes/blob/release-1.21/pkg/scheduler/factory.go#L59

// Configurator根据配置构造调度器
type Configurator struct {
	// 因为kube-scheduler需要访问apiserver，所以clientset.Interface是必须的。
	client clientset.Interface

	recorderFactory profile.RecorderFactory

	// informerFactory和client都是用来访问apiserver，informerFactory用来读API对象，client用于写API对象(比如绑定)
	informerFactory informers.SharedInformerFactory

	// 这个关闭信号，用chan实现是非常普遍的做法
	StopEverything <-chan struct{}

	// 调度缓存，调度器必须的模块，这可以证明调度缓存不是Scheduler构造的，而是通过Configurator传给Scheduler
	schedulerCache internalcache.Cache

	// 是否运行所有的FilterPlugin，即便中间某个插件返回失败。
	// 了解调度插件的读者都知道，有任何过滤插件返回失败，表示Pod不可调度，所有的过滤插件是与的关系。
	// 所以排序靠前的过滤插件返回失败理论上是无需再用后面的插件过滤了，这个配置就是是否运行所有的过滤插件。
	alwaysCheckAllPredicates bool

	// 这几个配置参数已经在调度器配置、调度框架、调度队列等文章中详细解释过了，Configurator只需要透明传递就好了
	percentageOfNodesToScore int32
	podInitialBackoffSeconds int64
	podMaxBackoffSeconds int64

	// 每个KubeSchedulerProfile对应一个调度框架(Framework)的配置，所以Configurator需要根据配置构造Framework
	profiles          []schedulerapi.KubeSchedulerProfile
	// 调度插件工厂注册表，即根据调度插件名字与调度插件工厂的映射。
	// 因为Configurator根据配置为Framework创建插件，所以需要根据插件名字获取调度插件工厂来构造插件
	registry          frameworkruntime.Registry
	// 调度缓存快照，熟悉调度缓存的读者应该知道，Scheduler每次调度之前都会更新调度缓存快照，调度缓存只需要将更新与快照diff的部分即可。
	// 所以调度缓存快照是和Scheduler一起创建，生命周期与调度器是相同的，由Configurator创建再传递给Scheduler。
	nodeInfoSnapshot  *internalcache.Snapshot
	// 调度扩展程序配置，Configurator需要根据配置构造调度扩展程序并传递给Scheduler
	extenders         []schedulerapi.Extender
	// frameworkCapturer是回调函数，用来捕获每最终的KubeSchedul