1 Scheduler及其算法介绍
Kubernetes Scheduler是Kubernetes Master的一个组件，通常与API Server和Controller Manager组件部署在一个节点，共同组成Master的三剑客。
一句话概括Scheduler的功能：将PodSpec.NodeName为空的Pods逐个地，经过预选(Predicates)和优选(Priorities)两个步骤，挑选最合适的Node作为该Pod的Destination。
展开这两个步骤，就是Scheduler的算法描述：
- 预选：根据配置的Predicates Policies（默认为DefaultProvider中定义的default predicates policies集合）过滤掉那些不满足这些Policies的的Nodes，剩下的Nodes就作为优选的输入。
- 优选：根据配置的Priorities Policies（默认为DefaultProvider中定义的default priorities policies集合）给预选后的Nodes进行打分排名，得分最高的Node即作为最适合的Node，该Pod就Bind到这个Node。 如果经过优选将Nodes打分排名后，有多个Nodes并列得分最高，那么scheduler将随机从中选择一个Node作为目标Node。
因此整个schedule过程，算法本身的逻辑是非常简单的，关键在这些Policies的逻辑，下面我们就来看看Kubernetes的Predicates and Priorities Policies。
2 Predicates and Priorities Policies
2.1 预选策略 (Predicates Policies)
Predicates Policies就是提供给Scheduler用来过滤出满足所定义条件的Nodes，并发的(最多16个goroutine)对每个Node启动所有Predicates Policies的遍历Filter，看其是否都满足配置的Predicates Policies，若有一个Policy不满足，则直接被淘汰。
1 NoDiskConflict
检查在此主机上是否存在卷冲突。如果这个主机已经挂载了卷，其它同样使用这个卷的Pod不能调度到这个主机上，不同的存储后端具体规则不同
2 NoVolumeZoneConflict
检查给定的zone限制前提下，检查如果在此主机上部署Pod是否存在卷冲突
3 PodFitsResources
检查主机的资源是否满足Pod的需求，根据实际已经分配（Limit）的资源量做调度，而不是使用已实际使用的资源量做调度
4 PodFitsHostPorts
检查Pod内每一个容器所需的HostPort是否已被其它容器占用，如果有所需的HostPort不满足需求，那么Pod不能调度到这个主机上
5 HostName
检查主机名称是不是Pod指定的NodeName
6 MatchNodeSelector
检查Node节点的label定义是否满足Pod的NodeSelector属性需求
7 MaxEBSVolumeCount
确保已挂载的EBS存储卷不超过设置的最大值，默认39
8 MaxGCEPDVolumeCount
确保已挂载的GCE存储卷不超过设置的最大值，默认16
9 CheckNodeMemoryPressure
检查pod是否可以调度到已经报告了主机内存压力过大的节点
10 CheckNodeDiskPressure
检查pod是否可以调度到已经报告了主机的存储压力过大的节点
11 MatchInterPodAffinity
检查pod和其他pod是否符合亲和性规则
12 GeneralPredicates
检查pod与主机上kubernetes相关组件是否匹配
13 PodToleratesNodeTaints
确保pod定义的tolerates能接纳node定义的taints
14 GeneralPredicates
检查pod与主机上kubernetes相关组件是否匹配
默认的DefaultProvider中选了以下Predicates Policies
1 NoVolumeZoneConflict
2 MaxEBSVolumeCount
3 MaxGCEPDVolumeCount
4 MatchInterPodAffinity
5 NoDiskConflict
6 GeneralPredicates
7 PodToleratesNodeTaints
8 CheckNodeMemoryPressure
9 CheckNodeDiskPressure
2.2 优选策略(Priorities Policies)
经过预选策略甩选后得到的Nodes，会来到优选步骤。在这个过程中，会并发的根据每个Priorities Policy分别启动一个goroutine，在每个goroutine中会根据对应的policy实现，遍历所有的预选Nodes，分别进行打分，每个Node每一个Policy的打分为0-10分，0分最低，10分最高。待所有policy对应的goroutine都完成后，根据设置的各个priorities policies的权重weight，对每个node的各个policy的得分进行加权求和作为最终的node的得分。
如果经过优选将Nodes打分排名后，有多个Nodes并列得分最高，那么scheduler将随机从中选择一个Node作为目标Node。
1 EqualPriority
所有节点同样优先级，无实际效果
2 ImageLocalityPriority
根据主机上是否已具备Pod运行的环境来打分，得分计算：不存在所需镜像，返回0分，存在镜像，镜像越大得分越高
3 LeastRequestedPriority
计算Pods需要的CPU和内存在当前节点可用资源的百分比，具有最小百分比的节点就是最优，得分计算公式
cpu((capacity – sum(requested)) * 10 / capacity) + memory((capacity – sum(requested)) * 10 / capacity) / 2
4 BalancedResourceAllocation
节点上各项资源（CPU、内存）使用率最均衡的为最优，得分计算公式
10 – abs(totalCpu/cpuNodeCapacity-totalMemory/memoryNodeCapacity)*10
5 SelectorSpreadPriority
按Service和Replicaset归属计算Node上分布最少的同类Pod数量，得分计算：数量越少得分越高
6 NodePreferAvoidPodsPriority
判断alpha.kubernetes.io/preferAvoidPods属性，设置权重为10000，覆盖其他策略
7 NodeAffinityPriority
节点亲和性选择策略
提供两种选择器支持：
- requiredDuringSchedulingIgnoredDuringExecution（保证所选的主机必须满足所有Pod对主机的规则要求
- preferresDuringSchedulingIgnoredDuringExecution（调度器会尽量但不保证满足NodeSelector的所有要求）
8 TaintTolerationPriority
类似于Predicates策略中的PodToleratesNodeTaints，优先调度到标记了Taint的节点
9 InterPodAffinityPriority
pod亲和性选择策略，类似NodeAffinityPriority
提供两种选择器支持：
requiredDuringSchedulingIgnoredDuringExecution（保证所选的主机必须满足所有Pod对主机的规则要求）preferresDuringSchedulingIgnoredDuringExecution（调度器会尽量但不保证满足NodeSelector的所有要求）
两个子策略：
- podAffinity
- podAntiAffinity
10 MostRequestedPriority
动态伸缩集群环境比较适用，会优先调度pod到使用率最高的主机节点，这样在伸缩集群时，就会腾出空闲机器，从而进行停机处理。
默认的DefaultProvider中选了以下Priorities Policies
1 SelectorSpreadPriority, 默认权重为1
2 InterPodAffinityPriority, 默认权重为1
3 LeastRequestedPriority, 默认权重为1
4 BalancedResourceAllocation, 默认权重为1
5 NodePreferAvoidPodsPriority, 默认权重为10000
6 NodeAffinityPriority, 默认权重为1
7 TaintTolerationPriority, 默认权重为1
3 总结
- kubernetes scheduler的任务就是将pod调度到最合适的Node。
- 整个调度过程分两步：预选(Predicates)和优选(Policies)
- 默认配置的调度策略为DefaultProvider，具体包含的策略见上。
- 可以通过kube-scheduler的启动参数--policy-config-file指定一个自定义的Json内容的文件，按照格式组装自己Predicates and Priorities policies。
