千家信息网

Kubernetes Scheduler有什么用

发表于:2026-11-03 作者:千家信息网编辑
千家信息网最后更新 2026年11月03日,这篇文章给大家分享的是有关Kubernetes Scheduler有什么用的内容。小编觉得挺实用的,因此分享给大家做个参考,一起跟随小编过来看看吧。先来过一下Kubernetes Scheduler的
千家信息网最后更新 2026年11月03日Kubernetes Scheduler有什么用

这篇文章给大家分享的是有关Kubernetes 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(10sum(requested) / capacity)) / 2

感谢各位的阅读!关于"Kubernetes Scheduler有什么用"这篇文章就分享到这里了,希望以上内容可以对大家有一定的帮助,让大家可以学到更多知识,如果觉得文章不错,可以把它分享出去让更多的人看到吧!

主机 节点 调度 规则 检查 得分 选择 优先级 函数 资源 镜像 不同 最大 容量 权重 存储 最高 公式 最大值 相同 数据库的安全要保护哪些东西 数据库安全各自的含义是什么 生产安全数据库录入 数据库的安全性及管理 数据库安全策略包含哪些 海淀数据库安全审计系统 建立农村房屋安全信息数据库 易用的数据库客户端支持安全管理 连接数据库失败ssl安全错误 数据库的锁怎样保障安全 广州淘业互联网络科技 关于新基建和互联网科技 有木互联网科技 广州善班互联网科技 互联网科技公司做什么 滨湖区互联网智能科技产品供应 互联网 科技馆 互联网系的金融科技公司 宁夏众和广鑫互联网科技有限公司 宁夏科技产业互联网案例 知域互联网科技有限公司大骗子 新兴科技互联网创新大赛颁奖典礼 呼和浩特新华互联网科技学院 畅思互联网科技 玉溪新华互联网科技好不好 南通创西澳互联网科技有限公司 宇信科技在杭州互联网排第几 福州德业互联网科技 互联网科技机房 杭州融税互联网科技有限公司 互联网科技工作委员会副主任毛军 互联网巨头科技公司 蓝色互联网科技 卫星互联网科技股票 互联网媒体平台算高科技产业 链环科技传统企业怎么转型互联网 乌苏新华互联网科技做什么的 如何创新互联网科技 互联网硬科技公司 恒生科技指数 中概互联网
0