忘记密码   免费注册 查看新帖 | 论坛精华区

ChinaUnix.net

  平台 论坛 博客 认证专区 大话IT HPC论坛 徽章 文库 沙龙 自测 下载 频道自动化运维 虚拟化 储存备份 C/C++ PHP MySQL 嵌入式 Linux系统
最近访问板块 发新帖
查看: 1263 | 回复: 0

资深实践篇 | 基于Kubernetes 1.61的Kubernetes Scheduler 调度详解 [复制链接]

论坛徽章:
0
发表于 2017-08-22 16:45 |显示全部楼层
关键字标签:腾讯云,性能优化,Github
说明:该文转载自腾讯云技术社区腾云阁,已征求作者本人同意。
源码为 k8s v1.6.1 版本,github 上对应的 commit id 为b0b7a323cc5a4a2019b2e9520c21c7830b7f708e
本文将对 Scheduler 的调度算法原理和执行过程进行分析,重点介绍 Scheduler 算法中预选和优选的相关内容。
先来过一下KubernetesScheduler的基本功能
KubernetesScheduler 的作用是根据特定的调度算法将pod调度到指定的工作节点(Node)上,这一过程也叫绑定(bind)。Scheduler 的输入为需要调度的 Pod 和可以被调度的节点(Node)的信息,输出为调度算法选择的 Node,并将该 pod bind 到这个 Node 。
链接1.jpg
KubernetesScheduler中调度算法分为两个阶段:
预选 : 根据配置的 Predicates Policies(默认为 DefaultProvider 中定义的 default predicates policies 集合)过滤掉那些不满足Policies的Nodes,剩下的Nodes作为优选的输入。
优选 : 根据配置的 Priorities Policies(默认为 DefaultProvider 中定义的 default priorities policies 集合)给预选后的Nodes进行打分排名,得分最高的Node即作为最适合的Node,该Pod就Bind到这个Node。
链接2.png
预选规则详细说明
预先规则主要用于过滤出不符合规则的Node节点,剩下的节点作为优选的输入。在1.6.1版本中预选规则包括:
链接3.png
详细的规则说明:
(1) NoDiskConflict : 检查在此主机上是否存在卷冲突。如果这个主机已经挂载了卷,其它使用这个卷的Pod不能调度到这个主机上。GCE 、AmazonEBS 和 Ceph RBD 使用的规则如下:
1.     GCE 允许同时挂载多个卷,只要这些卷都是只读的。
2.     AmazonEBS 不允许不同的 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。
( 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)
链接4.png
详细的规则说明:
(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(10sum(requested)/ capacity)) / 2

您需要登录后才可以回帖 登录 | 注册

本版积分规则

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号 北京市公安局海淀分局网监中心备案编号:11010802020122
广播电视节目制作经营许可证(京) 字第1234号 中国互联网协会会员  联系我们:
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP