优化Kubernetes横向扩缩HPA

2024-08-23 20:58

本文主要是介绍优化Kubernetes横向扩缩HPA,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

Pod水平自动扩缩(Horizontal Pod Autoscaler, 简称HPA)可以基于 CPU/MEM 利用率自动扩缩Deployment、StatefulSet 中的 Pod 数量,同时也可以基于其他应程序提供的自定义度量指标来执行自动扩缩。默认HPA可以满足一些简单场景,对于生产环境并不一定适合,本文主要分析HPA的不足与优化方式。

HPA Resource类型不足

默认HPA提供了Resource类型,通过CPU/MEM使用率指标(由metrics-server提供原始指标)来扩缩应用。

使用率计算方式

在Resource类型中,使用率计算是通过request而不是limit,源码如下:

// 获取Pod resource request
func calculatePodRequests(pods []*v1.Pod, resource v1.ResourceName) (map[string]int64, error) {requests := make(map[string]int64, len(pods))for _, pod := range pods {podSum := int64(0)for _, container := range pod.Spec.Containers {if containerRequest, ok := container.Resources.Requests[resource]; ok {podSum += containerRequest.MilliValue()} else {return nil, fmt.Errorf("missing request for %s", resource)}}requests[pod.Name] = podSum}return requests, nil
}
// 计算使用率
func GetResourceUtilizationRatio(metrics PodMetricsInfo, requests map[string]int64, targetUtilization int32) (utilizationRatio float64, currentUtilization int32, rawAverageValue int64, err error) {metricsTotal := int64(0)requestsTotal := int64(0)numEntries := 0for podName, metric := range metrics {request, hasRequest := requests[podName]if !hasRequest {// we check for missing requests elsewhere, so assuming missing requests == extraneous metricscontinue}metricsTotal += metric.ValuerequestsTotal += requestnumEntries++}currentUtilization = int32((metricsTotal * 100) / requestsTotal)return float64(currentUtilization) / float64(targetUtilization), currentUtilization, metricsTotal / int64(numEntries), nil
}

通常在Paas平台中会对资源进行超配,limit即用户请求资源,request即实际分配资源,如果按照request来计算使用率(会超过100%)是不符合预期的。相关issue见72811,目前还存在争论。可以修改源码,或者使用自定义指标来代替。

多容器Pod使用率问题

默认提供的Resource类型的HPA,通过上述方式计算资源使用率,核心方式如下:

metricsTotal = sum(pod.container.metricValue)
requestsTotal = sum(pod.container.Request)
currentUtilization = int32((metricsTotal * 100) / requestsTotal)

计算出所有container的资源使用量再比总的申请量,对于单容器Pod这没影响。但对于多容器Pod,比如Pod包含多个容器con1、con2(request都为1cpu),con1使用率10%,con2使用率100%,HPA目标使用率60%,按照目前方式得到使用率为55%不会进行扩容,但实际con2已经达到资源瓶颈,势必会影响服务质量。当前系统中,多容器Pod通常都是1个主容器与多个sidecar,依赖主容器的指标更合适点。

好在1.20版本中已经支持了ContainerResource可以配置基于某个容器的资源使用率来进行扩缩,如果是之前的版本建议使用自定义指标替换。

性能问题

单线程架构

默认的hpa-controller是单个Goroutine执行的,随着集群规模的增多,势必会成为性能瓶颈,目前默认hpa资源同步周期会15s,假设每个metric请求延时为100ms,当前架构只能支持150个HPA资源(保证在15s内同步一次)

func (a *HorizontalController) Run(stopCh <-chan struct{}) {// ...// start a single worker (we may wish to start more in the future)go wait.Until(a.worker, time.Second, stopCh)<-stopCh
}

可以通过调整worker数量来横向扩展,已提交PR。

调用链路

hpa controller中一次hpa资源同步,需要调用多次apiserver接口,主要链路如下

  1. 通过scaleForResourceMappings得到scale资源
  2. 调用computeReplicasForMetrics获取metrics value
  3. 调用Scales().Update更新计算出的副本数

尤其在获取metrics value时,需要先调用apiserver,apiserver调用metrics-server/custom-metrics-server,当集群内存在大量hpa时可能会对apiserver性能产生一定影响。

其他

对于自定义指标用户需要实现custom.metrics.k8s.ioexternal.metrics.k8s.io,目前已经有部分开源实现见custom-metrics-api。

另外,hpa核心的扩缩算法根据当前指标和期望指标来计算扩缩比例,并不适合所有场景,只使用线性增长的指标。

期望副本数 = ceil[当前副本数 * (当前指标 / 期望指标)]

watermarkpodautoscaler提供了更灵活的扩缩算法,比如平均值、水位线等,可以作为参考。

总结

Kubernetes提供原生的HPA只能满足一部分场景,如果要上生产环境,必须对其做一些优化,本文总结了当前HPA存在的不足,例如在性能、使用率计算方面,并提供了解决思路。

这篇关于优化Kubernetes横向扩缩HPA的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1100473

相关文章

MySQL索引的优化之LIKE模糊查询功能实现

《MySQL索引的优化之LIKE模糊查询功能实现》:本文主要介绍MySQL索引的优化之LIKE模糊查询功能实现,本文通过示例代码给大家介绍的非常详细,感兴趣的朋友一起看看吧... 目录一、前缀匹配优化二、后缀匹配优化三、中间匹配优化四、覆盖索引优化五、减少查询范围六、避免通配符开头七、使用外部搜索引擎八、分

Python通过模块化开发优化代码的技巧分享

《Python通过模块化开发优化代码的技巧分享》模块化开发就是把代码拆成一个个“零件”,该封装封装,该拆分拆分,下面小编就来和大家简单聊聊python如何用模块化开发进行代码优化吧... 目录什么是模块化开发如何拆分代码改进版:拆分成模块让模块更强大:使用 __init__.py你一定会遇到的问题模www.

SpringBoot首笔交易慢问题排查与优化方案

《SpringBoot首笔交易慢问题排查与优化方案》在我们的微服务项目中,遇到这样的问题:应用启动后,第一笔交易响应耗时高达4、5秒,而后续请求均能在毫秒级完成,这不仅触发监控告警,也极大影响了用户体... 目录问题背景排查步骤1. 日志分析2. 性能工具定位优化方案:提前预热各种资源1. Flowable

SpringBoot3实现Gzip压缩优化的技术指南

《SpringBoot3实现Gzip压缩优化的技术指南》随着Web应用的用户量和数据量增加,网络带宽和页面加载速度逐渐成为瓶颈,为了减少数据传输量,提高用户体验,我们可以使用Gzip压缩HTTP响应,... 目录1、简述2、配置2.1 添加依赖2.2 配置 Gzip 压缩3、服务端应用4、前端应用4.1 N

Spring Boot + MyBatis Plus 高效开发实战从入门到进阶优化(推荐)

《SpringBoot+MyBatisPlus高效开发实战从入门到进阶优化(推荐)》本文将详细介绍SpringBoot+MyBatisPlus的完整开发流程,并深入剖析分页查询、批量操作、动... 目录Spring Boot + MyBATis Plus 高效开发实战:从入门到进阶优化1. MyBatis

MyBatis 动态 SQL 优化之标签的实战与技巧(常见用法)

《MyBatis动态SQL优化之标签的实战与技巧(常见用法)》本文通过详细的示例和实际应用场景,介绍了如何有效利用这些标签来优化MyBatis配置,提升开发效率,确保SQL的高效执行和安全性,感... 目录动态SQL详解一、动态SQL的核心概念1.1 什么是动态SQL?1.2 动态SQL的优点1.3 动态S

Python如何使用__slots__实现节省内存和性能优化

《Python如何使用__slots__实现节省内存和性能优化》你有想过,一个小小的__slots__能让你的Python类内存消耗直接减半吗,没错,今天咱们要聊的就是这个让人眼前一亮的技巧,感兴趣的... 目录背景:内存吃得满满的类__slots__:你的内存管理小助手举个大概的例子:看看效果如何?1.

一文详解SpringBoot响应压缩功能的配置与优化

《一文详解SpringBoot响应压缩功能的配置与优化》SpringBoot的响应压缩功能基于智能协商机制,需同时满足很多条件,本文主要为大家详细介绍了SpringBoot响应压缩功能的配置与优化,需... 目录一、核心工作机制1.1 自动协商触发条件1.2 压缩处理流程二、配置方案详解2.1 基础YAML

MySQL中慢SQL优化的不同方式介绍

《MySQL中慢SQL优化的不同方式介绍》慢SQL的优化,主要从两个方面考虑,SQL语句本身的优化,以及数据库设计的优化,下面小编就来给大家介绍一下有哪些方式可以优化慢SQL吧... 目录避免不必要的列分页优化索引优化JOIN 的优化排序优化UNION 优化慢 SQL 的优化,主要从两个方面考虑,SQL 语

MySQL中慢SQL优化方法的完整指南

《MySQL中慢SQL优化方法的完整指南》当数据库响应时间超过500ms时,系统将面临三大灾难链式反应,所以本文将为大家介绍一下MySQL中慢SQL优化的常用方法,有需要的小伙伴可以了解下... 目录一、慢SQL的致命影响二、精准定位问题SQL1. 启用慢查询日志2. 诊断黄金三件套三、六大核心优化方案方案