本节内容
目录
文章目录
调度概览
调度器分类
1.单体调度器:对于大规模批量调度诉求场景,不能胜任!(基于pod的事件调度)!
2.两层调度器:应用平台–hadoop,spark;资源调度器(负责底层计算资源的管理),应用调度器;resource offers,存在的问题:1.资源争抢如何解决?2.分配资源不合理如何处理 解决办法:悲观锁 先锁定资源,再进行资源的腾挪处理。–>效率不高
3.状态共享调度器:基于版本控制/事务控制的基于乐观锁的调度! full state,本地缓存,回写,冲突判断,重试。
调度器需要充分考虑诸多的因素
资源高效利用:装箱率要高!
afinity:微服务,分步式系统,网络调用,本机调用,排除了网络调用,额外的传输时间,物理网卡带宽限制!
anti-affinity:某个业务的不同副本,不能让其跑在一台机器上,一个机架上,一个地域里,使其分布在不同的故障域。
locality:数据本地化,是一个很重要的概念,哪里有数据,我的作业就去哪里,这样可以减少数据拷贝的开销。k8s里的拉取镜像。
kube-scheduler
生产者-消费者模型,plugin,
调度核心阶段
调度阶段:
1.predicate(预选):
2.priority/score(优选):
绑定阶段:
调度插件
LeastAllocated:空闲资源多的分高 --使的node上的负载比较合理一点!
MostAllocated:空闲资源少的分高 – 可以退回Node资源!
Predicates plugin工作原理
链式过滤器,
Kubernetes中的资源分配
1.limits:在Cgroups里使用;cpu.cfs_quota/cpu.cfs_period(10w)=1
2.requests:cpu这个requests其实在Cgroup里也起作用。当你多个应用发生资源抢占时,他们抢占的cpu时间比较是多少呢?是通过cpu.share去调节的。k8s是如何实现的呢?这里如果设置的是一个cpu,request是1的话,那么cpu.share是1024。 如果你设置的是100m,相当于是0.1个cpu,那么cpu.share就是0.1*1024=102. 也就是cpu.requests也是最终会体现到Cgroups里面去的。
Init container的资源需求
nodeSelector
NodeAffinity
比nodeSelector更高级的一个!
matchExpressions比selector更加灵活。
podAffinity
这个是很重要的,线上业务基本要配置这种podAntiAffinity。
Taints和Tolerations
k8s的自愈能力/故障转移能力。
PriorityClass
这个可以执行抢占(抢占低优pod的资源哈哈)
多调度器
重调度器
腾讯内部自研,水位线,干扰率
增加一个模拟调度,先模拟调度一下pod,如果能调度成功的话,就驱逐pod,如果模拟调度失败,就先不驱逐pod。
默认的descheduler可能存在一些问题的!
扩展调度器
extender本身就是一个拉低性能的因素。
基于Scheduler Framework实现扩展
主流的方法。
动态调度器
代码的实现而是很简单的。
🍀
docs.gorance.io
🍀
p8s基本是k8s的标配!
这个调度插件只一个锦上添花的能力,而不会影响主调度能力的。
🍀
webhook,节点超售–实际生产上有大规模使用的!
动态调度成效
关于我
我的博客主旨:
-
排版美观,语言精炼;
-
文档即手册,步骤明细,拒绝埋坑,提供源码;
-
本人实战文档都是亲测成功的,各位小伙伴在实际操作过程中如有什么疑问,可随时联系本人帮您解决问题,让我们一起进步!
-
个人微信二维码:x2675263825 (舍得), qq:2675263825。
-
个人微信公众号:《云原生架构师实战》
-
个人csdn
https://blog.csdn.net/weixin_39246554?spm=1010.2135.3001.5421
-
个人博客:(www.onlyyou520.com)
-
开源干货😘
最后
好了,关于本次就到这里了,感谢大家阅读,最后贴上我女神的photo,祝大家生活快乐,每天都过的有意义哦,我们下期见!