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

　　1. 什么是在离线混部

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

　　

 

　　在线和离线业务如何划分?在百度内部，我们认为在线业务特点包括但不限于：运行时间长，延时敏感，对稳定向要求较高，服务不稳定业务会立马感知并且带来损失，有明显的波峰波谷，白天高，深夜低，比如广告搜索业务;而离线业务的特点包括但不限于非延时敏感，可重试，运行时间一般较短在几十分钟左右，内部一般为大数据计算，机器学习等服务。郑州妇科医院http://www.zzchxb110.com/

　　在线业务以搜索为例，白天用户工作学习时查询量会非常大，但是当大部分用户夜间休息时，查询量相对白天就会变得非常小，此时我们就可以引入离线业务。离线业务没有严格的时间要求，随时都能跑，用户关心的是任务能不能跑完，对于什么时候跑完并没有太大的需求，同时如果单机上资源有冲突，此时我们会压制离线业务，甚至会驱逐离线业务，这对用户是无感的，计算平台重新拉起任务，继续计算。

　　因此，在线型业务和离线业务具备资源互补的特点，从时间上和对资源的容忍度上可以完美的结合到一起。一方面，在线业务的优先级更高，单机和调度层面会优先保障在线的资源，可能会对离线进行压制和驱逐，另一方面，对于离线任务来说，压制和驱逐对用户是无感的，只需要保证任务顺利完成，有很高的容忍度。

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

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

　　高中优(在线)为静态分配 ∑High request + ∑Medium request <= Host Quota

　　动态计算低优(离线)可用量 Low Quota = Host Quota - ∑High used - ∑Medium used

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

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

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

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

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