深入理解百度在离线混部技术顾延笙

混部概念中将应用类型分为在线业务和离线业务两种。

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

2.资源利用率为何不高

纯在线业务集群的平均利用率普遍不高，百度应用混部技术之前，在线业务集群CPU利用率普遍在20%左右，造成这种现象主要由一下几种原因：

2.1潮汐现象和冗余

在线业务在申请资源的时候，一般是按照最高峰值评估资源去申请资源，同时还会上调一些，这就导致了业务对资源预估不准，申请的资源远大于实际使用资源。甚至可能会部署多个副本作为灾备。

此时的低峰时利用率就会非常低，导致整体利用率不高。

2.2在离线分池

一般来说机房规划的时候有一个非常大的特点，就是离线机房与在线机房分离做规划。举个例子，假如我们在宁夏做一个机房，这个时候肯定会考虑做一个离线机房，因为在线机房需要考虑网民请求地域分布的问题，要获得最好的访问优化体验以及访问速度，势必需要在一些访问热点上去做自己的在线机房规划，比如北京、上海、广州等。

而对于离线机房来说不用关心这些，它最在乎的是如何提升计算和储存的资源和基础设施的规模，所以在线业务和离线业务本身的资源需求和特点不一样，资源利用率非常不均衡。常态表现就是在线利用率低，离线利用率高，且常态资源不足。

针对以上场景，我们通过在离线混部技术将在离线资源统一资源池，把离线作业部署在在线资源池节点上，充分利用机器资源，达到了提升资源利用率的目的。

3.百度云原生混部详解

随着Kubernetes(以下简称「K8s」)生态的蓬勃发展，百度很多业务已经搭建并且运维了自己的诸多K8s集群，同时也遇到了一些问题，比如上面所说的资源利用率不高。我们根据内部积累混部经验对K8s进行在离线混部原生化改造，做到了零入侵K8s，可移植，可支持大规模集群。

混部系统架构图

3.1如何做到资源复用

原生K8s基于静态视图分配

上图显示了一个节点的CPU使用率和分配率，分配率为89%，使用率在0-16点之间都在20%以下，17点开始是用量高峰，在30-40%之间。可以看出request和used之间有大量的资源处于闲置状态，如果想让这部分资源可以重复利用起来，就需要调度更多的Pod上去，但是从K8s调度器视角来看，已经没有更多的CPU分给Pod了。

如果部署request和limit都不填写的Pod，此时它可以被调度，但是K8s针对这种BestEffort的Pod不会根据用量调度，可能会被调度到一个实际很繁忙的节点上，非但无法起到提升使用率的效果，可能还会加剧节点上服务的延迟。

动态资源视图

针对K8s无法根据资源使用量分配资源，我们引入了动态资源视图。

在混部调度中，在线和离线使用相同的物理资源，在线看到的资源视图和离线看到的资源视图相互独立。在线业务看到的可用资源依旧为整机资源进行静态分配，离线看到的可用资源为整机资源减去在线作业已经使用的资源。

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

高中优(在线)为静态分配∑Highrequest+∑Mediumrequest<=HostQuota

动态计算低优(离线)可用量LowQuota=HostQuota-∑Highused-∑Mediumused

注：以上是理想情况下的公式，实际应用中需要对离线使用量设置一个上限，此处排除了上限造成的影响。下面会有单机资源管理的说明。

由于K8s是静态分配，在K8s的QOS模型中BestEffort是不占用request的，即使一个node上即使资源已经分配完，但是BestEffort类型的资源依然可以调度上去，所以我们复用了BestEffort模型给离线任务使用，如上文架构图所示，这样有以下的优点：

解决了在离线视图冲突问题，离线使用的BestEffort模型，对在线不可见

兼容社区组件，比如cadvisor可以直接使用

无需修改已有组件，包括kubeletcontainerdrunc，侵入性小，可以直接安装混部系统，享受混部带来的资源效能提升。