乐趣区

关于阿里云:Koordinator-10-正式发布业界首个生产可用面向规模场景的开源混部系统

jiezi

作者：Koordinator 团队

Koordinator 从 2022 年 4 月公布以来，迄今一共迭代公布了 8 个版本。我的项目经验的大半年倒退过程中，Koordinator 社区吸纳了包含阿里巴巴、小米、小红书、爱奇艺、360 在内的大量优良工程师，奉献了泛滥的想法、代码和场景，一起推动 Koordinator 我的项目的成熟。

11 月 3 日，在 2022 杭州 · 云栖大会上，阿里云智能云原生利用平台负责人丁宇发表，Koordinator 1.0 正式公布。

如果你对混部、调度畛域不太关注，可能对 Koordinator 还没有做过太深刻的理解。本文就借着 v1.0 公布机会，为你具体的梳理一次 Koordinator 我的项目的倒退脉络，解读它的核心思想和愿景，把握这个正在疾速倒退的云原生混部零碎的技术理念。

我的项目的前生今世

Koordinator，名字取自 coordinator，K for Kubernetes，发音雷同。语意上符合我的项目要解决的问题，即协调编排 kubernetes 集群中不同类型的工作负载，使得他们以最优的布局、最佳的姿势在一个集群、一个节点上运行。

容器混部技术最早起源于 Google 外部的一个 Borg 零碎，在其论文公开发表（2015）之前在行业上始终是十分神秘的存在。在业界，基于 Hadoop 的大数据任务调度技术后行，在比拟晚期很好的解决了企业对于大数据计算的诉求。相熟历史的同学应该晓得，云原生容器调度编排零碎 Kubernetes 开源于 2014 年，而  Kubernetes 正是受 Borg 设计思维启发，由 Borg 零碎的设计者联合云时代利用编排的需要从新设计而来。Kubernetes 良好的扩展性使其能适应多样的工作负载，帮忙用户很好的解决工作负载日常运维效率。随着 Kubernetes 的蓬勃发展，逐渐成为行业的事实标准，越来越多的工作负载开始运行在 Kubernetes 之上，特地是在这两年，大数据相干的负载逐渐迁徙到 Kubernetes 之上。

阿里巴巴早在 2016 年就启动了混部技术研发，到往年，内混部零碎经验了三轮大的架构降级，并经验多年“双 11”峰值流量的锻炼。目前，阿里巴巴实现全业务规模超千万核的云原生混部，混部 CPU 利用率超 50%，混部技术帮忙 2022 年“双 11”计算成本大幅降落。在这个过程中，阿里巴巴混部也走过了一些弯路，积攒了大量的生产实践经验。

为了帮忙企业少走弯路，更疾速的拿到云原生混部带来的资源效率红利，阿里巴巴在 2022 年 4 月份正式对外公布的 Koordinator 开源我的项目。通过建设一个中立的开源社区，帮忙企业实现在规范 Kubernetes 之上的多种类型负载混部的调度解决方案，以达到云上、云下统一的云原生混部架构，升高零碎运维老本，放弃长期可继续倒退的衰弱状态。

Koordinator 自公布以来，在开源制度与标准上一直向 Kubernetes 等前辈学习，逐步造成了较为欠缺的社区运作机制。在这里，咱们会淡化每一位社区成员的雇主、职务，以用户、开发者的身份参加到社区建设中。同样，Koordinator 将来的 roadmap 与倒退布局，也将源于所有成员与用户的反馈、需要与共识，而非阿里巴巴本身制订。因而，对于每一位云原生爱好者，不论你是初识调度畛域或是混部场景的亲身经历者，都欢送你关注和参加到 Koordinator 我的项目中，独特打造一套面向未来的开源混部体系。

规范、通用的混部解决方案

混部须要一套残缺、自闭环的调度回路，但在企业应用混部的过程中，将要面临的两大挑战是：

  1. 利用如何接入到混部平台
  2. 利用如何在平台上可能运行稳固、高效 

Koordinator 汲取了阿里巴巴外部多年的生产实践经验教训，针对这两大挑战针对性的设计了解决方案，旨在帮忙企业真正意义上的用上混部，用好 Kubernetes，而不是秀技术秀肌肉。

Koordinator 1.0 的整体架构如下图所示，为了用户提供了残缺的混部工作负载编排、混部资源调度、混部资源隔离及性能调优解决方案，帮忙用户进步提早敏感服务的运行性能，开掘闲暇节点资源并调配给真正有须要的计算工作，从而进步全局的资源利用效率。

大规模生产实践锻炼

2021 双 11 之后阿里对外发表了“首次！对立调度零碎规模化落地，全面撑持阿里巴巴双 11 全业务”：

作为阿里巴巴的外围我的项目，阿里云（容器团队和大数据团队）联结阿里巴巴资源效力团队、蚂蚁容器编排团队，历时一年多研发和技术攻坚，实现了从“混部技术”到明天“对立调度技术”的全面降级。

明天，对立调度已实现阿里巴巴电商、搜推广、MaxCompute 大数据的调度全面对立，实现了 Pod 调度和 task 高性能调度的对立，实现了残缺的资源视图对立和调度协同，实现了多种简单业务状态的混部和利用率晋升，全面撑持了寰球数十个数据中心、数百万容器、数千万核的大规模资源调度。

作为云原生混部的践行者，阿里巴巴是真刀真枪的在生产环境中推动混部技术理念，并在去年双 11 实现了超过千万核的混部规模，通过混部技术帮忙阿里巴巴双 11 节约超过 50% 的大促资源老本，在大促快上快下链路上提速 100%，助力大促实现丝滑的用户体验。

正是在双 11 这样的峰值场景驱动之下，阿里的混部调度技术继续演进，积攒了大量的生产实践经验，到明天曾经是第三代即云原生全业务混部零碎。Koordinator 的架构基于阿里巴巴外部的超大规模生产实践，联合阿里云看到的企业容器客户的实在诉求，在标准化、通用化上做出了更多的冲破，实现首个基于规范 Kubernetes 的生产可用的开源混部零碎。

反对丰盛的负载类型

混部是一套针对提早敏感服务的精细化编排 + 大数据计算工作负载混合部署的资源调度解决方案，核心技术在于：

  1. 精密的资源编排，以满足性能及长尾时延的要求，关键点是精细化的资源调度编排策略及 QoS 感知策略；
  2. 智能的资源超卖，以更低成本满足计算工作对计算资源的需要，并保障计算效率的同时不影响提早敏感服务的响应工夫。

上图是 Koordinator 混部资源超卖模型，也是混部最要害最外围的中央。其中超卖的根本思维是去利用那些已调配但未应用的资源来运行低优先级的工作，如图所示的四条线别离是资源使用量（红线），短生命周期可超卖量（蓝线），长生命周期可超卖量（浅蓝），以及资源总量（黑线）。

该资源模型足够精炼的同时也具备很强的灵活性，反对丰盛的在线资源编排类别，反对短生命周期的批处理工作（MapReduce 类别），以及实时计算类的生命周期工作。Koordinator 整个混部资源调度的大厦构建在这样一个资源模型的根底之上，配合上优先级抢占、负载感知、烦扰辨认和 QoS 保障技术，构建出混部资源调度底层外围零碎。Koordinator 社区将围绕这个思路投入建设，继续将混部场景的调度能力开展，解决企业面临的实在业务场景问题。

零侵入，低接入老本

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

  1. 对 Kubernetes 平台的零侵入：无需批改任何 Kubernetes 原生组件，而是以插件的形式加强混部须要的各种能力
  2. 对工作负载编排零碎的零侵入：无需批改计算工作的治理引擎（operator），而是以配置化的形式治理混部策略参数，简化利用接入的难度
  3. 支持系统的平滑降级：已有的 Kubernetes 集群的调度器能够平滑降级到 Koordinator，存量的 Pod 的规范调度能力能够无损接管到 Koordinator 中 

通过在这三方面的致力，升高用户在生产环境中引入 Koordinator 的难度，只在帮忙用户解决生产环境利用混部的第一道拦路虎。

版本个性深刻解读

自 2022 年 4 月份 Koordinator 公布以来，社区围绕在混部资源的一层调度而构建，解决工作混部最外围的资源编排、资源隔离的问题。在版本迭代过程中，Koordinator 社区始终围绕三大能力而构建，即任务调度、差异化 SLO 以及 QoS 感知调度能力。

任务调度

  • Enhanced Coscheduling

Koordinator 在启动之初，冀望反对 Kubernetes 多种工作负载的混部调度，进步工作负载的运行时效率和可靠性，其中就包含了机器学习和大数据畛域中宽泛存在的具备 All-or-Nothing 需要的作业负载。例如当提交一个 Job 时会产生多个工作，这些工作冀望要么全副调度胜利，要么全副失败。这种需要称为 All-or-Nothing，对应的实现被称作 Gang Scheduling(or Coscheduling)。为了解决 All-or-Nothing 调度需要，Koordinator 基于社区已有的 Coscheduling 实现了 Enhanced Coscheduling：

  1. 反对 Strict/NonStrict 模式，解决大作业场景长时间得不到资源问题
  2. 反对 AI 场景多角色联结的 coscheduling 策略，例如一个 TF  训练 Job 中蕴含 PS 和 Worker 两种角色，并且两种角色都须要独自定义 MinMember，但又冀望两种角色的 All-or-Nothing 都满足后能力持续调度 
  • Enhanced ElasticQuota Scheduling

企业的 Kubernetes 个别由多个产品和研发团队共用一个规模比拟大的 Kubernetes 集群，由资源运维团队对立治理集群内大量 CPU/Memory/Disk 等资源。

Koordinator 为帮忙用户治理好资源额度，晋升资源额度的应用效率，实现降本增效，Koordinator 基于基于社区 ElasticQuota CRD 实现了 Enhanced  ElasticQuota Scheduling，具备如下加强个性：

  • 兼容社区的 ElasticQuota CRD，用户能够无缝降级到 Koordinator
  • 反对树形构造治理 Quota，符合企业的组织架构
  • 反对依照共享权重 (shared weight) 保障公平性
  • 容许用户设置是否容许借用 Quota 给其余生产对象 

Koordinator ElasticQuota Scheduling 通过额度借用机制和公平性保障机制，Koordinator 把闲暇的额度复用给更须要的业务应用。当额度的所有者须要额度时，Koordinator 又能够保障有额度可用。通过树形管理机制治理 Quota，能够不便的与大多数公司的组织构造映射，解决同部门内或者不同部门间的额度治理需要。

  • Fine-grained Device Scheduling

在 AI 畛域，GPU、RDMA、FPGA 等异构资源被宽泛的利用，Koordinator 针对异构资源调度场景，提供了精细化的设施调度管理机制，包含：

  1. 反对 GPU 共享，GPU 独占，GPU 超卖
  2. 反对百分比的 GPU 调度
  3. 反对 GPU 多卡调度
  4. NVLink 拓扑感知调度（doing）

差异化 SLO

差异化 SLO 是 Koordinator 提供的外围混部能力，保障资源超卖之后的 Pod 的运行稳定性。Koordinator 定了一一组 Priority & QoS，用户依照这一最佳实际的形式接入利用，配合欠缺的资源隔离策略，最终保障不同利用类型的服务质量。

  • CPU Supress

Koordinator 的单机组件 koordlet 会依据节点的负载水位状况，调整 BestEffort 类型 Pod 的 CPU 资源额度。这种机制称为 CPU Suppress。当节点的在线服务类利用的负载较低时，koordlet 会把更多闲暇的资源分配给 BestEffort 类型的 Pod 应用；当在线服务类利用的负载上升时，koordlet 又会把调配给 BestEffort 类型的 Pod 应用的 CPU 还给在线服务类利用。

  • CPU Burst

CPU Burst 是一种服务级别指标 (SLO) 感知的资源调度性能。用户能够应用 CPU Burst 来进步对提早敏感的应用程序的性能。内核的调度器会因为容器设置的 CPU Limit 压抑容器的 CPU，这个过程称为 CPU Throttle。该过程会升高应用程序的性能。

Koordinator 自动检测 CPU Throttle 事件，并主动将 CPU Limit 调整为适当的值。通过 CPU Burst 机制可能极大地提高提早敏感的应用程序的性能。

  • 基于内存平安阈值的被动驱赶机制

当提早敏感的应用程序对外提供服务时，内存使用量可能会因为突发流量而减少。相似地，BestEffort 类型的工作负载可能存在相似的场景，例如，以后计算负载超过预期的资源申请 / 限度。这些场景会减少节点整体内存使用量，对节点侧的运行时稳定性产生不可预知的影响。例如，它会升高提早敏感的应用程序的服务质量，甚至变得不可用。尤其是在混部场景下，这个问题更具挑战性。

咱们在 Koordinator 中实现了基于内存平安阈值的被动驱赶机制。koordlet 会定期检查 Node 和 Pods 最近的内存应用状况，查看是否超过了平安阈值。如果超过，它将驱赶一些 BestEffort 类型的 Pod 开释内存。在驱赶前依据 Pod 指定的优先级排序，优先级越低，越优先被驱赶。雷同的优先级会依据内存使用率（RSS）进行排序，内存使用率越高越优先被驱赶。

  • 基于资源满足的驱赶机制

CPU Suppress 在线利用的负载升高时可能会频繁的压抑离线工作，这尽管能够很好的保障在线利用的运行时品质，然而对离线工作还是有一些影响的。尽管离线工作是低优先级的，但频繁压抑会导致离线工作的性能得不到满足，重大的也会影响到离线的服务质量。而且频繁的压抑还存在一些极其的状况，如果离线工作在被压抑时持有内核全局锁等非凡资源，那么频繁的压抑可能会导致优先级反转之类的问题，反而会影响在线利用。尽管这种状况并不常常产生。

为了解决这个问题，Koordinator 提出了一种基于资源满足度的驱赶机制。咱们把理论调配的 CPU 总量与冀望调配的 CPU 总量的比值成为 CPU 满足度。当离线工作组的 CPU 满足度低于阈值，而且离线工作组的 CPU 利用率超过 90% 时，koordlet 会驱赶一些低优先级的离线工作，开释出一些资源给更高优先级的离线工作应用。通过这种机制可能改善离线工作的资源需要。

  • L3 Cache 和内存带宽调配(MBA) 隔离

混部场景下，同一台机器上部署不同类型的工作负载，这些工作负载会在硬件更底层的维度产生频繁的资源竞争。因而如果竞争抵触重大时，是无奈保障工作负载的服务质量的。

Koordinator 基于 Resource Director Technology (RDT, 资源导向技术)，管制由不同优先级的工作负载能够应用的末级缓存（服务器上通常为 L3 缓存）。RDT 还应用内存带宽调配 (MBA) 性能来管制工作负载能够应用的内存带宽。这样能够隔离工作负载应用的 L3 缓存和内存带宽，确保高优先级工作负载的服务质量，并进步整体资源利用率。

QoS 感知调度、重调度

Koordinator 差异化 SLO 能力在节点侧提供了诸多 QoS 保障能力可能很好的解决运行时的品质问题。同时 Koordinator Scheduler 也在集群维度提供了加强的调度能力，保障在调度阶段为不同优先级和类型的 Pod 调配适合的节点。

  • 负载感知调度

超发资源能够极大的晋升集群的资源利用率，但也会凸显集群内节点之间资源利用率不平均的景象。这个景象在非混部环境下也是存在的，只是因为 Kubernetes 原生是不反对资源超发机制，节点上的利用率往往不是很高，肯定水平上覆盖了这个问题。但当混部时，资源利用率会回升到比拟高的水位时就裸露了这个问题。

利用率不平均个别是节点之间不平均以及呈现部分的负载热点，部分的负载热点会可能影响工作负载的整体运行成果。另一个是在负载高的节点上，在线利用和离线工作之间可能会存在的重大的资源抵触，影响到在线利用的运行时品质。

为了解决这个问题，Koordinator 的调度器提供了一个可配置的调度插件管制集群的利用率。该调度能力次要依赖于 koordlet 上报的节点指标数据，在调度时会过滤掉负载高于某个阈值的节点，避免 Pod 在这种负载较高的节点上无奈取得很好的资源保障，另一方面是防止负载曾经较高的节点持续好转。在打分阶段抉择利用率更低的节点。该插件会基于工夫窗口和预估机制躲避因霎时调度太多的 Pod 到冷节点机器呈现一段时间后冷节点过热的状况。

  • 精细化 CPU 调度

随着资源利用率的晋升进入到混部的深水区，须要对资源运行时的性能做更深刻的调优，更精密的资源编排能够更好的保障运行时品质，从而通过混部将利用率推向更高的程度。

咱们把 Koordinator QoS 在线利用 LS 类型做了更粗疏的划分，分为 LSE、LSR 和 LS 三种类型。拆分后的 QoS 类型具备更高的隔离性和运行时品质。通过这样的拆分，整个 Koordinator QoS 语义更加准确和残缺，并且兼容 Kubernetes 已有的 QoS 语义。

而且咱们针对 Koordinator QoS，设计了一套丰盛灵便的 CPU 编排策略，如下表所示。

不同的 QoS 类型的工作负载具备不同的隔离性：

Koordinator Scheduler 会针对 LSE/LSR 类型的 Pod 调配具体的 CPU 逻辑核，并更新到 Pod Annotation 中，由单机侧 koordlet 配合，把调度器调配的 CPU 更新到 cgroup 中。

调度器在调配 CPU 时，会依据 CPU 拓扑构造调配，默认尽可能的保障调配的 CPU 属于同一个 NUMA Node 以取得更好的性能。并且 CPU 调度时，反对 Pod 依据须要设置不同的互斥策略，例如一个零碎中多个外围的服务部署在雷同的物理核上，性能体现比拟差，但离开就齐全没问题，此时就能够配置互斥策略，调度器会尽可能的把这种互斥属性的 Pod 调配应用不同的物理核。并且在打分阶段，调度器会参考集群的整体状况，抉择合乎 CPU 编排要求的节点。

  • 资源预留（Reservation）

Koordinator 反对在不侵入 Kubernetes 已有的机制和代码前提下，实现了资源预留的原子能力(Reservation)。Koordinator Reservation API 容许用户不批改 Pod Spec 或者存量的 Workload(例如 Deployment, StatefulSet）即能够预留资源。资源预留在容量治理、碎片优化、调度成功率和重调度等场景有重要作用：

  1. 当有重要的工作负载在将来某段时间须要资源时，能够提前预留资源满足需要。
  2. 用户在 PaaS 上发动扩容时，能够通过资源预留能力尝试预留，预留胜利后发动扩容，保障 PaaS 的 SLA。
  3. 用户在 PaaS 上公布时，如果利用采纳了滚动公布的能力，能够通过资源预留保留行将销毁的 Pod 持有的资源，在滚动公布时，新建的 Pod 能够复用预留下来的原有资源，可能无效进步滚动公布的成功率。
  4. 碎片优化场景中，能够通过资源预留占住闲暇的碎片资源，并把可被整顿的 Pod 迁徙到这些节点。
  5. 重调度时在发动驱赶前，先尝试预留资源，预留胜利后发动驱赶，防止驱赶后无资源可用影响利用的可用性。
  • 灵便可扩大且平安的重调度器

调度器调度时是依据过后集群内的状况和配置，做出综合的判断，抉择出一个最合适的节点调配给 Pod 应用。但随着工夫和工作负载的变动，本来最合适的节点也会变差，差异化 SLO 和调度器都提供了丰盛的能力帮忙改善这些问题，但差异化 SLO 更多还是关注在本身单机的状况，无奈感知全局的变动。

从管制的角度看，咱们也须要依据集群内的状况做出决策，把异样的 Pod 驱赶迁徙到更适合的节点，让这些 Pod 有机会能够更好的对外服务。因而 Koordinator Descheduler 应运而生。

咱们认为 Pod 迁徙是一个简单的过程，波及到审计、资源分配、利用启动等步骤，还夹杂着利用的公布降级、扩容 / 缩容场景和集群管理员的资源运维操作。因而，如何治理 Pod 迁徙过程的稳定性危险，保障利用不会因为 Pod 的迁徙影响可用性，是一个十分要害的必须解决的问题。

为了让大家更好的了解，举几个场景：

  1. 社区的重调度器内置的多个重调度策略依据本身逻辑判断某个 Pod 是否要被迁徙，须要迁徙时调用 Kubernetes Eviction API  发动驱赶。然而这个过程并不关注被驱赶的 Pod 在未来是否能够调配到资源。因而存在大量 Pod 被驱赶后因为没有资源而处于 Pending 状态的状况。如果利用此时有大量申请进来，又因为没有足够的可用的 Pod 导致可用性异样。
  2. 另外，社区重调度器调用的 Kubernetes Evcition API 尽管会查看 PDB 确保在平安范畴内驱赶，然而家喻户晓，泛滥的 workload Controller 在公布和缩容场景都是通过间接调用 Delete API 的模式销毁 Pod，此时并不会被 PDB 限度。这就导致重调度时如果遇到上述场景，是很可能引发重大的稳定性问题。
  3. 咱们认为 Pod 腾挪不是一个简略的后盾自动化逻辑，有相当多的场景和用户冀望由人工染指手工迁徙 Pod，甚至冀望重调度时发动的主动迁徙申请应该被拦挡掉，通过审批决定是否执行。

Koordinator 基于 CRD 定义了一个名为 PodMigrationJob API。重调度器或者其余自动化自愈组件通过 PodMigrationJob 能够平安的迁徙 Pod。PodMigrationJob Controller 在解决 PodMigrationJob 时会先尝试通过 Koordinator Reservation 机制预留资源，预留失败则迁徙失败；资源预留胜利后发动驱赶操作并期待预留的资源被生产。两头的过程都会记录到 PodMigrationJobStatus 中，并产生相干的 Event。

咱们在 Koordinator 中实现了一个全新的 Descheduler Framework。咱们认为重调度场景：

  1. 须要一个插件化机制实现自定义的重调度策略，但又不心愿这个形象过于简单；
  2. 须要具备根本的插件治理能力，通过配置启用和禁用插件；
  3. 具备对立的插件配置下发机制，不便插件自定义参数；
  4. 并可能不便的扩大和应用对立的 Evictor 机制；
  5. 另外冀望用户可能基于 controller-runtime 实现 controller 并纳入对立的插件管理机制。

Koordinator descheduler framework 提供了插件配置管理（例如启用、禁用，对立配置等）、插件初始化、插件执行周期治理等机制。并且该框架内置了基于 PodMigrationJob 实现的 Controller，并作为 Evictor Plugin 不便被各种重调度插件应用，帮忙重调度插件平安的迁徙 Pod。

基于 Koordinator descheduler framework，用户能够非常容易的扩大实现自定义重调度策略，就像基于 Kubernetes scheduling framework 的实现自定义的调度插件一样简略。并且用户也能够以插件的模式实现 controller，反对基于 Event 触发重调度的场景。

Koordinator 的将来布局

Koordinator 社区将不断丰富大数据计算工作混部的状态，拓展包含 Hadoop YARN 等计算框架混部反对，丰盛工作混部解决方案，我的项目上继续的欠缺烦扰检测、问题诊断体系，推动更多的负载类型融入 Koordinator 生态，并获得更好的资源运行效率。

Koordinator 社区将继续的保持中立的发展趋势，联结各厂商继续的推动混部能力的标准化，也欢送大家退出社区独特推动混部的标准化过程。

退出移动版