大规模k8s集群的成本和服务质量优化 美团容器平台降本运营落地实践 陆启超/美团基础研发平台 2 2023年9月 目录 大规模业务集群降本挑战和难点 资源利用率提升不同阶段的挑战和对应方案 第一阶段:峰值利用率低于40% 第二阶段:峰值利用率40%~45% 第三阶段:峰值利用率45~50% 实践总结及落地成果 未来演进方向 3 数据分级:C1 4 大规模业务集群降本难点 目标与挑战 •目标:用最小的资源成本满足业务资源使用需求,保障业务SLO。 •难点: •资源利用率提升与服务质量保障互相掣肘 •影响利用率和服务质量的因素多,运营场景复杂 6 资源利用率提升不同阶段的挑战和对应方案 资源利用率提升不同阶段 •第一阶段:利用率水平低 •关键思路:把资源分出去 •第二阶段:利用率水平中 •关键思路:资源在空间维度分合理 •第三阶段:利用率水平高 •关键思路:在时间、空间两个维度把资源分合理 •资源碎片化,资源余量总量大,但对于大规格资源调度请求调度履约率难保障 阶段一:峰值利用率低于40% 挑战:如何把资源分出去? •分配率高但实际节点资源利用率低,无法分配更多资源 阶段一:峰值利用率低于40% 挑战1:分配率高但实际节点资源利用率低 原因分析:业务申请实际规格和实际使用gap较大 •基于经验资源规格配置不准,倾向于过配置 •为可能的突发峰值预留资源 阶段一:峰值利用率低于40% 解决方案:业务资源使用分析预测 •日常资源使用时间分布于峰值 •节假日大促规律洪峰 •历史数据确定安全buffer 应对规律洪峰提前扩容 确定资源超售比例 数据分析推动业务运维降配 业务容器配置推荐 业务资源使用分析与预测 阶段一:峰值利用率低于40% 挑战2:资源碎片化,资源余量总量大,但对于大规格资源调度请求调度履约率难保障原因分析:k8s原生调度策略优先策略无法满足实际业务使用特征对资源分配的规划能力 •LeastRequestedPriority:优先调度到剩余资源多的节点上 •节点分配均衡,容易形成碎片,对大规格容器调度支持效果差 •MostRequestedPriority:优先调度到剩余资源少的节点上(类似预留资源) •节点分配率不均衡,资源使用不均衡 解决方案 •方案一:预留节点作为大规格容器申请专区X •实现简单,专区闲置资源浪费,管理复杂,且对资源碎片无优化作用 •方案二:基于桶迁移模型的资源调度✓ •保证大规格容器资源申请 •提升调度履约率 •降低资源碎片 •桶划分及更新 •根据历史资源申请规格统计数据,按照调度计算资源维度在对应的多维空间资源请求划分到不同区间; •根据历史运营数据,统计各个桶内资源申请的比例作为桶迁移代价r; •每个区间对应一个桶,并将集群待调度节点按照其剩余资源放入不同的桶,要求剩余资源满足桶下限资源要求,不满足上限资源要求; •在长期运营时,资源申请可能会发生变化,比如业务变化,之前主要使用4C8G的容器(比例最高)可能变成了8C16G,桶迁移代价푐�s�푏푢푐ke�可以定期自动或手动更新。 •节点位于不同的桶代表节点的资源供给能力; •节点从一个桶迁移到另一个桶,表征着节点资源供给能力的衰减。 优化成果:大规格容器调度履约率提升 •原生调度策略 •基于桶迁移模型规划调度策略 优化成果——碎片率下降、分配率提升 •原生调度策略 •基于桶迁移模型规划调度策略 阶段二:峰值利用率40%~45% 挑战:如何在空间维度把资源分合理? •集中调度导致热点宿主机,负载过高导致业务服务性能波动 •节假日大促时资源需求大,大促后大量资源冗余 阶段二:峰值利用率40%~45% 挑战1:集中调度导致热点宿主机,负载过高导致业务服务性能波动问题分析 •基于业务资源申请规格的静态调度无法感知业务的实际资源使用情况 •业务资源的实际使用和申请量之间的gap,不同的业务存在差异 解决方案: 技术优化:基于BinPack负载均衡调度 BinPack(装箱问题):宿主机目标负载即箱子大小,调度容器高峰期负载作为实际装箱的对象 预选策略 •根据已调度到节点上的容器的历史负载峰值及当前待调度容器 (假设调度到当前节点),预估对应节点的负载峰值 •如果预估的节点负载峰值超过预设的目标负载峰值大小,则过滤掉当前节点 优选策略 •预估的容器调度到当前节点后的负载和目标负载差值越小,当前节点优选阶段得分越高 技术对比及仿真评估——节点负载分布更合理 •原生调度策略 •基于BinPack负载均衡调度 资源运营:资源池分级及QoS分级保障 •资源分级池化 •池间资源隔离 •池内资源共享 •基于优先级池间资源抢占 •QoS分级保障 •基于服务分级的资源降级 •基于服务分级的主动驱逐 •基于服务分级的资源隔离 风险管控:预估与治理 •根据业务容器资源使用历史数据,预测节点负载变化 •通过重调度提前对存在高负载风险的节点容器重新调度 阶段二:峰值利用率40%~45% 挑战2:节假日大促时资源需求大,大促后大量资源冗余问题分析 •节假日大促资源,业务闲时资源浪费,公有云弹性服务接入成本更低 解决方案: •混合云建设,引入公有云弹性资源解决业务大促节假日资源洪峰 混合云建设 •公有云以独立集群形式接入统一调度系统 •公有云资源以节点方式接入 •云主机(中长期租用) •虚拟节点(弹性资源) 阶段三:峰值利用率45%~50% 阶段3资源利用率峰值接近理论极限,在阶段1、2不是主要影响利用率提升和服务质量保障的问题逐渐成为主要挑战 挑战 •服务在整体CPU利用率并未达到50%时出现性能波动问题 •在线业务集群峰值利用率接近极限情况下,如何进一步探索降本? 阶段三:峰值利用率45%~50% 挑战1: •服务在整体CPU利用率不高时出现性能波动 原因分析 •业务服务质量出现波动,其影响因 素多,需要挖掘更细粒度的资源使用信息进行原因分析 解决方案: •建立服务运行状态同通用系统运行 数据之间的映射关系,建设集群服务质量评估能力 图1业务服务延时 图2业务容器CPU利用率 图3业务容器宿主机CPU利用率 集群服务质量评估定义 •服务质量评价:服务质量简单概括是服务运行表现的性能,比如qps和latency,是质效运营的关键,也是数据分析的主要内容。 •难点: •业务种类复杂,表征服务性能指标存在差异,包括指标类别及精度等; •平台侧获取业务侧指标成本高,且分析价值低 •目标:通过通用操作系统QoS指标表征业务运行性能变化,细化服务资源使用特征。 服务质量评估建设路径 服务质量评估是循环迭代反复验证优化的过程,用于分析用的基础数据随着迭代不断丰富,评估准确度也在反复验证迭代中提升。 服务质量评估应用场景 服务质量评估应用覆盖资源利用率提升和服务质量保障运营的各个环节,包括调度策略优化、风险预估及治理以及资源管控等。 阶段三:峰值利用率45%~50% 挑战2: •在线业务集群峰值利用率接近极限情况下,如何进一步探索降本? 问题分析: 接近物理限制,进一步提升资源利用率空间复用优化空间有限,重点收益在时间维度上资源复用 解决方案: •在线服务精细化调度 •峰值利用率不变,部署更多在线服务 •推进在近线、在离线混部 •提升均值利用率 方案1在线服务精细化调度——容器峰值负载打散 节点业务容器负载高峰期分布集中 •节点负载峰值接近极限 •高峰期负载均值不高 节点业务容器负载高峰期分布分散 •节点负载峰值不变或更低 •高峰期负载均值高 •部署更多服务 在线服务精细化调度——服务资源特征打散 根据服务资源敏感性信息及干扰特征进行细粒度打散,提高部署密度,保障服务质量同时,提升资源利用率。 方案2在离线、在近线服务混部(探索、推进中…) •在线服务:一般要求实时性高,对请求响应时延短,成功率要求高,通常也是业务的核心服务,比如交易、订单服务等。 •离线服务:一般实时性要求很低,处理过程通常可中断,并重新发起请求,且请求处理时长通常大。(但30%以上的离线任务是高优任务,有处理时效性要求) •近线服务:服务在实时性及处理时延等要求介于在线服务和离线服务之间,有一定的时延敏感性,相对请求处理时间较大,比如音视频转码等服务。 33 实践总结及落地成果 实践成果-QCOps系统 •质量优先 •分级Qos保障 •分级资源池 •精细化打散 •数据驱动 •风险评估预测 •服务质量评估 •资源使用预测 •服务特征分析 •循环反馈、滚动迭代 •多系统联动 •结果评价反馈 •辅助治理 重点工作 进一步提升资源利用率,需要细粒度的服务分析能力,驱动QoS服务质量保障能力、风险预估能力的提升,同时提升整体运营工作自动化水平,降低运营成本 细粒度服务分析能力 •服务间干扰分析 •服务资源敏感性分析(IO密集型、内存敏感性、CPU敏感型…) 服务质量风险预检能力 •热点宿主风险(CPU、IO…) •服务打散风险(拓扑域容灾、干扰服务…) 运营自动化能力 •质量与成本运营反馈迭代 •风险预检与治理自动化 落地成果(2021~Now) CPU平均使用率累计提升9个百分点CPU峰值利用率累计提升10个百分点 高负载节点比例下降30% 服务打散合规比例提升超40% 37 未来演进方向 演进方向 数据驱动降本 在数据分析基础上的服务质量评估及服务画像能力是驱动整个运营体系优化的关键,通过不断迭代优化,持续提升资源利用率,保障业务服务质量。 自动化、智能化降低运营成本 运营是持续迭代优化的过程,具有很强自动化改造的潜力。建立智能化的分析能力,自动化的运营能力,从而降低整体运营成本。 38 感谢~