调度流程
调度器就是一个独立的进程，负责不断从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(re |
本文转移开源中国-
Kubernetes调度算法介绍
