美团集群调度系统的云原生实践
总第487篇
2022年 第004篇
导语
集群调度系统介绍
大规模集群管理的难题
运营大规模集群的挑战
设计集群调度系统时的取舍
美团集群调度系统演变之路
多集群统一调度：提升数据中心资源利用率
调度引擎服务：赋能PaaS服务云原生落地
未来展望：构建云原生操作系统
导语
集群调度系统介绍
大规模集群管理的难题
如何管理好数据中心大规模集群部署调度，特别是在跨数据中心场景下，如何实现资源的弹性和调度能力，在保障应用服务质量的前提下尽可能地提升资源的利用率，充分降低数据中心成本。 如何改造底层基础设施，为业务方打造云原生操作系统，提升计算服务体验，实现应用的自动化容灾响应和部署升级等，减少业务方对底层资源管理的心智负担，让业务方可以更专注于业务本身。
运营大规模集群的挑战
如何解决用户多样化需求并快速响应。业务的调度需求和场景丰富且动态多变，作为集群调度系统这样的平台型服务，一方面需要能够快速交付功能，及时满足业务需求；另一方面还需要把平台打造得足够通用，将业务个性化需求抽象为可落地到平台的通用能力，并长期进行迭代。这非常考验平台服务团队的技术演进规划，因为一不小心，团队就会陷入无休止的业务功能开发中，虽然满足了业务需求，却会造成团队工作低水平重复的现象。 如何提高在线应用数据中心的资源利用率且同时保障应用服务质量。资源调度一直是业界公认的难题，随着云计算市场快速发展，各云计算厂商不断加大对数据中心的投入。数据中心的资源使用率却非常低，更加剧了问题的严重性。Gartner调研发现全球数据中心服务器CPU利用率只有6%～12%，即使是亚马逊弹性计算云平台（EC2，Elastic Compute Cloud）也只有7%～17%的资源利用率，可见资源浪费有多严重。究其原因，在线应用对于资源利用率非常敏感，业界不得不预留额外资源以保障重要应用的服务质量（QoS，Qualityof Service）。集群调度系统需要在多应用混合运行时消除应用间的干扰，实现不同应用之间的资源隔离。 如何为应用，特别是有状态应用提供实例异常自动处理，屏蔽机房差异，降低用户对底层的感知。随着服务应用规模的持续扩大，以及云计算市场的日趋成熟，分布式应用往往会配置在不同地域的数据中心，甚至是跨越不同的云环境，实现了多云或混合云部署。而集群调度系统需要为业务方提供统一的基础设施，实现混合多云架构，屏蔽底层的异构环境。同时降低应用运维管理的复杂性，提升应用的自动化程度，为业务提供更好的运维体验。 如何解决单集群过大或集群数量过多，而带来的与集群管理相关的性能和稳定性风险。集群本身的生命周期管理复杂度会伴随集群规模和数量的增多而增大。以美团为例，我们所采取的两地多中心多集群方案，虽然在一定程度上规避了集群规模过大的隐患，解决了业务隔离性、地域延迟等问题。随着边缘集群场景和数据库等PaaS组件上云需求的出现，可以预见小集群数量将会有明显的上涨趋势。随之带来的是集群管理复杂度、监控配置成本、运维成本的明显增加，这时集群调度系统需要提供更有效的操作规范，并保证操作安全性、报警自愈和变更效率。
设计集群调度系统时的取舍
集群调度系统的系统吞吐量和调度质量。系统吞吐量是我们通常评估一个系统好坏很重要的标准，但在面向在线服务的集群调度系统里更重要的是调度质量。因为每次调度结果的影响是长期的（数天、数周甚至数月），非异常情况不会调整。所以如果调度结果错误，会直接导致服务时延增高。而调度质量越高则意味着需要考虑的计算约束条件越多，而且调度性能越差的话，系统吞吐量越低。 集群调度系统的架构复杂度和可扩展性。系统对上层PaaS用户开放的功能和配置越多，通过支持更多功能来提升用户体验（比如支持应用资源抢占回收和应用实例异常自愈），也就意味着系统复杂度越高，各子系统越容易发生冲突。 集群调度系统的可靠性和单集群规模。单集群规模越大，则可调度范围则越大，但对集群的可靠性挑战也越大，因为爆炸半径会增加，出现故障的影响也越大。单集群规模较小的情况下，虽然可以提升调度并发度，但可调度范围变小，调度失败概率变高，且集群管理复杂度变大。
单体式调度器使用复杂的调度算法结合集群的全局信息，计算出高质量的放置点，不过延迟较高。如Google的Borg系统、开源的Kubernetes系统。 两级调度器通过将资源调度和作业调度分离，解决单体式调度器的局限性。两级调度器允许根据特定的应用做不同的作业调度逻辑，且同时保持了不同作业之间共享集群资源的特性，可是无法实现高优先级应用的抢占。具有代表性的系统是Apache Mesos和Hadoop YARN。 共享状态调度器通过半分布式的方式来解决两级调度器的局限性，共享状态下的每个调度器都拥有一份集群状态的副本，且调度器独立对集群状态副本进行更新。一旦本地的状态副本发生变化，整个集群的状态信息就会被更新，但持续资源争抢会导致调度器性能下降。具有代表性的系统是Google的Omega和微软的Apollo。 分布式调度器使用较为简单的调度算法以实现针对大规模的高吞吐、低延迟并行任务放置，但由于调度算法较为简单并缺乏全局的资源使用视角，很难达到高质量的作业放置效果，代表性系统如加州大学的Sparrow。 混合调度器将工作负载分散到集中式和分布式组件上，对长时间运行的任务使用复杂算法，对短时间运行的任务则依赖于分布式布局。微软Mercury就采取了这种这种方案。
美团集群调度系统演变之路
集群整体的资源利用率不高。如CPU资源平均利用率还处于业内平均水平，相较于其他一线互联网公司差距较大。 有状态服务的容器化率程度不够，特别是MySQL、Elasticsearch等产品没有使用容器，业务运维成本和资源成本存在较大的优化空间。 从业务需求考虑，VM产品会长期存在，VM调度和容器调度是两套环境，导致团队虚拟化产品运维成本较高。
保稳定：提升调度系统的健壮性、可观测性；降低系统各模块之间的耦合，减少复杂度；提升多集群管理平台的自动化运维能力；优化系统核心组件性能；确保大规模集群的可用性。 降成本：深度优化调度模型，打通集群调度和单机调度链路。从资源静态调度转向资源动态调度，引入离线业务容器，形成自由竞争与强控结合，在保障高优业务应用服务质量的前提下，提升资源使用率，降低IT成本。 提效率：支持用户自助调整调度策略，满足业务个性化需求，积极拥抱云原生领域，为PaaS组件提供包括编排、调度、跨集群、高可用等核心能力，提升运维效率。
平台层负责业务接入，打通美团基础设施，封装原生接口和逻辑，提供容器管理接口（扩容、更新、重启、缩容）等功能。 策略层提供多集群统一调度能力，持续优化调度算法和策略，结合业务的服务等级和敏感资源等信息，通过服务分级提升CPU使用率和分配率。 引擎层提供Kubernetes服务，保障多个PaaS组件的云原生集群稳定性，并把通用能力下沉到编排引擎，降低业务云原生落地的接入成本。
多集群统一调度：提升数据中心资源利用率
系统地建立了集群状态、宿主状态、服务状态的关联，并结合调度仿真平台，综合考虑了峰值利用率和平均利用率，实现了基于宿主历史负载和业务实时负载的预测和调度。 通过自研的动态负载调节系统和跨集群重调度系统，实现了集群调度和单机调度链路的联动，根据业务分级实现了不同资源池的服务质量保障策略。 经过三版迭代，实现了自有集群联邦服务，较好地解决了资源预占和状态数据同步问题，提升了集群间的调度并发度，实现了计算分离、集群映射、负载均衡和跨集群编排控制（见下图3）。
Proxy层会综合集群状态的因子及权重选择合适的集群进行调度，并选择合适的Worker分发请求。Proxy模块使用etcd做服务注册、选主和发现，Leader节点负责调度时预占任务，所有节点都能负责查询任务。 Worker层对应处理一部分Cluster的查询请求，当某集群任务阻塞，可以快速扩容一台对应的Worker实例缓解问题。当单集群规模较大时会对应多个Worker实例，Proxy将调度请求分发给多个Worker实例处理，提升调度并发度，并减少每一个Worker的负载。
调度引擎服务：赋能PaaS服务云原生落地
加强集群运维能力，完善了集群的自动化运维能力建设，包括集群自愈、报警体系、Event日志分析等，持续提升集群的可观测性。 竖立重点业务标杆，与几个重要的PaaS组件深入合作，针对用户的痛点如Sidecar升级管理、Operator灰度迭代、报警分离做快速优化，满足用户的诉求。 持续改进产品体验，持续优化Kubernetes引擎，除了支持用户使用自定义Operator之外，也提供了通用的调度和编排框架（见图4），帮助用户以更低的成本接入MKE，获得技术红利。
基于Kubernetes意味着系统做到了闭环，不用担心两套系统经常出现的数据不一致问题。 异常响应可以做到毫秒级别，降低了系统的RTO（Recovery Time Objective，即恢复时间目标，主要指所能容忍的业务停止服务的最长时间，也是从灾难发生到业务系统恢复服务功能所需要的最短时间周期）。 系统运维复杂度也降低了，服务做到了自动化容灾。除了服务本身之外，服务依赖的配置和状态数据都可以一起恢复。 相比于之前各个PaaS组件“烟囱式”的管理平台，通用能力可以下沉到引擎服务，减少开发维护成本，而通过依托于引擎服务，可以屏蔽底层异构环境，实现跨数据中心和多云环境的服务管理。
未来展望：构建云原生操作系统
应用链路交付管理。随着业务规模和链路复杂度的增大，业务所依赖的PaaS组件和底层基础设施的运维复杂度早已超过普遍认知，对于刚接手项目的新人更是难上加难。所以我们需要支持业务通过声明式配置交付服务并实现自运维，给业务提供更好的运维体验，提升应用的可用性和可观测性，减少业务对底层资源管理的负担。 边缘计算解决方案。随着美团业务场景的不断丰富，业务对边缘计算节点的需求增长，比预期快很多。我们会参考业内最佳实践，形成适合在美团落地的边缘解决方案，尽快为有需求的服务提供边缘计算节点管理能力，实现云边端协同。 在离线混部能力建设。在线业务集群的资源利用率提升是有上限的，根据Google在论文《Borg: the Next Generation》中披露的2019年数据中心集群数据，刨去离线任务，在线任务的资源利用率仅为30%左右，这也说明了再往上提升风险较大，投入产出比不高。后续，美团集群调度系统将持续探索在离线混部，不过由于美团的离线机房相对独立，我们的实施路径会与业界的普遍方案有所不同，会先从在线服务和近实时任务的混部开始，完成底层能力的构建，再探索在线任务和离线任务的混部。
总结
在系统吞吐量和调度质量中我们选择优先满足业务对系统的吞吐量需求，不过度追求单次调度质量，而是通过重调度调整完善。 在架构复杂度和可扩展性中我们选择降低系统各模块之间的耦合，减少系统复杂度，扩展功能必需可降级。 在可靠性和单集群规模中我们选择通过多集群统一调度来控制单集群规模，保障系统可靠性，减少爆炸半径。
作者简介
阅读更多