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