Kubernetes HPA 的三个误区与避坑指南-阿里云开发者社区

Kubernetes HPA 的三个误区与避坑指南

2023-01-11 445

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

本文涉及的产品

云原生网关 MSE Higress，422元/月

Serverless 应用引擎免费试用套餐包，4320000 CU，有效期3个月

服务治理 MSE Sentinel/OpenSergo，Agent数量不受限

简介： 云计算带来的优势之一便是弹性能力，云原生场景下 Kubernetes 提供了水平弹性扩容能力（HPA），让应用可以随着实时指标进行扩/缩。然而 HPA 的实际工作情况可能和我们直观预想的情况是不一样的，这里面存在一些认知误区。本文总结了一下 EDAS 用户在使用 HPA 时常遇到的三个认知误区。

作者：之卫

前言

云计算带来的优势之一便是弹性能力，云原生场景下 Kubernetes 提供了水平弹性扩容能力（HPA），让应用可以随着实时指标进行扩/缩。然而 HPA 的实际工作情况可能和我们直观预想的情况是不一样的，这里面存在一些认知误区。本文总结了一下 EDAS 用户在使用 HPA 时常遇到的三个认知误区，具体如下：

误区一：HPA 存在扩容死区

现象：当 Request=Limit 时，期望利用率超过 90%时，无法正常扩容。

原因剖析：HPA 中存在容忍度（默认为 10%），指标变化幅度小于容忍度时，HPA 会忽略本次扩/缩动作。若当期望利用率为 90%时，则实际利用率在 81%-99%之间，都会被 HPA 忽略。

避坑指南：当 Request=Limit 时，避免设置过高的期望利用率，一来避免扩容死区；二来被动扩容有一定的迟滞时间，留下更多的缓冲余量以应对突增流量。

误区二：误解利用率计算方法，HPA 扩容与预期使用量不符

现象：当 Limit > Request 时，配置 50%的利用率，使用量未达到 Limit 的 50%便扩容。

原因剖析：HPA 计算利用率是基于 Request 计算，当 Limit > Request 时，实际利用率是可以超过 100%。

避坑指南：对于较为重要的应用，应当设置 Request=Limit 保证资源的独占。对于可以容忍资源共享的应用，对应的期望利用率也不应设置的过高，在集群资源紧张时，超量使用资源的 Pod 很有可能会被杀死，从而造成服务中断。

误区三：弹性行为总是滞后的，扩缩行为与心理预期不符

现象：指标突增时，HPA 不会立刻扩容，且扩容可能是分多次进行，最终稳定时的实例数也与预期不同。

原因剖析：HPA 的设计架构决定了，HPA 扩/缩容总是滞后的，且扩/缩容收到弹性行为（behavior）与容忍度共同作用。其中弹性行为限制了扩/缩容速率，不会一口气扩/缩到期望实例数。而容忍度会忽略指标的小幅度变化，从而导致在多次扩容的场景下，最终计算的实例数可能与一开始计算出的实例数不同。

避坑指南：阅读下文了解一下 HPA 工作原理，配置合理的弹性行为（behavior）。

HPA 工作机理

在打破认知误区前，我们有必要梳理一下 HPA 的工作机理。

如图所示，HPA 控制器执行弹性功能主要分为四个步骤：

监听 HPA 资源，一旦生成 HPA 资源或者是更改 HPA 配置，HPA 控制器能及时感知并调整。
从 Metrics API 获取对应的指标数据，这里的 Metrics Server 又可以分为三类：

Kubernetes MetricServer：提供容器级别CPU/内存使用量
Custom MetricServer：提供来自Kubernetes集群自定义资源的指标数据
External MetricServer：提供来自Kubernetes集群外的指标数据

每个指标项单独计算期望实例数，最后取所有期望实例数中的最大值，作为当前工作负载的期望实例数
调整对应的工作负载

其中步骤 2-4 约每 15 秒执行一次，如需改变时间周期，可以调整 KCM 的配置参数--horizontal-pod-autoscaler-sync-period。

数据源

如上图所示，HPA 目前提供了五种指标来源，以及三种指标服务（MetricsServer），简单介绍如下：

Resource：提供 Pod 级别的 CPU/内存使用量
ContainerResource：提供容器级别的 CPU/内存使用量
Object：提供 Kubernetes 集群内任意资源的相关指标
Pods：提供 Kubernetes集群内 pod 相关的指标
External：提供 Kubernetes 集群外的指标数据

值得一提的是，在自建 Kubernetes 场景下，这三种 MetricsServer 都需要额外安装，它们均运行于 KCM 之外。下表列举了几种 Kubernetes 集群 MetricsServer 的部署情况。

	自建Kubernetes	阿里云容器服务	EDAS托管集群
Kubernetes MetricsServer	手动安装	自动安装	自动安装
Custom MetricsServer（如Prometheus Adapter）	手动安装	手动安装	手动安装
External MetricsServer（如KEDA）	手动安装	手动安装	自动安装

指标计算方法

HPA 提供了三种期望值类型：

总量（Value）
平均量（AverageValue）= 总量 / 当前实例数
利用率（Utilization）= 平均量 / Request

值得一提的是，利用率是基于 Request 进行计算的，所以没有设置 Request 的场景下，HPA 可能无法正常工作。

下图介绍了五种指标来源支持的期望类型，不难看出所有指标来源都支持平均量。

对于单个指标的期望实例数计算规则如下：

这里面引入了容忍度的概念，即认为在期望值附近小范围的抖动是可以容忍忽略的。这个参数的来源是因为指标值是一个一直在抖动变化的值，如果不忽略微小的变动，那么很有可能造成应用不断的扩容缩容，进而影响整个系统的稳定性。

如下图所示，当指标值落入粉色区域内（容忍度范围）时，期望实例数等于当前实例数。粉色区域（容忍度范围）的上下限分别是 0.9 倍期望值与 1.1 倍期望值。

对于配置了多条指标规则，最终期望实例数计算规则如下：

其中 target1, ..., target n 分别是每个指标计算出来的期望实例数。

用一句话简要概括计算方法：单个指标波动小时忽略不计，多个指标之间取最大值，最终实例数会落在下限和上限之间。

扩缩行为

在某些情况下，指标数据会有一个频繁且大幅度的抖动。如下图所示的一段 CPU 指标数据，存在一些指标抖动或间歇流量下降导致利用率下降，指标的变化范围已经超出了容忍度的范围。此时，从应用稳定性角度来看，我们不期望应用缩容。为了解决这个问题，HPA引入了配置来控制扩缩容，即扩缩行为（behavior），它是在HPA（autoscaling/v2beta2）中引入，要求 Kubernetes 集群版本>=1.18。

HPA 的弹性行分为扩容行为和缩容行为。行为具体由以下三部分组成：

稳定窗口：稳定窗口会参考过去一段时间计算出的期望实例数，选取极值作为最终结果，从而保证系统在一段时间窗口内是稳定的。对于扩容取极小值，对于缩容取极大值。
步长策略：限制一段时间内实例变化的范围。由步长类型、步长值、时间周期三个部分组成。值得一提的是时间周期这个概念与上述的稳定窗口是两回事，此处的时间周期定义了回溯多长历史时间，计算实例数变化情况。
选择策略：用于选取多个步长策略计算后的结果，支持取最大值、取最小值、关闭这三种策略。

回顾与总结

至此，我们已经大致了解了 HPA 的工作机理。合理利用 HPA 可以有效提升资源利用率，在这之中我们总结了一些注意事项，熟记这些点可以在使用 HPA 时“有效避坑”。

HPA 的设计架构导致了 HPA 只能被动响应指标进行弹性扩缩，这种模式下，弹性滞后是一定存在的。目前阿里云容器服务推出了带预测能力的 AHPA，可以有效减少弹性迟滞。
HPA 的利用率计算方法是基于 Request，实际利用率/期望利用率超过 100%是正常的，配置较高的期望利用率需要合理规划集群资源和审视相应风险。
HPA 中的容忍度概念能缓解指标波动带来的系统震荡问题，但与此同时引入的扩容死区问题需要运维人员避开。
HPA 的设计架构允许扩展各种类型指标，需要开发/安装相应的 MetricsServer，如 EDAS 则为用户提供了微服务 RT 和 QPS 指标。
HPA 中存在扩缩容行为，即使不配置相应参数也有默认行为，扩容行为的稳定窗口默认是 0，如果应用常因噪声数据造成扩容，可以设置一个较短的扩容稳定窗口规避尖锐噪声。
单个 HPA 支持配置多个指标进行弹性，切勿对单个应用配置多个 HPA，会相互影响，导致应用震荡。

云原生场景下弹性能力更为丰富，可供弹性的指标也更具备业务定制能力。应用 PaaS 平台（如企业级分布式应用服务 EDAS）能结合云厂商在计算、存储、网络上的技术基础能力，能让使用云的成本更低。但是这里对于业务应用会提出一点点挑战（如：无状态/配置代码解耦等等）。从更广的侧面来看，这是云原生时代应用架构面临的挑战。不过应用越来越原生的话，云的技术红利也会离我们越来越近。