k8s学习笔记（8）--- kubernetes核心组件之scheduler详解

1、kube-schedule简介

        scheduler是kubernetes的调度器，主要任务是把定义的pod分配到集群的节点上，其在调度时需要考虑一下问题：

• 公平：如何保证每个节点都能被分配资源；
• 资源高效利用：集群所有资源最大化被使用；
• 效率：调度的性能要好，能够尽快的对大批量的pod完成调度工作；
• 灵活：允许用户根据自己的需求控制调度的逻辑；

1.1 kubernetes scheduler 基本原理

        kubernetes scheduler 作为一个单独的进程部署在 master 节点上，它会 watch kube-apiserver 进程去发现 PodSpec.NodeName 为空的 Pod，然后根据指定的算法将 Pod 调度到合适的 Node 上,这一过程也叫绑定(Bind)。scheduler 的输入是需要被调度的 Pod 和 Node 的信息，输出是经过调度算法筛选出条件最优的 Node，并将该 Pod 绑定到这个 Node 上。Scheduler结构图如下所示：

        通过上图我们可以看到，调度器实际上主要是由两个控制循环来完成对pod，service等的调度的。

• Informer Path
          第一个循环Informer Path中，调度器通过一系列的informer来对pod，node，service等信息进行list and watch。当对应资源（比如pod）有改变时，informer会收到来自api server的变化通知，然后informer会将资源的变动信息更新到调度器缓存中用于后续调度算法的判定依据（这里使用cache的好处就是避免了对api server的大量重复的请求操作，特别是后面的调度算法判定阶段，从而提升调度效率）。
  如果有新增的资源，比如有个新的pod，那么informer会将其添加到调度队列中。这里的调度队列是一个优先级的队列，它在保证FIFO的基本功能的同时，还能满足调度器的一些特殊操作，比如基于优先级的抢占操作。
• Scheduling Path
          在Scheduling Path中，调度器会从调度队列里不断取出需要调度的资源，然后通过Predicates算法对Scheduler Cache中的Nodes进行过滤，拿到合适的Node列表。然后根据Priorities算法对第一步的Node列表进行打分，选出得分最高的Node。
          经过Priorities后，修改资源的nodeName字段为选出的Node，并更新Scheduler Cache中pod和node的信息，然后启动一个异步的线程去请求api server去修改持久化的pod信息。这样做的好处是提高了调度器的调度效率。如果异步线程失败了也无所谓，cache中的信息会随着后续的更新而恢复正常，调度失败的资源会在后续进行重新调度。当然这种基于乐观绑定的设计，就需要kubelet在实际运行资源的时候再次通过基本的调度算法进行确认看当前pod是否能够在当前node运行。同时为了进一步提升调度的效率，调度器对Predicates和Priorities过程都是启动多个线程来并发地对多个资源进行判定，同时在Priorities的阶段以MapReduce的方式来进行打分。整个过程只有在资源出队和更新cache的时候会加锁，从而保证了调度器的执行效率。

1.1.1 scheduler 调度流程

       请求及Scheduler调度步骤：

• 预选：根据配置的Predicates Policies（默认为DefaultProvider中定义的default predicates policies集合）过滤掉那些不满足这些Policies的的Nodes，剩下的Nodes就作为优选的输入；
• 优选：根据配置的Priorities Policies（默认为DefaultProvider中定义的default priorities policies集合）给预选后的Nodes进行打分排名；
• 选定：根据Priorities得分最高的Node即作为最适合的Node，该Pod就Bind到这个Node；
  
  
         Scheduler 调度部分流程讲解如下：

1. 首先用户通过 Kubernetes 客户端 Kubectl 提交创建 Pod 的 Yaml 的文件，向Kubernetes 系统发起创建 Pod 的资源请求;
2. 命令行工具 Kubectl 向 Kubernetes 集群即 APIServer 用 的方式发送“POST”请求，即创建 Pod 的请求;
3. APIServer 接收到请求后把创建 Pod 的信息存储到 Etcd 中;
4. 从集群运行那一刻起，资源调度系统 Scheduler 采用 watch 机制就会定时去监控 APIServer获取 Pod 的信息，Scheduler发现 Pod 的属性中 Dest Node 为空时（Dest Node=””）便会立即触发调度流程进行调度;
5. 而这一个创建Pod对象，在调度的过程当中有3个阶段：节点预选、节点优选、节点选定，从而筛选出最佳的节点。当最佳节点多于1个时，则进行随机选择；

       Priorities算法实现：

       对每一个 Node, priority functions 会计算出一个 0-10 之间的数字，表示 Pod 放到该 Node 的合适程度，其中 10 表示非常合适，0 表示不合适，priority functions 集合中的每一个函数都有一个权重 (weight)，最终的值为 weight 和 priority functions 的乘积，而一个节点的 weight 就是所有 priority functions 结果的加和。

       例如，有两个 priority functions: priorityFunc1 和 priorityFunc2，对应的 weight 分别为 weight1 和 weight2，那么 NodeA 的最终得分是:

       例如有三个node，其调度流程如下图所示：

1.2 scheduler 调度策略

       scheduler 调度策略主要分为两部分Predicates（预选策略）和Priorites（优选策略）。

• 预选策略，Predicates是强制性规则，遍历所有的Node节点，按照具体的预选策略筛选出符合要求的Node列表，如没有Node符合Predicates策略规则，那该Pod就会被挂起，直到有Node能够满足；
• 优选策略，在第一步筛选的基础上，按照优选策略为待选Node打分排序，获取最优者。

       一般情况下，使用kube-scheduler的默认调度就能满足大部分需求。kubernetes的调度器是以插件化的形式实现的，方便用户对调度的定制与二次开发。因此用户也可以自定义预选和优选策略。

1.2.1 Predicates（预选策略）

       Predicates其实就相当于一个的filter chain，对当前所有的node list进行过滤，最后得到符合调度条件的node list。
       随着版本的演进Kubernetes支持的Predicates策略逐渐丰富，v1.0版本仅支持4个策略，v1.7支持15个策略。目前可用的Predicates策略有：

• 一般策略
         这一组 filter是最基础的filter，主要判断对应的node是否满足pod的运行条件。

策略	描述
PodFitsResources	用于判断当前node的资源是否满足pod的request的资源条件
PodFitsHost	用于判断当前node的名字是否满足pod所指定的nodeName
PodFitsHostPorts	Pod对象拥有spec.hostPort属性时,用于判断当前node可用的端口是否满足pod所要求的端口占用
PodMatchNodeSelector	用于判断当前node是否匹配pod所定义的nodeSelector或者nodeAffinity

PS: 此外还有个PodFitsPorts策略（计划停用），由PodFitsHostPorts替代

• Volume相关策略

策略	描述
NoDiskConflict	用于判断多个pod所声明的volume是否有冲突，默认没有启用
MaxPDVolumeCountPredicate	用于判断某种volume是否已经超过所指定的数目
VolumeBindingPredicate	用于检查pod所定义的volume的nodeAffinity是否与node的标签所匹配
NoVolumeZoneConflict	检查给定的zone限制前提下，检查如果在此主机上部署Pod是否存在卷冲突
NoVolumeNodeConflict	检查给定的Node限制前提下，检查如果在此主机上部署Pod是否存在卷冲突
MaxEBSVolumeCount	确保已挂载的EBS存储卷不超过设置的最大值，默认39
MaxGCEPDVolumeCount	确保已挂载的GCE存储卷不超过设置的最大值，默认16
MaxAzureDiskVolumeCount	确保已挂载的Azure存储卷不超过设置的最大值，默认16
CheckVolumeBinding	检查节点上已绑定和未绑定的PVC是否满足需求

• Node相关策略

策略	描述
MatchNodeSelector	Pod对象拥有spec.nodeSelector属性时，检查Node节点的label定义是否满足Pod的NodeSelector属性需求
HostName	如果Pod对象拥有spec.hostname属性，则检查节点名称是不是Pod指定的NodeName
PodToleratesNodeTaints	Pod对象拥有spec.tolerations属性时，仅关注NoSchedule和NoExecute两个效用标识的污点
PodToleratesNodeNoExecuteTaints	Pod对象拥有spec.tolerations属性时，，是否能接纳节点的NoExecute类型污点,默认没有启用
CheckNodeLabelPresence	仅检查节点上指定的所有标签的存在性,默认没有启用
CheckServiceAffinity	将相同Service的Pod对象放置在同一个或同一类节点上以提高效率,默认没有启用
N