甩掉容量规划炸弹：用 AHPA 实现 Kubernetes 智能弹性伸缩

01

AHPA 介绍

Aliware

01

背景

Kubernetes 中应用实例数设置有固定实例数、HPA 和 CronHPA 三种策略。使用最多的是固定实例数，但是很多业务都存在波峰浪谷，如果采用固定实例数的方式会造成较大的资源浪费。Kubernetes 中提供了 HPA 及 CronHPA 两种机制实现按需扩容实例数量，减少资源浪费。CronHPA 是用户设定定时规则，在固定时间进行实例数伸缩。但是设定定时规则较为复杂，如果定时间隔设置较大就会造成资源浪费。HPA 可以根据应用实时负载设置实例数量，当应用负载高时扩容，当应用负载低时则缩容实例。HPA 是基于实时负载进行扩容，只有当负载已经比较高时才会触发扩容，但此时业务已经处在高负载中因此业务部分流量出现响应慢或者超时的问题，即存在“弹性滞后”的问题。为此，我们提出了一种智能化弹性伸缩方案 AHPA，可以根据历史时序数据进行主动预测，提前扩容，避免弹性滞后。同时，会根据实时数据动态调整主动预测结果，兼容周期变动等场景。

图 1 各种弹性伸缩策略对比图

02

AHPA 架构

图 2 AHPA 框架图

AHPA 整体架构如图 2 所示，分为数据采集、预测及弹性伸缩三大部分。

• Data Collection

Data Collection 模块负责从数据源收集数据并将数据转为统一的格式传入给 Prediction 模块。数据源支持如 Prometheus、Metrics Serve、Log Service 以及其他自定义的监控平台。

指标包含 CPU、Memory、GPU 等资源指标，也包括 QPS、RT 等业务指标，同时也支持其他用户自定义指标。Adapter 模块负责将从多个数据源收集的各类指标转为统一的格式输入给 Prediction 模块。

• Prediction

Prediction 模块负责根据输入指标预测所需的 Pod 数量。Preprocessing 负责数据预处理，如过滤非 Running 状态的 Pod 利用率、处理缺失数据等。完成预处理后将时序数据传递给 RobustScaler^[1]算法模块。该模块将在第二部分详细介绍。

Revise 模块负责对 RobustScaler 模块给出的预测 Pod 数量进行修正。RobustScaler 分为 Proactive 和 Reactive 两种模式，用户也会为应用 Pod 数量设置上下限。为保证应用平稳运行，我们采取尽快扩，缓慢缩的策略，因此 Revise 模块会取 Proactive、Reactive 及用户设置的上下限中最大值作为预测的 Pod 数量。

• Scaling

Scaling 模块负责执行 Pod 扩缩容。弹性伸缩策略分为两类：auto 及 observer 模式。

• • auto：根据 Prediction 给出的 Pod 数量自动调整

  • observer：dryrun 模式，不调整 Pod 数量。用户可以通过这种方式观察 AHPA 工作是否符合预期。

03

AHPA 部署方式

图 3 AHPA 部署图

AHPA 在 Kubernetes 中部署图如上所示，分为 AHPA Algorithm 及 AHPA Controller 两部分。AHPA Algorithm Deployment 是负责 AHPA 中算法相关的部分，对应架构图中的 Prediction 模块。AHPA Controller 负责数据收集及弹性扩缩容的执行，对应架构图中的 D