kube-scheduler代码的组织结构（ver：1.9.2）
1.9中，kube-scheduler仍然是作为一个“plugin”放在k8s代码中，在k8s根目录下的plugin目录中，cmd/kube-scheduler目录是其编译入口，pkg/scheduler目录是其主要核心代码。如图：
在即将发布的1.10中，社区将kube-scheduler从plugin中移出，嵌入到与api-server、kubelet等组件平级的目录。也即根目录下的cmd、pkg目录：
调度器的算法是如何生效的
调度器二进制启动
调度器可以在启动时指定其算法的来源。算法来源有三种：a)本地policy文件；b)policy configMap；c)指定提供者。
对象*scheduler.Config记录了算法来源，当启动参数中policy相关参数不为空时，会从相应的文件或者configMap中读取调度策略；否则检查algorithm-provider参数，这个参数会列出当前可用的provider，如果没有明确指定，那么代码将启动默认的provider：default
从policy读取的调度策略，其内容是一个policy结构
type Policy struct { metav1.TypeMeta // Holds the information to configure the fit predicate functions Predicates []PredicatePolicy // Holds the information to configure the priority functions Priorities []PriorityPolicy // Holds the information to communicate with the extender(s) ExtenderConfigs []ExtenderConfig // RequiredDuringScheduling affinity is not symmetric, but there is an implicit PreferredDuringScheduling affinity rule // corresponding to every RequiredDuringScheduling affinity rule. // HardPodAffinitySymmetricWeight represents the weight of implicit PreferredDuringScheduling affinity rule, in the range 1-100. HardPodAffinitySymmetricWeight int32} 代码会直接根据policy的内容，调用CreateFromKeys 方法去构建最终的scheduler
当没有指定policy时，如果没有指定provider，最后会执行下面这个函数
// Create creates a scheduler with the default algorithm provider.func (f *configFactory) Create() (*scheduler.Config, error) { return f.CreateFromProvider(DefaultProvider)} 随后也会调用CreateFromKeys 方法构建最终的genericScheduler
调度器算法注入
上面的过程中，会最终都调用到func (f *configFactory) CreateFromKeys。 这个函数将参数中的predicate算法、priority算法等注入到调用链中，这个调用链中的函数，会在每次调度pod时被调用。两个调用链分别是genericScheduler结构中的：
type genericScheduler struct { ... predicates map[string]algorithm.FitPredicate ... prioritizers []algorithm.PriorityConfig ...} 当通过policy启动时，CreateFromKeys 方法的参数中的算法都记录到了policy对象中的成员变量里。而如果通过指定provider启动，参数中的算法都来自provider 的init方法。
我们通过阅读provider的init方法，以及init过程中引用到的plugins.go的一些方法，就能知道大概的流程是：
1.调度器的algorithmprovider目录下存放了一个defaults provider，以及一个plugins.go的文件，plugins.go提供了provider登记需要的一些方法。
2.plugins.go 中维护了一个全局的map：algorithmProviderMap， 这个map的key即provider的名字，value是一个结构,维护了两个string集合，用于记录该provider需要的prodicate算法名和priority算法名:
type AlgorithmProviderConfig struct {
FitPredicateKeys sets.StringPriorityFunctionKeys sets.String
}
3.provider的init方法中调用factory.RegisterAlgorithmProvider方法，向上文的map中登记自己。登记时会提供自己本身包含的两类算法的集合。可参考defaults/defaults.go 中的： registerAlgorithmProvider(defaultPredicates(), defaultPriorities())
defaultPredicates()、defaultPriorities()两个函数返回的就是两个集合，只有集合中的字符串对应的算法才会注入到genericScheduler ，从而被调用。而这里字符串和真实算法function的映射关系，分别记录在两个全局map：
fitPredicateMap 和priorityFunctionMap中，defaults.go中 调用的RegisterFitPredicate、RegisterMandatoryFitPredicate等许多方法均会将算法名和算法方法的映射记录到map中。
这里注意到，并不是所有的算法都会登记到集合中的，这里PodFitsPorts、PodFitsHostPorts、PodFitsResources等算法只是记录到map中，并没有登记到set中，但是也被调用了，这是因为这些算法都属于GeneralPredicates算法，在GeneralPredicates算法中被调用。而代码中下文我们会看到在default provider 中登记了GeneralPredicates算法
总结下来就是：要将predicate算法或prioirity算法的映射关系注册到全局map中，然后将算法名登记到provider中，再将provider登记到全局map中，在启动scheduler时指定provider的name，就可以使用相应的provider名下登记的算法来构造genericScheduler。
如何增加算法
上文中提及的plugins.go中， 还提供了一些额外的方法，比如：InsertPredicateKeyToAlgoProvider方法，可以将某个算法登记到指定的provider中。
因此，我们只要在init时将自定义的算法先注册到全局map中：
func init() { factory.RegisterFitPredicate("PodFitsNeteaseResources", predicates.PodFitsNeteaseResources))} 然后在defaults/defaults.go 的init方法尾部，调用InsertPredicateKeyToAlgoProvider将带有自定义算法的名字的set加入default provider即可:
factory.InsertPredicateKeyToAlgoProvider(factory.DefaultProvider, sets.NewString("PodFitsNeteaseResources")) 上述是一个比较规范的注册方式，也有投机取巧的方式，比如在default provider 的func defaultPredicates() 方法尾部增加一行：
factory.RegisterFitPredicate("PodFitsNeteaseResources", predicates.PodFitsNeteaseResources))