关于腾讯云:Effective-HPA预测未来的弹性伸缩产品

胡启明，腾讯云专家工程师，专一 Kubernetes、降本增效等云原生畛域，Crane 外围开发工程师，现负责老本优化开源我的项目 Crane 开源治理和弹性能力落地工作。

余宇飞，腾讯云专家工程师，专一云原生可观测性、老本优化等畛域，Crane 外围开发者，现负责 Crane 资源预测、举荐落地、经营平台建设等相干工作。

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

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

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

HPA 作为 Kubernetes 的内建性能，具备一系列长处：

兼顾业务顶峰稳固、低谷降本的诉求。
性能稳固，社区中立：随着 kubernetes 版本的迭代，其自身的性能也在一直地丰盛和欠缺，但 HPA 的外围机制始终保持稳定，这也阐明它能够满足最通用的弹性伸缩场景。
适应 Serverless 趋势：随着各个大厂公布 Serverless 容器产品，以及虚构节点池技术的提出，HPA 很大水平上笼罩了集群主动伸缩（CA）的性能，使得主动伸缩更轻量、更麻利。
欠缺的扩大机制：提供诸如 custom_metrics、external_metric 等扩大指标，用户能够依据理论状况配置最适宜业务的 HPA。

HPA 也并不完满：

如何配置：HPA 运行的成果取决于用户资源的配置（target、minReplicas、maxReplicas 等等）。配置过于激进可能导致利用可用性、稳定性受影响，配置过于激进弹性的成果就大打折扣。如何正当的配置是用好 HPA 的要害。
弹性不够及时：原生 HPA 是对监控数据的被动响应，此外利用自身启动、预热也须要肯定工夫，这使得 HPA 天生具备滞后性，进而可能影响业务稳固。这也是很多用户不信赖、不敢用 HPA 的一个重要起因。
可观测性低：HPA 没法通过相似 Dryrun 形式测试，一旦应用便会理论批改利用的实例数量，存在危险；而且弹性过程也难以观测。

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

这种周期性是由人们的作息法则决定的，例如，人们习惯中午、早晨叫外卖；早晚会有出行顶峰；即时是搜寻这种业务时段不显著的服务，夜里的申请量也会大大低于白天。对于此类业务，一个很天然的想法，就是通过过来几天的数据预测出明天的数据。有了预测的数据（例如：将来 24 小时的业务 CPU 的应用状况），咱们就能够对弹性伸缩做出某种“超前部署”，这也是 Effective HPA 可能克服原生 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 将其正本数设置更大一些，从而补救预测的有余。

针对某些非 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 能力存在一些不足之处：

Cron 能力是独自提供的，弹性没有全局观，和 HPA 的兼容性差，会产生抵触
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（Cloud Resource Analytics and Economics）。Crane 遵循 FinOps 规范，旨在为云原生用户提供云老本优化一站式解决方案。

Crane 的智能程度弹性能力是基于 Effective HPA 实现。用户在装置 Crane 后即可间接应用 Effective HPA 开启智能弹性之旅。

以后 Crane 我的项目次要贡献者包含有腾讯、小红书、谷歌、eBay、微软、特斯拉等出名公司的行业专家。

Crane 开源我的项目地址：【https://github.com/gocrane/cr…】
Crane 官网:【https://docs.gocrane.io/】
Effective HPA 应用文档：【https://docs.gocrane.io/dev/z…】

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

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

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

③公众号后盾回复【白皮书】，可取得《腾讯云容器平安白皮书》&《降本之源 - 云原生老本治理白皮书 v1.0》

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

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

关于腾讯云:Effective-HPA预测未来的弹性伸缩产品

作者

引言

什么是 HPA

传统 HPA 的问题

工夫序列预测

Effective HPA 是什么

架构

次要性能

基于预测的弹性

基于 Cron 的弹性

弹性后果预览

落地成果

衍生浏览：什么是 Crane

参考链接

对于咱们

福利：