Kubernetes调度算法介绍

2019独角兽企业重金招聘Python工程师标准>>> hot3.png

调度流程

调度器就是一个独立的进程,负责不断从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


官方版本发展

参考资料

  • https://github.com/kubernetes/community/blob/release-1.6/contributors/devel/scheduler.md
  • https://github.com/kubernetes/community/blob/release-1.6/contributors/devel/scheduler_algorithm.md
  • http://cizixs.com/2017/03/10/kubernetes-intro-scheduler
  • https://kubernetes.io/docs/concepts/configuration/assign-pod-node/
  • https://book.douban.com/subject/26894736/

转载于:https://my.oschina.net/u/1378920/blog/1550452

你可能感兴趣的:(Kubernetes调度算法介绍)