アリババから生まれ、Double 11を何年にもわたって磨き上げた後、毎年数十億ドルを節約するコロケーションシステムであるKoordinatorは、正式にオープンソースであることを本日発表しました。オープンソースを通じて、業界全体により良いコロケーションおよびスケジューリング機能を提供し、企業のお客様がクラウドネイティブワークロードの効率、安定性、およびコンピューティングコストを改善できるようにしたいと考えています。
混合部門とは何ですか？
業界の多くのインターネット企業は、さまざまな特性とタイプのワークロードを共同でスケジュールするという技術的な方向性を持っており、負荷間のピークシェービングとバレーフィリングの効果を最大限に活用して、ワークロードをより安定、効率的、コスト的にします-効果的。リソースを使用する。このようなシステムまたはメカニズムは、業界でよく言及される「コロケーション」の概念です。
アリババのミックス：
アリババは2011年にコンテナ技術の調査を開始し、2016年にコロケーション技術の研究開発を開始しました。技術アーキテクチャのアップグレードを数回行った後、最終的に今日のクラウドネイティブのコロケーションシステムアーキテクチャに進化し、フルサービス規模を達成しました。クラウドネイティブコロケーションのクラウドネイティブコロケーションでは、コロケーションの1日あたりの平均CPU使用率は50％を超えており、Alibabaは多くのリソースコストを節約できます。コワーキングは、インターネット企業内に構築されたコスト管理コアであり、ビジネスの抽象化とリソース管理の考え方と最適化の経験を数多く蓄積してきました。したがって、コワーキングは通常、徐々に安定して生産価値を生み出すために数年の磨きの練習が必要です。 。すべての企業は、コロケーションを使用するために高いしきい値を必要とし、価値を生み出すために多くの投資を必要としますか？次に、コーディネーターに答えてもらいます。
Koordinatorは、社内の超大規模コロケーション制作の実際の経験に基づいており、クラウドネイティブシナリオのユーザーにとって、アクセスコストが最小でコロケーション効率が最高のソリューションを作成し、ユーザー企業が継続的な配当を達成できるようにすることを目的としています。クラウドネイティブの後にリリースします。
コーディネーターとは何ですか？
コーディネーター：コーディネーターから引用したK for Kubernetesは、同じように発音します。セマンティクスは、プロジェクトによって解決される問題に適合します。プロジェクトは、Kubernetesクラスター内のさまざまなタイプのワークロードを調整および調整して、クラスターとノード上で最適なレイアウトと姿勢で実行されるようにします。
グーグルは、コンテナのコロケーションを行う最初のシステムであるボーグと呼ばれるスケジューリングシステムを持っています。それは、論文が発表される前は、業界で非常に不思議な存在でした。クラウドネイティブのコンテナスケジューリングおよびオーケストレーションシステムKubernetesは、Borgの設計アイデアに触発され、クラウド時代のアプリケーションオーケストレーションのニーズに基づいてBorgシステムの設計者によって再設計されました。
Kubernetesの優れたスケーラビリティにより、さまざまなワークロードに適応できるため、ユーザーはワークロードの日常の運用と保守の効率を解決できます。
Koordinatorは、Kubernetesの標準機能に基づいて完全に拡張され、クラスターとノードのシナリオにおける混合ワークロードのスケジューリング、ランタイムパフォーマンス、および安定性の課題を解決することに専念しています。このプロジェクトには、洗練されたリソーススケジューリング、タスクスケジューリング、差別化されたSLOの3つの主要なブロックを含む、混合ワークロードオーケストレーションのソリューションの完全なセットが含まれています。達成するためのそのような一連のソリューションを通じて：
- エンタープライズユーザーがKubernetesへのより多くのワークロード、特にビッグデータとタスク処理に関連するワークロードにアクセスできるようにし、運用効率と安定性を向上させます
- オープンソースの技術標準を通じて、企業ユーザーがクラウドの内外で一貫した技術アーキテクチャを実現し、運用と保守の効率を向上させるのを支援します
- エンタープライズユーザーがクラウドリソースを合理的に利用し、クラウド上で持続可能な開発を実現できるように支援します
Koordinatorの利点は何ですか？
コロケーションには、完全で自己クローズのスケジューリングループが必要ですが、エンタープライズアプリケーションのコロケーションのプロセスで直面する2つの主要な課題は次のとおりです。
- コロケーションプラットフォームにアプリケーションにアクセスする方法
- プラットフォーム上でアプリケーションを安定して効率的に実行する方法
Koordinatorは、Alibabaの社内生産実務の経験と教訓から長年学び、企業が技術的な力を発揮するのではなく、混合部門とKubernetesを実際に使用できるようにすることを目的として、これら2つの課題のソリューションを設計しました。
Koordinator 1.0の全体的なアーキテクチャを次の図に示します。これは、同じ場所に配置されたワークロードオーケストレーション、同じ場所に配置されたリソーススケジューリング、同じ場所に配置されたリソースの分離、パフォーマンスチューニングのための完全なソリューションをユーザーに提供し、ユーザーがレイテンシーのパフォーマンスを向上させるのに役立ちます。機密性の高いサービスとアイドル状態のリソースの活用ノードリソースは、本当に必要なコンピューティングタスクに割り当てられるため、全体的なリソース使用効率が向上します。
超大規模生産の実務経験
2021年のダブル11の後、アリババは「初めて！アリババのダブル11ビジネスを完全にサポートするために統合ディスパッチングシステムが大規模に実装されました」と発表しました。
作为阿里巴巴的核心项目，阿里云（容器团队和大数据团队）联合阿里巴巴资源效能团队、蚂蚁容器编排团队，历时一年多研发和技术攻坚，实现了从“混部技术”到今天“统一调度技术”的全面升级。
今天，统一调度已实现阿里巴巴电商、搜推广、MaxCompute 大数据的调度全面统一，实现了 pod 调度和 task 高性能调度的统一，实现了完整的资源视图统一和调度协同，实现了多种复杂业务形态的混部和利用率提升，全面支撑了全球数十个数据中心、数百万容器、数千万核的大规模资源调度。
作为云原生混部的践行者，阿里巴巴是真刀真枪的在生产环境中推进混部技术理念，并在去年双 11 完成了超过千万核的混部规模，通过混部技术帮助阿里巴巴双 11 节约超过 50% 的大促资源成本，在大促快上快下链路上提速 100%，助力大促实现丝滑的用户体验。
回头去看，阿里巴巴坚定的推进混部技术，主要是考虑到以下方面带来的问题：
• 利用率不均衡：在非混部时代，几大资源池之间的资源利用率不均衡，大数据资源池利用率极高长期缺乏算力，而电商资源池日常利用率比较低，空闲了大量的计算资源，但出于灾备设计又不能直接下掉机器提高在线密度。混部的初衷是让全局资源调度更合理，在日常态通过混部将大数据的任务调度到电商资源池中，充分利用这部分空闲的资源。
• 大促备战效率低：在大促时为了减少大促资源采购，希望在大促时能够借用大数据资源池，部署电商任务支撑流量洪峰同时。在非混部时代，这样的弹性资源借用只能通过腾挪机器的方式推进，大促支持的效率较低很难大规模实施。
正是在双 11 这样的峰值场景驱动之下，阿里的混部调度技术持续演进，积累了大量的生产实践经验，到今天已经是第三代即云原生全业务混部系统。这样一套基于云原生理念的混部技术解决方案，脱胎于阿里巴巴，希望通过开源社区辐射到整个行业，帮助企业在云原生容器调度方向上加速快跑。
聚焦混部技术，支持丰富的场景
混部是一套针对延迟敏感服务的精细化编排+大数据计算工作负载混合部署的资源调度解决方案，核心技术在于：
-
精细的资源编排，以满足性能及长尾时延的要求，关键点是精细化的资源调度编排策略及 QoS 感知策略
-
智能的资源超卖，以更低成本满足计算任务对计算资源的需求，并保证计算效率的同时不影响延迟敏感服务的响应时间
上图是 Koordinator 混部资源超卖模型，也是混部最关键最核心的地方。其中超卖的基本思想是去利用那些已分配但未使用的资源来运行低优先级的任务，如图所示的四条线分别是：
-
limit: 灰色，高优先级 Pod 申请的资源量，对应 Kubernetes 的 Pod request
-
usage: 红色，Pod 实际使用的资源量，横轴是时间线，红线也就是 Pod 负载随时间的波动曲线
-
short-term reservation: 深蓝色，是基于 usage 过去一段时间（较短）的资源使用情况，对其未来一段时间的资源使用情况的预估，reservation 与 limit 之间也就是已分配未使用（预估未来一段时间也不会使用）的资源，可以用于运行短生命周期批处理任务
-
long-term reservation: 浅蓝色，类似于 short-term reservation 但预估使用的历史周期较长，从 reservation 到 limit 之间的资源可用于较长生命周期的任务，其可用资源相比 short-term 更少但稳定性更高
这一套资源模型支撑了阿里巴巴内部全业务的混部，足够精炼的同时也具备很强的灵活性。Koordinator 整个混部资源调度的大厦构建在这样一个资源模型的基础之上，配合上优先级抢占、负载感知、干扰识别和 QoS 保障技术，构建出混部资源调度底层核心系统。Koordinator 社区将围绕这个思路投入建设，持续将混部场景的调度能力展开，将阿里巴巴内部丰富场景支持的经验输出到社区，解决企业面临的真实业务场景问题。
双零侵入，超低接入成本
企业接入混部最大的挑战是如何让应用跑在混部平台之上，这第一步的门槛往往是最大的拦路虎。Koordinator 针对这一问题，结合内部生产实践经验，设计了“双零侵入”的混部调度系统。
第一个零侵入，是指对 Kubernetes 平台的零侵入。行业内的人大多知道，将 Kubernetes 应用于企业内部的复杂场景混部时，因为这样或者那样的原因总是需要对 Kubernetes 做一定量的修改，特别是节点管理（Kubelet）部分，这部分修改本身具备较大的技术门槛，同时也为给后续的 Kubernetes 版本升级带来巨大的挑战。企业为了解决这一问题，往往需要专门的团队来维护这一些定制化的修改，并且具备很大的沉默成本，等到线上出现问题或者需要升级新版本时，熟悉这份修改的同学可能已不知去向。这给企业带来了很大的技术风险，往往让混部技术的推广受阻。而 Koordinator 混部系统，设计之处即保证了不需要对社区原生 Kubernetes 做任何修改，只需要一键安装 Koordinator 组件到集群中，不需要做任何配置，既可以为 Kubernetes 集群带来混部的能力。同时，在用户不启用混部能力时，不会对原有的 Kubernetes 集群有任何形式的打扰。
第二个零侵入，是指对工作负载编排系统的零侵入。想像一下，在企业内部的 Kubernetes 集群之上提供混部能力之后，将面临的问题是如何将企业的工作负载接入进来，以混部的方式运行。一般情况下将会面临的两种情况是：
-
工作负载具备企业私有运维特性，由平台或运维团队的系统管理这些工作负载的日常升级发布、扩容缩容，而企业推进混部的容器或 SRE 团队与平台运维团队之间，存在着组织的鸿沟（或大或小），如何推动平台团队改造工作负载管理机制，对接混部的协议，也是一个不小的挑战。
-
工作负载以原生的 Deployment/StatefulSet/Job 的方式管理，对其 Kubernetes 内部的设计实现或改造成本超出了团队的预期，也将成为推行混部的挑战。
Koordinator 针对应用接入层的改造成本，设计了单独的工作负载接入层（Colocation Profile），帮助用户解决工作负载接入混部的难题，用户只需要管理混部的配置（YAML）即可灵活的调度编排哪些任务以混部的方式运行在集群中，非常的简单且灵活。当前 Koordinator 为用户提供了混跑 Spark 任务的样例，未来，社区将持续丰富工作负载接入层的特性，支持更多场景的零侵入接入。
云上、云下一致的用户体验
Koordinator 开源项目是阿里巴巴云原生 2.0 的重点战役，用户除在自己的环境中可以体验到 Koordinator 混部带来的技术红利，也可以将其部署到任意一个云厂商中，保持混合云、多云的架构一致。当然，也可以在阿里巴巴提供的多款云产品中获得一致的用户体验，一次设计对接多处发挥价值。
可以看到，除了支持内部超大规模的业务混部外，Koordinator 也是阿里云容器服务集成的解决方案，社区将持续的保持活力，致力于将混部变成平民化、通用化、标准化的技术能力。
为什么要开源？
最早做容器混部的是 Borg， 在 Google 内部运行超过 15 年，最新公开的资料是 Borg: the next Generation[1]。国内互联网公司内部推进混部接近 10 年，其中阿里巴巴的混部技术也经历过了 3 代技术架构升级变迁，最终走到全局混部的终极形态。混部帮助阿里巴巴的电商、搜索、大数据业务极大的提高了大促的备战效率，也为历年的双 11 大促节省了大量的计算资源。
我们坚信，云原生混部是企业容器调度技术发展的必然方向，只有通过工作负载的混合编排，才能在业务多可用区灾备架构下实现更好的资源利用效率，才能充分的发挥不同类型负载的削峰填谷效应，从而完全的发挥出计算资源潜力，最大化释放云计算的价值。
Koordinator 的开源，希望让更多的企业能够看见并用上云原生混部的能力，帮助企业加速云原生化的过程。在技术上，Koordinator 能够帮助企业实现更多的负载能够接入到 Kubernetes 平台，丰富容器调度的工作负载类型，继而发挥出工作负载错峰分时的特征，从而实现效率、成本上的收益，保持长期可持续发展的健康形态。
当前，Koordinator 已经支持了 Spark 任务场景的混部，同时也提供了低成本接入混部的解决方案，期待看到你的混部应用案例，听到你的反馈！未来，Koordinator 社区将持续的丰富混部的场景及业务形态，支持 Flink、Hadoop、AI Jobs、音视频任务等，尽情期待。
加入 Koordinator 社区
你是否正在规划或者正在实施提升 Kubernetes 集群的资源利用率的项目？
你是否正在头痛 Kubernetes 集群上 Pod 的运行时资源稳定性、性能调优的问题？
你是否正在经历云上、云下调度体系不一致带来的多倍复杂性？
非常欢迎你通过 Github/钉钉/微信 等方式接入我们来参与 Koordinator 开源社区，我们期待听到你的声音：
Github 地址： github.com/koordinator…
加入社区 Slack channel（English）： koordinatorgroup.slack.com/archives/C0…
欢迎扫描下方二维码或搜索群号 33383887（中文）加入 Koordinator 社区钉钉群！
相关链接
[1]Borg: the next Generation research.google/pubs/pub490… 发布云原生技术最新资讯、汇集云原生技术最全内容，定期举办云原生活动、直播，阿里产品及用户最佳实践发布。与你并肩探索云原生技术点滴，分享你需要的云原生内容。
关注【阿里巴巴云原生】公众号，获取更多云原生实时资讯！