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

Posted 2022-06-03 CSDN云原生

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了百度沙翔宇：百度云原生混部大规模落地实践之路相关的知识，希望对你有一定的参考价值。

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

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命中率降低，性能受到影响。

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