给 K8s 装上大数据调度引擎：伏羲架构升级 K8s 统一调度

01

引言

Aliware

基于 K8s 的统一调度是阿里集团的核心项目，随着2021年双十一落下帷幕，这个历时一年多，汇集了蚂蚁、电商、搜索、计算平台等几大调度团队的联合项目在生产场景得到了终极验证。

作为统一调度项目的核心团队，伏羲成功地将 MaxCompute 弹内几万台机器、数百万核计算资源接入了统一调度系统，全程对业务和用户完全无感，无一故障，无一破线，完美实现了“飞行中更换引擎”的目标。统一调度在 MaxCompute 场景的规模化落地，为今年丝般顺滑地支撑双十一洪峰提供了强力保障。通过统一调度项目，伏羲也实现了架构上的再次升级，全面融入 K8s 统一调度架构，让 K8s 生态兼具在线服务和离线大数据的调度能力。

过去几年，阿里技术人一直在探索如何在一个资源池上让不同业务形态的应用在时空上“削峰填谷”，以提升利用率、降低成本、极致资源弹性；另一方面，飞天伏羲在长期的架构演进中，也一直在寻求如何兼容开源生态，更好地为开源引擎提供资源调度服务。基于 K8s 的统一调度，是阿里集团多年混部方案自然演进的结果，也是伏羲拥抱开源的终极形态。本文将从集团混部项目开始谈起，介绍基于 K8s 的统一调度方案，以及 MaxCompute 迁移统一调度的过程。

02

始于混部，终于统一调度

Aliware

阿里集团需要一个庞大的资源系统支撑线上丰富的业务形态，搜索、电商、大数据、数据库等，我们观察到电商纯在线集群长期处于低水位的状态，常态利用率在 10%以下，而以 MaxCompte 为代表的大数据离线集群长期处于高水位，平均利用率 70-80%。

以集团 10 万台（2017 年数字）在线机器为例，通过混部，理论上可以将机器利用率由 10%提升到 45%，这意味着每年可以额外提供 7.8 万台同等计算能力的机器，这是一笔巨大的收益。但混部的挑战也是巨大的，其中最核心的挑战是如何提供一套资源共享机制（全局、单机），在保障各应用 SLA 的前提下，达成集群利用率提升的目标。

01

基于资源静态划分的混部

集团混部项目从 2015 年 9 月正式立项，在经历了初期的技术栈整合和隔离技术的探索后，2017 年正式进入核心生产。当时 0 层作为资源展板，按机器粒度划分在线和离线资源的比例，管理机器的混部角色和状态，而在线离线两个一层调度器基于 0 层分配的资源进行各自业务场景的调度。2017 年双十一，电商和蚂蚁两个混部场景均平稳完成了大促的目标，但也有明显缺点：

1）离线作业的资源使用没有保障，可能被在线应用无条件抢占；

2）在线离线调度器静态划分资源，缺乏灵活性；

3）大促期间，离线全部降级，在更大规模场景下，很难保障离线核心业务的稳定性。

02

混部的进阶：规模化混部

2018 年年初，集团调度系统要全面提升混部能力，将电商混部扩大到万台规模，并全力保障离线作业的运行质量。为此，混部项目提出了资源优先级的概念，通过资源优先级划分，使离线的高优先级作业（Latency Critical）