关于阿里云:Kubernetes-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 控制器执行弹性性能次要分为四个步骤：

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

<!—->

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

<!—->

4. 每个指标项独自计算冀望实例数，最初取所有冀望实例数中的最大值，作为当前工作负载的冀望实例数 
5. 调整对应的工作负载 

其中步骤 2-4 约每 15 秒执行一次，如需扭转工夫周期，能够调整 KCM 的配置参数 –horizontal-pod-autoscaler-sync-period。

数据源

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

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

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

指标计算方法

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

1. 总量（Value）
2. 均匀量（AverageValue）= 总量 / 以后实例数
3. 利用率（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 时“无效避坑”。

1. HPA 的设计架构导致了 HPA 只能被动响应指标进行弹性扩缩，这种模式下，弹性滞后是肯定存在的。目前阿里云容器服务推出了带预测能力的 AHPA，能够无效缩小弹性通畅。
2. HPA 的利用率计算方法是基于 Request，理论利用率 / 冀望利用率超过 100% 是失常的，配置较高的冀望利用率须要正当布局集群资源和扫视相应危险。
3. HPA 中的容忍度概念能缓解指标稳定带来的零碎震荡问题，但与此同时引入的扩容死区问题须要运维人员避开。
4. HPA 的设计架构容许扩大各种类型指标，须要开发 / 装置相应的 MetricsServer，如 EDAS 则为用户提供了微服务 RT 和 QPS 指标。
5. HPA 中存在扩缩容行为，即便不配置相应参数也有默认行为，扩容行为的稳固窗口默认是 0，如果利用常因噪声数据造成扩容，能够设置一个较短的扩容稳固窗口躲避尖利噪声。
6. 单个 HPA 反对配置多个指标进行弹性，切勿对单个利用配置多个 HPA，会相互影响，导致利用震荡。

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

参考链接

[1] Prometheus Adapter

https://github.com/kubernetes…

[2] KEDA

https://github.com/kedacore/keda

[3] HorizontalPodAutoscaler Walkthrough

https://kubernetes.io/docs/ta…

[4] Resource metrics pipeline

https://kubernetes.io/docs/ta…

[5] Horizontal Pod Autoscaling

https://kubernetes.io/docs/ta…

[6] HPA 常见问题与诊断 *

https://help.aliyun.com/docum…

[7] EDAS 主动弹性扩缩容

https://help.aliyun.com/document_detail/178448.html

扩大浏览

Horizontal Pod Autoscaler with Arbitrary Metrics

https://github.com/kubernetes…