Koordinator 0.6：企业级容器调度系统解决方案，引入 CPU 精细编排、资源预留与全新的重调度框架...

阿里云原生开源的混部系统 Koordinator 基于阿里超大规模混部生产实践经验而来，旨在为用户打造云原生场景下接入成本最低、混部效率最佳的解决方案，助力用户企业实现云原生后提升计算资源利用率、降低 IT 成本。

经过社区多位成员的贡献，Koordinator 0.6 版本正式发布。相较于上一个版本 0.5^[1]，新版本进一步完善了 CPU 精细化编排能力，更好的兼容原生用法；支持了资源预留的能力（Reservation），补齐了调度原子语意缺失；发布了全新的重调度框架，支持用户灵活的扩展自定义插件。这些特性源自于阿里巴巴内部的生产实践，并结合上游社区规划思考，为用户带来标准、强大、灵活的调度解决方案。

01

现代化调度系统的挑战

Aliware

01

多云、混合云成为业务常态，调度系统必须适应多样化基础设施

随着国内外云厂商的不断发展，到 2022 年，大多数企业基础设施将围绕云计算环境构建，企业基础设施以云计算为主，以自建为辅。云计算按需的算力调配特性帮助企业实现通用、灵活、弹性的计算需求，自建部分满足企业传统应用架构过度、定制化或者安全合规诉求。

在企业使用云时，最大的顾虑是使用了厂商锁定的技术，因此多云架构是近年企业重点关注的领域，在多云环境中，不同云厂商的硬件可能存在不同程度的定制差异。调度系统如何适配多云场景下异构的算力设备，解决好异构资源调度、拓扑感知、运行时 QoS 保障，让用户在不同环境获得一致的体验，是一个很大的挑战。

为了帮助企业便利地管理云上、线下的算力，也会发展出混合云这样的产品架构，这其中可能出现一个集群中即包含云上又包含线下的计算节点，基础环境比较复杂。调度系统如何适配云上、线下环境，解决好不同环境对资源容量管理、任务编排、存储网络调度的诉求，同时支持用户在线下场景可以低成本的扩展自定义特性，让用户在一套调度系统上编排云上、线下的容器资源，是第二大挑战。

02

多种工作负载的混部成为常态，对调度系统能力的要求更加全面立体

Kubernetes 容器调度编排系统，帮助用户在一个节点上运行多个容器，也就提供了将不同业务的容器同时运行到一个节点的可能。也就是说，Kubernetes 天然地就支持了 “混部”。

随着企业容器化上云的进程加速，越来越多的应用类型通过 Kubernetes 部署到云基础设施之上。当企业的应用越来越多，为每一种类型的应用单独规划集群，在运维成本和资源成本上将不再可行。企业管理不同业务类型的方式逐步从切分集群到共享集群，从切分节点池到共享节点池这样的方式演进。

不同业务类型的工作负载，对调度系统都有不同的特性需求，调度系统如何在同一个集群、同一个节点上编排不同类型的工作负载，解决好它们各自的运行效率稳定性、对 Kubernetes 管控面性能和节点运行时稳定性的诉求，是现代化调度系统的一个重要课题。

03

成本效率成为企业关注的重点方向，调度系统是其中的关键一环

2020 年开始，受全球疫情的影响，企业的生产经营活动或多、或少的受到打击。有 65% 的企业开始考虑通过上云的方式降低企业 IT 信息化成本，已经上云的企业开始通过更深度的优化来降低 IT 资源成本。在成本治理领域，FinOps 的理念逐渐被企业所接受，在 2021 年 CNCF《FinOps Kubernetes Report》的调研报告显示，迁移至 Kubernetes 平台后，68% 的受访者表示所在企业计算资源成本有所增加，36% 的受访者表示成本飙升超过 20%。

这一调研结果与大型企业的应用实践截然不同，Google、微软、Alibaba 等国内外企业已经通过实践证明了企业容器化在成本上的巨大经济价值。这其中最关键的差别在于大型企业内部通常建设有完备的成本洞察能力，知道成本开销在哪里，同时建设了完备而强大的调度系统，让企业的资源充分的被利用起来。在这其中，调度系统如何处理好企业内部门间的 Quota 管理、资源借用，解决好上层弹性伸缩场景与底层节点池弹性伸缩之间的配合，合理的规划底层机型降低资源闲置率，是现代化云原生调度系统必须要解决的问题。

02

Koordinator 的解法和路径

Aliware

打造下一代容器调度系统，我们这么做：

01

拥抱上游标准，打造基于 QoS 的闭环调度系统

在学术界，集群资源调度系统的架构设计是一个老话题了，从集中式到分布式，从两层调度到共享状态架构，从悲观锁到乐观锁。在工业界历史上，每一种架构都或多或少的有过成功的案例，也正印证了那句话“架构设计没有对错，只有合适不合适”。在 Kubernetes 成为容易编排的事实标准之后，在 Kubernetes 之上依然衍生出了多种的调度器设计，他们或是擅长解决某一垂直领域的问题，或是采用了不同的设计实现，在各自的场景中实现了价值。

打造现代化的云原生调度系统，Koordinator 坚持了如下的设计思路：

1. 拥抱 Kubernetes 上游标准，基于 Scheduler-Framework 来构建调度能力，而不是实现一个全新的调度器。构建标准形成共识是困难的，但破坏是容易的，Koordinator 社区与 Kubernetes sig-scheduling 社区相向而行。

2. QoS 是系统的一等公民，与业界大多数调度器更多的关注编排结果（静态）不同，Koordinator 非常关注 Pod 运行时质量（QoS），因为对于调度系统的用户而言，运行时稳定性是其业务成功的关键。

3. 状态自闭环，Koordinator 认为调度必须是一个完整的闭环系统，才能满足企业级应用要求。因此，我们在第一个版本就引入了状态反馈回路，节点会根据运行时状态调优容器资源，中心会根据节点运行时状态反馈做调度决策。

4. 智能化、简单化，Koordinator 并不是就所有的选择暴露把问题留给客户，而是根据应用特征智能的为用户提供优化配置建议，简化用户使用 Kubernetes 的成本。

02

建设能力强大、灵活且可插拔的精细化资源编排优化方案

今天，服务器的 CPU 有 Intel、AMD、多家供应商的 ARM 芯片，AI 场景广泛应用的 GPU、FPGA 等，Kubernetes 作为容器编排基础设施，承载着异构硬件的管理工作，如何在标准 Kubernetes 之上提供异构硬件的调度编排，同时支持用户多样、灵活的策略控制，Koordinator 遵循了如下的设计思路：

1. 兼容 Kubernetes，Kubernetes 为用户提供了 static policy cpu manager，Koordinator 的 CPU 拓扑感知可以在用户启用 static policy 时兼容运行，也支持接管用户存量的运行时 Pod，方便用户做技术升级。

2. 中心调度 + 单机调度联合决策，中心调度看到全局视角，其决策可以找到集群中最适合应用需求的节点，而单机调度可以在节点侧做一定的灵活度，以应对应用突发的流量颠簸。

3. 调度 + 重调度密切配合，调度解决 Pod 一次性放置的问题，而重调度才是驱动集群资源编排长期保持最优化的关键。Koordinator 将建设面向 SLO 的重调度能力，持续的驱动应用的编排符合预定义的 SLO。

03

打造开箱即用的混部和工作负载弹性解决方案

混部是解决 Kubernetes 集群资源利用率的终极武器，这一点在国内外大型企业中都得到了实践论证，但也只是限于这个小圈子之中。近年随着国内外厂商的宣传以及关键信息在学术界论文透出，数字化路上的企业特别是云原生化的企业，对混部都有或多或少的了解。但面对混部，用户的心声是有没有一套开箱即用的解决方案，帮助用户优化 Kubernetes 集群的资源成本效率。

企业接入混部最大的挑战是如何让应用跑在混部平台之上，这第一步的门槛往往是最大的拦路虎。Koordinator 针对这一问题，结合内部生产实践经验，设计了“双零侵入”的混部调度系统：