通用集群管理：弹性扩缩容在eBay的实现和落地

01

云端弹性能力

PART1.

在讨论云端的弹性能力时，不得不提Kubernetes的HPA（Horizontal Pod Autoscaler），它允许根据实时监控指标自动调整工作负载的规模。HPA的运算公式如下：

该公式中  是HPA计算得出的期望副本数。Kubernetes的HPA控制器会定期利用这个公式来调节Deployment或任何支持scale子资源的工作负载的副本数量，目的是使得当前指标值（例如CPU使用率或用户定义的其他指标）接近或达到用户设定的期望指标值，从而实现副本数的自动调整。

HPA还支持配置多种精细化的弹性策略，例如稳定窗口和步进窗口等，这些策略可以帮助用户实现更加细致和控制性的扩缩容行为，以适应不同的业务需求和性能目标。

在eBay的云环境中，工作负载管理面临的挑战超出了Kubernetes单集群的能力范围。虽然HPA在单个Kubernetes集群内提供弹性扩缩容，但eBay的许多应用，尤其是那些需要高可用性的托管应用，要求实现跨地域的多活部署来满足灾难恢复需求。

eBay的云基础架构与公共云服务类似，分布在三个数据中心，每个数据中心包含多个可用区，每个可用区又有数个集群。为了适应这种复杂的分布式环境，eBay采用了特定的自定义资源来管理跨集群的应用部署和服务：

• Federated Deployment：负责管理跨多个集群的应用部署。它允许一致地更新和扩展应用的版本和副本，确保在不同集群之间实现同步和一致性。

• Access Point：负责管理跨多个集群的服务访问和负载均衡。它确保用户的请求能够按需地分发到不同集群上的服务，同时也处理跨集群的服务发现和网络路由。

  
  

为了支持应用跨集群的弹性扩缩容能力，eBay Resource Management团队评估了两种主要方式：

• 联邦HPA - 在联邦层面计算所需的副本数量，随后调整FederatedDeployment，如图2.3.1所示：

• 分布式HPA - 将弹性伸缩策略分发到下属的所有集群，每个集群独立调整其内部的工作负载部署。

在项目设计阶段，权衡各种方案的优劣并作出决策是一项具有挑战的任务。印象特别深刻的是，最初团队倾向于采用联邦HPA的方案。一方面是因为它对现有系统的侵入最小，仅需对联邦部署（FederatedDeployment）做少量修改，同时不会影响PaaS层现有的工作模式，因为联邦部署的Spec保持不变；另一方面是因为我们希望能够同时处理自动调整应用在各个可用区分布的问题。

然而，工作量的大小或对现有系统的影响程度不应成为技术架构决策的决定性因素。当时eBay Resource Management团队总架构师反复提一个问题：这两个方案的本质区别在哪里？我们需要从原语（primitives）、契约（contract）、边界（boundary）这三个方面来思考。如果社区已经提供了HPA作为一个扩缩容的有效手段，那么除非我们能找到一个社区解决不了或不会去解决的边界，否则就不应该试图为了一些次要问题而绕过它。

在深入讨论比较和慎重考虑之后，我们认为社区的HPA完全可以满足我们的需求，并且决定弹性扩缩容不应同时去自动调整可用区，否则将会导致边界不清晰，增加系统的复杂性并提高出错的风险。因此，我们最终决定采用分布式HPA方案，如图2.3.2所展示。

下面是这两种方法的优缺点对比：

下一个关键问题是如何获取应用HPA所需的指标。Kubernetes HPA通常通过metrics.k8s.io API获取指标，这一API由metrics-server提供。然而metrics-server所提供的资源指标，仅包括Pod和容器的CPU和内存使用情况，这些资源指标对于满足生产环境中多样化工作负载的需求往往是不够的。例如，某些专注于AI训练或推理的应用会关注GPU使用率；而处理消息传递的应用可能更加关心消息队列积压（queue backlog）的大小。因此，在生产环境中，我们需要从更全面的监控系统来获取多样的指标。

在eBay内部，我们有一个统一监控系统Sherlock，这个系统基于Prometheus构建，负责收集所有应用的各项指标数据。eBay内部所有团队都是基于Sherlock的指标数据来管理各自的应用，因此我们也希望利用Sherlock中的这些指标来指导HPA的扩缩容决策。那么问题来了，我们如何有效地集成Sherlock与HPA，以便从Sherlock中获取所需的指标？

Kubernetes HPA支持额外的指标类型，包括：

• 自定义指标：

  custom.metrics.k8s.io API。

• 外部指标：

  external.metrics.k8s.io API。

为了从外部源获取指标，Kubernetes提供了Prometheus Adapter。但是，Prometheus Adapter要求使用静态配置的规则来获取指标，这意味着每次添加新指标时，我们需要更新configmap，并且需要重启Prometheus Adapter，这对于后期维护来说是一个重大的挑战。以下是一个配置规则的示例。

我们随后发现了KEDA（Kubernetes事件驱动的弹性扩缩容），这是由云原生基金会（CNCF）孵化的项目，它实现了动态的外部指标服务器。KEDA通过调协每个ScaledObject中定义的触发器，生成并更新对应的外部指标。这意味着我们可以利用KEDA从Sherlock实时获取应用性能指标数据，而无需为添加新的指标重新启动或重新配置整个系统。

以下是一个KEDA Prometheus Scaler的示例配置：

我们详细评估了KEDA Metrics Server和Prometheus Adapter：

结论显而易见，KEDA全方位胜出。

在部署之前，我们必须确保所有关键的性能、安全性和可观测性要求均能满足生产环境的要求。

虽然KEDA是一个开源项目，但我们全面评估之后发现它并未完全符合我们对生产的标准。比如：

• KEDA默认配置不能满足我们的大规模部署需求，比如5分钟内处理10,000个scaledObjects的指标数据的调协。

• KEDA服务账号需要访问所有命名空间中的secrets，在eBay的生产环境中，安全性至关重要，这显然是不能接受的。

于是我们向KEDA社区提出了相关问题，并积极贡献代码，提交了相应的PR。通过这些贡献，我们成功在所有集群中部署了KEDA。

此外在我们的方案中，我们扩展了联邦部署来支持弹性扩缩容策略，并通过联邦控制平面（FCP）的控制器将其同步到所有成员集群，而集群内的控制器则负责创建相应的Deployment和KEDA ScaledObject。KEDA控制器创建相应的HPA，HPA负责从KEDA的外部指标服务器获取指标，并根据定义的策略动态调整部署规模。具体参考图2.5

此外，为了在全局层面控制弹性扩缩容行为，我们实现了特定的准入Webhook，确保了在需要全局暂停弹性扩缩容时，能够快速反应并执行全局性的控制措施。我们还构建了相应的监控仪表板，以便实时跟踪和评估弹性扩缩容事件的有效性。

至此，万里长征已经迈出了第一步。

02

弹性策略的推荐能力

PART2.

接下来的重点是确定如何在eBay内部的所有相关应用中有效实施弹性扩缩容。

这里需要说明的是，为应用启用弹性扩缩容并非简单地切换一个开关那么直接。实际上，它需要定义一套量身定制的策略，这些策略必须充分考虑每个应用的独特需求，包括：

• 最小副本数minReplicas和最大副本数maxReplicas，即工作负载的规模上下限。

• 用于驱动扩缩容决策的指标及其相应的阈值。

• 控制扩缩容行为的策略，这涉及到操作的频率和每次操作增加或减少的副本数量。防止频繁扩缩容导致Pod数量的过度波动，因为这可能会对APIServer、IP地址管理系统（IPAM）和防火墙等系统组件造成显著压力。

在eBay的通用集群上，运行着不同种类的工作负载：

• 托管应用：构建在统一的框架上，并由容量规划团队来维护。

• 通用应用：基于多种技术栈，由每个应用的管理者负责管理容量。

我们决定从托管应用开始着手，因为它们涵盖了几乎所有eBay的核心业务，并且有统一的监控指标。我们的目标是为这些托管应用持续提供弹性扩缩容策略的推荐并保持自动更新。

03

落地实施

PART3.

上述所有能力都只是解决方案。我们希望在eBay所有可适用的应用上启用弹性扩缩容功能，从而提升自动化水平、优化资源利用率，降低成本。

然而，这是一项改变游戏规则的转变，它涉及从固定副本模式过渡到动态副本模式，必然会影响现有的用户体验。因此，整个落地实施过程并不是一帆风顺的，总会遇到一些意料之外的问题。以下是我们在实施过程中遇到的四类挑战：

正如之前提到的，我们选择了分布式HPA的解决方案，这对现有系统侵入型较大。

目前，我们正在一个过渡阶段，将所有托管应用从旧的Assimilation框架迁移到新的CPDLC框架。在此过程中，我们同时运营着两个PaaS系统，这两个系统过去都是基于固定副本数模式运行的，并不完全适应弹性扩缩容。

这里简单举两个例子：

• 托管应用的框架支持流量镜像功能，用于测试。但流量镜像需要克隆一个只有一个副本的工作负载，这个工作负载是不允许扩缩容的。如果原始工作负载已经启用了弹性扩缩容，那么克隆出来的工作负载也会继承这个扩缩容策略，导致流量镜像不起作用。

  
  

• 当用户通过老的PaaS系统部署新版本时，系统会在部署任务前记录副本数量。如果在部署过程中发生了缩容，部署完成后的副本数将与记录的数量不一致，便会导致本次部署任务失败。而部署任务的失败又会影响到Velocity(框架部门的关键评估指标之一)的考量。

虽然我们期望其他团队能升级他们的系统以支持弹性扩缩容，但我们不能强迫他们因我们的改变而作出改变。因此，我们尝试去理解对方的初始设计理念，互相审查设计，探讨背后的逻辑，最终通过双方共同的努力，解决了所有潜在的冲突。

比如，对于第一个例子，我们确保在选择启用弹性扩缩容的工作负载时不会选择用于流量镜像的工作负载，框架团队也确保在克隆工作负载时不会带上弹性扩缩容的策略。

对于第二个例子，PaaS团队在部署任务开始前后通过APIServer提供信号，我们根据这个信号确保在部署进行中暂停针对这个工作负载的扩缩容操作，以此来避免部署过程中的副本数变动。

通常来说，引入新事物对所有人来说都是一个挑战。在实施初期，我们每天都会收到应用所有者和站点工程师的各种疑问。例如：

• 我们的应用应该有30个实例，为什么现在只有16个？

• 应用X目前出现问题，错误率上升了，这是不是弹性扩缩容导致的？

• 我们的应用在实例数量上进行了硬编码以匹配分片数量，我们可以禁用弹性扩缩容吗？

为了顺利落地，将负反馈转化为正向动力非常重要，因此在这一阶段我们对每一个问题都耐心回复。例如：

• 针对第一个问题，我们会详细地解释弹性扩缩容如何调整应用规模，以及这样做的好处。

• 对于第二个问题，我们尽力帮助定位问题的根本原因，证明并非由弹性扩缩容引起的。同时，还要强调弹性扩缩容实际上可以帮助减少因流量突增引起的稳定性问题。

• 针对第三个问题，我们深入了解了他们应用的设计细节，并在适当的情况下选择关闭弹性扩缩容功能。

此外，容量规划团队也在美国工作时间提供了极大的支持，帮助回答并解决这类问题。

当然，信任的建立不是一夜之间就能完成的，需要随着时间的积累逐渐建立起来。在这个过程中，所有相关者的支持对落地实施非常重要。

弹性扩缩容的有效性不仅取决于应用架构的支持，还依赖于一个高可扩展性的基础设施环境。然而，我们目前的基础设施并未完全适配于大规模的弹性伸缩需求。比如：

• 在从Assimilation迁移到CPDLC的过程中，Assimilation应用的Pod转变为就绪状态可能需要较长时间，有时这个过程甚至会超过一小时。

• 某些基础设施组件，例如硬件防火墙，无法同时处理成百上千个Pods同时扩展。

上述限制因素会影响到弹性扩缩容的SLA（我们希望弹性扩缩容能够在30分钟内将应用性能指标恢复到预定的阈值之下），因此在一定程度上阻碍了弹性扩缩容的广泛应用。

为应对这些限制，我们除了积极推动相关团队合作外，也在我们的层面上实施了多项改进。例如：

• 我们引入了准入控制机制，对所有的扩缩容事件进行管理，并针对基础设施能力的限制对扩容操作实行了速率限制。我们参考了APIServer的优先级和流量模式（Priority and Flow Schema）来设定基于应用优先级的速率限制。

• 针对Assimilation的应用，我们基于过去一段时间内的流量高峰期数据提出了建议，以保证在最小副本数配置下的系统稳定性，减少扩缩容频次。

不同的应用有不同的特征模式，一些应用对延迟非常敏感，另一些则不然；一些应用有TPS，另一些则没有；此外，不同应用的CPU使用率也有很大差异，有些应用的CPU使用率始终低于10%。

对于那些CPU使用率持续偏低的应用，最初我们有几个提议。其中一个是通过使用镜像流量进行压力测试。然而，这种方法无法完全模拟所有类型的请求，特别是写请求，并且在所有生产应用中广泛部署并不现实。

因此，我们决定采用插值算法去做预测。我们的做法是采样低利用率应用的所有副本的TPS与CPU配对数据，将它们拟合进线性回归模型，并预测当CPU使用率达到某一阈值时的TPS。这种方法对不少应用非常有效。

但是，当TPS与CPU的相关性不强时，如图4.1.4所示，插值算法就不再适用。为了解决这一问题，我们会首先计算相关系数；如果系数未达到预设的阈值，我们将放弃使用插值算法，转而采用逐步减少副本数量的策略，以便逐步提升CPU使用率，下次推荐的时候可以获取更多的数据点，最终帮助我们形成更为精确的优化推荐。

到目前为止，已有10%的托管应用启用了弹性扩缩容，并且新创建的CPDLC托管应用已经默认启用弹性扩缩容的自动推荐，最终我们期望所有适用的应用都能默认启用弹性扩缩容。

在已启用弹性扩缩容的托管应用中，我们观察到CPU利用率方面的显著提升：

• 对于所有托管应用，CPU的实际使用量与请求量的平均比值为36.16%。

• 对于那些启用了弹性扩缩容的托管应用，这一比值提升到了45.98%。

基于这些利用率提升，我们已经节约了超过2万个CPU核心。预计一旦所有托管应用都启用弹性扩缩容后，节约的核心数将达接近5万。

等托管应用都成功启用后，我们还会进一步将推荐策略迁移到规模更大的通用应用上。

此外，弹性扩缩容也已应用于部份AI推理工作负载，成功地将GPU的平均利用率从9%提升至13%。这意味着在不增加现有GPU集群规模（3000+GPU核心）的前提下，能够节省更多的GPU资源，从而支持更多的推理和训练任务。

04

对未来的展望

PART3.

尽管在落地过程中我们已经解决了不少挑战，但仍有很大的改进空间和许多工作要做。

弹性扩缩容的改进

• 定制化算法

目前我们使用的推荐算法虽然具有普适性，但并不能满足所有应用的需求。为此，下一阶段需要针对不同应用的独有特点，采用定制化的算法。

• 预测模型

目前HPA所依赖的指标是实时的，对于那些启动时间较长的工作负载而言，并非理想的方案。因此，我们计划构建预测模型，使得弹性扩缩容能够以自适应模式工作。

• 全自动审批

目前，弹性扩缩容策略的一部分推荐还依赖于人工审核和批准，这限制了我们调整扩缩容策略的频率，目前每周只能更新一次。因此，我们还需要持续提升推荐准确度并最终实现完全自动化。

资源优化的其他手段

此外，在提高资源利用率方面还有很多工作可以做，这一过程可以分为几个阶段进行：

• 阶段一：提升应用利用率

在此阶段，除了利用HPA进行弹性扩缩容外，对于那些不适合弹性扩缩容的工作负载，或者那些副本数量已经很少但CPU利用率依然较低的工作负载，可以选择利用垂直自动伸缩器（VPA）来为这些工作负载提供规格建议并进行调整。

• 阶段二：提高装箱率（Bin-packing Ratio）

第一阶段的目标是通过确定合适的规格和副本数量来提高应用的利用率，从而使节点能够容纳更多的Pods。

然而，如果如果应用数量或规模没有持续增长（Organical Growth）的话，这反而会导致节点装箱率降低。为了提升节点层面的装箱率，可以采用装箱感知调度和负载感知调度等策略，并结合下架多余的节点或缩减采购计划来实现目标。

• 阶段三：跨集群平衡

在执行完前两个阶段之后，我们将能够提升单集群中节点的利用率。然而，不同集群之间的利用率还会存在差异。因此，还需要实施自动化的集群选择和部署策略，以平衡各个集群之间的资源利用率。

• 阶段四：提高平均节点利用率

通常情况下，P95与平均利用率之间会存在显著差距，这主要是因为大部分在线应用都呈现出潮汐效应的使用模式，即有明显的高峰期和低谷期。

在这个阶段，可以考虑采取分级的QoS管理机制，并结合I/O隔离技术来实施在离线工作负载的混部。

05

感谢

PART3.

最后，我们需要感谢所有参与此项目的团队成员及兄弟团队：ESTools Team(Cloud Resource Management), Cloud Team, Capacity Team, Framework Team, AIOPS Team, AIP Team, SEC & SRE Team。

之后我们也会持续分享eBay在降本增效之路上的更多进展。