环球热讯:腾讯云胡启明:Kubernetes云上资源的分析与优化

嘉宾 | 胡启明

出品 | 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进行。点击『此处』进入活动专题,带你体验云原生降本增效实践案例、了解如何解决企业用云痛点、掌握降本增效关键技能……

推荐DIY文章
高通中国区董事长孟樸:5G+AI双擎赋能工业“智造”高质量发展
真实测评 | 4款热门骨传导耳机选购指南
世界最资讯丨iOS9.3.5怎么升级?iOS9.3.5正式版图文升级教程
【世界热闻】iPhone6S如何进恢复模式 苹果6S进恢复模式图文教程
焦点热文:iPhone7屏幕上的小圆点怎么打开 苹果7AssistiveTouch开启关闭方法教程
环球头条:iphone4壁纸制作及壁纸设置图文教程
精彩新闻

超前放送