写点什么

作业帮 Kubernetes 原生调度器优化实践

  • 2021-10-21
  • 本文字数:3075 字

    阅读完需:约 10 分钟

作业帮 Kubernetes 原生调度器优化实践

调度系统的本质是为计算服务或任务匹配合适的资源,使其能够稳定高效地运行,以及在此基础上进一步提高资源使用密度,而影响应用运行的因素非常多,比如 CPU、内存、IO、差异化的资源设备等一系列因素都会影响应用运行的表现。同时,单独和整体的资源请求、硬件 / 软件 / 策略限制、 亲和性要求、数据区域、负载间的干扰等因素以及周期性流量场景、计算密集场景、在离线混合等不同应用场景的交织也带来了决策上的很多变化。


调度器的目标则是快速准确地实现这一能力,但快速和准确这两个目标在资源有限的场景下往往会产生矛盾,这需要在二者间权衡,本文主要分享了作业帮在实际应用 K8s 过程中遇到的问题以及最终探讨出的解决方案,希望对广大开发者有所帮助。

调度器原理和设计


K8s 默认调度器的整体工作框架可以简单用下图概括:

两个控制循环


1、第一个控制循环称为 Informer Path,主要工作是启动一系列 Informer,用来监听(Watch)集群中 Pod、Node、Service 等与调度相关的 API 对象的变化。比如,当一个待调度 Pod 被创建出来之后,调度器就会通过 Pod Informer 的 Handler,将这个待调度 Pod 添加进调度队列;同时,调度器还要负责对调度器缓存 Scheduler Cache 进行更新,并以这个 cache 为参考信息,来提高整个调度流程的性能。


2、第二个控制循环即为对 pod 进行调度的主循环,称为 Scheduling Path。这一循环的工作流程是不断地从调度队列中取出待调度的 pod,运行两个步骤的算法,来选出最优 node


  • 在集群的所有节点中选出所有“可以”运行该 pod 的节点,这一步被称为 Predicates;

  • 在上一步选出的节点中,根据一系列优选算法对节点打分,选出“最优”即得分最高的节点,这一步被称为 Priorities。


调度完成之后,调度器就会为 pod 的 spec.NodeName 赋值这个节点,这一步称为 Bind。而为了不在主流程路径中访问 Api Server 影响性能,调度器只会更新 Scheduler Cache 中的相关 pod 和 node 信息:这种基于乐观假设的 API 对象更新方式,在 K8s 中称为 Assume。之后才会创建一个 goroutine 来异步地向 API Server 发起更新 Bind 操作,这一步就算失败了也没有关系,Scheduler Cache 更新后就会一切正常。

大规模集群调度带来的问题和挑战


K8s 默认调度器策略在小规模集群下有着优异表现,但是随着业务量级的增加以及业务种类的多样性变化,默认调度策略则逐渐显露出局限性:调度维度较少,无并发,存在性能瓶颈,以及调度器越来越复杂。


迄今为止,我们当前单个集群规模节点量千级,pod 量级则在 10w 以上,整体资源分配率超过 60%,其中更是包含了 GPU、在离线混合部署等复杂场景。在这个过程中,我们遇到了不少调度方面的问题。

问题 1:高峰期的节点负载不均匀


默认调度器,参考的是 workload 的 request 值,如果我们针对 request 设置的过高,会带来资源浪费;过低则有可能带来高峰期 CPU 不均衡差异严重的情况;使用亲和策略虽然可以一定程度避免这种,但是需要频繁填充大量的策略,维护成本就会非常大。而且服务的 request 往往不能体现服务真实的负载,带来差异误差。而这种差异误差,会在高峰时体现到节点负载不均上。


实时调度器,在调度的时候获取各节点实时数据来参与节点打分,但是实际上实时调度在很多场景并不适用,尤其是对于具备明显规律性的业务来说,比如我们大部分服务晚高峰流量是平时流量的几十倍,高低峰资源使用差距巨大,而业务发版一般选择低峰发版,采用实时调度器,往往发版的时候比较均衡,到晚高峰就出现节点间巨大差异,很多实时调度器往往在出现巨大差异的时候会使用再平衡策略来重新调度,高峰时段对服务 POD 进行迁移,服务高可用角度来考虑是不现实的。显然,实时调度是远远无法满足业务场景的。

我们的方案:高峰预测时调度


针对这种情况,需要预测性调度方案,根据以往高峰时候 CPU、IO、网络、日志等资源的使用量,通过对服务在节点上进行最优排列组合回归测算,得到各个服务和资源的权重系数,基于资源的权重打分扩展,也就是使用过去高峰数据来预测未来高峰节点服务使用量,从而干预调度节点打分结果。

问题 2:调度维度多样化


随着业务越来越多样,需要加入更多的调度维度,比如日志。由于采集器不可能无限速率采集日志且日志采集是基于节点维度。需要平衡日志采集速率,各个节点差异不可过大。部分服务 CPU 使用量一般但是日志输出量很大,而日志并不属于默认调度器决策的一环,所以当这些日志量很大的多个服务 pod 在同一个节点上时,该机器上的日志上报就有可能出现部分延迟。

我们的方案:补全调度决策因子


该问题显然需要对调度决策补全,我们扩展了预测调度打分策略,添加了日志的决策因子,将日志也作为节点的一种资源,并根据历史监控获取到服务对应的日志使用量来计算分数。

问题 3:大批量服务扩缩带来的调度时延


随着业务复杂度进一步上升,在高峰时段出现,会有大量定时任务和集中大量弹性扩缩,大批量(上千 POD)同时调度导致调度时延上涨,这两者对调度时间比较敏感,尤其对于定时任务来说,调度延时的上涨会被明显感知到,原因是 K8s 调度 pod 本身是对集群资源的分配,反应在调度流程上则是预选和打分阶段是顺序进行的。如此一来,当集群规模大到一定程度时,大批量更新就会出现可感知的 pod 调度延迟。

我们的方案:拆分任务调度器,加大并发调度域、批量调度


解决吞吐能力低下最直接的方法就是串行改并行,对于资源抢占场景,尽量细化资源域,资源域之间并行。基于以上策略,我们拆分出了独立的 Job 调度器,同时使用 Serverless 作为 Job 运行的底层资源。K8s Serverless 为每一个 Job POD 单独申请了独立的 POD 运行 sanbox,也就是任务调度器,完整并行。以下为对比图:


原生调度器在晚高峰下节点 CPU 使用率

优化后调度器在晚高峰下节点 CPU 使用率

总结


Work 节点资源、GPU 资源、Serverless 资源是我们集群异构资源的三类资源域,这三种资源上运行的服务存在天然差异,我们使用 forecast-scheduler、gpu-scheduler、job-schedule 三个调度器来管理这三种资源域上的 Pod 调度情况。


  • 预测调度器管理大部分在线业务,其中扩展了资源维度,添加了预测打分策略。

  • GPU 调度器管理 GPU 资源机器的分配,运行在线推理和离线训练,两者的比例处于长期波动中,高峰期间离线训练缩容、在线推理扩容;非高峰期间离线训练扩容、在线推理缩容;同时处理一些离线图片任务来复用 GPU 机器上比较空闲的 CPU 等资源。

  • Job 调度器负责管理定时任务调度,定时任务量大且创建销毁频繁,资源使用非常碎片化,而且对时效性要求更高;所以我们将任务尽量调度到 Serverless 服务上,压缩集群中为了能容纳大量任务而冗余的机器资源,提升资源利用率。

未来演进探讨


  • 更细粒度的资源域划分,将资源域划分至节点级别,节点级别加锁来进行。


  • 资源抢占和重调度。正常场景下,当一个 Pod 调度失败,这个 Pod 会保持在 pending 的状态,等待 Pod 更新或者集群资源发生变化进行重新调度,但是 K8s 调度器依然存在一个抢占功能,可以使得高优先级 Pod 在调度失败时,挤走某个节点上的部分低优先级 Pod 以保证高优先级 Pod 的正常运行,迄今为止我们并没有使用调度器的抢占能力,即使我们通过以上多种策略来加强调度的准确性,但依然无法避免部分场景下由于业务带来的不均衡情况,这种非正常场景中,重调度的能力就有了用武之地,也许重调度将会成为日后针对异常场景的一种自动修复方式。


作者介绍:


吕亚霖,作业帮基础架构 - 架构研发团队负责人。2019 年加入作业帮,负责技术中台和基础架构工作。在作业帮期间主导了云原生架构演进、推动实施容器化改造、服务治理、GO 微服务框架、DevOps 的落地实践。

2021-10-21 15:325276

评论 1 条评论

发布
用户头像
您好,能开源代码吗
2021-11-26 11:17
回复
没有更多了
发现更多内容

详解ThreadLocal

threedayman

读懂深度学习,走进“深度学习+”阶段

白洞计划

如何破越发展 to B 市场亏损越多问题?

风铃架构日知录

互联网 程序人生 后端 IT tob产品

【Redis实战专题】「性能监控系列」全方位探索Redis的性能监控以及优化指南

码界西柚

redis监控 Redis优化 redis性能

设计千万级学生管理系统的考试试卷存储方案 - 模块四

Geek_e5f2e5

WEB开发人员应该知道 10 个 Docker 命令

devpoint

Docker 前端开发 docker image Docker 镜像

Pytorch 基础-tensor 数据结构

嵌入式视觉

Tensor ndarray 张量的基本操作 view函数 reshape

【深入浅出Seata原理及实战】「入门基础专题」探索Seata服务的AT模式下的分布式开发实战指南(2)

码界西柚

分布式事务 分布式架构 Alibaba SpringCloud Alibaba

2023-01-13:joxit/docker-registry-ui是registry的web界面工具之一。请问部署在k3s中,yaml如何写?

福大大架构师每日一题

k8s k3s 福大大

【Java基础】Java8 使用 stream().sorted()对List集合进行排序

No8g攻城狮

java; 开发语言 语言 & 开发 Java’

Tapdata Cloud 场景通关系列:将数据导入阿里云 Tablestore,获得毫秒级在线查询和检索能力

tapdata

SAP 交货单与HU指派关系数据不一致问题的解决方案

SAP虾客

SAP 公司间STO 外向交货单 HU DEBUG改表

一个比一个牛皮的5个杨辉三角特性!

风铃架构日知录

Java 程序员 算法 IT 杨辉三角

天翼云第八代云主机助力企业攻克上云“大象流”加密处理业务难题

极客天地

Hero动画应用之列表详情页切换

岛上码农

flutter ios 前端 安卓 移动端开发

小兔子在终端给大家拜年啦

陈明勇

Go golang 后端

模块9毕业设计项目

冷夫冲

架构设计实战

【架构设计】你真的理解软件设计中的SOLID原则吗?

小小怪下士

Java 程序员 架构设计

兼容东西,贯通南北:超聚变的“四水归堂”

脑极体

科技 算力 超聚变

photozoompro2023下载激活教程

茶色酒

PhotoZoom photozoompro

系统风险处置

agnostic

风险系统 业务风险 操作风险

第四周作业-千万级学生系统课程存储设计

不爱学习的程序猿

总结一下经典机器学习算法

风铃架构日知录

Java 程序人生 算法 后端 IT

【架构设计】你真的理解软件设计中的SOLID原则吗?

JAVA旭阳

Java 架构

非常实用的代码阅读策略!

风铃架构日知录

Java 程序员 后端 IT 代码

David Murray 加入 VeraViews 担任需求总监

鳄鱼视界

Tapdata 杨庆麟:实时数据如何赋能制造业,实现业务卓越与持续发展?

tapdata

Alluxio 2022技术干货年终大赏

Alluxio

大数据 分布式 案例 Alluxio 数据编排

算力狂热时代的冷静之道:宁畅总裁秦晓宁分享企业的算力最优解

脑极体

算力 东数西算 算力网络

【Java基础】Java8 使用 stream().filter()过滤List对象(查找符合条件的对象集合)

No8g攻城狮

java; 开发语言 语言 & 开发 Java’

tinyrpc源码阅读

骑牛上青山

golang 源码 RPC

作业帮 Kubernetes 原生调度器优化实践_服务革新_吕亚霖_InfoQ精选文章