Kubernetes调度算法是怎么使用的，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
调度器就是一个独立的进程，负责不断从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，具体规则为：
|
| 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 |
关于Kubernetes调度算法是怎么使用的问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注亿速云行业资讯频道了解更多相关知识。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
