调度流程

调度器就是一个独立的进程，负责不断从apiserver拉取还没有被调度的pod，以及可调度的node列表，通过一些列算法筛选，选出一个node并与该pod绑定，将绑定的结果写回apiserver

调度算法

下面讲解基于k8s v1.6.6的源码

算法需要经过两个阶段，分别是过滤和打分，首先过滤掉一部分，保证剩余的节点都是可调度的，接着在打分阶段选出最高分节点，该节点就是scheduler的输出节点。

算法流程：

过滤

过滤环节就是一条过滤器链，包含多个过滤器，每个相当于一个函数，接收node和待调度的pod作为参数，返回bool来确定是否可调度。通过组合多个函数可以完成一条可扩展的过滤器链。目前k8s中已注册的过滤器函数如下：

算法名称	是否默认	详细说明
NoVolumeZoneConflict	是	当主机上zone-label（地区）包含pod中PersistentVolume卷下的zone label时，可以调度。当主机没有zone-label，表示没有没有zone限制，也可调度
MaxEBSVolumeCount	是	当主机上被挂载的AWS EBS Volume超过了默认限制39，就不调度到该主机
MaxGCEPDVolumeCount	是	当主机上被挂载的GCD Persistent Disk超过了默认限制16，就不调度到该机器
MaxAzureDiskVolumeCount	是	当主机上被挂载的Azure Disk Volume超过了默认限制16，就不调度到该机器
NoDiskConflict	是	当主机上所有pod使用的卷和待调度pod使用的卷存在冲突，就不调度到该主机。这项检查只针对GCE, Amazon EBS, Ceph RBD, ISCSI，具体规则为： GCE PersistentDisk允许多次只读挂载相同的volume EBS禁止两个pod挂载同一个id的volume Ceph RBD禁止两个pod共享一个monitor、pool、image ISCSI禁止两个pod共享同一个IQN
MatchInterPodAffinity	是	亲和性检查，设带调度的pod为X，当主机上所有正运行的pod与X不相互排斥时，则可调度
PodToleratesNodeTaints	是	当pod可以容忍（tolerate）主机所有的taint（污点）时，才可被调度（容忍taint标签的方式就是给自己也打上相应tolerations标签）
CheckNodeMemoryPressure	是	当主机剩余内存紧张时，BestEffort类型的pod无法被调度到该主机
CheckNodeDiskPressure	是	当主机剩余磁盘空间紧张时，无法调度到该主机
PodFitsHostPorts	是	当待调度pod中所有容器所用到的HostPort与工作节点上已使用端口存在冲突，就不调度到该主机
PodFitsPorts	是	被PodFitsHostPorts取代
PodFitsResources	是	当总资源-主机中所有pod对资源的request总量 < 带调度的pod request资源量，则不调度到该主机，现在会检查CPU,MEM,GPU资源
HostName	是	如果待调度的pod指定了pod.Spec.Host，则调度到该主机上
MatchNodeSelector	是	当主机label与pod中nodeSelector以及annotations scheduler.alpha.kubernetes.io/affinity匹配，则可调度

打分

打分环节也是一条链路，包含多个打分函数，每个打分函数会接收node和待调度的pod作为参数，返回一个范围在0-10的分数，每个打分函数还有一个权重值。某个node算出的总分就是所有打分函数的分值*权重值的总和，获取总分最大的node（如果有多个，随机取一个），该node就是最终要被调度的节点

示例：假设有个节点nodeA，有两个打分函数priorityFunc1、priorityFunc2（每个方法都能返回一个score），两个方法分别都有权重因子weight1、weight2。则nodeA的总分为：finalScoreNodeA = (weight1 * priorityFunc1) + (weight2 * priorityFunc2)

目前k8s中已注册的打分函数如下：

算法名称	是否默认	权重	详细说明
SelectorSpreadPriority	是	1	相同service／rc的pods越分散，得分越高
ServiceSpreadingPriority	否	1	相同service的pods越分散，优得分越高，被SelectorSpreadPriority取代，保留在系统中，并不使用
InterPodAffinityPriority	是	1	pod与node上正运行的其他pod亲和性匹配度越高，得分越高
LeastRequestedPriority	是	1	剩余资源越多，得分越高。cpu((capacity - sum(requested)) * 10 / capacity) + memory((capacity - sum(requested)) * 10 / capacity) / 2
BalancedResourceAllocation	是	1	cpu和内存利用率越接近，得分越高。10 - abs(cpuFraction-memoryFraction)*10
NodePreferAvoidPodsPriority	是	10000	当node的annotation scheduler.alpha.kubernetes.io/preferAvoidPods被设置时，说明该node不希望被调度，得分低，当没有设置时得分高。之所以权重较大是因为一旦设置preferAvoidPods表示该node不希望被调度，该项得分为0，其他没有设置的node得分均为10000*分值，相当于直接过滤掉该节点。思考：其实可以放在过滤环节处理
NodeAffinityPriority	是	1	pod与node的亲和性匹配度越高，得分越高
TaintTolerationPriority	是	1	pod对node的污点（taint）的容忍（tolerate）程度越高，得分越高
EqualPriority	否	1	所有机器得分一样
ImageLocalityPriority	否	1	待调度的pod会使用到一些镜像，拥有这些镜像越多的节点，得分越高
MostRequestedPriority	否	1	request资源越多，得分越高，与LeastRequestedPriority相反。(cpu(10 * sum(requested) / capacity) + memory(10 * sum(requested) / capacity)) / 2