kubernetes调度器
在kubernetes中，调度指的是将新生成的pod调度到合适的Node节点上，然后Node上对应的kubelet才能运行pod。
1.调度概述
调度器通过kubernetes的watch机制来发现新生成的且未调度到Node上的pod。调度器会将发现的每一个未调度的pod调度到合适的Node上运行，调度器会使用以下所述的调度原则来做出调度选择。
2.kube-scheduler
kube-sceduler时kubernetes集群中默认调度器，并且是集群控制面的一部分，kube-scheduler在设计上允许你写一个自己的调度组件并替换原有的kube-scheduler。
对每一个新创建或未被调度的的pod,kube-scheduler都会选择一个最优的Node去运行这个pod。然而，pod内的每一个容器对资源都有不同的需求，而且pod本身也有不同的资源需求。因此，pod被调度到Node之前，会根据这些特定的资源调度需求，对集群中的Node进行一次过滤。
在一个集群中，满足一个pod调度请求的所有node称之为可调度节点。如果没有任何一个Node满足pod的调度请求，那个这个pod会一直处于未调度状态直到调度器能够找到合适的Node。
调度器先在集群中找到pod的所有可调度节点，然后根据一系列函数对这些可调度节点打分，然后选出得分最高的Node来运行pod。之后，调度器将这个调度决定通知给kube-apiserver,这个过程叫做绑定。
在做调度决定时需要考虑的因素包括：单独和整体的资源需求，硬件/软件/策略限制，亲和以及反亲和要求，数据局域性，负载间的干扰等。
3.kube-scheduler调度流程
kube-scheduler给一个pod做调度选择包含两个步骤：
(1)过滤
(2)打分
过滤阶段会将所有满足调度需求的node选择出来。例如，PodFitsResources 过滤函数会检查候选 Node 的可用资源能否满足 Pod 的资源请求。在过滤之后，得出一个Node列表，里面包含了所有可调度节点;通常情况下，这个Node列表不止一个Node。如果这个列表是空的，说明这个pod不可调度。
在打分阶段，调度器会为pod在所有可调度节点中选择最合适的Node。根据当前的打分规则，调度器会给每一个可调度节点进行打分。
最后，kube-scheduler会将pod调度到得分最高的Node上。如果存在多个得分最高的Node，kube-scheduler会从中随机选择一个。
默认策略
kube-scheduler 有一系列的默认调度策略。
过滤策略
PodFitsHostPorts：如果 Pod 中定义了 hostPort 属性，那么需要先检查这个指定端口是否 已经被 Node 上其他服务占用了。
PodFitsHost：若 pod 对象拥有 hostname 属性，则检查 Node 名称字符串与此属性是否匹配。
PodFitsResources：检查 Node 上是否有足够的资源（如，cpu 和内存）来满足 pod 的资源请求。
PodMatchNodeSelector：检查 Node 的 标签 是否能匹配 Pod 属性上 Node 的 标签 值。
NoVolumeZoneConflict：检测 pod 请求的 Volumes 在 Node 上是否可用，因为某些存储卷存在区域调度约束。
NoDiskConflict：检查 Pod 对象请求的存储卷在 Node 上是否可用，若不存在冲突则通过检查。
MaxCSIVolumeCount：检查 Node 上已经挂载的 CSI 存储卷数量是否超过了指定的最大值。
CheckNodeMemoryPressure：如果 Node 上报了内存资源压力过大，而且没有配置异常，那么 Pod 将不会被调度到这个 Node 上。
CheckNodePIDPressure：如果 Node 上报了 PID 资源压力过大，而且没有配置异常，那么 Pod 将不会被调度到这个 Node 上。
CheckNodeDiskPressure：如果 Node 上报了磁盘资源压力过大（文件系统满了或者将近满了）， 而且配置没有异常，那么 Pod 将不会被调度到这个 Node 上。
CheckNodeCondition：Node 可以上报其自身的状态，如磁盘、网络不可用，表明 kubelet 未准备好运行 pod。 如果 Node 被设置成这种状态，那么 pod 将不会被调度到这个 Node 上。
PodToleratesNodeTaints：检查 pod 属性上的 tolerations 能否容忍 Node 的 taints。
CheckVolumeBinding：检查 Node 上已经绑定的和未绑定的 PVCs 能否满足 Pod 对象的存储卷需求。
打分策略
SelectorSpreadPriority：尽量将归属于同一个 Service、StatefulSet 或 ReplicaSet 的 Pod 资源分散到不同的 Node 上。
InterPodAffinityPriority：遍历 Pod 对象的亲和性条目，并将那些能够匹配到给定 Node 的条目的权重相加，结果值越大的 Node 得分越高。
LeastRequestedPriority：空闲资源比例越高的 Node 得分越高。换句话说，Node 上的 Pod 越多，并且资源被占用的越多，那么这个 Node 的得分就会越少。
MostRequestedPriority：空闲资源比例越低的 Node 得分越高。这个调度策略将会把你所有的工作负载（Pod）调度到尽量少的 Node 上。
RequestedToCapacityRatioPriority：为 Node 上每个资源占用比例设定得分值，给资源打分函数在打分时使用。
BalancedResourceAllocation：优选那些使得资源利用率更为均衡的节点。
NodePreferAvoidPodsPriority：这个策略将根据 Node 的注解信息中是否含有 scheduler.alpha.kubernetes.io/preferAvoidPods 来 计算其优先级。使用这个策略可以将两个不同 Pod 运行在不同的 Node 上。
NodeAffinityPriority：基于 Pod 属性中 PreferredDuringSchedulingIgnoredDuringExecution 来进行 Node 亲和性调度。你可以通过这篇文章 Pods 到 Nodes 的分派 来了解到更详细的内容。
TaintTolerationPriority：基于 Pod 中对每个 Node 上污点容忍程度进行优先级评估，这个策略能够调整待选 Node 的排名。
ImageLocalityPriority：Node 上已经拥有 Pod 需要的 容器镜像 的 Node 会有较高的优先级。
ServiceSpreadingPriority：这个调度策略的主要目的是确保将归属于同一个 Service 的 Pod 调度到不同的 Node 上。如果 Node 上 没有归属于同一个 Service 的 Pod，这个策略更倾向于将 Pod 调度到这类 Node 上。最终的目的：即使在一个 Node 宕机之后 Service 也具有很强容灾能力。
CalculateAntiAffinityPriorityMap：这个策略主要是用来实现pod反亲和。
EqualPriorityMap：将所有的 Node 设置成相同的权重为 1。
4.调度器性能调优
在大规模 Kubernetes 集群下调度器性能优化的方式。
设置打分阶段 Node 数量占集群总规模的百分比
在Kubernetes1.12版本之前，kube-scheduler会检查集群中所有节点的可调度性，并且给可调度节点打分。Kubernetes1.12版本添加了一个新的功能，允许调度器在找到一定数量的可调度节点之后就停止继续寻找可调度节点。该功能能提高调度器在大规模集群下的调度性能。这个数值是集群规模
的百分比。这个百分比通过 percentageOfNodesToScore 参数来进行配置。其值的范围在1到100之间，最大值就是100%。如果设置为0就代表没有提供这个参数配置。Kubernetes1.14版本又加入了一个特性，在该参数没有被用户配置的情况下，调度器会根据集群的规模自动设置一个集群比例，然后
通过这个比例筛选一定数量的可调度节点进入打分阶段。该特性使用线性公式计算出集群比例，如在100-node 的集群下取 50%。在 5000-node 的集群下取 10%。这个自动设置的参数的最低值是5%。换句话说，调度器至少会对集群中 5% 的节点进行打分，除非用户将该参数设置的低于5。
注意： 当集群中的可调度节点少于 50 个时，调度器仍然会去检查所有的 Node，因为可调度节点太少，不足以停止调度器最初的过滤选择。
如果想要关闭这个功能，你可以将 percentageOfNodesToScore 值设置成 100。
调节 percentageOfNodesToScore 参数
percentageOfNodesToScore 的值必须在 1 到 100 之间，而且其默认值是通过集群的规模计算得来的。另外，还有一个 50 个 Node 的数值是硬编码在程序里面的。设置这个值的作用在于：当集群的规模是数百个 Node 并且percentageOfNodesToScore 参数设置的过低的时候，调度器筛选到的可调度节点数目基本不会受到该参数影响。当集群规模较小时，这个设置将导致调度器性能提升并不明显。然而在一个超过 1000 个 Node 的集群中，将调优参数设置为一个较低的值可以很明显的提升调度器性能。
值得注意的是，该参数设置后可能会导致只有集群中少数节点被选为可调度节点，很多 node 都没有进入到打分阶段。这样就会造成一种后果，一个本来可以在打分阶段得分很高的 Node 甚至都不能进入打分阶段。由于这个原因，这个参数不应该被设置成一个很低的值。通常的做法是不会将这个参数的值设置的低于 10。很低的参数值一般在调度器的吞吐量很高且对 node 的打分不重要的情况下才使用。换句话说，只有当你更倾向于在可调度节点中任意选择一个 Node 来运行这个 Pod 时，才使用很低的参数设置。
如果你的集群规模只有数百个节点或者更少，我们并不推荐你将这个参数设置得比默认值更低。因为这种情况下不太可能有效的提高调度器性能。
调度器做调度选择的时候如何覆盖所有的 Node
在将 Pod 调度到 Node 上时，为了让集群中所有 Node 都有公平的机会去运行这些 Pod，调度器将会以轮询的方式覆盖全部的 Node。你可以将 Node 列表想象成一个数组。调度器从数组的头部开始筛选可调度节点，依次向后直到可调度节点的数量达到 percentageOfNodesToScore 参数的要求。
在对下一个 Pod 进行调度的时候，前一个 Pod 调度筛选停止的 Node 列表的位置，将会来作为这次调度筛选 Node 开始的位置。
如果集群中的 Node 在多个区域，那么调度器将从不同的区域中轮询 Node，来确保不同区域的 Node 接受可调度性检查。如下例，考虑两个区域中的六个节点：
Zone 1: Node 1, Node 2, Node 3, Node 4 Zone 2: Node 5, Node 6
调度器将会按照如下的顺序去评估 Node 的可调度性：
Node 1, Node 5, Node 2, Node 6, Node 3, Node 4
在评估完所有 Node 后，将会返回到 Node 1，从头开始。
原文地址：https://www.cnblogs.com/golinux/p/12568508.html