关于腾讯云:酷家乐基于-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。

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