【百度云原生导读】服务器资源利用率较低，TCO(IT 基础设施的总领有老本)逐年上涨，对于领有大量机器资源的公司来说无疑是一个头疼的问题。混部技术就是在这种状况下应运而生，目前，混部技术在业界还属于比拟小众的畛域，只有一些资源量级较大的公司在钻研、倒退混部技术，以期取得收益。

对于百度而言，通过利用混部技术，主混部集群数十万台，晋升 CPU 利用率到 40+%，累计节约了数十亿人民币。目前百度容器引擎产品 CCE 已反对在离线混部，并实现了大规模业务落地，本文将带大家深刻理解百度的在离线混部技术。

1. 什么是在离线混部

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

在线和离线业务如何划分？在百度外部，咱们认为在线业务特点包含但不限于：运行工夫长，延时敏感，对稳固向要求较高，服务不稳固业务会立马感知并且带来损失，有显著的波峰波谷，白天高，深夜低，比方广告搜寻业务；而离线业务的特点包含但不限于非延时敏感，可重试，运行工夫个别较短在几十分钟左右，外部个别为大数据计算，机器学习等服务。

在线业务以搜寻为例，白天用户工作学习时查问量会十分大，然而当大部分用户夜间劳动时，查问量绝对白天就会变得十分小，此时咱们就能够引入离线业务。离线业务没有严格的工夫要求，随时都能跑，用户关怀的是工作能不能跑完，对于什么时候跑完并没有太大的需要，同时如果单机上资源有抵触，此时咱们会压抑离线业务，甚至会驱赶离线业务，这对用户是无感的，计算平台从新拉起工作，持续计算。

因而，在线型业务和离线业务具备资源互补的特点，从工夫上和对资源的容忍度上能够完满的联合到一起。一方面，在线业务的优先级更高，单机和调度层面会优先保障在线的资源，可能会对离线进行压抑和驱赶，另一方面，对于离线工作来说，压抑和驱赶对用户是无感的，只须要保障工作顺利完成，有很高的容忍度。

简略来说，将在线业务和离线工作混合混部到雷同物理资源上，通过资源隔离、调度等管制伎俩 , 充沛应用资源，同时保障服务的稳定性，咱们称这样的技术为“混部”。

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，侵入性小，能够间接装置混部零碎，享受混部带来的资源效力晋升。

3.2 优先级

因为在离线业务同时部署在雷同节点上可能会产生烦扰，咱们从调度和单机两个方面对在线离线做了优先级辨别。

大的优先级分为 (高，中，低) 三种，其中高优中优为在线业务，低优为离线业务。每个优先级优化分若干小优先级。

首先看一下 K8s 的 QOS 模型

• Guaranteed :  当 Pod 中所有 Container 的 request == limit 时
• Burstable : 当 Pod 中存在 Container 的 request != limit 时
• BestEffort : 当 Pod 中所有 Container 均未设置 request, limit 时

比照 K8s 模型，百度混部调度器做了如下扩大：

3.3 资源隔离

因为在离线混部是 将在线业务和离线工作混合混部到雷同物理资源上，所以在离线业务因为流量激增，呈现资源争抢时，如何保障在线的 SLA 不受影响，并且在保障在线服务的 SLA 时，也要保障离线工作的整体品质，保障离线作业的成功率和耗时。

CPU

cpuset 编排

针对于须要绑核的在线业务，单机上能够感知到 CPU 拓扑，不须要 kubelet 开启绑核机制，能够间接进行绑核，会将在线业务尽量绑在同一 NUMA node 上，防止跨 node 通信提早。

NUMA 调度

NUMA 是一种内存治理技术，在 NUMA 架构下 CPU 被划分为多个 node，每个 node 都有各自的 CPU core 和 local memory，node core 中的过程拜访 local memory 和 remote memory 的代价是不一样的。节点的所有内存对于本节点所有的 CPU 都是等同的，对于其余节点中的所有 CPU 都不同。因而每个 CPU 能够拜访整个零碎内存，然而拜访本地节点的内存速度最快(不通过互联模块)，拜访非本地节点的内存速度较慢(须要通过互联模块)，即 CPU 拜访内存的速度与节点的间隔无关。

针对开启了 NUMA 的节点，咱们感知 NUMA 架构，将在线业务绑在同一 NUMA 上，晋升在线业务的性能，并且感知 NUMA 节点的负载，当 node 之间呈现显著的不均衡时，进行重调度。

离线调度器

在线业务要求实时性高，提早低；为了保障低提早，CPU 负载不会打的特地高，当 CPU 负载升高时，在线间烦扰会导致延时增大。而离线业务个别 CPU 利用率高，然而重吞吐不重延时。所以如果能满足在线的延时保障，在线和离线跑在一个核上不会对在线造成烦扰，那么能够极大的晋升资源利用率。

依照当初通用的 Linux 内核调度器调度算法，无奈给在线服务做 CPU 的强保障，无奈辨别在离线业务，会导致在线无奈抢占离线 CPU，并且在负载平衡时，因为无奈辨别在离线业务，可能在线业务会调配到雷同的核上，无奈打散。导致性能降落。

离线调度器是一种离线工作专用的 CPU 调度算法，从调度器上离开，在线调度器看不到离线工作。在线调度器先于离线调度器进行任务调度，存在在线工作时，离线得不到调度。所以对于在线工作来说，能够达到混部前相近的 CPU 品质。

内存

Linux 零碎会常常执行一些写日志、生成备份文件的工作，当这些文件比拟大时相应的 cache 就会占用大量的零碎内存，而且这些类型的 cache 并不会被常常拜访，所以零碎会定期将这些 cache flush 到磁盘中。Linux 会通过 cache 回收算法进行回收。这会造成两个问题：

1. 容器的 page cache 得不到回收，它依赖于容器治理 page cache 的机制是须要才去回收的形式，即没有后盾回收，每次都是调配时候发现达到 limit 了，在 alloc 的时候登程回收，如果业务压力较大，调配的速度大于回收的速度，就可能呈现 OOM 的问题

2.cache 回收时并不会辨别在线离线业务，会导致在线业务的 cache 可能会被先于离线 cache 回收掉，如果在线有大量的读 cache 行为，会造成 cache 命中升高，间接进行读盘操作，会导致在线业务的性能降落，甚至会导致 IO 夯住。

为了解决以上的问题，咱们新增了背景回收机制，背景回收指的是异步回收 cache，依据在线离线的 QOS 不同，设置不同的背景回收水位，优先回收离线业务的 cache。

• 每个容器后盾周期主动回收本人产生的 page cache
• 每个容器都能够设置开关和本人的高下水位线

网络层面咱们也开发了容器级别的出入网带宽限度和流量打标等 Cgroup 子系统，能够对离线进行流量限度。

更多的内核隔离见下图：

基于 eBPF 的动静策略

现有的内核隔离策略都是基于 QOS，创立容器时进行 cgroup 配置，由内核进行对立的资源管理，然而某些高敏业务在最高优先级的 QOS 下也无奈保障其特定资源，或者须要某一纬度的资源须要高优保障，此时通用隔离策略无奈满足。

另外因为隔离调度策略是全局对立的策略，业务如果想依据本身特点批改一些隔离能力，只能由业务反馈平台，平台对底层进行批改，周期较长，并且全局利用的隔离能力可能会对离线或者其余业务造成误伤，所以把隔离晋升到用户态更合乎业务需要。

针对这样的场景，因为 eBPF 稳固，平安，高效，并有可热加载 / 卸载 eBPF 程序，无需重启 Linux 零碎的个性，咱们基于 eBPF 开发了定制策略，能够实时下发，实时失效，侵入性小，不须要对业务既有服务和平台侧进行批改。能够在用户态针对某些业务进行定制化隔离策略更新，达到服务能够无差别混部的指标。

单机资源管理

在混部时，离线能够占用多少资源始终是一个问题。机型不同，在线服务的敏感度不同，离线业务占用的资源多少对在线造成的影响也不尽相同，针对这种状况，咱们对集群纬度，池 (具备雷同个性的一批机器) 纬度，节点纬度对离线可用资源下限做了限度，其中粒度最小优先级最高。

以 CPU 为例，如下图：

咱们设置了整机的 CPU 阀值 X，当整机 CPU 用量趋近或超过肯定用量，比方 X =50% 时，会压缩离线应用的 CPU 资源。

列举一个简略的公式：

Offline Quota =  Host Quota * X – ∑NotOffline Used

Offline Free = Offline Quota –  ∑Offline used

同样，对于 Memory，IO 和网络咱们也做了同样的限度。这样咱们能够依据不同的机型和业务很不便的调整离线的用量，防止在线用量升高时性能受到影响。

3.4 高性能调度器

在线和离线业务的调度需要是不一样的，在线个别为常驻服务，不会频繁变更，对调度器要求较低。然而离线工作因为具备运行工夫短(几分钟到几小时)，工作多的特点，以 K8s 默认调度器的调度性能不足以撑持离线工作的调度。所以咱们开发了高性能的离线调度器，计算能够达到 5000 ops。

如上图所示，咱们调度了 15W 个 Pod，计算性能能够达到 5k ops，为了避免调度速度过快，对 ETCD 和整个集群造成压力，咱们限度了 binding 速度为 1500 ops。

3.5 资源画像

单机资源隔离是针对曾经调度到节点上的工作进行隔离，如果检测到离线工作对在线产生肯定的影响后，会很快响应对离线工作进行压抑和驱赶的操作。这样会影响离线工作的稳定性。针对这种场景，如果在调度时能够预测到节点上将来一段时间的在线使用量，能够针对性的调度离线工作。

比照实时计算的资源模型，假如离线作业的运行工夫为 1 小时，如果资源模型应用实时的资源视图，如果在线作业会在半个小时候用量升高，那么当离线作业运行半个小时之后，资源被在线压抑，运行品质受影响。

咱们预测了将来 1 小时窗口内的在线资源用量，调度适当的离线工作下来，即可确保任意离线作业运行过程中资源不受任何压抑，从而达到晋升运行品质的目标。

如何提供更稳固的超发资源，则取决于咱们资源预测的准确度是什么样的。

不仅离线调度须要资源画像，在线调度也须要资源画像，通过资源画像能够无效的防止热点产生。

• 对于在线调度来说，调度的次要指标是晋升服务的可用性，在调度时应用资源画像来预测将来一个周期内的用量，能够防止热点问题(某一纬度的资源用量过高)，并且在重调度时也能够躲避热点问题。

• 对于离线调度来说，调度的次要指标是晋升集群的吞吐，升高作业的排队工夫和执行工夫，所以资源画像能够晋升离线作业的稳定性，防止驱赶从新调度和资源压抑导致执行工夫过长。

4. 将来瞻望

百度目前混部规模数十万台，它的混部集群 CPU 利用率比在线利用率晋升 40%—80%，累计节俭近 10 万台服务器。

将来百度混部的次要指标是持续扩充混部的规模，更大规模地节约资源老本，能够反对更多的负载类型，不局限于在离线混部，要做到无差别混部。

• 在单机隔离方面，反对更多的业务进入混布，在检测抵触和资源隔离方面做的更好。
• 调度方面做更有打算的调度，资源画像更加精细化，调度时能够更精准的预测热点概率，优化调度能力，缩小热点率。

并在以下方向投入更多的力量：

• 内核可编程技术：

通过 eBPF 可观测技术的翻新，实现混部容器负载性能的近距离察看，达到进一步无损高密度混

利用 eBPF 热加载 / 卸载的个性，能够用户态下发隔离策略，疾速的解决高敏的资源品质问题

• 异构：更好的反对 GPU 等异构资源混部，进步异构资源效力与弹性，大幅升高 GPU 老本。
• 容器虚机交融：解决高密机型共享内核混部的瓶颈。
• 多云混部：联合私有云进行极致的弹性，例如联合弹性竞价实例，基于用户对价格的敏感度设置，主动纳入或者摘除竞价实例，用于离线业务运行或混部，实现多云弹性混部。

对于百度容器引擎 CCE

百度容器引擎产品 CCE 提供 Docker 容器生命周期治理、大规模容器集群运维治理、业务利用一键式公布运行等性能，无缝连接百度智能云其余产品。弹性、高可用的云端 Kubernetes 容器运行平台，助力零碎架构微服务化、DevOps 运维、AI 利用深度学习容器化等场景。

———- END ———-

百度 Geek 说

百度官网技术公众号上线啦！

技术干货 · 行业资讯 · 线上沙龙 · 行业大会

招聘信息 · 内推信息 · 技术书籍 · 百度周边

欢送各位同学关注