百度沙翔宇：百度云原生混部大规模落地实践之路

嘉宾 | 沙翔宇 整理 | 吴林锋

出品 | CSDN云原生

2022年5月31日，在CSDN云原生系列在线峰会第6期"K8s大规模应用和深度实践峰会"上，百度高级研发工程师沙翔宇分享了百度云原生混部大规模落地的架构、核心技术和应用案例。

戳👇观看沙翔宇分享视频

百度沙翔宇：百度云原生混部大规模落地实践之路

当前，越来越多的企业在云上使用基础设施资源，通过Kubernetes平台来管理应用。CNCF 2021年云原生调查显示，96%的组织正在使用或评估Kubernetes。迁移至Kubernetes平台后，68%的受访者表示所在企业计算资源成本有所增加，36%的受访者表示成本飙升超过20%。

基础设施的资源成本增加的同时，我们发现，集群整体的资源利用率却是偏低的。这是由于不同的业务对资源的需求不同、在线业务存在潮汐现象、不同业务部署在不同的数据中心等原因共同导致的。

在线数据中心资源使用情况

这个时候，我们就需要通过一些手段来提高资源利用率，混部就是业内认为提高利用率的一个有效手段。在具体介绍混部系统之前，先来看一下在线业务和离线业务的区别。

• 在线业务对延迟比较敏感，对稳定性要求较高，且需要长期运行。例如广告、搜索类服务，其特征是白天流量高，夜晚流量低，资源使用的波动曲线较大。
• 离线服务对延迟敏感度较低，对稳定性要求不高，允许失败后重跑，且一般运行的时间都比较短，资源使用率一般较高，如大数据、AI等业务。

结合在线资源利用率低的特点，以及它具有典型的潮汐现象，这时我们就可以利用离线服务来填充在线作业的空闲资源，在资源上形成互补。

混部架构

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

百度混部已有10余年历史：

• 2011年开始准备做混部
• 2012年混部的规模达到上万台
• 2014年上线Matrix和离线诺曼底调度器
• 2015年上线在离线混部平台“千寻平台”
• 2017年混部规模达到5万台，此时的架构开始向K8s方向演化
• 2020年混部的规模达到30万台，K8s集群的规模超过10万，整机CPU利用率提升到40%以上，内存利用率提高到60%以上，为公司节省了10万台的物理机成本，价值20亿元

可以看到，混部的确是能为企业节省很大的成本，但它不仅仅是把在线服务和离线服务部署到一起，而需要从多方面来进行考虑。例如在混部离线后要优先保证在线服务的质量，在保证在线服务的前提下，最大程度地提高资源利用率，同时需要保证离线业务的SLA，保证离线业务不能无限地被压制和重试。

基于此，我们开发了百度云原生混部系统，云原生混部系统的核心分为三个部分：单机管理层、调度层、运营层。

• 单机管理层具体实现混部的单机Agent，它会以Demon Set的形式部署在每一个K8s的Worker节点上。混部单机服务首先负责资源质量的管理，提供内核级别的QoS隔离能力。其次负责资源视图的上报和策略的执行，在在线业务的质量受损时，在CPU、Memory、磁盘、网络4个维度进行离线任务的压制和驱逐。混部单机还提供了动态SLA的感知能力和eBPF细粒度指标的采集的机制，对在线业务提供保障。
• 调度层使用混部调度器，它首先负责资动态源视图的感知，其次是提供丰富的调度策略将业务调度到最合适的节点，比如组调度、基于容量的调度、抢占调度等。
• 运营层通过资源画像、资源运营、水位设置、热点治理等功能，一方面帮助用户接入混部，另一方面是在提高资源利用率的同时保证服务的稳定性。

混部核心技术

如何复用在线资源

下图是线上的一个原生K8s节点的监控图，可以看到，CPU分配了89c但只使用了11c。申请的很多，实际使用却很少，浪费的资源也无法做复用。

是什么原因导致的呢？来看下图示例。

图中，黄色框代表2个Node，这两个Node的CPU总数都是40核，并且都已经分配了38核。其中NodeA的真实用量是35核，NodeB的真实用量是10核。而蓝色框则代表当前还有3个待调度的Pod。

若想调度 3 个 Pod：

• PodA的Request和Limit都是5c，此时它无法被调度，即使Node B上还有空闲资源
• PodB的Request为1c，Limit为10c，该Pod超发比较严重，它可以被调度到NodeA或NodeB，但调度到NodeA时可能被驱逐
• PodC的Request和Limit都没有填写，此时它可以被调度，但当调度到NodeA时可能被驱逐

因此，可以尝试总结为什么原生Kubernetes没办法直接解决资源利用率的问题。

第一，资源使用是动态的，而配额是静态限制。在线业务会根据其使用的峰值去预估 Quota（Request和Limit），配额申请之后就不能再修改，但资源用量却是动态的，白天和晚上的用量可能都不一样。

第二，原生调度器并不感知真实资源的使用情况。所以对于PodB、PodC这种想要超发的业务来说，无法做到合理的配置。

为了解决改问题，我们引入了动态资源视图。

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

再看刚才的例子。通过添加一个Agent去收集单机的资源用量情况，并且汇总计算得到动态的资源视图（机器真实的用量情况），将其上报到调度器，在调度器中配置相关策略，可以将PodB和PodC准确地调度到NodeB上。

也就是说通过构建资源视图，可以将Limit大于Request的Pod或者没填Request和Limit的Pod，调用到真实用量更少的Node。这个方法可以解决由于不知道机器到底用了多少资源，所以调度失败被驱逐的问题，最终达到提升CPU利用率的效果。

质量分级

大多数情况下，用户都倾向于使用Limit比Request大很多的资源，基于此我们构建了质量分级的概念。向用户承诺Request申请资源是稳定的，应用在任何时间都必须对Request做出保障。

分级之后产生了新问题，因为所有用户都倾向于去使用稳定的资源，但从平台成本的角度来看，并非所有业务都必须需要使用高质量的资源。在做完质量分析后，我们引入了账单系统，对不同质量的资源进行分开计费，用户可以根据应用的实际情况以及部门预算来选择自己使用哪种质量的资源。

资源隔离

资源隔离是混部中一个很重要的模块，主要保证在线服务的质量不受影响，可以将其分为4个模块：CPU、内存、IO和网络。

CPU

首先是抢占，引入离线调度算法，满足在线业务对离线业务的快速抢占需求。通过超线程隔离来保证在线业务和离线业务的运行优先级，保证在线业务和离线业务运行在同一个逻辑核时，在线业务的优先级永远是高于离线优先级的。其次是限制，通过L3Cache隔离，限制离线最多使用的L3Cache。最后通过NUMA调度，感知NUMA架构，将在线业务绑在同一NUMA上，提高在线业务运行效率。

内存

内存隔离主要分为两部分，第一部分是OOM优先级，当发生Memory OOM时，优先杀掉离线任务，来保证在线业务的运行；第二部分是内存回收隔离，Cache的回收在Linux中并不对在线业务和离线业务进行区分，这可能会使在线业务的Cache优先于离线的Cache被回收，造成Cache命中率降低，性能受到影响。

为了解决以上的问题，我们新增异步回收机制。

异步回收机制是根据在线、离线的QoS的不同设置不同的异步回收水位，优先回收离线业务的Cache。了避免高优任务受到影响，网络层面我们开发容器级别的出入、网带宽限制等，通过报文进行质量分级，对离线业务进行流量限制。

服务质量提升

前面已经提到可以使用C Group做资源隔离以及内核的QoS能力来保护在线服务的服务质量，那么采用了这些措施们就不需要担心在线服务的性能了吗？

其实未必。由于它们运行在同一个物理机上，对于一些物理资源来说并没有做到完全的隔离。另外由于它们共享了内核，在内核层面上也有资源的竞争，所以除了资源隔离，在上层还需要为在线服务提供保护措施。

单机退避策略

设置整机的CPU阀值X，当整机CPU用量趋近或超过一定用量时，会执行对离线任务的压制和驱逐策略，压缩离线使用的CPU资源。

同样，对于内存、IO和网络也做同样的限制，这样可以根据不同的机型和业务很方便地调整离线的用量，避免在线用量升高时性能受到影响。

基于eBPF的干扰检测

判断在线业务是否受到干扰，最好的指标是业务暴露的指标，如时延、错误率等。

目前混部主要使用的是eBPF，无入侵地对CPU排队延迟、内存分配延迟、在线业务的CPI以及IO排队延迟等进行采集。

资源画像

资源画像也可以称为应用画像，基于应用历史资源使用量的数据，通过算法训练可以得出未来1天或1周的预期使用量。

资源画像可以适用于以下场景：

• 在线调度
• 离线调度
• 重调度
• 低负载应用治理
• 智能HPA

热点问题

为了避免和降低热点的问题发生概率，主要提供了三种方式来进行热点问题的处理。

• 第一种就是我们根据应用的资源画像。在调度时，尽量避免将CPU用量很高的应用调度到同一台物理机上，最大程度地避免热点问题发生的概率。
• 在调度之后，定期在单机上做处理。根据服务的资源画像，对可能出现的热点机器做应用迁移，避免热点方向的概率。
• 若已经发生了热点，借助重调度对集群中存量的热点机器上的应用做迁移，保证服务的运行质量。

混部最佳实践

外部落地案例——互联网客户月销节省50W+

背景：容器化资源比例达到公司50%以上，其中容器化环境中的CPU平均使用率达到28%，内存平均使用率35%以上，并且该公司已经进行了在离线混部的尝试。

挑战：离线容器化收益低且挑战巨大；缺乏内核隔离技术，影响在线服务质量；在离线混部产品化程度低。

通过混部落地后的效果：

• CPU利用率提升至47%
• Hadoop Yarn容器化改造，混部调度器无损嵌入
• 引入内核隔离能力，全面保障在线业务质量
• 提供产品化混部运营大盘与策略管理界面，全面提升运营效率

内部最佳实践——大规模落地混部、超卖、全面提升TVO

背景：百度EKS平台是基于CCE容器引擎之上构建得PaaS平台，用于支持百度内部各种在离线业务，整体规模10w台服务器。

挑战：成本居高不下，TVO只有50%；利用率低，30%左右；调度效率低不满足大数据要求。

通过混部落地后的效果：

• 将离线业务统一调度，大数据生态无缝打通，调度效率5000pod/s
• 动态系数超卖，售卖率达到125%
• 基于应用画像智能调度，热点率低至0.3%
• 资源分级供给，市场定价，TVO从50%提升至95%

混部未来探索

从实际情况看，混部帮助我们提高了整体的资源利用率，降低了资源使用的成本。在未来，百度会继续扩大混部的规模，更大规模地去节省资源的成本，主要涉及三个方面。

1. 软硬结合的资源隔离

• 微架构通用性能指标
• 基于RDT的CPU隔离

1. 异构资源的混部调度能力

• cGPU显存的隔离与共享
• ARM、GPU、FGPA等异构场景的GPU调度能力

1. AI相结合的智能化调度与运营

• 应用画像分析，资源趋势预测
• 资源趋势预测，弹性资源预采购
• 多云弹性混部

聚焦云原生新技术、新实践，帮助开发者群体赢在开发范式转移的新时代。欢迎关注CSDN云原生微信公众号～

** 限时活动，数量有限🔥**

关注【CSDN云原生****】公众号，回复【图书】

邀请好友助力即可免费领图书，赶快参与吧！

​