美团集群调度系统云原生实践

介绍

集群调度系统在企业数据中心中发挥着举足轻重的作用。 随着集群规模和应用数量不断增加，开发人员处理业务问题的复杂度也显着增加。 如何解决大规模集群管理问题，设计优秀合理的集群调度系统，保证稳定性、降低成本、提高效率？ 本文将一一解答。

| 备注：文章首发于《新程序员003》云原生时代开发者专栏。

集群调度系统简介

集群调度系统又称为数据中心资源调度系统，一般用于解决数据中心的资源管理和任务调度问题。 其目标是有效利用数据中心资源，提高资源利用率，为业务提供自动化运维能力，降低服务运维管理成本。 业界知名的集群调度系统，如开源的OpenStack、YARN、Mesos、Kubernetes等，以及知名互联网公司的如Google的Borg、微软的Apollo、百度的Matrix、阿里巴巴的伏羲、ASI等。

集群调度系统作为互联网企业核心的IaaS基础设施，近十年来经历了多次架构演进。 随着业务从单体架构向SOA（面向服务的架构）演进以及微服务的发展河南调度服务器云空间，底层的IaaS设施也逐渐从裸机物理机时代走向容器时代。 虽然在演进过程中我们要处理的核心问题没有发生变化，但由于集群规模和应用数量的快速膨胀，问题的复杂度也呈指数级增长。 本文将阐述大规模集群管理的挑战和集群调度系统的设计思路，并以美团集群调度系统的实现为例，讲述如何通过创建多集群来不断提高资源的利用率。集群统一调度服务，并提供Kubernetes引擎服务赋能。 PaaS组件等一系列云原生实践以及为业务带来更好的计算服务体验。

大规模集群管理难点

众所周知，业务的快速增长带来了服务器规模和数据中心数量的激增。 对于开发者来说，在大规模集群调度系统的业务场景中，必须解决两个难题：

如何管理数据中心大规模集群的部署和调度，特别是跨数据中心场景，如何实现资源弹性和调度能力，在保证应用服务质量的同时尽可能提高资源利用率河南调度服务器云空间，充分减少数据量中心成本。 如何改造底层基础设施，为业务侧打造云原生操作系统，提升计算服务体验，实现应用的自动容灾响应和部署升级等，减轻业务侧的心理负担底层资源管理，让业务方更专注于业务本身。 运营大规模集群的挑战

为了解决实际生产环境中的上述两个问题，可以进一步分为以下四个大规模集群运行管理挑战：

如何解决用户的多样化需求并快速响应。 业务调度需求和场景丰富且动态。 作为集群调度系统这样的平台服务，一方面需要能够快速交付功能，及时满足业务需求； 将需求抽象为平台上可以实现的通用能力，并长期迭代。 这是对平台服务团队的技术演进规划的考验，因为一不小心，团队就会陷入无休止的业务功能开发中。 虽然满足了业务需求，但会造成团队工作的低级重复。 如何在保证应用服务质量的同时，提高线上应用数据中心的资源利用率。 资源调度一直是业界公认的问题。 随着云计算市场的快速发展，各云计算厂商不断加大对数据中心的投入。 数据中心的资源利用率非常低，这加剧了问题的严重性。 Gartner研究发现，全球数据中心服务器的CPU利用率仅为6%至12%，甚至亚马逊弹性计算云（EC2，弹性计算云）的资源利用率也仅为7%至17%，这表明资源浪费有多严重。 原因是在线应用对资源利用率非常敏感，业界不得不预留额外的资源来保证重要应用的服务质量（QoS，Quality of Service）。 集群调度系统需要消除多个应用程序混合运行时应用程序之间的干扰，实现不同应用程序之间的资源隔离。 如何为应用尤其是有状态应用提供实例异常的自动处理，屏蔽机房的差异，减少用户对底层的感知。 随着服务应用规模的不断扩大和云计算市场的成熟，分布式应用往往部署在不同地区的数据中心，甚至跨不同的云环境，实现多云或混合云部署。 集群调度系统需要为业务侧提供统一的基础设施，实现混合多云架构，屏蔽底层异构环境。 同时降低应用运维管理的复杂度，提高应用的自动化程度，为业务提供更好的运维体验。 如何解决单个集群过大或集群过多带来的集群管理相关的性能和稳定性风险。 集群本身生命周期管理的复杂度会随着集群规模和数量的增加而增加。 以美团为例，我们采用的两区域、多中心、多集群的解决方案，在一定程度上避免了集群过大的隐患，解决了业务隔离、地域延迟等问题。 随着边缘集群场景、数据库等PaaS组件云化需求的出现，可以预见，小型集群的数量将会有明显的上升趋势。 这带来了集群管理复杂度、监控配置成本、运维成本的明显增加。 这时集群调度系统需要提供更有效的运行规范，保证运行安全、告警自愈、变更效率。设计集群调度系统时的权衡

为了解决上述挑战，一个好的集群调度器将发挥关键作用。 但现实中，永远不存在完美的系统，所以在设计集群调度系统时，我们需要根据实际场景在几个矛盾之间做出选择：

集群调度系统的系统吞吐量和调度质量。 系统吞吐量是我们评价一个系统质量的重要标准，但在面向在线服务的集群调度系统中，调度质量更为重要。 由于每次调度结果的影响都是长期的（数天、数周、甚至数月），非异常情况不予调整。 因此，如果调度结果错误，将直接导致服务时延的增加。 调度质量越高，需要考虑的计算约束越多，调度性能越差，系统吞吐量越低。 集群调度系统的架构复杂性和可扩展性。 系统向上层PaaS用户开放的功能和配置越多，支持的提升用户体验的功能就越多（如支持应用资源抢占和恢复以及应用实例的自愈），这意味着系统复杂度也随之降低。越高，各个子系统就越容易发生冲突。 集群调度系统的可靠性和单集群规模。 单个集群规模越大，调度范围越大，但对集群可靠性的挑战也越大，因为爆炸半径会增大，故障影响也会更大。 在单集群较小的情况下，虽然可以提高调度并发度，但是调度的范围变小，调度失败的概率变高，集群管理的复杂度也变大。

目前业界的集群调度系统可以分为五种不同的架构：单级调度器、两级调度器、共享状态调度器、分布式调度器和混合调度器（见下图1）。 他们都是根据各自的场景需求做出了不同的选择，并没有绝对的好坏。

因此，如何评价一个调度系统的好坏主要取决于实际的调度场景。 以业界应用最广泛的YARN和Kubernetes为例。 虽然这两个系统都是通用资源调度器，但实际上 YARN 专注于短任务的离线批量处理，而 Kubernetes 专注于在线长时间运行的服务。 除了架构设计和功能上的差异（Kubernetes是单级调度器，YARN是两级调度器）之外，两者的设计理念和视角也不同。 YARN更注重任务，注重资源复用，避免远程数据的多副本。 目标是以更低的成本和更高的速度执行任务。 Kubernetes更注重服务状态，注重错峰、服务肖像、资源隔离，目标是保证服务质量。

美团集群调度系统的演进

在实施容器化的过程中，美团根据业务场景的需要，将集群调度系统的核心引擎从OpenStack更换为Kubernetes，并于2019年底完成了线上业务容器化覆盖率超额完成的既定目标98%。 但仍面临资源利用率低、运维成本高等问题：

因此，我们决定开始对集群调度系统进行云原生改造。 构建具有多集群管理和自动化运维能力的大规模高可用调度系统，支持调度策略推荐和自助配置，提供云原生底层扩展能力，在保证应用服务质量的同时提高资源利用率。 核心工作是围绕保证稳定、降低成本、提高效率三个方向构建调度系统。

最后，美团集群调度系统架构按照领域分为三层（参见上图2），调度平台层、调度策略层、调度引擎层：

通过精细化运营和产品功能打磨，一方面管理美团近百万个容器/虚拟机实例，另一方面资源利用率从行业平均水平提升至一流水平，同时支持PaaS组件容器化和云原生落地。

多集群统一调度：提高数据中心资源利用率

资源利用率是评估集群调度系统质量的最重要指标之一。 所以，虽然我们在2019年就完成了容器化，但容器化不是目的，而是手段。 我们的目标是通过从VM技术栈切换到容器技术栈，给用户带来更多的好处，比如全面降低用户的计算成本。

资源利用率的提升受到集群中单个热点主机的限制。 一旦扩容，业务容器就可能扩容到热点主机。 TP95耗时等业务绩效指标会出现波动，所以我们只能像行业内其他公司那样做。 通过增加资源冗余来保证服务质量。 原因是 Kubernetes 调度引擎的分配方式简单地考虑了 Request/Limit Quota（Kubernetes 为容器设置请求值 Request 和约束值 Limit，作为用户申请容器的资源配额），属于静态资源分配。 这样一来，虽然不同的主机分配了相同的资源，但由于主机的服务差异慈云数据自营海外云服务器,高稳定高性价比,支持弹性配置，导致主机的资源利用率存在较大差异。

在学术界和工业界，有两种常见的方法来解决资源使用效率和应用服务质量之间的冲突。 第一种方法是通过高效的任务调度器从全局角度来解决； 第二种方法是通过单机资源管理来加强应用程序之间的资源隔离。 无论使用哪种方法，都意味着我们需要全面掌握集群的状态，因此我们做了三件事：

第三版集群联邦服务（图3）按照模块拆分为Proxy层和Worker层，独立部署：

最后，通过多集群统一调度，实现了从静态资源调度模型到动态资源调度模型的转变，从而降低了热点主机的比例，减少了资源碎片的比例，保证了高质量的服务质量。商业应用程序。 平均CPU利用率提高了10个百分点。 集群资源利用率平均值的计算方法：Sum(nodeA.cpu.当前使用核心数+nodeB.cpu.当前核心数+xxx)/Sum(nodeA.cpu.总核心数+nodeB.cpu) .总核心数+xxx)，每分钟1分，当天所有值取平均值。

调度引擎服务：赋能PaaS服务云原生落地

集群调度系统除了解决资源调度问题外，还解决服务使用计算资源的问题。 《Google Software Engineering at Google》一书中提到，集群调度系统作为Compute as a Service的关键组件之一，既需要解决资源调度（从物理机拆解到CPU/Mem等资源维度），资源调度。 竞争（解决“吵闹的邻居”）还需要解决应用管理（实例的自动部署、环境监控、异常处理、保证服务实例数量、确定业务所需的资源量、不同类型的服务等）。 ）。 而且从某种程度上来说，应用管理比资源调度更重要，因为它会直接影响业务开发、运维和服务容灾的效率。 毕竟，互联网的人力成本高于机器成本。

复杂有状态应用的容器化一直是业界的难题，因为这些不同场景下的分布式系统通常会维护自己的状态机。 当应用系统进行扩容或升级时，如何保证现有实例服务的可用性以及如何保证它们之间的连通性是比无状态应用复杂和棘手的问题。 虽然我们已经容器化了无状态服务，但是我们还没有完全意识到一个好的集群调度系统的全部价值。 想要管理好计算资源，就必须对服务的状态进行管理，将资源与服务分离，提高服务的弹性。 这就是 Kubernetes 引擎所擅长的。

基于美团优化定制的 Kubernetes 版本，我们创建了美团 Kubernetes 引擎服务 MKE：

在推动云原生落地的过程中，一直被广泛关注的一个问题是：基于Kubernetes云原生的方式管理有状态应用与我们自己搭建一个管理平台有什么区别？

对于这个问题，我们需要考虑问题的根源——可操作性：

未来展望：打造云原生操作系统

我们相信云原生时代的集群管理将全面从以前管理硬件和资源的功能转变为以应用为中心的云原生操作系统。 围绕这一目标，美团集群调度系统需要重点关注以下几个方面：

总结

美团集群调度系统在设计时遵循整体适度的原则。 在满足业务基本需求的情况下，保证系统稳定，然后逐步完善结构，提高性能，丰富功能。 因此，我们选择：

未来我们将按照同样的逻辑不断优化和迭代美团的集群调度系统，彻底转型为以应用为中心的云原生操作系统。

关于作者

谭琳，美团基础研发平台/基础技术部。

手机扫描二维码访问