美团大规模容器集群降本增效实践

本文整理自美团集群调度系统负责人谭霖在 QCon 2022 北京站的演讲分享，主题为“大规模容器集群降本增效实践”。

随着 Kubernetes 广泛应用，越来越多公司基于 Kubernetes 落地集群调度系统。在集群规模增长同时，社区方案局限性也逐步体现，集群规模受限和只支持按照资源配额调度等问题日渐凸显。其中，资源配额调度问题又是制约集群资源利用率提升的最大痛点。

本文将从真实业务场景出发，讲述如何通过落地动态负载均衡服务，实现动态实时调整容器资源实例，解决资源配额调度问题带来的集群内物理机负载不均衡的问题，并保障业务服务质量，充分实现云计算成本优化。

今天我将分享四个主要内容。第一个主题是在线集群调度，我将介绍它的核心挑战以及为什么各个大型企业都需要投入大量人力去解决这个复杂的问题。第二个主题是美团系统 LAR，它专门解决应用资源利用率提升的问题，并且已经在我们的实际落地中得到了应用。第三部分将分享在线集群调度的运营实践。最后一部分分享集群调度的演进思考。

在线集群调度的核心挑战

集群调度领域介绍

在线集群调度系统又叫做数据中心资源调度系统，目标是将离散和异构的服务器整合到一个弹性资源池中，以提高数据中心的资源利用率，并为业务方提供自动化的运维能力。通过网络和存储系统，我们可以根据业务需求动态地分配计算实例，从而降低整体计算成本。

如右图所示，我们将服务器整合成一个弹性资源池，并与网络和存储结合，例如像快存文件存储， vxlan 大二层网络等技术。最后，我们可以按需为业务分配计算实例，并通过集群的规模效应降低公司的计算成本。

集群调度的挑战与困难

至于集群调度系统，它的复杂性体现在哪些方面呢？首先，随着云原生化、微服务化和容器化趋势的普及，所有业务的容器都需要在集群调度系统的管控下运行。在这种情况下，确保整个应用的服务质量是至关重要的。同时，我们也面临着一个巨大的挑战，即如何在保证服务质量的同时提高资源利用率，以降低公司的成本。因此，需要在这两个方面之间找到一个平衡点。

其次，在美团我们有外卖、酒旅、优选等各种业务，每个业务都有其个性化的调度需求。为了快速满足他们的需求，同时不阻塞迭代过程，我们需要以一个高效的方式为其提供服务。

还需要解决的问题是，有状态服务如数据库 RDS 或 KV 存储进行云原生化改造。与无状态服务相比，这些有状态服务的状态机复杂，无法像无状态服务一样快速扩容或销毁。因此，我们需要提供自动化变更和异常处理的能力，以解决这些挑战，这也是集群调度需要解决的问题之一。

今天我们的重点会关注成本，也就是如何在提高在线集群资源利用率和同时保障应用服务质量上做出一些工作。

行业资源利用率水平

2020 年全球数据中心的服务器总量达到 1800 万台，并且正以每年 100 万台的速度增长。 统计数据表明，目前全球数据中心资源利用率仅为 10%~20%，如此低的资源利用率意味着数据中心大量的资源浪费，导致目前数据中心的成本效率极低。

这么低的资源利用率意味着什么呢？它意味着如果您购买了一个 64 核的服务器，实际上可能只有 6.4 核被平均使用，最多只有 10 核。这意味着我们的成本或产出在财务上没有得到充分利用。

美团业务特征

美团的外卖业务，特别是在午高峰和晚高峰时间点，在线需求呈现出非常明显的双峰特征。对于这样的业务，我们分配给它的资源在时间和空间维度上都存在相当程度的闲置。如何充分利用这些资源是一个非常关键的问题。

资源利用率提升难点

资源利用存在一个关键的矛盾：对于在线服务来说，一台物理机上的资源是有限的，特别是对于共享资源，例如 CPU、内存、磁盘 IO、网络 IO 以及末级缓存，它们的使用会相互干扰。这在离线环境中可能会好一些，但在线服务的情况特别明显，这使得服务质量非常容易受到影响。如果我们提高资源利用率水平，但服务质量不能得到保证，那么一切都是有问题的。

这里是在实际生产环境中，我们经常遇到的一些高频问题。第一个是热点宿主的问题。尽管集群利用率可能不是特别高，但我们通常会发现一些物理机或宿主机的利用率较高，并成为整个集群利用率的瓶颈。如果我们扩容到这些热点宿主上，就会出现服务质量问题，导致很多业务不再希望我们扩容。

第二个场景涉及到集中调度。之前我提到的是以集群维度为维度，但是现在我们要切换到业务维度。如果某个业务实例出现了问题，那么它可能会被调度到某个特定的宿主机或者交换机下面，一旦出现硬件故障，这会给业务带来非常大的影响。尽管我们现在采用的是多实例的方式，但如果出现了 10%、20%或者 30%的实例故障或损坏，那么业务依然难以承受。

第三个场景，即资源抢占的问题。业务肯定都有核心链路和非核心链路，或者我们称之为旁路。在调度时，我们通常没有明确区分核心链路和非核心链路，因此很可能会将它们调度在同一台机器上。这可能会导致核心链路和非核心链路之间的资源冲突，甚至可能出现非核心链路占用资源来抢核心链路的情况。这些问题在我们的实际生产环境中经常出现。

问题根因：原生调度能力无法满足大规模调度需求

这个问题的根本原因是什么呢？实际上，尽管大家现在都使用 Kubernetes 作为集群调度系统，但它本质上还是不够完善的，无法满足大规模场景下的某些问题。具体而言，首先在大规模调度中有一些非常重要的问题，例如打散需求。就像刚才所说的，我们的服务需要按照故障域进行分布，而故障域可能会涉及到宿主机、交换机、IDC，甚至是 Region 等概念。为了满足这些需求，我们需要考虑服务和服务之间以及服务内部的一些亲和性和反亲和性的调度需求。此外，在容量需求方面，为了确保业务的可用性，业务往往会申请冗余资源。但是，我们应该如何尽可能地减少这些冗余资源呢？因为如果每个业务都有 20% 的冗余，那么整个成本将会非常高。另外，从集群本身来看，业务可能会出现突然增长的需求，因此我们需要保障一定的容量，以满足业务整体弹性的需求。

综上所述，当前的集群调度系统存在以下几个问题。第一，集群调度系统存在资源水位失真的问题。我们仍然按照业务申请的资源数量进行分配，而没有考虑实际负载情况。这也是问题一的根因。第二，单个集群始终存在局限性，尽管规模可能达到四五千台，但当资源水位上升时，我们依然会发现在单个群集中无法找到合适的宿主机。第三，优先级不区分的问题，这不仅存在于集群调度中，也存在于内核单机层面。例如，资源能力、隔离能力不足以及内存溢出后的不可控等问题。目前业内通常只能通过资源冗余来保证服务质量，但这也带来了成本较高、利用率偏低的问题。

解决方案：全局视角下的精细化管控

在美团，我们的解决方案是在全局视角下进行精细化管控，以解决整个调度均衡的问题。我们通过掌握集群的实际负载数据，实现全局调度。同时，我们通过提升单机资源隔离能力，实现资源化管控。具体来说，我们采用了多层多集群的维度，但对业务进行屏蔽，并在单集群维度上增强了调度器和优化调度策略。此外，我们还提升了节点和内核的隔离能力。最后，集群运营数据中心帮助我们收集集群和服务的状态数据，并为我们提供数据支持。

集群负载自动管理系统 （ LAR ，Load Auto Regulator） 落地实践

下面我将详细介绍美团落地的一个集群负载自动管理系统——Load Auto Regulator（LAR）。 LAR 主要作用在单机层面，可以解决 Kubernetes 默认将单机资源按照业务申请分配 quota 的问题。由于容器的 quota 维度相对有限，当所有容器一起增强整体单机资源时，很容易导致服务质量无法保障。此外，从业务角度来看，对 quota 是否合理也难以评估。因此，就会出现业务申请多少，我们给多少。

LAR 的核心思路并不复杂。我们将单机资源按照优先级分为多个资源池，包括高、低优先级和离线资源池等。然后，我们将业务容器归属到不同的资源池，以平衡服务质量和成本。由于业务负载是动态变化的，因此在分配资源池资源时，我们支持动态流动的过程。如果某个资源池的资源过剩或不足，将导致资源浪费或短缺。

举个例子：资源池 CPU 资源变化

例如，如果我们有一个单机 64 核和两个 Numa 服务器，我们会将其分为三个资源池，包括高优先级的核心业务资源池（Pool 0），普通在线业务资源池（Pool 1）和离线业务资源池（Pool 2）。

可以看到，最开始的 Pool 0 有 12 核，Pool 1 有 20 核，Pool 2 有 32 核。随着在线业务负载的增加，我们优先减少离线业务资源池的容量。因此，核心业务资源池有了 16 核，普通在线资源池使用了 34 核，离线资源池缩减为 24 核。

集群负载自动管理系统架构

上图是我们 LAR 的整体架构，它是基于 Kubernetes 原生架构进行的研发和扩展。如整体架构所示，在 Kubernetes 的基础上，一方面修改和扩展了 Scheduler 和 Controller，同时还新增了两个功能模块，分别是 Recommender 和 QosAdapter。总体而言，我们的产品分为三个核心模块，分别是分级资源池调度 Scheduler；Recommender 负载分析预测；以及 QosAdapter，它的作用是保证服务质量。接下来，我将详细介绍这些功能模块的工作原理。

核心概念 1：分级池化资源

首先是分级池化资源。我们将单节点的资源池分为 0、1、2 三类资源池，每个池子的优先级依次降低。每个池子都会部署多个容器实例。例如，在图中，我们一开始有 8 个容器。当发现有空闲资源时，我们会给 Pool 2 增加一些资源并且调度离线容器上来。

核心概念 2：动态资源视图

我们有一个动态资源视图。从 schedule 的层面，它不再只是一个单机，例如，64

 个资源可以被看作是 3 个资源池，每个资源池都对应一些资源。因此，在调度时，可以按需进行调度。我们有一些策略，例如，所有资源池类分配资源之和是整个节点的可用资源。如图所示，当负载升高时，我们会向下抢占低优先级的资源。当负载降低时，我们会把闲置的资源提供给低优先级的资源去复用。

核心概念 3：QoS 服务质量保障机制

我们还有一个 QoSAdapter，它的主要作用是服务质量保障。我们现在主要关注的是 CPU、Memory、磁盘 IO 和网络 IO 资源。我们通过一些调整手段，在 CPU 上进行配额、调度优先级和 CPU 绑核等操作；在 Memory 上，我们用容量 OOM Score 来调整进程，还利用 Cgroup V2 提供的能力，基于此做了 Memory 带宽的限制。但是，我们还发现 OOM 不太可控，所以我们落地了 Memory 提前回收的机制。在磁盘上，我们正在实施包括磁盘的限速调度算法等措施。在网络上，我们也有带宽限速和带宽共享，通过 quota 限制。

再举个例子：容器负载异常处理策略

最后，作为兜底方案，我们还有容器驱逐策略。举例来说，在右侧的图中，其主要工作原理是通过 cadvisor、node-exporter 等监控来源，收集整个宿主和容器的负载情况。然后，我们会使用各种策略进行计算，例如资源释放、资源抢占，以及强制抢占、CPU 降级甚至 pod 驱逐等策略。接下来，我们会将这些策略下发给操作系统，以保证服务质量。

核心概念 4：基于负载预测资源用量

接下来，会再详细介绍一下 Recommender 的具体工作。它的主要任务是：在每天凌晨，根据历史负载进行预测计算，包括宿主、服务和容器层面。此外，在每次调度之前，我们会实时进行负载校准，每 10 秒一次。根据调度策略，我们将其下发到每个宿主机 Kubernete node 等，并在进行调度时使用这些策略，以提高资源池资源保障的稳定性。

LAR 落地效果

让我们来看一下 LAR 的实际效果。橙色部分表示非 LAR 集群的资源利用率情况，而蓝色则是 LDR 的整体利用率情况。可以看到，通过使用 LDR，我们的日均利用率提高了近 10 个百分点，效果非常显著。

在线集群调度的运营实践

虽然刚才我们讲了很多技术上的细节，但实际上集群调度还是一个重运营工作。因此，接下来我想分享一些集群调度的运营实践。

资源运营模型

在我的理解中，我把资源利用率这个模型进行了拆解，因为我们不仅要关注业务使用情况，还要更细致地看待资源的组成部分。当然，业务使用资源是分子中最重要的一部分。但实际上，分母还包括分配给业务但未被使用的资源以及未分配出去的资源。除此之外，系统损耗和兜底资源也是分母的组成部分。

为了提升资源利用率，我们需要准确地了解这些资源的成本和使用情况。只有这样，我们才能通过技术和运营手段提升资源调度能力。因此，我们建立了一个运营大盘，包括业务端到端成本、业务配额利用率、集群利用率、数据分配率数据和碎片率数据等。

又又举个例子：集群资源运营挑战

举个例子，很多公司在管理集群节点资源时都需要进行预算提报。然而，预算提报往往依赖于经验和估计，特别是在当前情况下，很难做到精准预测。因此，仅仅将业务上报的预算加和获得总量往往会导致与实际使用情况偏差较大。

在我看来更合理的方式是什么呢？第一，我们希望缩短预算周期，因为按年计算很难准确估算。第二，我们需要对业务的实际使用资源进行预测，并监控实时资源水平，以便进行动态释放和回收。举个例子，如果您使用公有云，最好的方法可能是将闲置资源退还给云服务提供商。在美团这样的私有云环境中，我们可以在不同的业务之间进行资源调配，并向搜索推荐等业务提供闲置资源，因为资源越多，精度就越高。

集群运营数据中心（Cluster Pulse）

对于美团这样的私有云环境，我们需要及时反馈给供应链，以调整采购计划。因此，我们的关键在于建立一个集群运营数据中心，将资源成本和服务质量的数据运营体系化。

通常我们在监控业务时会看到业务数据或基础设施数据。我们的目标是将集群、容器、数组和业务的数据进行一体化，以便向下钻取到特定容器的利用率和资源情况。我们可以将这些数据汇聚到一个结算单元中，例如在美团可能是一个较大的业务单元，以更好地分析业务实际使用资源情况，以及是否存在资源闲置问题。通过这些数据支持，我们可以制定一些以服务质量为优先的个性化调度策略，包括基于负载的一次调度和二次调度等。我们的整体流程如右图所示：首先分析数据，然后优化调度策略，以便更好地管理整个集群状态。

运营指标大盘

我们还有一个运营指标大盘，其中包括资源碎片率、分配率和利用率等。在图右侧，我们还包括了一些重调度、资源缓冲池和业务 Appkey 打散等情况。这里面的内容还有很多，就不详细展开了。

在线集群调度的演进思考

集群调度器核心逻辑

在我看来，集群调度本质上是一个数据驱动的决策过程。如何获取高质量的数据非常关键，这对于提高集群利用率至关重要。但是，这不仅仅是集群调度可以解决的，它还需要与系统内核和服务可观测性等多个维度进行深度协同建设。

在线集群调度能力

如何构建一个优秀的在线集群呢？我认为可以分为以下几个步骤。首先，我们可以基于历史负载进行一定的超卖。其次，像我之前提到的，我们可以根据服务优先级对应用进行分类，并引入动态资源调整机制。第三，与硬件和软件相结合的能力一起获取服务信息。例如，利用 eBPF 分析微服务，或者使用 CPI 来分析服务是否受到干扰。第四步是离线混部。我们需要创建立统一的资源视图，以更好地规划公司的整体资源。第五步，我们需要预测集群和服务资源的需求，并充分利用公有云的资源。

集群调度待解决的需求

接下来，我认为需要解决以下几个紧迫问题。首先是裸金属容器和虚拟机的融合。虽然在公有云中，容器普遍嵌套在虚拟机内，但在美团这样的私有云场景中，虚拟化需求仍然存在。我们不能将所有实例迁移到容器中。因此，我们需要同时提供虚拟机和容器场景，并解决这个问题。在美团，我们之前使用 OpenStack 来管理虚拟机，使用 Kubernetes 来管理容器。但由于这两套系统都是我们团队负责的，我们发现在整个行业降本增效的趋势下，使用两套系统来管理成本非常高，无论是管理成本还是资源成本。因此，我们现在正在尝试将虚拟机和容器统一纳管到 Kubernetes 中。

其次，我们需要解决的是边缘场景的需求。美团正在探索边缘场景的业务，但是与中心机房相比，边缘场景面临更多的限制，比如弱网，宿主机规模较小等，我们需要解决这些挑战。

第三个问题是，国家正在推广东数西算。一旦这个项目真正落地，我们将面临大量跨机房、跨地域的数据同步。目前，专线成本非常高，我们需要减少跨地域机房的数据同步，并充分利用西部地区的资源，为我们的在线机房提供可用资源，以降低成本。

这些是我们要持续探索的问题，我希望可以与大家分享这些热门研究领域的话题。谢谢大家！

相关阅读：

亚马逊 CEO：我们将重视“降本增效”

多云之下，京东云的降本增效之道