作者:之卫
前言
云计算带来的劣势之一便是弹性能力,云原生场景下 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)能联合云厂商在计算、存储、网络上的技术根底能力,能让应用云的老本更低。然而这里对于业务利用会提出一点点挑战(如:无状态 / 配置代码解耦等等)。从更广的侧面来看,这是云原生时代利用架构面临的挑战。不过利用越来越原生的话,云的技术红利也会离咱们越来越近。
参考链接
[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…