导读: 本文描述了好未来在容器资源优化方面进行的探索和实践,包括业务弹性动态扩缩容来减少时间维度上的资源占用,通过超卖和在离线服务混合部署来优化CPU资源利用率,最后也讲述了公有云上容器计算资源类型选择的一些参考和账单优化的常规建议。
现状概述
图1:某个k8s集群CPU利用率
尽管图1中集群CPU利用率很低,但是实际上该集群已经的CPU已经分配完了,再需要较大CPU申请量时,k8s已经比较难分配出来,即该集群的资源大量空闲,且碎片化比较严重。业务服务在申请CPU用量时,一般倾向于申请远远大于实际用量的资源,同时会倾向于屯一部分资源(业务在闲时也开启过多副本),导致集群CPU利用率非常低。
适配业务流量的周期特征动态扩缩容
互联网业务流量一般有明显的周期特征。在一天、一周表现出非常规律的流量波峰和波谷。下图展示了某个业务的流量监控。
图 2 某业务流量波峰/波谷周期特征
从图2可以看到,基本上每天晚上7点以后会有一波较短时间的流量高峰。然后在一天其他时间流量处于很低的水平。我们查看了其他的一些业务,流量基本上也是这种规律。这跟当前业务形态是一致的,即在政策允许的时间段,在线服务会有流量。而其他时间段,在线服务流量较少。这些业务已经容器化,非常适合利用容器的极速弹性能力实现资源和成本的优化。尤其是在公有云上的服务,及时的向公有云申请和释放资源,节约的成本直接反应在账单上。我们利用率阿里云提供的定时水平扩展(CrohHPA),并结合弹性节点池,实现动态扩缩容。如下图 3所示。在资源不够时,利用k8s cluster api向阿里云申请资源,并将新加的节点按照初始化模版加入到k8s集群提供算力。在流量高峰过去后,pod数量大幅减少,集群资源空闲较多,此时将富余的计算节点归还给阿里云。
图 3 弹性节点池
我们分析了某个在阿里云上的业务的服务,按照一周的平均量来看,该服务所在的k8s集群大概使用1/2的固定节点资源,另外1/2使用弹性扩缩容形式动态申请和释放,每天只用几个小时。通过计算,大约能节省23%的资源成本。当然这里面还可以进行优化,该集群还运行其他的业务,并没有开启弹性,整体开弹性的比例不高。如果整体开启弹性动态扩缩容,我们估算能节省30%以上的资源。
优化资源利用率
应用申请资源超卖
弹性扩缩容是从时间纬度上优化资源用量。在容器现状分析里面看到,容器集群整体CPU利用率极低,天级别平意思均不到10%。另一方面,k8s集群上经常出现资源无法分配导致pending的状态。我们分析了集群的应用,应用申请的CPU都会比实际用量大。对多个集群近千个应用进行统计分析表明,应用申请的CPU大约是实际使用量峰值的3 倍。k8s在调度时,采用request设置的值静态调度。应用设置超过需是什么要实际的用量,导致多余的资源被分配,但实际处理闲置状态。k8s还可以设置limit值,在运行时限制实际使用的资源。根据request和limit不同,k8s对Pod有以下服务等级。
- Guaranteed:Pod 中的每个容器,包含初始化容器,必须指定内存和CPU的reques集群ts和limits,且两者值相等。
- Burstable:Pod 不符合 Guarant化eed QoS 类的标准;Pod 中至少一个容器具有内存或 CPU requests。
- BestEffort:Pod 中的容器必须没有设置内存和 CPU的requests或limits。
在业务实际使用中,大部分业务服务设置了request和limit,同时limit是request的2倍以上。limit比request大,实际是对物理资源的一种超卖。我们对应用进行分析,reqeust大概是最大使用值的2~3倍,而limit大概是最大使用值的5~6倍,参考如下示意图4。
图4 集群资源利用现状
通过资源进行一定程度的超卖,增加了pod的部署密度,能提升集群整体的利用率。但直接让用户自行设置超卖值,会造成超卖的标准非常不统一。我们发现有些业务超卖16 倍以上,而有的按照2 倍来设置。这里造成的问题是,节点CPU利用率极其不均衡。如下图5所示,集群节点CPU利用率波动较大,如图5所示。超卖严重不均衡,实际欺骗了k8s的静态调度器,造成节点CPU利用率极其不均衡。更严重的情形下,会造成部分节点负载进入异常状态,从而影响业务的稳定性。容器团队正在开发相应的调度相关插件,优化此种情况。
图5 节点CPU利用率不均衡
根据目前结果来看,如果放开用户设置超卖倍率,对集群的稳定性带来较大的隐患。同时我们也分析了跟业务服务使用方式比较相近阿里云ASK类型容器(ECI)。在这种类型k8s集群上,会按照某种规则控制超卖比例,不让用户直接设置,我们猜测可能跟硬件资源库存有关系。同样,容器团队也在开发相应的功能,引导用户设置合理的request值,并根据规则设置limit值。
节点超卖
如果大家关注容器集群CPU资源利用率优化,很多公司分享的经验里会提到对节点进行超卖,即通过k8s的webhook,更改CPU的容量值,给k8s调度器更多的可分配CPU资源。当然,这种超卖会提高pod的部署密度,因而会提高CPU利用率。我们在某个测试集群上的数据如图6所示。超卖的一组节点比未超卖节点组CPU利用率高约10个百分点。
图6 超卖/未超卖两组节点池CPU利用率
当然,这里超卖跟应用超卖的效果是一样的,在提升利用率的同时,会对集群的和应用带来极大的稳定性风险,为此,容器团队在这种情形下,专门针对稳定性资源进行优化,期望在超卖和稳定性之间找到平衡点。
在离线服务混部
在离线服务混合部署,是提高意思集群利用率的一大利器,各个大厂分享的实践经验比较多。其实原理也很简单,即在容器集群的计算资源在在线和离线服务之间进行动态拆借。我们目前已经完成了在离线服务混部的demo测试,整个方案比较简单,直接将在线和离线的服务划分两个资源池,每一时刻只能由在线服务或者离线服务使用。当然有集群些公司实现了更复杂的方案,在同一台机器上,同时运行在线服务和离线服务,通过调度器优化避免在线服务被离线服务影响。为避免一开始方案过于复杂,难于实现和落地,我们采用不混用的形式实现在线和离线计算资源的拆借,具体细节可以参考大数据团队ttc文章 《Yarn混合部署方案在好未来的实现》 。
公有云资源与成本优化
目前在好未来,大量使用公有云计算资源部署服务,在公有云上优化资源利用能直接反应在账单上。在弹性扩缩容例子中,我们看到开启弹性伸缩,大概能节省20 %的计算资源。在公有云上除了上文提到的CPU利用率优化外,还需要考虑公有云上的各个不同产品之间的差异,以及计费策略等等,为业务寻找合适的计算资源。在自建的IDC集群中,即使资源处于空闲状态,机器/机柜等开销仍然存在,这部分属于沉没成本。然而在公有云上,我们及时的将资源返还给云厂商,能立即节省费用。针对容器弹性计算资源的需求,阿里云提供serverless形态的k8s集群ASK(ECI),提供极高的弹性,而且基本不需要运维。在好未来刚开始选择公有云上的容器产品时,大量的使用了ASK,但对于常驻内存的后台服务,ASK成本通常比较差,通过测算,使用ASK类型产品比使用裸金属机器搭建的ACK集群,成本高40%以上。目前正在废弃对这种资源类型的使用。
在裸金属机器和虚拟机之间如何选择呢?我们会优先使用裸金属机器,在IDC采用物理机器搭建并运维了较多的k8s集群,而且我们的运维团队具备运维大规模物理k8s集群的经验,而且一些在k8s集群上实现基础扩展功能能继续使用。另一方面,裸金属机器成本比虚
拟资源机更有优势。 对于虚拟机和裸金属机器选型问题,可以继续参考这篇文章 《裸金属与虚拟机如何选择》 。 另外,公有云提供的AMD机型,通常在同等算力下,单位成本更低。而且,公有云提供较多的计费策略可供选择,例如包年包月、弹性资源、竞价型资源等。价格差异也比较大,需要根据实际业务类型进行仔细评估并进行选择,这里需要根据实际需要针对公有云计费策略进行测试,细节不再赘述。
与业务研发一起优化资源和成本
容器资源和成本优化,并不都是对业务无感知的,甚至一些改动需要业务研发老师一起进行,例如进行定时弹性伸缩、应用申请的资源调整等。而业务研发倾向于保持稳定,减少底层干扰对业务稳定性的影响。为此,我们开发了容器的账单服务,提供给业务参考。同时,我化们也正在开发业务申请资源的有效利用率,通过榜单的形式,推动业务优化申请的成本。
另外,我们在做资源利用率优化时,容器团队也会做稳定性的保障工作,在资源优化和稳定性上相互兼顾平衡。我们也会跟业务研发讲明白如何保障业务稳定性、如何保障资源分配的及时性、优化资源方式的合理性,让业务研发老师能在使用我们提供的优化资源建是什么议时,少一些后顾之忧。
容器资源和成本优化,涉及到多个方面,既有技术上的重构和优化,也有不同团队的合作,需要自上而下的推进,基础部门和业务研发密切配合。在保证业务稳定性的前提 下,优化集群资源,降低成本。
出处:https://mp.weixin.qq.com/s?__biz=MzI4MDM5MTAzNA==&mid=2247491478&idx=1&sn=9145880bd9b6e5f77b30d28f93c98346
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至123456@qq.com 举报,一经查实,本站将立刻删除。