调度器(scheduler)
当用户请求向API Server请求创建一个Pod时，API Server检查权限，用户等没有问题时，会把这个请求交由scheduler，由default scheduler从众多节点中选择一个适用的节点，来做为运行此Pod的节点，其反馈结果不是反馈到节点之上的而是会告诉API Server我帮你选定了某某节点，而这个选定的结果会记录在etcd当中，之后由API Server指挥被选定节点的kubelet，或者节点的kubelet始终监控着API Server当中与当前节点相关的事件变动。如果某一scheduler调度的结果已经被API Server输出到说关乎到某一节点上，那么这个节点上的kubelet一定能监控到跟自己相关资源的变动状态，之后选中的节点会去API Server获取到API Server定义的配置清单，然后根据配置清单中的定义去创建Pod。
镜像获取策略，根据镜像创建容器，选择存储卷等一系列操作都是由kubelet来控制。
scheduler在二进制手动部署时是一个守护进程，其中有很多调度算法。
调度器的功能是调度Pod在哪个Node上运行,这些调度信息存储在master上的etcd里面,能够和etcd打交道的只有apiserver;
kubelet运行在node节点上,监控着Node节点上的pod状态,并参与pod的创建等工作;
调度三步骤

Predicate（预选） --> Priority（优选） --> Select（选定）

预选(predicate):    先排除那些完全不符合此pod运行法则的节点,有两个维度来排除,一个是最低资源需求,即节点必须满足此Pod的最低资源;第二个是资源限额,即当前节点最多能给pod提供的资源.
优选(priority):     在符合节点找到最佳匹配的节点;
选定(select):       把pod绑定到优选的节点上.
如果有特殊偏好的Pod需要运行在特定的节点之上，例如：有些服务需要运行在SSD硬盘之上，对于这类需求应该使用标签进行分类的。比如地理位置上的分类，特性上的分类，Pod在定义要运行在哪些或者哪个节点上时
是可以完全额外定义自己特有倾向性的。
在Pod中定义时可以使用space中的nodeName和nodeSelect
  nodeName：  指定后此Pod只能运行在此节点之上
  nodeSelector：指定后节点中的拥有这个标签或者这个标签的值符合当前定义的标签时Pod可以在这些节点上运行

调度方式有如下几类:

nodeaffinity:表示node亲和性调度,表示pod对这个节点有一定的倾向性,通过nodeselector来完成这类调度;
podaffinity或podunaffinity:pod亲和性或者pod反亲和性调度,有时我们期望某些Pod运行在同一个节点上或者是相邻的节点上,或者我们期望某些Pod不能运行在某些节点上;
taints和tolerations:污点和污点容忍调度,可以在某些节点上打上污点,表示这些节点不让pod在其上面运行，也可以设置容忍这些污点让其Pod在其节点上运行，,taints是定义在节点之上的,tolerations是定义在pod之上的，

预选策略官方地址：https://github.com/kubernetes/kubernetes/blob/v1.11.1/pkg/scheduler/algorithm/predicates/predicates.go 地址中的V1.17.0是kubernetes的版本号，可直接在地址中修改对应的版本地址
源代码中定义了很多种预选策略，但是不是所有的预选策略都可以使用，而是默认启用了一部分，如果想要启用一些默认没有启用的预选策略，可以在安装部署的时候或者后期配置scheduler时启用即可，如果没定义预选策略默认预选策略只是用了这整个所支持预选策略当中的一个子集。

常用的预选策略：

1、ChekNodeCondition:检测节点状况是否允许将pod调度上去;
2、GeneralPredicates(通用预选策略):虽然名字是通用预选策略，但他不是一个单独的预选策略，而是包含了多个预选策略
      HostName：如果某pod定义了hostname属性(pod.spec.hostname),则检查节点的名字跟pod的hostname是否匹配,如果该节点有了相同名字的pod,则不在这个节点上部署;
      PodFitsHostPorts: 如果节点定义了hostport属性(pod.spec.containers.ports.hostPort),表示指定在节点的哪个端口上,如果这个节点的端口被占用了,那么这个节点就不适合运行这个pod;
      MatchNodeSelector:检查pods.spec.nodeSelector这个字段你是否定义了,运行在有这些标签选择器的节点上;
      PodFitsResources: 检查节点是否有足够的资源来支撑这个pod运行;
3、NoDiskConfict:  检查Pod依赖的存储卷在此节点上是否能满足需求,该调度策略默认没有启用;
4、PodToleratesNodeTaints:如果Pod定义了Tolerates(容忍度),即pods.spec.tolerations,那么就看pod能不能容忍节点上的污点,如果能容忍,表示这个节点可以被选定;
5、PodToleratesNodeNoExecuteTaints:检查pod是否容忍节点上有NoExecute污点.如果一个pod上运行在一个没有污点的节点上后,这个节点又被加上了污点,默认是后来添加的污点不满足了也要继续存在在这个节点上，但NoExecute不能容忍这个污点，此时节点发现此Pod不能容忍这个污点，会把这个Pod驱离出这个node
6、CheckNodeLabelPresence:检查节点上指定标签的存在性,如果节点有pod指定的标签,那么这个节点就被选中,默认没有启用;
7、CheckServceAffinity:一个service下可以有多个pod,比如这些pod都运行在1、2、3机器上,而没有运行在4、5、6机器上,那么CheckServceAffinity就表示新加入的pod都集中运行在1、2、3机器上,默认没有启用.
8、CheckVolumeBinding:检查节点上已绑定和未绑定的PVC是否能满足Pod对象的存储卷需求；
9、NoVolumeZoneConflict:在当前区域当中检查此节点的Pod对象是否存在存储卷冲突，
10、CheckNodeMemoryPressure：检查内存节点是否存在压力过大状态
11、CheckNodePIDPressure：检查节点上的PID数量资源是否压力过大
12、CheckNodeDiskPressure：检查磁盘IO是否压力过大
13、MatchInterPodAffinity：检查节点是否能满足Pod的亲和性或反亲和性条件

注意：以上预选策略是一票否决制,有一个不符合,则该节点就会被排除。以上分析只对kubernetes v1.11.1的版本

优先函数：
官方优先函数地址：https://github.com/kubernetes/kubernetes/blob/v1.17.0/pkg/scheduler/algorithm/priorities/least_requested.go 地址中的V1.17.0是kubernetes的版本号，可直接在地址中修改对应的版本地址

1、least_requested：计算出资源空闲率最大的节点;
 (cpu((capacity-sum(requested))*10/capacity)+memory(cpu((capacity-sum(requested))*10/capacity)/2
 CPU总容量减去已经被使用的容量之和乘于10再除以capacity（CPU总容量）+内存总容量减去已经被使用的容量之和乘于10再除以capacity（内存总容量） 
2、balanced_resource_allocation:以cpu和内存占用率的相近程度作为评估标准,二者占用越接近,得分就越高;
3、node_prefer_avoid_pods:看节点是否有注解信息"scheduler.alpha.kubernetes.io/preferAvoidPods",没有这个注解信息,说明这个节点适合运行这个pod的，优先级最高;
4、taint_toleration:将pod对象的spec.toleration与节点的taint列表项进行匹配度检查,匹配的条目越多,得分越低;
5、selector_spreading:spreading是散开的意思,查找当前pod对象对应的标签选择器,在节点上运行的带有这样标签的pod越少得分越高,这样的节点被优先选出;
6、interpod_affinity:遍历Pod对象亲和性的条目,并将那些能够匹配到节点权重相加,值越大的得分越高,得分高的胜出;
7、node_affinity:根据pod对象中的nodeselector,对节点进行匹配度检查,能够成功匹配的数量越多,得分就越高;
8、most_requested:表示尽可能的把一个节点的资源先用完,和least_requested相反,二者不能同时使用; 默认没有启用
9、node_label:根据节点是否拥有标签,来评估分数;默认没有启用
10、image_locality:表示根据满足当前pod对象需求的已有镜像的体积大小之和来选择节点；默认没有启用