如何治理资源浪费？百度云原生成本优化最佳实践

科技 08-03 来源：百度云原生计算

【百度云原生导读】根据 Gartner 的调查数据，到 2022 年底，全球企业在云计算基础设施方面的支出约为 3330 亿美元。

麦肯锡在调查报告中指出，2020 年，由于缺乏成本优化手段，80% 企业的云资源成本大幅超出预算；同时，45% 的企业由于缺乏优化措施，在直接迁移上云的过程中会超买 55% 的资源，并且在上云的头 18 个月会多花 70% 的费用。

随着全球经济持续下行，企业应该如何做好精细化运营和降本增效，如何优化云资源的分配、使用和管理成为了当下必须要考虑的问题。

本文将会具体介绍百度的云原生成本优化体系并重点阐释对成本优化起到关键作用的混部和超卖技术，最后介绍如何保证资源资源利用率提升之后的稳定性，希望能给企业的云原生转型提供经验借鉴。

从下面两张图中可以看出企业在云原生转型过程中面临 K8S 采用率逐年提升但资源成本却不断飙升的矛盾。

左边图片来源于《2020 年 CNCF 中国云原生调查报告》，图中显示生产系统中使用 Kubernetes 的比例已从 2019 年的 72% 增长到了 82%，越来越多的企业在云上使用基础设施资源、通过 Kubernetes 平台来管理应用。
右边图片来源于 CNCF《FinOpsKubernetes Report》，报告中指出云原生导致资源成本增加，迁移至 Kubernetes 平台后，68% 的受访者表示所在企业计算资源成本有所增加，36% 的受访者表示成本飙升超过 20%

为什么会出现这个矛盾？其实，企业在云原生转型过程中主要面临三个困难：

成本管理困难：K8S 的弹性帮助了业务快速整张，但也带来了计费、分账管理上的困难。因为 K8S 的 Pod 迁移性比较强，对比传统的 Agent 部署模式，Pod 可能会在各个节点上漂移。多集群场景下，也可能在集群之间漂移
成本优化难：弹性、潮汐、混部超发、预留实例、竞价实例，手段很多，但需要投入人力来对这些手段精心搭配
资源利用率低：给业务分配的资源过大，实际使用的资源过小，企业的 CPU 资源利用率普遍低于 15%

这些困难就导致了企业的资源成本无法有效控制。百度借助当下流行的 FinOps 理念，结合内部多年的实践经验发现：可以从成本洞察、成本优化以及成本运营三个方面形成闭环，对上述困难各个击破。

1. 成本优化实施路径

1.1 成本洞察方案

在 K8S 平台做成本洞察，基本会按以下三个方向进行：

可视化的资源追踪：对集群，节点维度的资源变化做追踪
应用级别的用量分析：对用用做 Pod 级别分配率核算；统计不同的 Namespace 和 Label 对应相不同的业务和业务线，向上聚合产出报表
利用率统计：对多资源维度的分配率、利用率进行统计。比如 CPU、Memory、GPU、磁盘等数据。

1.2 成本优化方案

浪费的根因主要是由于业务申请的资源过大，实际使用的资源过小，整体利用率不高，并且业务自身存在波峰波谷且申请时一般会按照波峰申请。同时，如果企业有在线业务也有离线业务的话，会存在在离线分池，技术栈不统一、资源池不统一的问题。

成本优化主要手段涉及资源优化和应用优化两个层面：

资源优化：

预留套餐互转，通过资源画像检测出的保底资源，由后付费转为包年包月
使用弹性扩缩容，使用竞价实例，潮汐实例支持有计划的资源申请，使用 Serverless 实例支持突发流量

一般云上企业的资源由包年包月和后付费两种方式组成，通过成本洞察做分析和统计，然后通过成本运营做推荐和具体的实施，最终把它转化成下图右侧的金字塔形状的资源分层。

最保底的资源采用包年包月的形式，每日计划的资源通过弹性（竞价）实例以及潮汐实例去做中间层资源的满足，突发的情况使用 Serverless Pod 满足。

应用（利用率）优化：

百度内部通过多年的经验积累，总结出了一条完整的应用优化路径。比如有一个标准的在线集群，首先会通过资源画像去梳理在线业务的质量，经 7-14 天的梳理周期给出应用的利用率的预估进而做对应的配额进行推荐，如果业务方配合应用配额缩减之后普遍会节约 20% 的成本，这个方法的落地难度为中等。

如果对节点利用率做预估配合在线超卖，也就是节点不变，通过放大节点上面的一个资源的总量提升集群的总容量，最终效果就是用固定的节点去承载更多的在线业务，普遍会减少 30% 的成本，这个方法较容易落地。

最后是在离线合池的方法，在线业务和离线业务一般都是由大数据等重吞吐不重时延的业务组成，通过在离线任务混部，在百度内部 CPU 利用率可以从 20% 提高到 40%，普遍减少 30% 的成本，当然它的技术难度和落地成本也比较大。

1.3 成本运营方案

上图是我们的成本平台示意图，成本管控平台包含了传统的账单 \ 权限，预算 \ 规划，需求安排，成本优化等内容。

产品能力主要针对售卖按照质量分级给出不同计费模式，按质量分为独占型、共享型和抢占型。针对某些业务的特殊需求如敏感、保密等需求，可以通过独占集群方式或者是独占节点方式进行部署。

共享型是指面向混部队列的共享池，在离线共享资源会跑超发的在线以及离线混部的业务），抢占型专门为离线业务所使用的，它的质量是最低的，但是对应它的价钱也最便宜。整体的价格比例，如果独占型为 1，共享型为 0.8，抢占型可能也就是 0.1 或者免费，业务可以根据自己的需求选择不同的资源。

计量计费包含资源包和配额两种方式。配额一般给离线作业使用，配额之间也可以抢占，如果我们资源足够的话，你可以超过配额而不需要额外付费。

资源分摊方面，百度内部把所有的资源如 CPU、内存、GPU 和存储做统一的计费。需要说明的是 CPU 在云上还好，但是在百度内部 CPU 异构特别严重，型号不同，它的能力实际上也不同，所以我们提出一个概念：标准化核，也叫归一化核。我们用最低级的 CPU 作为一个基准，所有的 CPU 参照这个基准去产生对应的标准核，这样在 K8S 做调度的时候，就可以按按自定义的标准核去分，规避了在不同机型上同样的 Request 质量性能不一样的问题。

不同成本优化手段的技术难度和落地难度如下图所示：

实施路径如下图：

要注意的是，落地过程需要特别谨慎，如果做的不好，我们要讲的故事，都可能会变成一个事故。

2. 成本优化核心技术

2.1 在线超卖

在线资源通常存在分配率高但使用率低的现象，主要原因是业务规格申请过大，此外还存在核存比例不平均以及节点规格过小、碎片很多的问题。使用在线超卖的方案，也就是资源超发，可以通过动态超发节点规格以及对热点（我们将 CPU 或内存超过 80% 定义为热点）的事前和事后处理来解决上述问题。

事前的处理指的是根据资源画像做精细调度，避免热点。事后是对应用的可迁移性进行分级，来保障稳定性。应用可迁移性与应用的重要程度不直接相关，根据百度内部经验，会通过平台来定义其等级：第一个等级不可迁移或需要人工介入迁移，第二个等级是指一般情况不要迁移，第三个等级就是可以迁移，默认所有业务进入时都是第三个等级，如果有特殊需求，需要和平台方做评审。通过资源超卖，测试集群的分配率对比应用超卖之前可以达到 130%，使用率达到 15%。

技术层面，超卖有两个方向：一是节点级别的超卖，二是应用规格的智能调整。二者手段虽不同，但总体逻辑就是用最少的节点去承载更多的业务。百度内部选择的是节点级别超卖。

节点超卖是通过 operator 设定 node 的超卖系数，通过 webhook 拦截 kubelet 的上报，简单来说，就是让调度器认为这个节点的实际容量比以前大，并且支持了资源维度的 CPU memory 或者自定义资源的超卖。这种方法包含以下优势：

动态超卖：如果通过人工评估，一般会得出静态上超卖系数，但是这种系数往往不足以代表真实的用量，它可能会发生热点，也可能会过小。利用资源画像可以进行定期的建模，然后去做针对每个节点的使用情况去做动态超发。
适用于大小集群：整体超卖，资源利用率提升。
降本：如果业务申请量不够，可以做节点缩容或节点下线；如果业务量足够，就可以让节点承载更多业务，对业务也没有感知

应用规格调整主要通过智能推荐实现，百度内部支持原地 resize，也就是规格调整之后，不会进行 Pod 和 Container 级别的重启。但一般来说不会使用这种方式，主要是有以下几个原因：

代码侵入性比较强：会修改 kubelet 和原生的一些代码
可能重启容器：重启容器的原因是从资源层面来讲内存是不可压缩的资源，如果我们规格调小，可能需要去做重启容器，如果不重启容器，那么它的在单机和调度器等资源视图，中间的状态就比较多
需要业务感知：落地时间长

对于资源超卖的质量保障主要通过精细调度 (负载感知调度)、可迁移性分级、热点治理以及单机驱逐等手段完成。具体来讲，精细调度是根据单机的资源画像预测未来资源使用情况，然后调度不同业务到不同节点，依据是调度完成之后的未来一个月或七天之内，发生热点的概率有多大，如果特别大，就不会去调度在指定的节点并且可以做可迁移性的一个分级。热点治理分为调度器治理和单机治理，做单机治理的主要原因是，监控可能有延迟，没有单机驱逐反应迅速。单机驱逐既支持通过利用率水位线做驱逐，也支持对通过内核指标做驱逐，比如可以通过 ebpf 去做容器级别的 CPU 调度延迟和内存分配延迟的感知。

下图展示了超卖的具体架构：

在实践过程中，通过使用超卖显著提升了分配率，降低了成本。

以 EKS 大集群为例：EKS 平台是基于百度智能云 CCE 容器引擎之上构建得 PaaS 平台，用于支持百度内部各种在离线业务。整体规模 10w 台服务器，单集群规模最大 1w 节点，多地域多集群，以单一集群举例，2500 + 节点，通过超卖下线节点 500+，通过动态系数超卖售卖率达到 125%，基于应用画像智能调度热点率低至 0.3%，通过下线节点方式节约计算节点成本 20%；
在 CCR 小集群中效果同样显著：CCR 是百度智能云容器镜像服务，是面向容器镜像、Helm Chart 等符合 OCI 规范的云原生制品安全托管以及高效分发平台。单集群规模 10-20 节点，多地域多集群，使用动态系数超卖售卖率达到 148%，基于应用画像智能调度规避了热点问题，通过推荐的降规格，缩节点方式，计算节点节约成本 50%。

2.2 在离线混部

将在线服务和离线任务混合混部到相同物理资源上，通过资源隔离、调度等控制手段，充分使用资源，同时保证服务的稳定性，我们称这样的技术为 “混部”。

下图是一个典型的单机模型，从图中可以看出，在线申请用量和在线 usage 之间存在很大的差异，主要是由于研发同学部署业务选择容器资源规格时，带有一定的盲目性，申请量高于实际使用资源量或者按照超出峰值用量申请。混部离线可以复用这部分可回收资源，通过快速填充离线作业，把这部分资源利用起来。

高中优 (在线) 为静态分配 ∑High request+ ∑Medium request <= Host Quota
动态计算低优 (离线) 可用量 Low Quota = Host Quota- ∑High used - ∑Medium used

下图是百度内部的混部整体架构：

最上方调度器层面，使用了 Prometheus 原生的技术栈，可以去单机上抓取对应的指标，再通过资源画像 SRP 建立资源模型，会同步 be 视图（离线的视图）到离线调度器，然后将近线视图同步给 Apiserver
右侧的资源模型分为了多种类型：stable used 和 stable request，对应 K8S 来说就是 Burstable 和 Guaranteed；normal used 和 be used，对应 K8S 的 BestEffort，其中又分了近线和离线两种。可以看到，除了 free 这种没有分配的资源类型，在同一个机器上承载了三种业务（stable、normal、be）并且他们之间互不干扰。
监控方面除了标准的利用率监控，也增加了压力监控，通过 perf ebpf 获取 cpu CPI，内核级别的调度延时，以及内存的分配延时等。

在一个外部落地案例中，某客户的容器化资源比例达到公司 50% 以上，其中容器化环境中的 CPU 平均使用率达到 28%，内存平均使用率 35% 以上。并且该公司已经进行了在离线混部的尝试，在分析该公司在离线服务结构和类型后，我们推荐使用在离线混部手段；克服了缺乏内核隔离技术、在线服务质量差以及离线容器化程度低的挑战，通过对 Hadoop Yarn 的容器化改造，混部调度器无损嵌入，引入内核隔离能力，提供产品化混部运营大盘与策略管理界面等手段，最终使得 CPU 利用率提升至 47%。