开发者学堂课程【AHPA 弹性预测最佳实践：容器服务 AHPA 弹性预测最佳实践-元毅】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/989/detail/15077
容器服务AHPA弹性预测最佳实践-元毅
前言
云原生场景下资源容量难以预估，使用 K8S 原生 HPA，面对弹性后配置复杂问题。
阿里云容器服务与智能决策算法团队合作推出 AHPA 弹性预测，可根据业务历史指标自动识别弹性周期并对容量进行预测，帮助提前进行弹性规划，解决弹性周的问题，AHPA 配置解锁最佳使用方式。
目录
一、AHPA 弹性预测介绍
二、指标源及 AHPA 配置参数介绍
三、边界保护的适用情况
四、降噪、算法分位数
五、典型场景:从 HPA 转 AHPA
六、典型场景:弹性推荐
一、AHPA 弹性预测介绍
1.弹性预测，应用冷启动问题
库冷启动过程大致如下
拉镜像、应用启动相对耗时长的阶段，不可预测。
当前弹性方案面临的问题
应用实例数评估困难，少了不够，多了浪费。稳定性风险，K8s原生HPA负载后弹，存在弹性滞后问题。CronHPA 定时弹性，可配置定时的时间段做弹性。随着业务变化，配置的时间段不能满足突发的资源诉求，带来稳定性风险。HPA 和 CronHPA 配置繁琐，HPA 需要知道当前应用阈值，需要不停尝试阈值，找到平衡点。随着业务变化，业务处理能力在变化，阈值可能变化，通用性较差，用户对资源成本诉求强烈。
HPA 和 CronHPA 弹性手段，不可避免的引入成本风险且复杂的问题，希望通过弹性预测解决。
2.弹性预测做什么事情
弹性预测三元组，指标数据、预测算法、工作负载。
预测把历史的业务指标做依据，有依据后找预测算法做，与专业智能决策算法团队做一次算法，结合预测算法，作用在相应的工作负载上做弹性预测。
3.目标
资源提前预热，做到实时容量调整。自动弹性规划，无需人工干预。弹性稳定性在及时生效情况下做到容错保护，兜底方案。
4.弹性预测实现方式
指标源，支持性能指标、流量指标、自定义指标。性能指标 CPU、memory，流量指标包括 RDQPS。预测配置提供给用户配置，可提供配置的工作负载和算法策略给用户。
AHPA 弹性预测的实现包括指标收集、数据分析、算法模块。从指标源收集数据，数据预处理详解到去重、数据清洗。结合补偿机制，补齐指标。指标采集后放到指标缓存里，提供给数据分析。数据分析有两部分，主动预测分析和被动预测分析。主动预测分析根据历史7天的指标，主动预测未来24小时的趋势。被动预测分析是实时预测分析，可拿最近五分钟的数据做实时的预测。调主动预测分析和被动预测分析模块，拿到主动预测分析和被动预测分析结果后，结合置时间区间最大最小值的边界配置，计算弹性执行的值，作用到工作负载。工作负载支持 Deployment、StatefulSet、HPA、Knative,可结果server
less平台进行弹性生效。
通过多指标源支持，主/被动预结合，多功能负载实现弹性预测。
5.AHPA 弹性预测优势体现
弹的更快，可毫秒级预测、秒级弹性，调用预制算法，秒级区进行弹性生效。
更准，可在多周期情况下，通过算法达到95%的周期性识别率，被动和主动相结合让弹性更准。
更稳，算法支持鲁棒性，数据有一段时间缺失，可容忍错误。细粒度边界设置，区间可做到分钟级别设置。
二、指标源及 AHPA 配置参数介绍
1.指标源配置
apiVersion: v1
kind: ConfigMap
metadata:
name: application-intelligence
namespace: kube-system
data:
armsUri:https://cn-beiing.arms.aliyuncs.com:9443/api/v1/prometheus/xxx/1581204543170042/xxx/cn-beijing
token: xxxx
realtimesource:metric-server
可在 ConfigMap 里做配置，包括三部分内容。配置历史指标源的Url 参数，通过此参数，可拿到历史。Token 根据 Promethues 配置的 token，推荐使用 token，更安全。没有设置 token，直接拿数据。实时数据源，实时指标可通过 realtimesource 或 metric-server，使用 serverless K8S 时，可不使用 metric-server，直接使用 VK。
AdvancedHorizontalPodAutoscaler 配置
弹性生效策略，目前支持 observer、auto，observer 确认模式，只做观察，不做生效，推荐上线先使用观察模式，观察后判断预测结果是否符合预期，符合预期开启 auto 模式。
Metric 定义指标、名称、阈值，cpu、memory、qps、rt
弹性工作负载支持 Deployment、HPA、Knative 平台。
预测分位数，表示业务指标实际值低于设定目标值的概率，越大表示越保守，两位小数，0~1。实例目标值50%，设置50%cpu目标值，分位数是否趋近50%，越靠近1，表示实际值大概率低于目标设定值。99%低于50%设定值，90是90%低于，10%超过值。值作用根据实际业务设置，业务思维使用率高，可设置的不保守。思维使用率严格控制在50%以下，cpu 很敏感，值可设置相对保守。
Pod 冷启动时间，通过冷静启动时间决定提前的预测时间，值建议配置，不配置拿当前正在运行的 Pod 当前生命周期和计算 Pod 迭代时间。
扩缩容边界区间，推荐配置，设置时间范围内的最大最小值。
2.指标预处理
指标去重，分钟级别去除重复的指标。指标补齐，指标缺失，指挥补齐。指标清洗，在启动时消除冷启动 cpu 毛刺。
某一时刻有 CPU 明显波动，此时刻有 Pod 创建，Pod 创建本身是Java 的应用，应用启动过程中涉及到 Java 的类加载，消耗大量 CPU，造成此时刻 CPU 的递增。不是实际业务的 CPU 指标，没必要拿指标做预测。针对冷启动 CPU 毛刺，指标清洗时剔除。剔除后，此时刻是平滑的数据，算法更可靠。
三、边界保护的适用情况
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
maxReplicas:15
可做时间区间的保护，某个时间段可设置最大值最小值，在最大最小值范围内进行扩缩容，起到边界保护作用。可设置时间段和分钟级别的时间点，如果结合最大值最小值设为一样，退化成定时弹性，可在某个时间段内处于固定的时位数。应急资源准备，某一时间段内需要大量做准备，可预期的时间段和时间点，时间段内设置资源，通过最大最小值设最高值，做资源的体现准备。边界保护除时间段保护外，可做定时弹性和应急资源准备。
四、降噪、算法分位数
提供用户降噪能力可通过设置降噪函数，剔除毛刺。降噪与数据清洗区别，数据清洗里清洗可预期的数据，非可预期的不知道造成毛刺的原因，可通过降噪的方式，算法上去除。
某个业务范围未知的抖动，网络或其它因素导致的负载，引起CPU波动，此类毛刺可通过降噪的方式去除。
分位数可做到平衡 CPU 使用率和业务稳定性的作用，可通过分位数确定，CPU 敏感分位数可设置相对保守，更多落在设定的 CPU 目标阈值下，Pod 数资源多，保证业务更加稳定。
CPU 超过目标阈值之上，可忍受波动。设置更小，用更少的资源，平衡 CPU 使用率和业务稳定性的手段。
五、典型场景:从 HPA 转 AHPA
用户之前使用原生的 K8S HPA 转到 AHPA 弹性预测
痛点，使用 HPA，应用存在冷启动的问题，导致 CPU 使用率无法提升。应用承载 CPU 使用率40%，本身存在冷启动问题，导致 HPA受到弹性负载出发后开始弹，弹的过程中，业务量上升，如果 HPA按40%设置，CPU 使用率达到50%，超出承受范围，使用 HPA 设置比较低的值做缓冲，取小的方式。使用自动弹性，不影响业务稳定性。CPU 在 HPA 里不敢配置较高，导致 CPU 使用率无法提升。
HPA 弹性使用原理，黑色表示实际业务请求量，蓝色表示 HPA 弹性，灰色表示实际 Pod 数，业务量上升后触发到 HPA 弹性，弹的过程中业务上量，导致本身业务不稳定出现。弹的过程区间导致本身应用负载比较高，甚至超出承受范围，AHPA 解决了 HPA 的问题。同样一个线，业务到来前，根据冷启动时间，提前准备资源，到时刻有充足的资源满足业务负载。使用 AHPA 弹性预测方案，上线前后对比，CPU 使用率较上线前提高9%，资源成本节省比例28.68%。
绿色线表示平均 CPU 使用率，整体比较稳定。红线暗含趋势，Pod数逐渐上升，业务量上升，自动扩容做。保证 CPU 使用率和投资资源，满足业务负载。AHPA 带来自动弹性规划，免去人工干预。中间Pod 数有平稳的阶段，是一段时间做重度的资源规划，满足压缩环境，此时间段通过边界保护，设置固定时间解决资源准备情况，是AHPA 带来的额外能力。
六、典型场景:弹性推荐
痛点：自身的 PaaS 平台想与 WEB 方案相结合，现有 HPA 弹性生效没有提高规划和生效。
AHPA 提高弹性生效的能力，可以通过 AHPA 做规划，不进行生效。
kubectl get --raw/apis/metrics.alibabacloud.com/v1beta1/namespaces/default/predictions/fibdeployment
通过 K8S 原生 api 暴露接口，可拿到三个参数。
periodicity 可判断当前应用是否有周期性，未来24小时的预测结果。当前推荐的 Pod 数，将主动被动、未来24小时预测的当前时刻值、当前实时的结果、边界保护配置的区间做计算，最终有当前推荐生效配置 Pod 数。
示例
spec:
instanceBounds:
-bounds:
-cron:'* 0-8 ? * MON-FRI'
maxReplicas:50
minReplicas:4
-cron:'* 9-15 ? * MON-FRI'
maxReplicas:50
minReplicas:10
-cron:'* 16-23 ?* MON-FRI
maxReplicas:50
minReplicas:12
-resource:
name:cpu
target:
averageUtilization:50
type: Utilization
type: Resource
minReplicas: 0
prediction:
quantile: 95
scaleUpForward:180
scaleStrategy: observer
scaleTargetRef:
apiVersion:apps/v1
kind: Deployment
name:fib-deployment
richard@B-N3TEMD6P-1650 demo %
跑 HPA 弹性预测资源，设置边界保护的区间范围，时间保护区间不能设置重叠。设置重叠，有不断抖动情况发生。CPU 阈值50%，分位数95，冷启动时间3分钟，作用于 deployment 上。弹性生效策略观察模式，可看到预测的趋势。
richard@B-N3TEMD6P-1650 demo % kubectl get--raw'/apis/metrics.alibabacloud.com/v1beta1/namespaces/default/predictionsobserver/fib-deployment'ljq -r'.content' lbase64 -d >observer.html
登录接口可拿到预测趋势的结果，分析。
CPU使用率如下
CPU 使用量如下，绿色线是预测的 CPU 使用量，蓝色线是实际的CPU 使用量，预测量可满足当前实际诉求。
Pod 数如下，绿色线低于蓝色线，更少的 Pod 数满足实际 CPU 使用量。
整体有周期性，预测结果符合周期性预测，可做 photo 生效。
配置推荐，另一个接口。接口内容有未来小时，每分钟 Pod 数的推荐结果，当前是否有周期性。推荐 Pod 数，时间点时刻的 Pod 数是多少，数据结合主动和被动，实时、边界保护的值，三个值作用实际生效的结果。
{"timestamp":1656507480,"podnum":18},{"timestamp":1656507540,"podnum":18},{"timestamp":1656507600,"podnum":17}],"recommend_pod_series":[{"timestamp":1656422460,"cpu":0.168,"podnum":35}],"periodicity":1}
richard@B-N3TEMD6P-1650 demo %
