腾讯云胡启明:Kubernetes云上资源的分析与优化
source link: https://blog.csdn.net/m0_46700908/article/details/126153059
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
嘉宾 | 胡启明
出品 | CSDN云原生
2022年6月30日,中国信通院、腾讯云、FinOps产业标准工作组联合发起的《原动力x云原生正发声 降本增效大讲堂》系列直播活动第2讲如期举行,腾讯云容器技术专家胡启明分享了Kubernetes云上资源的分析与优化。
胡启明是开源项目Crane的Founder和负责人,专注Kubernetes云原生领域8年,负责专有云容器产品、云原生应用平台的研发和管理,是Kubernetes、Dapr、KubeEdge等多个开源项目的Contributor。本文整理自胡启明的分享。
Kubernetes云上资源管理
Kubernetes资源模型:Request和Limit
-
Request代表Kubernetes应用声明它希望获得的最小的资源使用量。
-
Limit代表Kubernetes应用声明它希望获得的最大的资源使用量。
Kubernetes的调度器,会根据Request的申请量去调度应用到Kubernetes的节点上。
资源预留带来的资源浪费
关于Request的模型,用户设置时存在一个问题:用户的开发者不一定对业务线上运行情况完全感知。例如:不知道业务在线上运行时需要多少CPU和内存,以及业务洪峰的场景下资源使用量会上涨的维度。因此,基于这些问题,在业务开发、运维在配置Request时,开发者会选择保守策略,常把配置设高。
同时,也带来另一个问题:资源浪费比较显著。如下图所示,应用的Request声明了4个核,但实际使用不超过2个核。这都是由于保守、业务运行不了解带来的资源浪费。
资源紧缺带来的资源浪费
CPU是可压缩资源。当CPU紧缺时,实际用量可以超过CPU总量,此时会出现资源的争抢,导致应用处理程序速度变慢。
内存是不可压缩资源,如果业务运行中超过了上限,就会呈现下图的情况。
如上图所示,Kubernetes中的节点上部署了两个容器,它们在处理业务都有规律:
-
在晚上,业务的使用量会降低,白天高峰期业务容量就会偏高;
-
昼夜规律比较相似,相似的业务部署在了同一个节点上;
-
业务高峰期,容器的内存用量会达到它的Limit值,但由于调度应用是根据Request完成的,会导致在业务高峰期节点上内存被耗尽。
资源被耗尽时候,会发生什么事?
-
如果节点的内存耗尽,Kubernetes会按顺序驱逐容器,排序规则是容器实际内存使用超出Request的用量。如果去驱逐用量大于Request的东西,业务就会发生损伤,因为它的容器被Kill,并且这时候往往是处在于业务的高峰期,使业务受到损伤。
-
如果容器内所有的进程分配的内存超过了内存Limit,节点上的OOM Killer会立刻Kill 这些进程。这种场景下,业务的使用也会受到损伤,用户也会感知。这导致了应用开发者或者SRE去配置资源时会采取保守策略,以保证业务稳定性和正确性,这加剧了云上资源浪费。
大量资源无法使用导致资源浪费
当业务上了Kubernetes等云原生平台后,它的资源的用量和与使用率会偏低。下图显示资源总量很大,但实际使用量却很低,导致大量资源的使用浪费。
Kubernetes弹性伸缩
HPA工作原理
HPA工作原理如下图所示。
在云上,用户通过Service+Load Balance,请求到一个Deployment,Deployment里有几个Pod。为了让Deployment+Pod在用户流量增大时自动扩容,在流量减少时自动缩容,达到按需计费,于是创建了HPA。
HPA会让用户设置最小的副本数和最大的副本数,并且用户设置目标的CPU使用率。根据目标使用率,在最小副本数和最大副本数之间做自动弹性伸缩。
HPA在社区发展了已有3~4年,版本目前达到v2,功能比较完善。社区的HPA不但支持基于K8s内置的CPU和Memory指标,还提供了丰富的扩展能力customer metric、External metric的外部指标,让用户可以通过外部的监控指标来对业务做弹性。
最常见的基于Prometheus的adapter,让用户基于Prometheus的metric自动做弹性。社区有一个开源产品叫KEDA,它专注于通过Event Driven的方式让业务做弹性。本质是使用了HPA,把一些基于Kafka、MQ数据的event去做弹性的输入,通过external metric的方式让HPA去做水平弹性。
HPA原生能力不足
社区的HPA也有局限性,主要在两个方面。
-
在业务流量的洪峰来临时来不及扩容。例如:用户MQ的connection会提升,随着message数量会增加,CPU的用量会提升,但如果资源洪峰已经来临时,再去扩就常常会发现来不及。一方面原因是Event Driven,洪峰来临再去弹,另外一方面的原因是容器化的业务启动速度赶不上流量来的速度。由于业务系统慢,导致很多业务没办法使用社区的HPA。
-
流量抖动。在下图的“深V”时间点内,如果使用HPA将导致HPA的副本剧烈抖动。虽然HPA里有个behavior的功能可以减少抖动,但调大behavior减少抖动时,HPA的弹性会变得迟钝,导致弹性效果不理想。
VPA工作原理和局限性
VPA工作原理如下。
-
首先,用户会创建一个VPA的对象,它会有VPA的Recommend,便于定期获取VPA里面的弹性配置。同时,Recommend也会去从ApiServer拿到整个集群中的状态信息。通过VPA的算法,根据这两个信息计算出用户应用推荐配置CPU和memory的数量。最后,根据资源配置推荐信息更新到VPA上去。
-
还有一个组件叫做VPA Updater,它会去获取弹性配置,并且感知到配置后,需要把Pod重建,配置它才能生效。因此,VPA Updater会对Pod做Eviction。众所周知,当Pod做Eviction时,它会自动创建新的Pod来替代它,新的Pod的创建请求会被VPA Admission plugin给拦截,拦截之后它会把VPA上面的弹性配置更新到Pod Spec,新建的Pod就会使用VPA推荐的资源配置。
在现实中,VPA的落地场景其实不多,因为VPA有其局限性:业务很难接受随时重建的Pod。
例如一个业务正在接受一个用户的数据处理,这时Pod重建了,用户的业务使用就会受损, Pod 重建无法通知到业务,并且一定会对业务造成影响,导致很多时候在生产环境很难使用VPA。
基于Crane的Kubernetes的资源分析与优化
Crane是腾讯的一个基于Kubernetes的开源项目,全称是Cloud Resource Analytics and Economics,译为“云上资源的分析和降本”。
Crane是基于FinOps的理论来去编排设计的能力模型,从下往上看分为五层:
-
Understand Fully Loaded Costs:多维度业务成本分摊表、标签管理、分期账单、预算和配额管理等。
-
Enable Real Time Decision Making:资源利用率报表、异常识别、识别资源浪费等。
-
Benchmark Performance:趋势和变化分析、评分和PKI、内部评比、跨供应商评分对比等。
-
Optimize Usage:支持的资源优化的能力,比如资源回收再分配、Request推荐、基于预测的智能弹性、机型推荐等。
-
Optimize Rate:提供计费方面的能力,比如计费方式推荐、抵用券支持等。
云上资源的分析和优化
下图展示的是Kubernetes云上资源的分析和优化的能力。
Kubernetes里有个重要的概念,叫做Infrastructure as Code。Kubernetes上所有资源都是可以通过YAML配置的方式来去声明,例如Deployment、Job、PV、SVC、node、CPU,都可以用通过一段YAML配置来去声明。Crane提供了一套分析推荐的插件能力,去分析Kubernetes中的云资源。
同时,输入的一方面是云资源,另一方面是Kubernetes的观测数据,例如Deployment对应CPU的使用率,内存的使用率,都是观测数据。
“云资源+观测数据+分析算法”作为一个输入,再加上资源推荐的插件,能给用户推荐优化的建议。比如,资源推荐的插件会根据用户的应用配置、实际使用量、推荐算法,得到建议资源CPU和memory的配置值。
在分析结果之后,还可以利用一些工具包,比如Kubernetes的插件,把资源优化的分析结果汇总给用户,让用户能够观测到优化结果。优化结果通过API去计算云端费用的节省,帮助用户在云上做成本决策。
云上资源的分析与优化,还提供了一个插件系统。用户可以自定义推荐的插件,使用推荐的framework插到分析的推荐系统中去,实现自定义分析和推荐的逻辑。
资源推荐
下图展示的是资源推荐中的诉求、方案以及成效。
-
从“让应用的资源配置更简单”的诉求出发。
-
Crane方案是根据应用的历史用量推荐,支持按照机型规格做调整,基于VPA的算法进行资源推荐。很多业务都跑在Serverless构上,Serverless架构上的资源规格、机型规格都会做规整,例如1.5Core/3G的资源就会向上规整到2Core/4G上,Crane的推荐结果会根据规则做规整,同样是基于VPA算法。
-
成效如上图右侧所示,没有使用资源推荐之前,很多业务的机型是偏大的,经过资源推荐优化之后,用户采纳推荐配置并且重建了容器。资源推荐是使用推荐建议的方式,让用户去选择时间和是否采纳建议。在用户采纳之后,才会去批量的rolling更新,避免VPA随时更新应用的配置,导致应用被重启的问题。
副本/弹性推荐
下图展示的是副本/弹性推荐中的诉求、方案以及成效。
-
从”让应用副本配置更简单“的诉求出发。
-
Crane方案会去扫描集群中的应用,根据它的应用历史用量,基于HPA的算法计算未来副本数。其中,部分应用用量有昼夜规律波动,这类业务则可以推荐它的副本配置,实现降本。对于能够支持动态扩缩、有规律性的业务,可以配智能弹性Effective HPA,用户进行降本增效。
-
成效如上图右侧所示,大部分业务配了很多副本数,但经过计算发现降到三个副本也可以满足业务诉求。
内部大规模落地实践
腾讯的智能推荐的能力在腾讯内部和自研业务上大规模落地,部署到数百个Kubernetes的集群,管控了数百万个CPU的核,在全面上线一个月之内,大盘的总和数缩减了25%。
腾讯把集群中资源推荐的建议展现到控制台里,让用户看到工作负载、当前的核数、推荐的资源量、推荐副本数。
该页面还能帮用户整理出工作环境中的应用数字、可以被优化的数字以及用户采纳优化建议后能降低多少CPU和内存的使用,通过图形的方式展现出来,方便用户去决策。我们还支持基于kubectl插件去分析整个集群中的状态。
智能弹性—Effective HPA
HPA落地有两个问题:弹性时间滞后、弹性毛刺。
上图展示的是智能弹性的功能,Effective HPA。Effective HPA是基于时间预测的算法,通过预测未来的metric使用量去解决问题,它有以下能力。
-
第一个能力:提前扩容,保证服务质量。采取时间序列算法(Fast Fourier Trans former),可以根据过去7天或者14天的metric,预测未来7天metric变化轨迹。通过预测窗口里面metric的最大值做提前扩容,还会采取metric兜底保护策略。
-
第二个能力:减少无效缩容。能够预测未来的一个资源用量,当曲线发生抖动时,因为取的预测窗口中的最大值,所以整个曲线的抖动毛刺程度明显降低。
-
第三个能力:支持Cron配置。应对大促、节假日等有规律的流量洪峰。
-
第四个能力:易于使用。Effective HPA完全兼容社区HPA的功能,还支持Dryrun观测,指标支持Prometheus Metric。
下图展示的是Effective HPA的架构。
用户创建Effective HPA的对象后会生成两个资源对象:
-
一个是TimeSeries Prediction;
-
另一个是社区原生的HPA。
TimeSeries Prediction是时间序列预测的Controller的对象。创建后有一个组件叫Predictor开始从Prometheus中拿取应用历史数据,并且通过预测算法得到未来持续预测,把预测结果更新到TimeSeriesPredicton中。
社区HPA在创建后,HPA的Controller就会工作。定义中的metric的配置向Kubernetes的ApiServer请求。一方面,它会去向Metric server去请求它的CPU的用量。另一方面,它向Crane metric adapter去请求预测数据。
最后,Metric-adapter会从TSP中获取它的预测数据,并且把结果返回给HPA Controller。HPA Controller将两个源头数据通过HPA算法,计算得到较高的副本数,并且用副本数更新到真实的应用中,这就是Effective HPA智能弹性的工作过程。
CronHPA 、KEDA、Effective HPA有什么差异点呢?如下图所示。
-
CronHPA是通过修改HPA的配置去控制底层的HPA,并且控制应用的弹性伸缩。由于它是自动修改HPA的配置,这就会导致用户的HPA配置能力遭到弱化。
-
KEDA实现原理是为每一个框配置生成metric。但它的问题是在Cron的周期之外,KEDA的Cron配置会自动把用户的应用缩容到一个副本,原因是它把每一个Cron都定义成了metric。由于metric定义互相不感知,就导致metric返回的默认值只能设置为1,因为它不能够去影响别的metric配置。
-
Effective HPA的Cron配置解决了前两个问题。通过预测、观测和周期性触发策略共同作用、计算和考虑,最后取中间的较大值。Cron的问题也解决了,在用户配置的Cron周期之内,副本数能够保持跟当前的配置不变,不会自动缩溶。
智能弹性落地成效
下图展示的是智能弹性的落地成效。
-
腾讯内部的安全部门WAP和腾讯的容器服务,在生产环境已经使用了Effective HPA做弹性伸缩器。作为一个开源产品,很多公司对Effective HPA感兴趣,并且正在使用。
-
酷乐家生产环境全量使用。酷乐家原本在生产环境中已经全量使用了HPA,由于没有办法提前扩容,导致它的配置相当保守。酷乐家看到Cron的Effective HPA后,将HPA存量切换到了Effective HPA,在生产环境全量使用后,解决了弹性问题,提升了平均使用率。
-
目前Effective HPA在生产环境已经管控了数千个应用。
-
平均利用率的提升达到10%。如上图右下方所示,蓝线是预测的metric,绿线是CPU实时的metric容量,黄线是使用Effective HPA后的提前扩容能力。
【原动力×云原生正发声降本增效大讲堂】第二期聚焦全场景在离线混部、K8s GPU资源效率提升、K8s资源拓扑感知调度主题,分别在7月28日、8月4日、8月11日晚20:00-21:00进行。点击『此处』进入活动专题,带你体验云原生降本增效实践案例、了解如何解决企业用云痛点、掌握降本增效关键技能……
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK