Effective HPA:预测未来的弹性伸缩产品

此账号已注销
• 阅读 6000

作者

胡启明,腾讯云专家工程师,专注 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 通常被应用于负载具有潮汐性的业务, 如果从流量或者资源消耗等指标的时间维度来看,会发现很明显的波峰、波谷形态。进一步观察,这类具有波动性的业务往往天然地在时间序列上也有着明显周期性,尤其是那些直接或间接服务于“人”的业务。

Effective HPA:预测未来的弹性伸缩产品

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

Effective HPA 是什么

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

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

Effective HPA:预测未来的弹性伸缩产品

架构

EHPA 的主要架构如下:

Effective HPA:预测未来的弹性伸缩产品

  • 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 能力对比:

Effective HPA:预测未来的弹性伸缩产品

针对上述问题,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 后的落地效果。

Effective HPA:预测未来的弹性伸缩产品

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

Effective HPA:预测未来的弹性伸缩产品

上图显示了该应用使用弹性后在一天内副本数的变化趋势。红色曲线是通过原生的 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。

点赞
收藏
评论区
推荐文章
blmius blmius
2年前
MySQL:[Err] 1292 - Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘CREATE_TIME‘ at row 1
文章目录问题用navicat导入数据时,报错:原因这是因为当前的MySQL不支持datetime为0的情况。解决修改sql\mode:sql\mode:SQLMode定义了MySQL应支持的SQL语法、数据校验等,这样可以更容易地在不同的环境中使用MySQL。全局s
KubeCon 2021|使用 eBPF 代替 iptables 优化服务网格数据面性能
作者刘旭,腾讯云高级工程师,专注容器云原生领域,有多年大规模Kubernetes集群管理及微服务治理经验,现负责腾讯云服务网格TCM数据面产品架构设计和研发工作。引言目前以Istioiptables实现流量劫持首先看一下当前社区使用的基于iptables的流量劫持方案,下图是一个Pod的创建过程,sidecarinjector会向
光速从0到1掌握Prometheus和Grafana,腾讯云专家5万字精华教程免费送
作者黄雷,腾讯云高级工程师,曾负责构建腾讯云云监控新一代多维业务监控系统,擅长大规模分布式监控系统设计,对golang后台项目架构设计有较深理解,后加入TKE团队,致力于研究Kubernetes相关运维技术,拥有多年Kubernetes集群联邦运维管理经验,目前在团队主要负责大规模集群联邦可观测性提升,主导研发了腾讯云万级Kubernetes
如何接入 K8s 持久化存储?K8s CSI 实现机制浅析
作者王成,腾讯云研发工程师,Kubernetescontributor,从事数据库产品容器化、资源管控等工作,关注Kubernetes、Go、云原生领域。概述进入K8s的世界,会发现有很多方便扩展的Interface,包括CSI,CNI,CRI等,将这些接口抽象出来,是为了更好的提供开放、扩展、规范等能力。K8s持久化存储经历了从in
腾讯发布 K8s 多集群管理开源项目 Clusternet
11月4日,在腾讯数字生态大会上,腾讯宣布了云原生领域一项重磅开源进展——K8s多集群管理项目Clusternet正式开源。Clusternet由腾讯联合多点生活、QQ音乐、富途证券、微众银行、酷狗音乐、三七互娱等共同发起,专注K8s多集群管理和应用治理方向,希望让管理多集群就像上网一样简单。作为未来分布式云的技术基石,Clusternet通
Stella981 Stella981
2年前
Flink 在又拍云日志批处理中的实践
日前,由又拍云举办的大数据与AI技术实践|OpenTalk杭州站沙龙在杭州西溪科创园顺利举办。本次活动邀请了有赞、个推、方得智能、又拍云等公司核心技术开发者,现场分享各自领域的大数据技术经验和心得。以下内容整理自又拍云资深开发工程师张召现场分享:张召,资深开发工程师,目前负责又拍云CDN的刷新预热、日志处理和运维平台开发。熟悉OpenRes
最佳案例 | 游戏知几 AI 助手的云原生容器化之路
作者张路,运营开发专家工程师,现负责游戏知几AI助手后台架构设计和优化工作。游戏知几随着业务不断的拓展,游戏知几AI智能问答机器人业务已经覆盖了自研游戏、二方、海外的多款游戏。游戏知几研发团队主动拥抱云原生,推动后台业务全量上云,服务累计核心1w。通过云上的容器化部署、自动扩缩容、健康检查、可观测性等手段,提高了知几项目的持续交付能力和稳定性,形成了
AMS 新闻视频广告的云原生容器化之路
作者卓晓光,腾讯广告高级开发工程师,负责新闻视频广告整体后台架构设计,有十余年高性能高可用海量后台服务开发和实践经验。目前正带领团队完成云原生技术栈的全面转型。吴文祺,腾讯广告开发工程师,负责新闻视频广告流量变现相关后台开发工作,熟悉云原生架构在生产实践中的应用,拥有多年高性能高可用后台服务开发经验。目前正推动团队积极拥抱云原生。陈宏钊,腾讯广告高级开发工程
Crane-scheduler:基于真实负载进行调度
作者邱天,腾讯云高级工程师,负责腾讯云TKE动态调度器与重调度器产品。背景原生kubernetes调度器只能基于资源的resourcerequest进行调度,然而Pod的真实资源使用率,往往与其所申请资源的request/limit差异很大,这直接导致了集群负载不均的问题:1.集群中的部分节点,资源的真实使用率远低于resourc
性能提升,成本降低,原生数据库的崛起
腾讯高级工程师杨宇基介绍,作为国内首个云原生无服务器数据库,TDSQLC实现了自动伸缩三大目标,可以根据业务负载进行伸缩。开发者不需要提前预测负载和扩展资源;按使用量计费,按实际使用负载计费,开发者不需要为未使用的资源付费;没有使用,没有付款,没有数据请求