[转帖]Effective HPA：预测未来的弹性伸缩产品

作者

胡启明，腾讯云专家工程师，专注 Kubernetes、降本增效等云原生领域，Crane 核心开发工程师，现负责成本优化开源项目 Crane 开源治理和弹性能力落地工作。

余宇飞，腾讯云专家工程师，专注云原生可观测性、成本优化等领域，Crane 核心开发者，现负责 Crane 资源预测、推荐落地、运营平台建设等相关工作。

田奇，腾讯高级工程师，专注分布式资源管理和调度，弹性，混部，Kubernetes Contributor，现负责 Crane 相关研发工作。

引言

业务的稳定性和成本之间的矛盾由来已久。在云原生时代，按需付费的成本模型催生出了自动弹性伸缩技术——通过动态申请、归还云上资源，在满足业务需求的前提下，降低成本。

什么是 HPA

谈到云原生中的弹性，大家自然想到 Kubernetes 的各种自动伸缩（Auto Scaling）技术，其中最具代表性的当属水平 Pod 自动伸缩（HPA）。

HPA 作为 Kubernetes 的内建功能，具有一系列优点：

1. 兼顾业务高峰稳定、低谷降本的诉求。
2. 功能稳定，社区中立：随着 kubernetes 版本的迭代，其本身的功能也在不断地丰富和完善，但 HPA 的核心机制一直保持稳定，这也说明它可以满足最通用的弹性伸缩场景。
3. 顺应 Serverless 趋势：随着各个大厂发布 Serverless 容器产品，以及虚拟节点池技术的提出，HPA 很大程度上覆盖了集群自动伸缩（CA） 的功能，使得自动伸缩更轻量、更敏捷。
4. 完善的扩展机制：提供诸如 custom_metrics、external_metric 等扩展指标，用户可以根据实际情况配置最适合业务的 HPA。

传统 HPA 的问题

HPA 也并不完美：

1. 如何配置：HPA 运行的效果取决于用户资源的配置（target、minReplicas、maxReplicas 等等）。配置过于激进可能导致应用可用性、稳定性受影响，配置过于保守弹性的效果就大打折扣。如何合理的配置是用好 HPA 的关键。

2. 弹性不够及时：原生 HPA 是对监控数据的被动响应，此外应用本身启动、预热也需要一定时间，这使得HPA天生具有滞后性，进而可能影响业务稳定。这也是很多用户不信任、不敢用HPA的一个重要原因。

3. 可观测性低：HPA 没法通过类似 Dryrun 方式测试，一旦使用便会实际修改应用的实例数量，存在风险；而且弹性过程也难以观测。

时间序列预测

HPA 通常被应用于负载具有潮汐性的业务， 如果从流量或者资源消耗等指标的时间维度来看，会发现很明显的波峰、波谷形态。进一步观察，这类具有波动性的业务往往天然地在时间序列上也有着明显周期性，尤其是那些直接或间接服务于“人”的业务。

这种周期性是由人们的作息规律决定的，例如，人们习惯中午、晚上叫外卖；早晚会有出行高峰；即时是搜索这种业务时段不明显的服务，夜里的请求量也会大大低于白天。对于此类业务，一个很自然的想法，就是通过过去几天的数据预测出今天的数据。有了预测的数据（例如：未来24小时的业务 CPU 的使用情况），我们就可以对弹性伸缩做出某种“超前部署”，这也是 Effective HPA 能够克服原生 HPA 实时性不足的关键所在。

Effective HPA 是什么

Effective HPA（简称 EHPA）是开源项目 Crane 中的弹性伸缩产品，它基于社区 HPA 做底层的弹性控制，支持更丰富的弹性触发策略（预测，监控，周期），让弹性更加高效，并保障了服务的质量：

• 提前扩容，保证服务质量：通过算法预测未来的流量洪峰提前扩容，避免扩容不及时导致的雪崩和服务稳定性故障。
• 减少无效缩容：通过预测未来可减少不必要的缩容，稳定工作负载的资源使用率，消除突刺误判。
• 支持 Cron 配置：支持 Cron-based 弹性配置，应对大促等异常流量洪峰。
• 兼容社区：使用社区 HPA 作为弹性控制的执行层，能力完全兼容社区。

架构

EHPA 的主要架构如下：

• EHPA Controller: 负责 EHPA 对象的控制逻辑，包括 EHPA 的增删改查和 HPA 的同步
• Metric Adapter：负责预测指标以及其他相关指标的生成
• Predictor：负责主要用于时序数据分析和预测
• TimeSeriesPrediction：时序数据预测 CRD，主要供 EHPA 和 MetricAdapter 进行消费
• HPA Controller: 社区原生 HPA 控制器，EHPA 对此完全兼容，允许用户有已经配置的 HPA
• KubeApiServer：社区原生 Kubernetes ApiServer
• Metric Server：社区原生 Metric Server

主要功能

基于预测的弹性

EHPA 充分挖掘 Workload 的相关指标，对于资源消耗和流量有明显周期性的 Workload，预测其在未来一段时间窗口的时序指标，利用该预测窗口数据，HPA 获取到的指标会带有一定的前瞻性，当前 EHPA 会取未来窗口期内指标的最大值，作为当前 HPA 的观测指标。

这样当未来流量上升超过 HPA 容忍度的时候，HPA 就可以在当下完成提前扩容，而当未来短时间内有流量降低，但是其实是短时抖动，此时由于 EHPA 取最大值，所以并不会立即缩容，从而避免无效缩容。

用户可以通过配置以下指标：

apiVersion: autoscaling.crane.io/v1alpha1
kind: EffectiveHorizontalPodAutoscaler
spec:
  # Metrics 定义了弹性阈值，希望 workload 的资源使用保持在一个水平线上
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
  # Prediction 定义了预测配置
  # 如果不设置，则不开启弹性预测
  prediction:
    predictionWindowSeconds: 3600   # PredictionWindowSeconds 定义了预测未来多久的时间窗口。
    predictionAlgorithm:
      algorithmType: dsp
      dsp:
        sampleInterval: "60s"
        historyLength: "3d"

• MetricSpec: 配置和 HPA 是一致的，保持用户一致的体验
• Prediction: 主要用来设置预测先关参数，包括预测窗口和算法类型，未来对于窗口时序指标的处理策略，用户可以自行定制。
  • PredictionWindowSeconds: 预测未来时间窗口长度
  • Dsp: 该算法是基于FFT（快速傅里叶变换）的时序分析算法，针对周期性强的时序有不错的预测效果，而且无需进行模型训练，简单高效

基于 Cron 的弹性

除了基于监控指标，有时候节假日弹性和工作日会有差异，简单的预测算法可能无法比较好的工作。那么此时可以通过设置周末的 Cron 将其副本数设置更大一些，从而弥补预测的不足。

针对某些非 Web 流量型应用，比如有些应用会在周末的时候无需工作，此时希望工作副本缩容为1，也可以配置 Cron 进行缩容，降低用户成本。

定时 Cron 弹性 Spec 设置如下：

apiVersion: autoscaling.crane.io/v1alpha1
kind: EffectiveHorizontalPodAutoscaler
spec:
  crons:
  - name: "cron1"
    description: "scale up"
    start: "0 6 ? * *"
    end: "0 9 ? * *"
    targetReplicas: 100
  - name: "cron2"
    description: "scale down"
    start: "00 9 ? * *"
    end: "00 11 ? * *"
    targetReplicas: 1

• CronSpec: 可以设置多个 Cron 弹性配置，Cron 周期可以设置周期的开始时间和结束时间，在该时间范围内可以持续保证 Workload 的副本数为设定的目标值。
  • Name：Cron 标识符
  • TargetReplicas：本 Cron 时间范围内 Workload 的目标副本数
  • Start：表示 Cron 的开始时间，时间格式是标准的 linux crontab 格式
  • End: 表示 Cron 的结束时间，时间格式是标准的 linux crontab 格式

目前一些厂商和社区的弹性 Cron 能力存在一些不足之处：

1. Cron 能力是单独提供的，弹性没有全局观，和 HPA 的兼容性差，会产生冲突
2. Cron 的语义和行为不是很匹配，甚至使用起来非常难以理解，容易造成用户故障

下图是当前 EHPA 的 Cron 弹性实现和其他 Cron 能力对比：

针对上述问题，EHPA 实现的 Cron 弹性，是在兼容 HPA 基础上来设计的，Cron 作为 HPA 的指标，是和其他指标一样共同作用于 Workload 对象的。另外，Cron 的设置也很简单，单独配置 Cron 的时候，不在激活时间范围是不会对 Workload 进行默认伸缩的。

弹性结果预览

EHPA 支持预览(Dry-run)水平弹性的结果。在预览模式下 EHPA 不会实际修改目标工作负载的副本数，所以你可以通过预览EHPA弹性的效果来决定是否需要真的开始自动弹性。另外一种场景是当你希望临时关闭自动弹性时，也可以通过调整到预览模式来实现。

• ScaleStrategy: Preview 为预览模式，Auto 为自动弹性模式
• SpecificReplicas: 在预览模式时，可以通过设置 SpecificReplicas 指定工作负载的副本数

apiVersion: autoscaling.crane.io/v1alpha1
kind: EffectiveHorizontalPodAutoscaler
spec:
  scaleStrategy: Preview   # ScaleStrategy 弹性策略，支持 "Auto" 和 "Preview"。
  specificReplicas: 5      # SpecificReplicas 在 "Preview" 模式下，支持指定 workload 的副本数。
status:
  expectReplicas: 4        # expectReplicas 展示了 EHPA 计算后得到的最终推荐副本数，如果指定了 spec.specificReplicas，则等于 spec.specificReplicas.
  currentReplicas: 4       # currentReplicas 展示了 workload 实际的副本数。

实现原理：当 EHPA 处于预览模式时，Ehpa-controller 会将底层的 HPA 对象指向一个 Substitute(替身) 对象，底层计算和执行弹性的 HPA 只会作用于替身，而实际的工作负载则不会被改变。

落地效果

目前 EHPA 已经在腾讯内部开始使用，支撑线上业务的弹性需求。这里展示一个线上应用使用 EHPA 后的落地效果。

上图显示了该应用一天内的 CPU 使用。红色曲线是实际使用量，绿色曲线是算法预测出的使用量，可以看到算法可以很好的预测出使用量的趋势，并且根据参数实现一定的偏好（比如偏高）。

上图显示了该应用使用弹性后在一天内副本数的变化趋势。红色曲线是通过原生的 HPA 自动调整的副本数，而绿色曲线是通过 EHPA 自动调整的副本数，可以看到 EHPA 的弹性策略更加合理：提前弹和减少无效弹性。

衍生阅读：什么是 Crane

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

Crane 的智能水平弹性能力是基于 Effective HPA 实现。用户在安装 Crane 后即可直接使用 Effective HPA 开启智能弹性之旅。

当前 Crane 项目主要贡献者包括有腾讯、小红书、谷歌、eBay、微软、特斯拉等知名公司的行业专家。

参考链接

1. Crane 开源项目地址：【https://github.com/gocrane/crane/】
2. Crane 官网: 【https://docs.gocrane.io/】
3. Effective HPA 使用文档：【https://docs.gocrane.io/dev/zh/tutorials/using-effective-hpa-to-scaling-with-effectiveness/】

关于我们

更多关于云原生的案例和知识，可关注同名【腾讯云原生】公众号~

福利：

①公众号后台回复【手册】，可获得《腾讯云原生路线图手册》&《腾讯云原生最佳实践》~

②公众号后台回复【系列】，可获得《15个系列100+篇超实用云原生原创干货合集》，包含Kubernetes 降本增效、K8s 性能优化实践、最佳实践等系列。

③公众号后台回复【白皮书】，可获得《腾讯云容器安全白皮书》&《降本之源-云原生成本管理白皮书v1.0》

④公众号后台回复【光速入门】，可获得腾讯云专家5万字精华教程，光速入门Prometheus和Grafana。