共计 3149 个字符，预计需要花费 8 分钟才能阅读完成。
前言
云计算带来的劣势之一便是弹性能力，云原生场景下 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 的部署状况。
指标计算方法
HPA 提供了三种期望值类型
- 总量（Value）
- 均匀量（AverageValue）= 总量 / 以后实例数
- 利用率（Utilization）= 均匀量 / Request
值得一提的是，利用率是基于 Request 进行计算的，所以没有设置 Request 的场景下，HPA 可能无奈失常工作。
下图介绍了五种指标起源反对的冀望类型，不难看出所有指标起源都反对均匀量。
对于单个指标的冀望实例数计算规定如下：
这外面引入了容忍度的概念，即认为在期望值左近小范畴的抖动是能够容忍疏忽的。这个参数的起源是因为指标值是一个始终在抖动变动的值，如果不疏忽渺小的变动，那么很有可能造成利用一直的扩容缩容，进而影响整个零碎的稳定性。
如下图所示，当指标值落入粉色区域内（容忍度范畴）时，冀望实例数等于以后实例数。粉色区域（容忍度范畴）的上上限别离是 0.9 倍期望值与 1.1 倍期望值。
对于配置了多条指标规定，最终冀望实例数计算规定如下：
用一句话简要概括计算方法：单个指标稳定小时忽略不计，多个指标之间取最大值，最终实例数会落在上限和下限之间。
扩缩行为
在某些状况下，指标数据会有一个频繁且大幅度的抖动。如下图所示的一段 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）能联合云厂商在计算、存储、网络上的技术根底能力，能让应用云的老本更低。然而这里对于业务利用会提出一点点挑战（如：无状态 / 配置代码解耦等等）。从更广的侧面来看，这是云原生时代利用架构面临的挑战。不过利用越来越原生的话，云的技术红利也会离咱们越来越近。
原文链接
本文为阿里云原创内容，未经容许不得转载。
