深入剖析 Kubernetes
张磊
Kubernetes 社区资深成员与项目维护者
116709 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 57 讲
再谈开源与社区 (1讲)
结束语 (1讲)
深入剖析 Kubernetes
15
15
1.0x
00:00/00:00
登录|注册

41 | 十字路口上的Kubernetes默认调度器

kubelet端的二次确认
异步向APIServer发起更新Pod的请求
更新Scheduler Cache里的Pod和Node信息
PriorityQueue
Go语言插件机制
可插入自定义逻辑的接口
Admit操作
Bind操作
Priorities算法为Node打分
Predicates算法过滤Node
从调度队列出队一个Pod
调度器缓存更新
调度队列
监听Etcd中与调度相关的API对象的变化
Priority调度算法
Predicate调度算法
插件机制的使用
接口设计合理性
对默认调度器进行扩展和重新实现
插件化
轻薄化
提升可扩展性设计
清理“技术债”
Scheduler Framework
无锁化设计
Cache化集群信息
Scheduling Path
Informer Path
调度算法
为新创建的Pod寻找最合适的节点
Kubernetes默认调度器与Mesos的“两级”调度器的异同
Scheduler Framework的问题
社区的诉求
调度器的演进方向
默认调度器的重构目的
可扩展性设计
调度器性能优化
调度器工作原理
调度器核心职责
思考题
调度器的重构与未来走向
调度器设计与实现
作者:张磊
标题:十字路口上的Kubernetes默认调度器
主题:十字路口上的Kubernetes默认调度器
参考文章
Kubernetes默认调度器知识关系脑图

该思维导图由 AI 生成,仅供参考

你好,我是张磊。今天我和你分享的主题是:十字路口上的 Kubernetes 默认调度器。
在上一篇文章中,我主要为你介绍了 Kubernetes 里关于资源模型和资源管理的设计方法。而在今天这篇文章中,我就来为你介绍一下 Kubernetes 的默认调度器(default scheduler)。
在 Kubernetes 项目中,默认调度器的主要职责,就是为一个新创建出来的 Pod,寻找一个最合适的节点(Node)。
而这里“最合适”的含义,包括两层:
从集群所有的节点中,根据调度算法挑选出所有可以运行该 Pod 的节点;
从第一步的结果中,再根据调度算法挑选一个最符合条件的节点作为最终结果。
所以在具体的调度流程中,默认调度器会首先调用一组叫作 Predicate 的调度算法,来检查每个 Node。然后,再调用一组叫作 Priority 的调度算法,来给上一步得到的结果里的每个 Node 打分。最终的调度结果,就是得分最高的那个 Node。
而我在前面的文章中曾经介绍过,调度器对一个 Pod 调度成功,实际上就是将它的 spec.nodeName 字段填上调度结果的节点名字。
备注:这里你可以再回顾下第 14 篇文章《深入解析 Pod 对象(一):基本概念》中的相关内容。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

Kubernetes默认调度器是Kubernetes项目中的核心组件之一,负责为新创建的Pod寻找最合适的节点。调度器通过一系列调度算法来选择可运行该Pod的节点,并最终确定最适合的节点。调度器的工作原理包括Informer Path和Scheduling Path两个控制循环,通过监听Etcd中的API对象变化和并发执行算法来提高执行效率。调度器还采用了Cache化和乐观绑定的设计,避免了全局竞争资源和锁同步带来的性能损耗。随着Kubernetes项目的发展,对默认调度器进行扩展和重新实现成为社区的主要诉求,因此默认调度器正在经历大量重构,以提高可扩展性和性能。Scheduler Framework的设计为用户提供了自定义调度器的能力,使得扩展和自定义Kubernetes的默认调度器变得非常容易实现。这一设计符合Kubernetes的“民主化”设计思路,但也存在接口设计不合理可能导致整个生态无法很好地使用插件机制的问题。总的来说,Kubernetes默认调度器的发展方向是向着组件的轻量化、接口化和插件化发展,以满足不断增长的集群规模和复杂业务的需求。在 Kubernetes 的整体架构中,kube-scheduler 的责任虽然重大,但其实它却是在社区里最少受到关注的组件之一。调度这个事情,在不同的公司和团队里的实际需求一定是大相径庭的,上游社区不可能提供一个大而全的方案出来。因此,将默认调度器进一步做轻做薄,并且插件化,才是 kube-scheduler 正确的演进方向。Kubernetes默认调度器与Mesos的“两级”调度器相比,都致力于提高集群资源的利用率和任务的调度效率,但在实现方式和架构设计上存在一些差异。Kubernetes默认调度器更加注重轻量化、接口化和插件化的发展方向,以满足不断增长的集群规模和复杂业务的需求。而Mesos的“两级”调度器则采用了不同的架构,将资源的分配和任务的调度分为两个阶段,以实现更灵活的资源管理和调度策略。这些差异体现了两者在调度理念和架构设计上的不同取向。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《深入剖析 Kubernetes》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(19)

  • 最新
  • 精选
  • CYH
    问题回答:messos二级调度是资源调度和业务调度分开;优点:插件化调度框架(用户可以自定义自己调度器然后注册到messos资源调度框架即可),灵活可扩展性高.缺点:资源和业务调度分开无法获取资源使用情况,进而无法做更细粒度的调度.k8s调度是统一调度也就是业务和资源调度进行统一调度,可以进行更细粒度的调度;缺点其调度器扩展性差。以上是本人拙见,请老师指正。

    作者回复: 一点都不拙!

    2018-11-29
    3
    83
  • Vip He
    老师您好,这个pod调度过程是并行的吗还是一个一个pod调度?

    作者回复: 串行的

    2019-05-26
    3
    26
  • Jasper
    2021年了,来还18年没读完的债。在老孟的指导下学习,再回首张磊老师的文章,感慨万千
    2021-10-31
    7
    14
  • dgonly
    调度器对APIServer的更新失败,Bind过程失败,老师说等schedule cache同步后就恢复正常,这个怎么理解? 我理解是informer path继续watch,发现pod没有被bind到node就继续执行一遍调度流程吗?如果某种原因更新APIServer一直失败,会不会就一直执行重新调度的操作,有没有一种类似重试超过一定比如就丢弃的机制。谢谢!
    2018-11-26
    2
    9
  • 陈斯佳
    第四十一课:十字路口上的Kubernetes默认调度器 K8s项目中默认调度器的主要职责是就是为了新创建出来的Pod寻找一个最合适的Node。 调度器首先会调用一组叫Predicate的调度算法,来检每一个Node。然后再调用一组叫作Priority的调度算法来给上一步得到的结果里的每一个Node打分。最终的调度结果就是得分最高的那个Node。 Kubernetes 的调度器的核心,实际上就是两个相互独立的控制循环。第一个是Informer Path,主要是启动一系列Informer用来监听(Watch)Etcd中的Pod,Node, Service等与调度相关的API对象的变化。此外,Kubernetes 的默认调度器还要负责对调度器缓存(即:scheduler cache)进行更新。事实上,Kubernetes 调度部分进行性能优化的一个最根本原则,就是尽最大可能将集群信息 Cache 化,以便从根本上提高 Predicate 和 Priority 调度算法的执行效率。第二个控制循环是Scheduling Path,主要逻辑是不断从调度队列里调出Pod,然后用Predicates算法进行过滤,得到一组可以运行这个Pod的宿主机列表,然后再用Priority打分,得分高的称为Pod结果。
    2021-11-02
    4
  • loda
    想请教个问题,kubernetes如何保证用户能提前知道这次调度能否成功? 场景:很多公司都希望提前就发现资源池余量是否充足,从而决定是要加机器还是可以继续扩容 拙见: 1.scheduler的缓存其实是一个非常重要的数据,可以提供当前时刻调度能否成功的视图,但是直接暴露出来不太符合kubernetes以apiserver为依据的原则 2.提供余量检查接口,实时查询apiserver中所有pod和node,根据扩容参数算出剩余资源量。不过规模大后,对集群压力太大 3.定时采集上述指标,缺点是实时性太差 4.监听pod crud,自己独立维护一个和scheduler一样的缓存或持久话数据,每次基于这个数据判断剩余量。缺点是维护成本较高,容易出现数据不一致 想问下,有没有更合适的方式?
    2018-12-09
    5
    4
  • 宋晓明
    老师 刚才遇到一个问题 我初始化的时候 分配的ip范围是10.64.200.0/22 然后两个master 3个node kubernetes自己分配master分别是200.0/24 201.0/24 然后其他两个node是202.0/24 203.0/24 其实这些范围已经用满了 在加第三个node 在master看也成功了 但创建多个pod的时候 第三个node上的pod是失败的,后来发现第三个node上kube-bridge网桥上没有IP地址,需求是:因为master上不会有自己创建的pod的,所以master上地址段有点浪费,我如何把master上空闲的地址段用到新增node上,还是不用管,还是怎么样?
    2018-11-27
    3
  • 如果能结合源码将解决就更好了,不知道相关代码在哪啊
    2019-01-25
    1
    2
  • Jake
    2023年了,来还18年没读完的债。在老孟的指导下学习,再回首张磊老师的文章,感慨万千
    2023-06-20归属地:上海
    1
  • 小寞子。(≥3≤)
    2021年,找到代码了 https://github.com/kubernetes-sigs/scheduler-plugins/blob/master/pkg/trimaran/handler.go 不知道这是不是正确的地方。
    2021-01-28
    1
收起评论
显示
设置
留言
19
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部