Kubernetes HPA 的三个误区与避坑指南
01
前言
Aliware
云计算带来的优势之一便是弹性能力,云原生场景下 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 工作机理
Cloud Native
在打破认知误区前,我们有必要梳理一下 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。
01
数据源
如上图所示,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) |
手动安装 |
手动安装 |
自动安装 |
02
指标计算方法
HPA 提供了三种期望值类型:
总量(Value)
平均量(AverageValue)= 总量 / 当前实例数
利用率(Utilization)= 平均量 / Request
值得一提的是,利用率是基于 Request 进行计算的,所以没有设置 Request 的场景下,HPA 可能无法正常工作。
下图介绍了五种指标来源支持的期望类型,不难看出所有指标来源都支持平均量。
对于单个指标的期望实例数计算规则如下:
这里面引入了容忍度的概念,即认为在期望值附近小范围的抖动是可以容忍忽略的。这个参数的来源是因为指标值是一个一直在抖动变化的值,如果不忽略微小的变动,那么很有可能造成应用不断的扩容缩容,进而影响整个系统的稳定性。
如下图所示,当指标值落入粉色区域内(容忍度范围)时,期望实例数等于当前实例数。粉色区域(容忍度范围)的上下限分别是 0.9 倍期望值与 1.1 倍期望值。
对于配置了多条指标规则,最终期望实例数计算规则如下:
其中 target1, ..., target n 分别是每个指标计算出来的期望实例数。
用一句话简要概括计算方法:单个指标波动小时忽略不计,多个指标之间取最大值,最终实例数会落在下限和上限之间。
03
扩缩行为
在某些情况下,指标数据会有一个频繁且大幅度的抖动。如下图所示的一段 CPU 指标数据,存在一些指标抖动或间歇流量下降导致利用率下降,指标的变化范围已经超出了容忍度的范围。此时,从应用稳定性角度来看,我们不期望应用缩容。为了解决这个问题,HPA引入了配置来控制扩缩容,即扩缩行为(behavior),它是在HPA(autoscaling/v2beta2)中引入,要求 Kubernetes 集群版本>=1.18。
HPA 的弹性行分为扩容行为和缩容行为。行为具体由以下三部分组成:
稳定窗口:稳定窗口会参考过去一段时间计算出的期望实例数,选取极值作为最终结果,从而保证系统在一段时间窗口内是稳定的。对于扩容取极小值,对于缩容取极大值。
步长策略:限制一段时间内实例变化的范围。由步长类型、步长值、时间周期三个部分组成。值得一提的是时间周期这个概念与上述的稳定窗口是两回事,此处的时间周期定义了回溯多长历史时间,计算实例数变化情况。
选择策略:用于选取多个步长策略计算后的结果,支持 取最大值、取最小值、关闭 这三种策略。
03
回顾与总结
Aliware
至此,我们已经大致了解了 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-sigs/prometheus-adapter
[2] KEDA
https://github.com/kedacore/keda
[3] HorizontalPodAutoscaler Walkthrough
https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/
[4] Resource metrics pipeline
https://kubernetes.io/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/
[5] Horizontal Pod Autoscaling
https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
[6] HPA 常见问题与诊断
https://help.aliyun.com/document_detail/186980.html
[7] EDAS 自动弹性扩缩容
https://help.aliyun.com/document_detail/178448.html
扩展阅读
Horizontal Pod Autoscaler with Arbitrary Metrics
https://github.com/kubernetes/design-proposals-archive/blob/main/autoscaling/hpa-v2.md
Kubernetes HPA 的三个误区与避坑指南相关推荐
- 新媒体运营教程:需求管理的避坑指南,主要需求分布在三个阶段!
B端产品在需求搜集.分析.迭代上线的方法上与C端大同小异,但由于B端产品使用对象的角色多样性,跨部门协作的流程复杂性,B端产品的需求管理相比于C端"坑"更多. 作为一名B端产品运营 ...
- 跨境电商选品避坑指南-成都扬帆凌远跨境电商
跨境电商选品避坑指南-成都扬帆凌远跨境电商 除了台湾的气候和我们差不多,其他国家都是夏天(雨季多,天气常年炎热) 可以围绕雨季用品做一个小类别的店铺: 雨衣(轻薄,运费低,款式多,价格差异大,利润可操 ...
- Serverless 时代前端避坑指南
作者 | 张挺 每个时代,从来不缺机会. 云原生的浪潮席卷而来,从 14 年到现在,上云的声音就没有停歇过,而如今到了 2020,云厂商都已经准备好了,而前端,是否也准备好踏入这纷争的领域,去拥抱时代 ...
- 项目从0到1避坑指南
背景: 物流行业,老板信息化意识弱,不是现有的TMS而是一个新的方向,目前市场上竞品较少 前言: 一个项目从0到1,有相关的固定的考虑事项.然而,由于公司环境.项目涉及的行业等一些实际条件的约束,会在 ...
- HarmonyOS 开发避坑指南
Harmony OS 开发避坑指南--源码下载和编译 本文介绍了如何下载鸿蒙系统源码,如何一次性配置可以编译三个目标平台(Hi3516,Hi3518和Hi3861)的编译环境,以及如何将源码编译为三个 ...
- boot spring 解析csv_spring-boot-starter-thymeleaf 避坑指南
spring-boot-starter-thymeleaf 避坑指南 spring-boot-starter-thymeleaf 避坑指南 第一步:pom配置环境 先不要管包是做什么的 总之必须要有 ...
- hive 增加表字段语录_Hive改表结构的两个坑|避坑指南
Hive在大数据中可能是数据工程师使用的最多的组件,常见的数据仓库一般都是基于Hive搭建的,在使用Hive时候,遇到了两个奇怪的现象,今天给大家聊一下,以后遇到此类问题知道如何避坑! 坑一:改变字段 ...
- ext列表禁止滑动_后台列表设计避坑指南(下)
编辑导语:列表页是后台界面的重要组成之一,上篇说了后台列表设计的"搜索"设计(详情见:后台列表设计避坑指南 上):本篇继续讲剩下的两个部分的"坑"和必坑指南,我 ...
- @程序员,区块链开发平台避坑指南!
来源 | Michiel Mulders 译者 | 火火酱 责编 | Carol 出品 | 区块链大本营(blockchain_camp) 市面上有很多不同的区块链网络,就可扩展性和功能而言,每个区块 ...
最新文章
- 干货 | 浅谈 Softmax 函数
- Spring_hibernate整合初步 based in annotation
- web 点击劫持 X-Frame-Options
- 数据库经典书籍--数据库系统概念
- flash java 通信_FLASH与服务器通讯 (JAVA)
- 【企业管理】2019年11 月 每日花语
- 【Python】函数外定义变量并在函数内进行更新
- 卓京计算机学校,卓京--计算机数据原理课程设计任务书.doc
- 敬业福和花花卡算啥?这次不来,你亏了
- Qt多线程-QThreadPool线程池与QRunnable
- linux模拟发包工具,linux发包软件-线不是一个压力测试工具的linux以上收缩服务器可...
- c语言 word转pdf,批量Word转PDF之捷径
- 解读 PackageManager.resolveActivity
- hadoop的filesplit
- 天王表的网络营销战略
- 盘一盘那些提效/创意的宝藏网站
- php后台腾讯地图显示折线图
- 二维码生成插件qrious(纯JS)
- postgresql java驱动_PostgreSQL的JDBC驱动和URL
- 计算机产业能否迅速发展,工业计算机得到了迅速的发展和全面的普及