前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >优化 Kubernetes 横向扩缩容 HPA

优化 Kubernetes 横向扩缩容 HPA

作者头像
我是阳明
发布于 2021-06-25 08:56:20
发布于 2021-06-25 08:56:20
2.3K00
代码可运行
举报
文章被收录于专栏:k8s技术圈k8s技术圈
运行总次数:0
代码可运行

图片来源: instagram.com/febin_raj

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

HPA Resource类型不足

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

使用率计算方式

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

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
// 获取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 := 0

 for podName, metric := range metrics {
  request, hasRequest := requests[podName]
  if !hasRequest {
   // we check for missing requests elsewhere, so assuming missing requests == extraneous metrics
   continue
  }

  metricsTotal += metric.Value
  requestsTotal += request
  numEntries++
 }


 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,通过上述方式计算资源使用率,核心方式如下:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
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内同步一次)

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
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核心的扩缩算法根据当前指标和期望指标来计算扩缩比例,并不适合所有场景,只使用线性增长的指标。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
期望副本数 = ceil[当前副本数 * (当前指标 / 期望指标)]

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

总结

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

❝本文链接: https://qingwave.github.io/k8s-hpa-enchance/ ❞

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2021-05-30,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 k8s技术圈 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
K8S之HPA自动扩缩容机制
kubectl scale 命令可以来实现 Pod 的扩缩容功能,但是这个毕竟是完全手动操作的,要应对线上的各种复杂情况,我们需要能够做到自动化去感知业务,来自动进行扩缩容。为此,Kubernetes 也为我们提供了这样的一个资源对象: Horizontal Pod Autoscaling(Pod 水平自动伸缩) ,简称 HPA ,HPA 通过监控分析一些控制器控制的所有 Pod 的负载变化情况来确定是否需要调整 Pod 的副本数量
tunsuy
2023/08/19
1.1K0
K8S之HPA自动扩缩容机制
K8s pod 动态弹性扩缩容(HPA )部署!步骤齐全,少走坑路
Horizontal Pod Autoscaler(HPA,Pod水平自动伸缩),根据平均 CPU 利用率、平均内存利用率或你指定的任何其他自定义指标自动调整 Deployment 、ReplicaSet 或 StatefulSet 或其他类似资源,实现部署的自动扩展和缩减,让部署的规模接近于实际服务的负载。HPA不适用于无法缩放的对象,例如DaemonSet。
民工哥
2022/10/27
6.8K0
K8s pod 动态弹性扩缩容(HPA )部署!步骤齐全,少走坑路
Kubernetes HPA 控制器横向伸缩的关键实现
HPA 是 Kubernetes 中横向伸缩的实现,里面有很多可以借鉴的思想,比如延迟队列、时间序列窗口、变更事件机制、稳定性考量等关键机制, 让我们一起来学习下大佬们的关键实现。
我是阳明
2020/06/19
1K0
Kubernetes HPA 控制器横向伸缩的关键实现
13.深入k8s:Pod 水平自动扩缩HPA及其源码分析
Pod 水平自动扩缩全名是Horizontal Pod Autoscaler简称HPA。它可以基于 CPU 利用率或其他指标自动扩缩 ReplicationController、Deployment 和 ReplicaSet 中的 Pod 数量。
luozhiyun
2020/10/10
2.5K0
13.深入k8s:Pod 水平自动扩缩HPA及其源码分析
Kubernetes HPA 详解
在前面的学习中我们使用用一个 kubectl scale 命令可以来实现 Pod 的扩缩容功能,但是这个毕竟是完全手动操作的,要应对线上的各种复杂情况,我们需要能够做到自动化去感知业务,来自动进行扩缩容。为此,Kubernetes 也为我们提供了这样的一个资源对象:HorizontalPodAutoscaling(Pod水平自动伸缩),简称 HPA,HPA 通过监控分析一些控制器控制的所有 Pod 的负载变化情况来确定是否需要调整 Pod 的副本数量,这是 HPA 最基本的原理:
我是阳明
2020/06/15
4.6K0
Kubernetes HPA 详解
原 荐 Kubernetes HPA Con
Author: xidianwangtao@gmail.com 更多关于kubernetes的深入文章,请看我csdn或者oschina的博客主页。 关于kubernetes HPA Controller的工作原理,请参考我这篇博文。 源码目录结构分析 HorizontalPodAutoscaler(以下简称HPA)的主要代码如下,主要涉及的文件不多。 cmd/kube-controller-manager/app/autoscaling.go // HPA Controller的启动代码
Walton
2018/04/13
2K0
原                    荐                                                            Kubernetes HPA Con
使用k8s-prometheus-adapter实现HPA
当HPA请求metrics时,kube-aggregator(apiservice的controller)会将请求转发到adapter,adapter作为kubernentes集群的pod,实现了Kubernetes resource metrics API and custom metrics API,它会根据配置的rules从Prometheus抓取并处理metrics,在处理(如重命名metrics等)完后将metric通过custom metrics API返回给HPA。最后HPA通过获取的metrics的value对Deployment/ReplicaSet进行扩缩容。
charlieroro
2020/03/24
5.9K0
生气!能省 50% 成本,为啥你不早点让我用 HPA
原文 https://www.chenshaowen.com/blog/how-to-set-hpa-for-kubernetes-app.html
陈少文
2023/06/09
4580
生气!能省 50% 成本,为啥你不早点让我用 HPA
k8s群集之动态扩缩容——HPA
HPA的全称为Horizontal Pod Autoscaling,它可以根据当前pod资源的使用率(如CPU、磁盘、内存等),进行副本数的动态的扩容与缩容,以便减轻各个pod的压力。当pod负载达到一定的阈值后,会根据扩缩容的策略生成更多新的pod来分担压力,当pod的使用比较空闲时,在稳定空闲一段时间后,还会自动减少pod的副本数量。
小手冰凉
2020/09/15
2.8K0
再战 k8s(13):Pod 的扩缩容
实际生产系统, 会遇到某个服务需要扩容的场景,也可能会遇到由于资源紧张或者工作负载降低而需要减少服务实例数量的场景。
看、未来
2022/05/06
7800
再战 k8s(13):Pod 的扩缩容
k8s中pod的自动扩缩容
Kubernetes从1.1版本开始, 新增了名为Horizontal Pod Autoscaler(HPA) 的控制器, 用于实现基于CPU使用率进行自动Pod扩缩容的功能。 HPA控制器基于Master的kube-controller-manager服务启动参数–horizontal-pod-autoscaler-sync-period定义的探测周期(默认值为15s) , 周期性地监测目标Pod的资源性能指标, 并与HPA资源对象中的扩缩容条件进行对比, 在满足条件时对Pod副本数量进行调整。Kubernetes在早期版本中, 只能基于Pod的CPU使用率进行自动扩缩容操作, 关于CPU使用率的数据来源于Heapster组件。 Kubernetes从1.6版本开始, 引入了基于应用自定义性能指标的HPA机制, 并在1.9版本之后逐步成熟。
dogfei
2020/08/06
3.6K0
k8s中pod的自动扩缩容
Kubernetes 微服务最佳实践
原文作者:ryan4yin,🔗: https://thiscute.world/posts/kubernetes-best-practices/ 本文主要介绍我个人在使用 Kubernetes 的过程中,总结出的一套「Kubernetes 配置」,是我个人的「最佳实践」。其中大部分内容都经历过线上环境的考验,但是也有少部分还只在我脑子里模拟过,请谨慎参考。 阅读前的几个注意事项: 这份文档比较长,囊括了很多内容,建议当成参考手册使用,先参照目录简单读一读,有需要再细读相关内容。 这份文档需要一定的 Kube
我的小碗汤
2023/03/19
1.2K0
Kubernetes 微服务最佳实践
Pod的垂直扩缩容的触发指标以及配置方法
以上指标可以根据业务需求自定义和配置。通常,可以使用Kubernetes的水平Pod自动扩展(HPA)功能来实现自动垂直扩缩容。通过创建Pod资源并定义自动扩缩容的策略,可以在Pod资源中设置触发垂直扩缩容的指标和阈值。
一凡sir
2023/09/12
3990
Pod的垂直扩缩容的触发指标以及配置方法
kubernetes(十六) k8s 弹性伸缩
常规的做法是给集群资源预留保障集群可用,通常20%左右。这种方式看似没什么问题,但放到Kubernetes中,就会发现如下2个问题。
alexhuiwang
2020/09/23
3.6K0
kubernetes(十六) k8s 弹性伸缩
Kubernetes HPA级别扩缩容配置预览
本文分析 HPA 功能增强的建议,而不是真正的实现。Kubernetes 1.16 发布前夕,该功能增强还没有合入,所以最快也要到 1.17 版本发布。
CNCF
2019/12/05
1.6K0
Kubernetes HPA级别扩缩容配置预览
Kubernetes运维之容器编排Deployment动态扩缩容
HPA(Horizontal Pod Autoscaler)的实现是一个控制循环,由controller manager的–horizontal-pod-autoscaler-sync-period参数指定周期(默认值为15秒)。每个周期内,controller manager根据每个HorizontalPodAutoscaler定义中指定的指标查询资源利用率。controller manager可以从resource metrics API(pod 资源指标)和custom metrics API(自定义指标)获取指标。
王先森sec
2023/04/24
1.2K0
Kubernetes运维之容器编排Deployment动态扩缩容
HPA 还是 KEDA,如何在 Kubernetes 中更有效的使用弹性扩缩容?
Kubernetes 有非常广泛的话题。但是构建云原生应用程序时最常见的问题还是弹性扩缩容。
用户5166556
2023/03/18
1.6K0
HPA 还是 KEDA,如何在 Kubernetes 中更有效的使用弹性扩缩容?
k8s滚动升级和扩缩容
用于实现基于CPU使用率进行自动Pod扩缩容的功能。HPA控制器基于Master的kube-controller-manager服务启动参数--horizontal-pod-autoscaler-sync-period定义的探测周期(默认值为 15s),周期性地监测目标Pod的资源性能指标,并与HPA资源对象中的扩缩容条件进行对比,在满足条件时对Pod副本数量进行调整.
丁D
2022/08/12
1.6K0
Kubernetes 服务部署最佳实践(一) 如何合理利用资源
业务容器化后,如何将其部署在 K8S 上?如果仅仅是将它跑起来,很简单,但如果是上生产,我们有许多地方是需要结合业务场景和部署环境进行方案选型和配置调优的。比如,如何设置容器的 Request 与 Limit、如何让部署的服务做到高可用、如何配置健康检查、如何进行弹性伸缩、如何更好的进行资源调度、如何选择持久化存储、如何对外暴露服务等。
imroc
2020/06/19
1.7K0
Kubernetes(k8s)-自动扩缩工作负载(HPA)
作者介绍:简历上没有一个精通的运维工程师。下面的思维导图也是预计更新的内容和当前进度(不定时更新)。
运维小路
2025/03/28
1020
Kubernetes(k8s)-自动扩缩工作负载(HPA)
相关推荐
K8S之HPA自动扩缩容机制
更多 >
领券
💥开发者 MCP广场重磅上线!
精选全网热门MCP server,让你的AI更好用 🚀
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
本文部分代码块支持一键运行,欢迎体验
本文部分代码块支持一键运行,欢迎体验