2022年4月6日，阿里云原生混部系统 Koordinator 宣布正式开源。据介绍，Koordinator沉淀于阿里巴巴内部多年大规模应用实践，在2021年“双11”计算成本下降50% 中起到了关键作用。这个来自于阿里巴巴的大规模实践项目到底是什么？它的发展背景、技术原理及开源规划是怎样的？阿里内部又是如何利用混部技术解决“双11”等极端场景下的资源挑战的？
不久前，在【T·TALK】系列活动的第五期中，懿川、曾凡松、杨国东三位阿里技术专家，从 Koodinator 项目出发，为我们分享了混部的技术背景、落地经验以及对混部技术未来演进的思考与前瞻。【T·TALK】也将本次直播的核心内容进行了整理，希望能给大家带来一些不同的思考与启发：
混部技术概念
混部概念可以从两方面进行理解：从节点粒度的角度来看，混部就是将多个容器或多种应用部署在同一节之上。其中，多个容器包括，多个在线容器、多个离线容器与多个离在线容器三种形态，并不仅限于常规理解中的离线容器。单个节点，则是能够运行容器的最小单位，包含物理机、单个 ECS 等。
另一方面，从集群粒度的定义出发，多种应用在一个集群内自动部署，通过预测分析应用特性，实现业务间的错峰填谷，这便是混部。总的来说，混部所希望实现的是，利用更少的资源运行所有任务，以达到降本增效的终极目标。
通过上述混部的定义，我们可以梳理出混部的两项核心技术。
1、节点粒度
- 容器隔离技术：包括依赖内核的袋鼠、RunC 等；
- 单机调度技术：包括单机的负载感知，容器策略和阈值设置，容器优先 级和伸缩控制、cpushare 等；
- 中心调度技术：支持单机粒度的负载反馈、调度策略、调度性能等；
- 资源的差异化 SLO 技术：包括差异化 SLO 设定，优先级设定，基于 差异化SLO 的单机和中心调度配合。
2、集群粒度：基于节点粒度之上实现
- 中心调度技术：高性能调度、资源视图、多负载的调度协同、GPU 拓扑 感知等；
- 单机调度技术：任务的高频起停控制，单机多环境、硬件适配、cpu 归 一化等；
- k8s 生态框架优化和配套能力建设：包括集群规模突破、稳定性改进、 运维配套能力、界面和接口能力、业务对接等。
阿里作为业界混部技术的先行者之一，在 2011 年便开始探索容器技术，并在2016 年启动了混部技术研发，至今经历了多轮技术架构升级，最终演进到今天的云原生混部系统架构，直接采用基于 K8S 的云原生统一调度来实现多任务、多负载的协同感知，实现整个混部的效果。这也是目前经过验证的、最理想的架构和最好的工程实现。
如今，业界许多企业都在关注混部，希望能够快捷地获取到混部所带来的收益。对此，第一种解决方案便是直接采用公有云或商业化的产品，这部分会默认携带一些混部和弹性能力的支持。第二种解决方案则是开源共建，这种方式既能够保证团队自建的效果，又可以借助开源社区所积累的各层技术栈的经验，这也是目前比较推荐的一种方案。
阿里云原生混部系统Koordinator
Koordinator 是脱胎于阿里巴巴内部的混部系统，已于2022年4月6日正式开源（https://koordinator.sh/）。Koordinator 的技术基础和整套系统设计思路均来源于阿里内部的多年实践经验。阿里希望通过开源去推进整个混部技术的标准化，让更多用户能够应用混部并从中受益。
目前 Koordinator 项目中包含的内容分为三部分：
- 差异化 SLO：在 Kubernetes 之上抽象一套面向QoS的资源调度机制，同时在优先级内部划分不同的 QoS，并保障每一个优先级与 QoS 的资源特性；
- 资源精细化调度：阿里巴巴的最佳实践，其中包括 CPU 拓扑感知、性能优化调度、资源预留、交互式抢占、碎片整理、资源预览、GPU 共享调度以及算力归一化等；
- 任务调度：大数据与 AI 相关的任务调度，比如 Gang、批量、优先级抢占以及弹性 Quota（队列间借用）等，从而更好地去应用整个集群资源。
从整体架构的角度分析，Koordinator 项目的技术同样分为三大模块：最底层为Koordlet 模块，负责对应单机的一些技术能力，例如特征感知、单机级别干扰监测以及一些 QoS 管理与单机资源隔离。
当然，Koordinator 组件在单机上还会扩展出一些运行时的管理者角色，以帮助适配各种不同的运行时，同时避免对底层基础组件的侵入式修改。
中心端有两个主要角色，第一部分是 Koordinator Scheduler，其中包含调度特性与从调度特性。虽然在一般情况下，做调度的概率会远高于做从调度的概率，但从调度在混部项目中也是非常关键的一环，能够保证整个集群资源的运行质量持续保持较高的水准。
第二部分是 Koordinator Manager，这一组件主要用于混部策略的管理，包括如何对工作负载进行接入。此外，Koordinator Manager 中还集成了一个资源画像模块，目的是为了更好地支持调度器，做更好的资源打散，避免局部的机器出现热点，从而导致服务受损。
以上便是 Koordinator 的整体架构。上述这些模块的核心目标是希望帮助大家解决混部的两大核心问题：第一个问题是如何将混部工作负载进行接入，让各类任务能够以最低成本的方式接入到 Koordinator 混部的框架之中；第二个问题则是如何让各类任务在混部时各自良好运行，让计算任务能够获得所需的算力，让在线任务的运行延迟不受影响。
作为目前较为成熟的混部系统，Koordinator 有“双零入侵”的特性。第一，Koordinator 对应用的工作负载管理是零侵入的。Koordinator 会投大量精力，帮助用户将典型计算类负载的混部链路打通，用户只需要进行简单的配置、Koordinator 会 apply 一些配置的 yaml，就可以自动将计算的任务转化成混部的任务，从而避免对这些计算框架进行修改，这可以帮助到用户更快将混部落地到企业内部场景之中。
第二个零入侵指，Koordinator 对 Kubernets 是没有入侵的。在 Koordinator支持的 Kubernetes 版本上，用户可以将开源组件安装到自己的 Kubernetes 集群，去获得对应能力。Kubernetes 的扩展性在中心端是很好的，但是在节点端扩展性较差，因此在 Koordinator 项目的 Kubelet 和底层的容器运行池之间存在 Hook Manager，用来支持策略的扩展，从而避免对 Kubelet 以及底层的Containerd 或者 Docker 的侵入式修改。
整个混部之中，最重要的就是资源模型。做混部最本质的就是做出差异化能力，这样才能够进行资源超发，才能够提高资源的利用率，这一系列过程是倒推得来的。Koordinator 定义的资源模型是非常完备的，能够支持在线服务、实时计算、AI 训练任务、批处理计算任务，甚至一些测试任务都可以通过这套资源模型去满足。
此外，Koordinator也提供了各种资源维度的资源隔离技术，例如 CPU cquset、LLC 的一些隔离能力以及操作系统提供的优先级抢占能力等等。这些隔离能力未来都会在 Koordinator 社区中呈现，大家会逐渐看到这些隔离能力，以及针对不同资源特性实现的干扰检测能力。
Koordinator 是基于 Kubernetes 社区的，但 Koordinator 不会对 Kubernetes社区做任何修改，用户在运用混部技术时，首先会应用到 Kubernets，而后在Kubernets 之上去安装 Koordinator 对应的组件，这是 Koordinator 上下游的关系状况。
Koordinator 社区所提供的能力与企业内部真实环境的需求能力之间可能会有一些差异。用户可以基于社区使用自己内部的版本，结合企业特性去兼容一些旧的场景，通过这种方式，能够跟整个 Koordinator 社区更好的协作。Koordinator 社区会非常快的迭代，在这种模式下，用户可以不断从社区拿到新的特性，并且只需要在内部版本中维护自身企业非特殊化的部分即可。
如今，阿里巴巴已经基本实现了全量混部的覆盖，也通过自身实践证明了，混部技术能够给企业带来很大价值。阿里希望通过开源推进混部技术的标准化，让更多用户能够更简便地应用混部技术，并从中获得收益。未来，Koordinator 社区也将定义一些不同的角色，也非常欢迎大家参与其中，持续通过开源去做更多的贡献。
混部实践与发展前瞻
阿里巴巴集团有两个比较典型的混部场景，一部分是常态化的，日常主要的混部利用是在容灾的余量，阿里希望能够把容灾的余量用来进行大数据计算，这样能够提高整体资源的利用率。
另一部分就是“双11”这类应用场景，阿里的在线流量大概是日常的十倍量级。按照传统的资源准备方式，需要准备十倍的机器来支持大促的资源需求。但阿里将 MaxCompute 、批处理以及非实时任务作为离线任务，通过大量的降级，将资源释放给在线业务，以实现大促资源采购的降低。
结合阿里巴巴的技术发展来看，混部的适用环境可以抽象为几点：其一，企业的工作负载应该是多样化的；其二，当企业的流量与业务达到一定规模时，才有对资源弹性的需求，才更需要考虑降本增效。对于初期或规模不大的场景，使用 ECS 的弹性基本就能够享受到混部以及弹性的优势。
混部技术是一个系统工程，是从硬件到操作系统的调度，需要协同优化。从阿里集团的资源利用率提升阶段看，当资源利用率从 10% 提升为 30% 时，这一阶段的技术门槛是相对较低的，通过类似于K8S调度以及基础混部能力，便能够实现整体负载的提升，这一阶段对大部分企业都是适用的。
但如果将混部的水位从 30% 提升到 50%，其中的挑战还是很大的。阿里混部技术一路演进过来，在计算、存储、网络等方面都做了很多升级。但到目前为止，这些依然不能够满足我们对混部以及弹性的资源模型。这时，需要依靠应用架构的改进，例如，阿里将业务架构去掉了本地盘，将 IO 隔离的问题转化成了网络隔离问题等，这些是全链路需要在应用侧去配合的，这样才能切实提高利用率。
此外，在集群的混部本身其实也有着很高的门槛。基于简单的 workload，可以按照4核或8核16G标准规格去调度。但随着混部的 workload 复杂度提升，资源规格的多样性，将分配问题变成了一个 NP 问题，此时要解决好专项问题，则需要使用一些较为复杂的、类似于决策智能的问题求解算法，以及在做混部的过程中如何做好应用画像，这些都是需要打磨的。
可以看到，混部是一个很大的系统工程。今天，阿里通过开源，将过往在混部落地中所踩过的坑以及所积累的经验，都呈现给了大家，也希望今后有更多的伙伴能够加入进来，在收获混部效益的同时，发掘更有深度的技术，共建混部技术生态。
