酷家乐基于 Crane EHPA 的弹性落地实践

为什么需要自动伸缩

互联网业务由于人的活动规律从而普遍具有周期性繁忙的特征，最常见的是以天为单位的周期性变化，比如白天繁忙、夜间空闲。按传统固定资源模式，低峰期时资源使用率较低但仍然持有资源，便会造成浪费。服务的自动伸缩（可能还需要配合集群资源的自动伸缩）就能实现在高峰期扩容并在低峰期回收资源的效果，在公有云等按量计费的场景下实现成本优化。

传统固定资源模式下，业务往往会冗余一定的资源来应对流量增长，使用自动伸缩后可以减少这部分冗余资源，也能更从容地应对热点流量等情况。

在进入 K8S 时代之后，服务通过声明式 API 就可以轻松地完成扩缩容操作，而 K8S 提供的水平扩缩容（Horizontal Pod Autoscaling，以下简称HPA）功能可以基于 CPU、QPS、任务队列等指标实现服务实例数量的自动伸缩。

本文主要总结了 HPA 落地实践中的问题，以及 Crane 的 EffectiveHPA(以下简称 EHPA)是如何帮助我们解决对应问题的。

HPA落地的问题

HPA的运行机制主要是由 HPA Controller 通过指标与扩缩容阈值的计算得到服务的期望实例数来进行扩缩容活动。自动扩缩容带来的挑战一方面是对服务提出了更高的要求，随时扩缩容的前提是需要服务能够优雅启动与下线；另一方面则是 HPA 基础设施自身功能与健壮性的挑战。以下主要讨论的是后者遇到的问题。

1. 扩容滞后：首要问题便是基于监控指标的扩缩容存在滞后性，当探测到指标达到阈值并扩容启动服务，会有一定的时间差。这就导致服务在高峰来临的时候才开始扩容，此时如果扩容机制出现异常（集群资源不足、依赖项异常导致启动失败等原因) 还会引发更大的危机。
2. 监控故障影响服务稳定性：因为 HPA 是基于监控指标进行自动伸缩，在低峰期完成缩容后，如果因为监控系统故障而导致在高峰期无法扩容，则会对线上服务的稳定性造成非常大的影响。而在以往，监控系统的故障只影响服务的可观测性。
3. 指标毛刺造成实例数抖动：有些服务的监控指标可能不是平滑的（尤其是 CPU 使用率之类的系统指标），会存在间断性的毛刺。这类指标应用到 HPA 的时候会造成服务实例数的抖动，进行非预期的反复扩容与缩容。虽然可以通过 HPA 的稳定时间窗口参数来减少抖动次数，但效果有限。

EHPA 如何解决问题

通过预测算法提前扩容

针对指标具有周期性特征的服务，通过 DSP 预测算法实现提前扩容的效果，从而保证在高峰期来临之前扩容完成。DSP 通过快速傅里叶变换基于历史指标数据讲指标从时域（即时间域）变换到频域（即频率域），即把一个比较复杂的函数（指标的历史数据曲线）转换为多个简单函数的叠加，过滤处理后再反向拟合出指标的未来数据。

获取到预测数据后，EHPA 会新增一个预测指标（与原来的实时指标一起）来指导服务的自动扩缩容。预测指标的阈值与原有指标一致，其中一者达到阈值即可触发扩容。EHPA 会用未来一段时间（通过 PredictionWindowSeconds 参数控制）的预测数据的最大值来作为预测指标的数据源，这样就可以达到提前扩容的效果。

利用预测数据做降级

当监控数据失效的时候，如果此时还在预测数据有效期内，则仍可以通过预测数据来完成扩容。目前预测数据的有效期也是根据上一节的 PredictionWindowSeconds 参数来控制，有效期不会太长。并且有些服务的指标并不具备周期性特征所以无法获取预测数据，所以该降级方案目前只能说是一定程序地缓解。

利用平滑的预测指标缓解抖动

在拟合预测数据之前过滤掉了低振幅信号，相当于过滤掉了指标曲线中毛刺的部分，所以预测指标的曲线整体比较平滑。同时还可以通过 EHPA 的 MarginFraction 参数实现将指标数据向外溢出的效果，其实就是将数据再乘以（1+MarginFraction）。这样预测指标就能包裹住更多的毛刺，减少服务实例数的抖动。

其它

Crane 的预测功能是通过 TimeSeriesPrediction CRD 提供的通用功能，所以能根据所提供的指标计算规则来做任意指标的预测。上文提到 HPA 往往会结合集群弹性同时工作，所以除了给服务的资源水位提供预测，还可以提供集群水位的预测数据，实现节点资源提前扩容的效果。

整体架构

Crane EHPA 采用类似 Proxy 的方式来增加预测功能，减少对原有架构的侵入性，在整体架构中的位置见上图左上角部分。

原先的弹性架构主要包括以下组件：

1. HPA Controller：KubeControllerManager 进程中的一个控制器，可以循环监听 hpa 的阈值配置以及指标数据的实时值来判断是否需要扩缩容，是自动扩缩容的核心组件。
2. PrometheusAdapter：通过一系列配置规则，作为适配器打通 K8S Apiserver 与 Prometheus。通过 K8S Aggregation API 机制注册到 APIService 的形式，使得能通过查询 K8S Apiserver 来间接获取 Prometheus 中的数据，用来作为自定义指标的数据源。
3. MetricsServer：查询节点或 Pod 实时资源（CPU、内存等）使用的指标数据源，HPA Controller 的 Resources 类型阈值会查询该数据源。
4. Prometheus：查询各种指标历史数据的数据源，HPA Controller 的 Pods、External 类型阈值会查询该数据源，同时也提供预测功能的历史数据。

在引入 Crane EHPA 之后，主要增加了以下两个组件：

1. Craned：Craned 的 EHPA Controller 会监听 EHPA 对象来创建/更新对应的 HPA 对象和 TSP 对象。其中 HPA 对象还是由 HPA Controller 管理，而 Craned 的 Predicator 模块则会基于 TSP 对象的配置来生成对应指标的预测数据。
2. MetricsAdapter：代替 PrometheusAdapter 注册到 APIService，作为 PrometheusAdapter 的 Proxy。当要读取预测指标的数据时，会根据预测数据来返回数据；否则转发到 PrometheusAdapter。

落地效果

应用到白天繁忙、夜间空闲的服务，如上图所示，可以看到蓝色的预测数据与绿色的实时监控数据几乎吻合，表示预测数据的准确性。同时黄色曲线即为上文所说的未来 PredictionWindowSeconds 时间内预测数据的最大值，所以将预测指标也作为 HPA 的阈值之一就可以达到提前扩容的效果。

针对指标毛刺比较多的服务，可以通过平滑的预测数据来缓解，同时还可以自己定义 DSP 算法参数来定制效果。如上图所示，黄色曲线是默认参数下的预测曲线，仍然有部分毛刺（绿色曲线）在预测曲线以外。通过调整 MarginFraction 参数，可以让预测曲线继续外溢一些，即为图中蓝色曲线的效果。

总结

上面主要介绍了 EHPA 带来的优势，但在落地时笔者也遇到了一些局限性和优化点。

1. 在笔者落地时 EHPA 的预测功能只能支持 CPU 指标，因此笔者通过自己 Fork 代码修改实现。在0.6.0版本已经支持自定义指标的预测，后续可直接使用社区版本。
2. 目前的 DSP 算法主要支持了周期性服务的常规处理，因此应对节假日大促等场景，可通过 EHPA 的 Cron 功能提前扩容，并用应用的监控指标兜底。

衍生阅读：什么是 Crane

为推进云原生用户在确保业务稳定性的基础上做到真正的极致降本，腾讯推出了业界第一个基于 Kubernetes 的成本优化开源项目 Crane（ Cloud Resource Analytics and Economics ）。Crane 遵循 FinOps 标准，旨在为云原生用户提供云成本优化一站式解决方案。

Effective HPA 是 Crane 提供的水平弹性工具，帮助用户开启智能弹性之旅。

Crane 已成功加入 CNCF Landscape，欢迎关注项目，合作共建：https://github.com/gocrane/crane。

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！