Kubernetes K8S之调度器kube-scheduler详解

 

Kubernetes K8S之调度器kube-scheduler概述与详解

 

kube-scheduler调度概述

在 Kubernetes 中，调度是指将 Pod 放置到合适的 Node 节点上，而后对应 Node 上的 Kubelet 才可以运行这些 pod。

调度器经过 kubernetes 的 watch 机制来发现集群中新建立且还没有被调度到 Node 上的 Pod。调度器会将发现的每个未调度的 Pod 调度到一个合适的 Node 上来运行。调度器会依据下文的调度原则来作出调度选择。

调度是容器编排的重要环节，须要通过严格的监控和控制，现实生产一般对调度有各种限制，譬如某些服务必须在业务独享的机器上运行，或者从灾备的角度考虑尽可能把服务调度到不一样机器，这些需求在Kubernetes集群依靠调度组件kube-scheduler知足。

kube-scheduler是Kubernetes中的关键模块，扮演管家的角色听从一套机制——为Pod提供调度服务，例如基于资源的公平调度、调度Pod到指定节点、或者通讯频繁的Pod调度到同一节点等。容器调度自己是一件比较复杂的事，由于要确保如下几个目标：

• 公平性：在调度Pod时须要公平的进行决策，每一个节点都有被分配资源的机会，调度器须要对不一样节点的使用做出平衡决策。
• 资源高效利用：最大化群集全部资源的利用率，使有限的CPU、内存等资源服务尽量更多的Pod。
• 效率问题：能快速的完成对大批量Pod的调度工做，在集群规模扩增的状况下，依然保证调度过程的性能。
• 灵活性：在实际运做中，用户每每但愿Pod的调度策略是可控的，从而处理大量复杂的实际问题。所以平台要容许多个调度器并行工做，同时支持自定义调度器。

为达到上述目标，kube-scheduler经过结合Node资源、负载状况、数据位置等各类因素进行调度判断，确保在知足场景需求的同时将Pod分配到最优节点。显然，kube-scheduler影响着Kubernetes集群的可用性与性能，Pod数量越多集群的调度能力越重要，尤为达到了数千级节点数时，优秀的调度能力将显著提高容器平台性能。

 

kube-scheduler调度流程

kube-scheduler的根本工做任务是根据各类调度算法将Pod绑定（bind）到最合适的工做节点，整个调度流程分为两个阶段：预选策略（Predicates）和优选策略（Priorities）。

预选（Predicates）：输入是全部节点，输出是知足预选条件的节点。kube-scheduler根据预选策略过滤掉不知足策略的Nodes。例如，若是某节点的资源不足或者不知足预选策略的条件如“Node的label必须与Pod的Selector一致”时则没法经过预选。

优选（Priorities）：输入是预选阶段筛选出的节点，优选会根据优先策略为经过预选的Nodes进行打分排名，选择得分最高的Node。例如，资源越富裕、负载越小的Node可能具备越高的排名。

通俗点说，调度的过程就是在回答两个问题：1. 候选有哪些？2. 其中最适合的是哪一个？

值得一提的是，若是在预选阶段没有节点知足条件，Pod会一直处在Pending状态直到出现知足的节点，在此期间调度器会不断的进行重试。

 

预选策略（Predicates）

官网地址：调度器预选、优选策略

过滤条件包含以下：

• PodFitsHostPorts：检查Pod容器所需的HostPort是否已被节点上其它容器或服务占用。若是已被占用，则禁止Pod调度到该节点。
• PodFitsHost：检查Pod指定的NodeName是否匹配当前节点。
• PodFitsResources：检查节点是否有足够空闲资源（例如CPU和内存）来知足Pod的要求。
• PodMatchNodeSelector：检查Pod的节点选择器(nodeSelector)是否与节点(Node)的标签匹配
• NoVolumeZoneConflict：对于给定的某块区域，判断若是在此区域的节点上部署Pod是否存在卷冲突。
• NoDiskConflict：根据节点请求的卷和已经挂载的卷，评估Pod是否适合该节点。
• MaxCSIVolumeCount：决定应该附加多少CSI卷，以及该卷是否超过配置的限制。
• CheckNodeMemoryPressure：若是节点报告内存压力，而且没有配置异常，那么将不会往那里调度Pod。
• CheckNodePIDPressure：若是节点报告进程id稀缺，而且没有配置异常，那么将不会往那里调度Pod。
• CheckNodeDiskPressure：若是节点报告存储压力(文件系统已满或接近满)，而且没有配置异常，那么将不会往那里调度Pod。
• CheckNodeCondition：节点能够报告它们有一个彻底完整的文件系统，然而网络不可用，或者kubelet没有准备好运行Pods。若是为节点设置了这样的条件，而且没有配置异常，那么将不会往那里调度Pod。
• PodToleratesNodeTaints：检查Pod的容忍度是否能容忍节点的污点。
• CheckVolumeBinding：评估Pod是否适合它所请求的容量。这适用于约束和非约束PVC。

若是在predicates(预选)过程当中没有合适的节点，那么Pod会一直在pending状态，不断重试调度，直到有节点知足条件。

通过这个步骤，若是有多个节点知足条件，就继续priorities过程，最后按照优先级大小对节点排序。

 

优选策略（Priorities）

包含以下优选评分条件：

• SelectorSpreadPriority：对于属于同一服务、有状态集或副本集（Service，StatefulSet or ReplicaSet）的Pods，会将Pods尽可能分散到不一样主机上。
• InterPodAffinityPriority：策略有podAffinity和podAntiAffinity两种配置方式。简单来讲，就说根据Node上运行的Pod的Label来进行调度匹配的规则，匹配的表达式有：In, NotIn, Exists, DoesNotExist，经过该策略，能够更灵活地对Pod进行调度。
• LeastRequestedPriority：偏向使用较少请求资源的节点。换句话说，放置在节点上的Pod越多，这些Pod使用的资源越多，此策略给出的排名就越低。
• MostRequestedPriority：偏向具备最多请求资源的节点。这个策略将把计划的Pods放到整个工做负载集所需的最小节点上运行。
• RequestedToCapacityRatioPriority：使用默认的资源评分函数模型建立基于ResourceAllocationPriority的requestedToCapacity。
• BalancedResourceAllocation：偏向具备平衡资源使用的节点。
• NodePreferAvoidPodsPriority：根据节点注释scheduler.alpha.kubernet .io/preferAvoidPods为节点划分优先级。可使用它来示意两个不一样的Pod不该在同一Node上运行。
• NodeAffinityPriority：根据preferredduringschedulingignoredingexecution中所示的节点关联调度偏好来对节点排序。
• TaintTolerationPriority：根据节点上没法忍受的污点数量，为全部节点准备优先级列表。此策略将考虑该列表调整节点的排名。
• ImageLocalityPriority：偏向已经拥有本地缓存Pod容器镜像的节点。
• ServiceSpreadingPriority：对于给定的服务，此策略旨在确保Service的Pods运行在不一样的节点上。总的结果是，Service对单个节点故障变得更有弹性。
• EqualPriority：赋予全部节点相同的权值1。
• EvenPodsSpreadPriority：实现择优 pod的拓扑扩展约束

 

自定义调度器

除了Kubernetes自带的调度器，咱们也能够编写本身的调度器。经过spec.schedulername参数指定调度器名字，能够为Pod选择某个调度器进行调度。

以下Pod选择my-scheduler进行调度，而不是默认的default-scheduler

 1 apiVersion: v1
 2 kind: Pod
 3 metadata:
 4   name: annotation-second-scheduler
 5   labels:
 6     name: multischeduler-example
 7 spec:
 8   schedulername: my-scheduler
 9   containers:
10   - name: pod-with-second-annotation-container
11     image: gcr.io/google_containers/pause:2.0

至于调度器如何编写，咱们这里就不详细说了，工做中几乎不会使用到，有兴趣的同窗能够自行查阅官网或其余资料。

 

相关阅读

一、官网：调度器预选、优选策略

二、k8s调度器kube-scheduler

完毕！

 

---

 

 

———END———
若是以为不错就关注下呗 (-^O^-) ！