因为这个使用方式可能会一直变化，我们假设这个拓扑结构是这样的：Spec 是要求在 node 上进行分布的，我们就可以按照上图中的计算公式，计算一下在这个 node 上满足 Spec 指定 labelSelector 条件的 pod 数量，然后计算一下最大的差值，接着计算一下 Node 分配的权重，如果说这个值越大，表示这个值越优先。
Node 亲和&反亲和NodeAffinityPriority，这个是为了满足 Pod 和 Node 的亲和 & 反亲和；
ServiceAntiAffinity，是为了支持 Service 下的 Pod 的分布要按照 Node 的某个 label 的值进行均衡。比如：集群的节点有云上也有云下两组节点，我们要求服务在云上云下均衡去分布，假设 Node 上有某个 label，那我们就可以用这个 ServiceAntiAffinity 进行打散分布；
NodeLabelPrioritizer，主要是为了实现对某些特定 label 的 Node 优先分配，算法很简单，启动时候依据调度策略 (SchedulerPolicy）配置的 label 值，判断 Node 上是否满足这个label条件，如果满足条件的节点优先分配;
ImageLocalityPriority，节点亲和主要考虑的是镜像下载的速度。如果节点里面存在镜像的话，优先把 Pod 调度到这个节点上，这里还会去考虑镜像的大小，比如这个 Pod 有好几个镜像，镜像越大下载速度越慢，它会按照节点上已经存在的镜像大小优先级亲和。
Pod 亲和&反亲和InterPodAffinityPriority
先介绍一下使用场景：
第一个例子，比如说应用 A 提供数据，应用 B 提供服务，A 和 B 部署在一起可以走本地网络，优化网络传输；
第二个例子，如果应用 A 和应用 B 之间都是 CPU 密集型应用，而且证明它们之间是会互相干扰的，那么可以通过这个规则设置尽量让它们不在一个节点上。
NodePreferAvoidPodsPriority
用于实现某些 controller 尽量不分配到某些节点上的能力；通过在 node 上加 annotation 声明哪些 controller 不要分配到 Node 上，如果不满足就优先。
如何配置调度器 配置调度器介绍怎么启动一个调度器，这里有两种情况：
第一种我们可以通过默认配置启动调度器，什么参数都不指定；
第二种我们可以通过指定配置的调度文件。
如果我们通过默认的方式启动的话，想知道默认配置启动的参数是哪些？可以用 --write-config-to 可以把默认配置写到一个指定文件里面。
下面来看一下默认配置文件，如下图所示：
**algorithmSource **:算法提供者，目前提供三种方式：Provider、file、configMap，后面会介绍这块；
**percentageOfNodesToscore **: 调度器提供的一个扩展能力，能够减少 Node 节点的取样规模；
**schedulerName **:用来表示调度器启动的时候，负责哪些 Pod 的调度；如果没有指定的话，默认名称就是 default-scheduler；
**bindTimeoutSeconds **:用来指定 bind 阶段的操作时间，单位是秒；
clientConnection: 用来配置跟 kube-apiserver 交互的一些参数配置。比如 contentType，是用来跟 kube-apiserver 交互的序列化协议，这里指定为 protobuf；
**disablePreemption **:关闭抢占调度；
**hardPodAffinitySymnetricweight **:配置 PodAffinity 和 NodeAffinity 的权重是多少。
algorithmSource这里介绍一下过滤器、打分器等一些配置文件的格式，目前提供三种方式：
Provider
file
configMap
如果指定的是 Provider，有两种实现方式：
一种是 DefaultPrivider；
一种是 ClusterAutoscalerProvider。