1、调度概览
在Kubernetes中，调度是指将Pod放置到合适的Node上，然后对应Node上的Kubelet才能够运行这些pod。调度器通过kubernetes的watch机制来发现集群中新创建且尚未被调度到Node上的Pod。调度器会将发现的每一个未调度的Pod调度到一个合适的Node上来运行。
2、kube-scheduler
kube-scheduler 是Kubernetes集群的默认调度器，并且是集群 控制面的一部分。如果你真的希望或者有这方面的需求，kube-scheduler 在设计上是允许你自己写一个调度组件并替换原有的 kube-scheduler。
对每一个新创建的Pod或者是未被调度的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做调度选择包含两个步骤：过滤和打分
过滤阶段会将所有满足Pod调度需求的 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或ReplicaSe 的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。
Kubernetes调度器
官网：https://kubernetes.io/zh/docs/concepts/scheduling/#%E8%BF%87%E6%BB%A4%E7%AD%96%E7%95%A5
