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

2023-01-11
浙江
本文字数：3259 字
阅读完需：约 11 分钟

作者：之卫

前言

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

误区一：HPA 存在扩容死区

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

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

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

1.jpeg

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

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

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

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

2.jpeg

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

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

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

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

3.jpeg

HPA 工作机理

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

4.jpeg

如图所示，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。

数据源

5.jpeg

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

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

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

指标计算方法

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

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

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

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

6.jpeg

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

7.png

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

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

8.jpeg

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

9.png

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

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

扩缩行为

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

10.jpeg

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

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

11.jpeg

回顾与总结

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

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

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