资深实践篇 | 基于Kubernetes 1.61的Kubernetes Scheduler 调度详解

欢迎大家前往腾讯云技术社区，获取更多腾讯海量技术实践干货哦~

作者：腾讯云容器服务团队

源码为 k8s v1.6.1 版本，github 上对应的 commit id 为 b0b7a323cc5a4a2019b2e9520c21c7830b7f708e

本文将对 Scheduler 的调度算法原理和执行过程进行分析，重点介绍 Scheduler 算法中预选和优选的相关内容。

Kubernetes Scheduler的基本功能

Kubernetes Scheduler 的作用是根据特定的调度算法将pod调度到指定的工作节点（Node）上，这一过程也叫绑定（bind）。Scheduler 的输入为需要调度的 Pod 和可以被调度的节点(Node)的信息，输出为调度算法选择的 Node，并将该 pod bind 到这个 Node 。

Kubernetes Scheduler中调度算法分为两个阶段：
预选 : 根据配置的 Predicates Policies（默认为 DefaultProvider 中定义的 default predicates policies 集合）过滤掉那些不满足Policies的的Nodes，剩下的Nodes作为优选的输入。

优选 : 根据配置的 Priorities Policies（默认为 DefaultProvider 中定义的 default priorities policies 集合）给预选后的Nodes进行打分排名，得分最高的Node即作为最适合的Node，该Pod就Bind到这个Node。

预选规则详细说明

预先规则主要用于过滤出不符合规则的Node节点，剩下的节点作为优选的输入。在1.6.1版本中预选规则包括：

详细的规则说明：

(1) NoDiskConflict : 检查在此主机上是否存在卷冲突。如果这个主机已经挂载了卷，其它使用这个卷的Pod不能调度到这个主机上。GCE 、Amazon EBS 和 Ceph RBD 使用的规则如下:

  1. GCE 允许同时挂载多个卷，只要这些卷都是只读的。
  2. Amazon EBS 不允许不同的 Pod 挂载同一个卷。
  3. Ceph RBD 不允许任何两个 pods 分享相同的 monitor，match pool 和 image。
    注：ISCSI 与 GCE 一样，在卷都是只读的情况下，允许挂载两个 IQN 相同的卷。

(2) NoVolumeZoneConflict : 检查在给定的 zone 限制前提下，检查在此主机上部署 Pod 是否存在卷冲突，目前指对 PV 资源进行检查(NewVolumeZonePredicate对象predicate函数)。

(3) MaxEBSVolumeCount : 确保已挂载的 EBS 存储卷不超过设置的最大值。默认值是39。它会检查直接使用的存储卷，和间接使用这种类型存储的 PVC 。计算不同卷的总目，如果新的 Pod 部署上去后卷的数目会超过设置的最大值，那么 Pod 就不能调度到这个主机上。

(4) MaxGCEPDVolumeCount : 确保已挂载的 GCE 存储卷不超过设置的最大值。默认值是16。规则同MaxEBSVolumeCount。

(5) MaxAzureDiskVolumeCount : 确保已挂载的Azure存储卷不超过设置的最大值。默认值是16。规则同MaxEBSVolumeCount。

(6) CheckNodeMemoryPressure : 判断节点是否已经进入到内存压力状态，如果是则只允许调度内存为0标记的 Pod。

(7) CheckNodeDiskPressure : 判断节点是否已经进入到磁盘压力状态，如果是则不调度新的Pod。

(8) PodToleratesNodeTaints : Pod 是否满足节点容忍的一些条件。

(9) MatchInterPodAffinity : 节点亲和性筛选。

(10) GeneralPredicates : 包含一些基本的筛选规则（PodFitsResources、PodFitsHostPorts、HostName、MatchNodeSelector）。

(11) PodFitsResources : 检查节点上的空闲资源(CPU、Memory、GPU资源)是否满足 Pod 的需求。

(12) PodFitsHostPorts : 检查 Pod 内每一个容器所需的 HostPort 是否已被其它容器占用。如果有所需的HostPort不满足要求，那么 Pod 不能调度到这个主机上。

(13) 检查主机名称是不是 Pod 指定的 HostName。

(14) 检查主机的标签是否满足 Pod 的 nodeSelector 属性需求。

优选规则详细说明

优选规则对符合需求的主机列表进行打分，最终选择一个分值最高的主机部署 Pod。kubernetes 用一组优先级函数处理每一个待选的主机。每一个优先级函数会返回一个0-10的分数，分数越高表示主机越“好”，同时每一个函数也会对应一个表示权重的值。最终主机的得分用以下公式计算得出：

finalScoreNode = (weight1 priorityFunc1) + (weight2 priorityFunc2) + … + (weightn * priorityFuncn)

详细的规则说明：
(1) SelectorSpreadPriority : 对于属于同一个 service、replication controller 的 Pod，尽量分散在不同的主机上。如果指定了区域，则会尽量把 Pod 分散在不同区域的不同主机上。调度一个 Pod 的时候，先查找 Pod 对于的 service或者 replication controller，然后查找 service 或 replication controller 中已存在的 Pod，主机上运行的已存在的 Pod 越少，主机的打分越高。

(2) LeastRequestedPriority : 如果新的 pod 要分配一个节点，这个节点的优先级就由节点空闲的那部分与总容量的比值(（总容量-节点上pod的容量总和-新pod的容量）/总容量）来决定。CPU 和 memory 权重相当，比值最大的节点的得分最高。需要注意的是，这个优先级函数起到了按照资源消耗来跨节点分配 pods 的作用。计算公式如下：
cpu((capacity – sum(requested)) 10 / capacity) + memory((capacity – sum(requested)) 10 / capacity) / 2

(3) BalancedResourceAllocation : 尽量选择在部署 Pod 后各项资源更均衡的机器。BalancedResourceAllocation 不能单独使用，而且必须和 LeastRequestedPriority 同时使用，它分别计算主机上的 cpu 和 memory 的比重，主机的分值由 cpu 比重和 memory 比重的“距离”决定。计算公式如下：score = 10 – abs(cpuFraction-memoryFraction)*10

(4) NodeAffinityPriority : Kubernetes 调度中的亲和性机制。Node Selectors（调度时将 pod 限定在指定节点上），支持多种操作符（In、 NotIn、 Exists、DoesNotExist、 Gt、 Lt），而不限于对节点 labels 的精确匹配。另外，Kubernetes 支持两种类型的选择器，一种是 “ hard（requiredDuringSchedulingIgnoredDuringExecution）” 选择器，它保证所选的主机满足所有Pod对主机的规则要求。这种选择器更像是之前的 nodeselector，在 nodeselector 的基础上增加了更合适的表现语法。另一种 “ soft（preferresDuringSchedulingIgnoredDuringExecution）” 选择器，它作为对调度器的提示，调度器会尽量但不保证满足 NodeSelector 的所有要求。

(5) InterPodAffinityPriority : 通过迭代 weightedPodAffinityTerm 的元素计算和，并且如果对该节点满足相应的PodAffinityTerm，则将 “weight” 加到和中，具有最高和的节点是最优选的。

(6) NodePreferAvoidPodsPriority(权重1W) : 如果 Node 的 Anotation 没有设置 key-value:scheduler. alpha.kubernetes.io/ preferAvoidPods = "..."，则该 node 对该 policy 的得分就是10分，加上权重10000，那么该node对该policy的得分至少10W分。如果Node的Anotation设置了，scheduler.alpha.kubernetes.io/preferAvoidPods = "..." ，如果该 pod 对应的 Controller 是 ReplicationController 或 ReplicaSet，则该 node 对该 policy 的得分就是0分。

(7) TaintTolerationPriority : 使用 Pod 中 tolerationList 与 Node 节点 Taint 进行匹配，配对成功的项越多，则得分越低。

另外在优选的调度规则中，有几个未被默认使用的规则：

(1) ImageLocalityPriority : 据主机上是否已具备 Pod 运行的环境来打分。ImageLocalityPriority 会判断主机上是否已存在 Pod 运行所需的镜像，根据已有镜像的大小返回一个0-10的打分。如果主机上不存在 Pod 所需的镜像，返回0；如果主机上存在部分所需镜像，则根据这些镜像的大小来决定分值，镜像越大，打分就越高。

(2) EqualPriority : EqualPriority 是一个优先级函数，它给予所有节点一个相等的权重。

(3) ServiceSpreadingPriority : 作用与 SelectorSpreadPriority 相同，已经被 SelectorSpreadPriority 替换。

(4) MostRequestedPriority : 在 ClusterAutoscalerProvider 中，替换 LeastRequestedPriority，给使用多资源的节点，更高的优先级。计算公式为：(cpu(10 sum(requested) / capacity) + memory(10 sum(requested) / capacity)) / 2

相关阅读

td { border: 1px solid #ccc }
br { }

老司机和你深聊Kubenertes 资源分配之 Request 和 Limit 解析

kubernetes 容器编排系统介绍

5 种 Docker 日志最佳实践

此文已由作者授权腾讯云技术社区发布，转载请注明文章出处

原文链接：https://cloud.tencent.com/community/article/339740

时间： 2024-07-31 15:02:58

资深实践篇 | 基于Kubernetes 1.61的Kubernetes Scheduler 调度详解的相关文章

基于PBOC电子钱包的圈存过程详解

基于pboc的电子钱包的圈存过程,供智能卡行业的开发人员参考 一． 圈存 首先终端和卡片有一个共同的密钥叫做圈存密钥:LoadKey   (Load即圈存的意思,unLoad,是圈提的意思) 假设LoadKey = 11223344556677888877665544332211 (密钥一般都是16字节的,圈存即往IC卡里存钱的意思) 在满足安全条件的情况下: 第一步:终端向卡片发送圈存初始化命令: Apdu:  80        50   00  01   0B         01   

基于 Web 的远程 Terminal 模拟器安装使用详解

http://lzw.me/a/shellinabox.html 一.Shellinabox 简介 Shellinabox 是一个基于 web 的终端模拟器,采用 C 语言编写,使用 Ajax 与后端服务通信.它实现了一个 Webserver,默认监听 4200 端口,在支持 Javascript 和 CSS 的浏览器上访问 http://host:4200 即可.并且可以配置 SSL/TLS 证书,使用 https 方式加密通信. 二.Shellinabox 安装 2.1 编译安装 wget

基于Mycat的MySQL主从读写分离配置详解与示例

1.mycat二进制包安装 tar -zxvf Mycat-server-1.6.5-release-20180122220033-linux.tar.gzcd mycatmv mycat /opt/ useradd mycatchown -R mycat:mycat mycat 2.mysql操作搭建主库环境省略...... 创建数据库CREATE DATABASE `integration01` DEFAULT CHARACTER SET utf8 ; 创建物理表 CREATE TABLE

基于request.getAttribute与request.getParameter的区别详解

HttpServletRequest类既有getAttribute()方法,也有getParameter()方法,这两个方法有以下区别:1.HttpServletRequest类有setAttribute()方法,而没有setParameter()方法:2.当两个Web组件之间为链接关系时,被链接的组件通过getParameter()方法来获得请求参数: 例如,假定welcome.jsp和authenticate.jsp之间为链接关系,welcome.jsp中有以下代码:代码如下: <a hre

基于CentOS6.7的DRBD安装配置过程详解

一.DRBD简介 DRBD的全称为:Distributed ReplicatedBlock Device(DRBD)分布式块设备复制,DRBD是由内核模块和相关脚本而构成,用以构建高可用性的集群.其实现方式是通过网络来镜像整个设备.你可以把它看作是一种网络RAID.它允许用户在远程机器上建立一个本地块设备的实时镜像. 二.DRBD是如何工作的呢? (DRBD Primary)负责接收数据,把数据写到本地磁盘并发送给另一台主机(DRBD Secondary).另一个主机再将数据存到自己的磁盘中.目

基于JavaScript 声明全局变量的三种方式详解

JS中声明全局变量主要分为显式声明或者隐式声明下面分别介绍. 声明方式一: 使用var(关键字)+变量名(标识符)的方式在function外部声明,即为全局变量,否则在function声明的是局部变量.该方式即为显式声明详细如下: var test = 5; //全局变量 function a() { var cc=3; //局部变量 alert(test); } function b(){alert(test);} 声明方式二: 没有使用var,直接给标识符test赋值,这样会隐式的声明了全局

基于C语言EOF与getchar()的使用详解

转自:http://www.jb51.net/article/36848.htm   大师级经典的著作,要字斟句酌的去读,去理解.以前在看K&R的The C Programming Language(SecondEdition) 第1.5节的字符输入/输出,被getchar()和EOF所迷惑了.可能主要还是由于没有搞清楚getchar()的工作原理和EOF的用法.因此,感觉很有必要总结一下,不然,很多琐碎的知识点长时间过后就会淡忘的,只有写下来才是最好的方法. 其实,getchar()最典型的程

基于PHP+Ajax实现表单验证的详解

一,利用键盘响应,在不刷新本页面的情况下验证表单输入是否合法 用户通过onkeydown和onkeyup事件来触发响应事件.使用方法和onclick事件类似.onkeydown表示当键盘上的键被按下时触发,onkeyup和它正好相反,当键盘上的键被按下又抬起时触发. 两种常用调用方法: (1)将事件添加到页面元素中,当用户输入完信息后,单击任意键,onkeydown事件被触发,并调用refer()函数. 这种方法最简单,最直接,格式如下: 代码如下: <script type="text/

详解 Kubernetes Pod 的实现原理

Pod.Service.Volume 和 Namespace 是 Kubernetes 集群中四大基本对象,它们能够表示系统中部署的应用.工作负载.网络和磁盘资源,共同定义了集群的状态.Kubernetes 中很多其他的资源其实只对这些基本的对象进行了组合. Pod 是 Kubernetes 集群中能够被创建和管理的最小部署单元,想要彻底和完整的了解 Kubernetes 的实现原理,我们必须要清楚 Pod 的实现原理以及最佳实践. 在这里,我们将分两个部分对 Pod 进行解析,第一部分主要会从