AHPA 弹性预测最佳实践

在云原生场景下，资源容量往往难以预估，而使用 K8s 原生的 HPA，往往要面对弹性滞后以及配置复杂问题。阿里云容器服务与达摩院决策智能时序团队合作推出的 AHPA（Advanced Horizontal Pod Autoscaler）弹性预测，可以根据业务历史指标，自动识别弹性周期并对容量进行预测，帮你提前进行弹性规划，解决弹性滞后的问题。 AHPA 如何配置才能解锁最佳使用姿势？本文给你带来  AHPA 弹性预测最佳实践。接下来将从如下方面展开介绍：

• AHPA 弹性预测介绍
• 指标源及AHPA配置参数介绍
• 边界保护的适用情况
• 利用降噪、算法分位数可以做哪些事情
• 典型场景：从 HPA 转 AHPA
• 典型场景：弹性推荐

AHPA 弹性预测介绍

为什么要做弹性预测，首先当前应用存在冷启动的问题，我们可以看一下应用启动阶段包括资源调度、拉镜像、容器创建、容器启动以及应用启动。冷启动除了要解决 IaaS 资源的分配、Kubernetes 的调度、拉镜像等问题以外还涉及到应用的启动时长。应用启动时长从毫秒到分钟级别都有。应用启动时间这完全是业务行为，在底层平台层面几乎无法控制。

此外当前通用的弹性方案面临如下问题，可用性差，无法预估容量，少了不够，多了浪费。稳定性风险弹性之后，配置固化，易用性差，配置繁琐，如定时的CronHPA, 需要评估每个时间段扩容多少，缩容多少，并且随着业务的变化需要随时进行调整。

我们思考弹性核心要解的问题：在提升资源使用率的同时，保障业务的稳定性。

那么我们如果能够根据历史数据，通过机器学习算法，提前预测未来需要多少资源，那么就可以避免上述的问题。围绕这个思路，我们需要做哪些事情呢？

首先要有历史指标数据，数据是预测的前提，然后需要预测算法，通过算法提前预测未来的需要多少资源，最后生效在工作负载上。我把他归纳为弹性预测三元组。当然我们目标是：资源提前预热、自动弹性规划、同时能够支持弹性降级，保证稳定性。

方案实现如下：

• 丰富的数据指标：支持包括CPU、Memory、QPS、RT以及外部指标等
• 稳定性保障：AHPA的弹性逻辑基于主动预热、被动兜底的策略，并结合降级保护，保证了资源稳定。

• 主动预测：根据历史预测出未来一段时间的趋势结果，适用于周期性的应用。
• 被动预测：实时预测。针对突发流量场景，通过被动预测实时准备资源。
• 降级保护：支持配置多个时间区间范围最大、最小实例。

• 多种伸缩方式：AHPA支持伸缩方式包括Knative、HPA以及 Deployment：

• Knative：解决 Serverless 应用场景下，基于并发数/QPS/RT 弹性冷启动的问题
• HPA：简化 HPA 弹性策略配置，降低用户使用弹性的门槛，解决使用 HPA 面临的冷启动的问题
• Deployment：直接使用Deployment，自动扩缩容

优势体现：

通过AHPA我们可以做到毫秒级预测、秒级弹性，对于复杂周期识别率到达95%以上，同时支持鲁棒性以及分钟级别边界保护配置。

AHPA 最佳实践配置

指标源配置

首先介绍指标源配置，这里我们通过ConfigMap配置相应的指标源，具体如下

apiVersion: v1
kind: ConfigMap
metadata:
  name: application-intelligence
  namespace: kube-system
data:
  armsUrl: https://cn-beijing.arms.aliyuncs.com:9443/api/v1/prometheus/xxx/1581204543170042/xxx/cn-beijing
  token: xxxx
  realtimesource： metric-server

参数说明：

AdvancedHorizontalPodAutoscaler 配置

在 AHPA 中我们通过 AdvancedHorizontalPodAutoscaler 配置弹性策略、目标对象以及扩缩容时间边界。具体如下：

apiVersion: autoscaling.alibabacloud.com/v1beta1
kind: AdvancedHorizontalPodAutoscaler
metadata:
  name: ahpa-demo
spec:
  scaleStrategy: observer
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  maxReplicas: 100
  minReplicas: 2
  prediction:
    quantile: 95
    scaleUpForward: 180
  instanceBounds:
  - startTime: "2021-12-16 00:00:00"
    endTime: "2022-12-16 00:00:00"
    bounds:
    - cron: "* 0-8 ? * MON-FRI"
      maxReplicas: 15
      minReplicas: 4
    - cron: "* 9-15 ? * MON-FRI"
      maxReplicas: 15
      minReplicas: 10
    - cron: "* 16-23 ? * MON-FRI"
      maxReplicas: 20
      minReplicas: 15

参数说明：

指标预处理

由于指标数据质量参差补齐，在AHPA中我们需要对指标进行预处理，包括指标去重、指标补齐以及指标清洗。在应用启动时，往往遇到启动过程中CPU使用率比较高的现象，以java应用为例，类加载过程是比较耗CPU。这样的情况其实不是业务流量本身造成的，因此对于这类指标是不需要参与预测指标输入的，需要清洗过滤掉。因此通过指标预处理，剔除这部分预测干扰。

边界保护配置的灵活使用

在AHPA 中，可以设置不同时间段的最大值和最小值，这样即使遇到指标异常或者弹性预测不准的情况下，也能有兜底的策略。

apiVersion: autoscaling.alibabacloud.com/v1beta1
kind: AdvancedHorizontalPodAutoscaler
metadata:
  name: ahpa-demo
spec:
  …
  maxReplicas: 100
  minReplicas: 2
  instanceBounds:
  - startTime: "2021-12-16 00:00:00"
    endTime: "2022-12-16 24:00:00"
    bounds:
    - cron: "* 0-8 ? * MON-FRI"
      maxReplicas: 15
      minReplicas: 4
    - cron: "* 9-15 ? * MON-FRI"
      maxReplicas: 15
      minReplicas: 10
    - cron: "* 16-23 ? * MON-FRI"
      maxReplicas: 20
      minReplicas: 15

除了可以进行分钟级别保护之后，利用边界保护配置，可以做到定时弹性或者资源应急准备。也就是如果在某个时间段需要大量的资源（用于突发流量应急、压测等），可以通过调整这个时间段的最小资源，保障这个时间段的资源水位。

利用分位数可以做哪些事情

在 AHPA 中可以设置预测的分位数 quantile ，这个值表示业务指标实际值低于设定目标值的概率,越大表示越保守,取值范围 0～1。越大表示越保守的意思是，值越大表示超出目标设置的数值点越少，也就意味着牺牲更多的资源。但有的业务其实超出一部分目标指标也是可以接受的，这样的情况下也是可以将这个值调低一些。默认推荐值是0.95

典型场景：从HPA转AHPA

客户痛点：当前使用 HPA， 由于应用存在冷启动的问题，导致CPU使用率无法提升。

解决方案：通过 AHPA 预测，资源预热，提升CPU使用率

上线前后使用情况对比：

•CPU使用率：较上线提高 9%

•资源成本：成本节省比例 28.68%

典型场景：弹性推荐

客户痛点： 现有弹性方案无法与自身 PaaS 平台结合，期望只做规划不进行生效。

解决方案：通过 AHPA 预测未来24小时Pod实例数，给出弹性规划，不做生效。实际弹性生效由客户自身 PaaS 平台确定执行。

获取配置推荐命令：

kubectl get --raw '/apis/metrics.alibabacloud.com/v1beta1/namespaces/default/predictions/fib-deployment'

参数说明：

小结

当前阿里云容器服务 AHPA 已产品化上线，点击此处了解产品使用详情。