前几天在KM上看到的深度好文，去和各位大佬要了授权。拿出来分享一下

导读

服务器资源利用率较低，IT基础设施的总拥有成本（TCO）逐年上涨，一直是困扰很多企业的难题。随着云原生技术的发展，Kubernetes逐渐成为数据中心的一项基础设施，将在/离线业务统一使用Kubernetes调度编排日渐成熟。本议题结合网易轻舟在这一领域的工作实践，介绍如何基于Kubernetes通过混合部署，在不影响在线业务的前提下将CPU利用率提高到50%以上，大幅降低企业数据中心成本。

前言

数据分析显示，数据中心成本中，服务器采购成本占比超过50% 1, 2 ，而全球服务器平均资源利用率不到20%，并且服务器一般3~5年就会淘汰，需要购置新服务器，造成了巨大的成本浪费。

如果数据中心或者机房规模较小，服务器数量有限，很少有人会去关注资源利用率这个问题。因为在小规模场景下，耗费人力、物力想办法提高服务器资源利用率并不会获得太高的收益。如果数据中心规模比较大，提升数据中心资源利用率则能够显著降低成本、带来巨大收益，所以国内外的大型互联网公司，很早就开始投入大量的人力物力进行较多的探索实践。

近几年，随着云音乐、严选、传媒、有道等互联网业务的快速发展，网易内部的服务器数量不断攀升，而实际资源利用率又比较低，IT基础设施成本问题日益严峻。面对日益增长的业务，我们希望用最小的基础设施资源成本来支撑更大的业务需求。提升服务器资源利用率成为一个比较重要的解决手段。

网易轻舟团队提出了一套基于kubernetes的业务混部方案，目前已经在网易内部得到广泛应用，在不影响业务SLO（service-level objective）的前提下，资源利用率得到显著提升。

本文将从以下几个方面逐步展开：

• 资源利用率现状和原因分析
• 如何通过混部提高资源利用率
• 落地成果
• 未来展望

资源利用率现状和原因分析

麦肯锡数据统计显示，整个业界的服务器平均利用率大约为6%，而Gartner的估计要乐观一些，大概在12%。国内一些银行的数据中心的利用率大概在5%左右 3 。

而造成利用率比较低的原因主要有以下三个方面：

• 不同类型的业务划分了独立的服务器资源池

绝大多数企业在构建数据中心或者机房的时候，对于在线服务（latency-sensitive service）和离线服务（batch job）是单独采购机器并且分开管理部署的，各自采用独立的资源调度管理系统（比如离线业务使用Yarn调度，在线业务Mesos调度），从服务器采购、规划到业务调度层面都是完全隔离的。

 

图1 Google数据中心资源使用情况

图1(b) 是Google 专门运行在线应用的2万台服务器CPU利用率分布图，大部分处于30%左右。图1© 是Google专门运行批处理作业的2万台服务器CPU利用率分布图，大部分在75%左右 3。

在线业务SLO要求较高，为了保证服务的性能和可靠性，通常会申请大量的冗余资源，因此，会导致资源利用率很低、浪费比较严重。而离线业务，通常关注吞吐量，SLO要求不高，容忍一定的失败，资源利用率很高。

假如将离线业务跑在在线业务的机器上，充分利用在线业务的空闲资源，那是不是就能节省下离线业务的服务器成本了呢？

• 服务的reserved资源和实际used资源存在较大Gap，通常overprovision

业务通常是有波峰和波谷的，用户在部署服务时，为了保证服务的性能和稳定性通常都会按照波峰申请资源，即 provision resource for the peek load，但是波峰的时间可能很短。另外，也有相当一部分用户对于自己服务的资源使用情况不是很了解，在申请资源时具有较大盲目性，但是通常也是申请过量资源而不是申请的过少。

图2 推特数据中心资源使用情况

图2 是推特数据中心资源使用情况，可以看到cpu利用率大约在20%左右，但是用户申请了60%左右的cpu资源；内存利用率在40%左右，但是用户申请了80%左右的内存资源 4。

服务A已申请的但是实际没有使用的资源，即使是空闲的，其他服务也是不能够使用的。Reserved - Used差值越大，资源浪费越多。所以我们应该如何去缩小Reserved - Used的差值，从而提高业务部署密度和资源利用率呢？

• 业务负载具有明显的时间上的波峰波谷，处于波谷时，空闲资源其他服务无法使用

很多面向用户的在线服务具有明显的波峰波谷，比如白天用户使用量较多，资源利用率相应较高，但是夜间用户使用量较少，资源利用率相应较低。夜间空闲出来的资源，其实都是浪费的。那夜间空闲出来的这部分资源是不是也可以用来跑离线业务呢？

在/离线业务混部

在线业务（latency-sensitive service）：和用户存在交互的、并且对交互延时敏感的应用称为在线业务。例如：网络搜索服务、即时通讯服务、支付服务、游戏服务等，延迟对于这些服务的服务质量至关重要，故称为“延时敏感”，在线业务通常有着严格的SLO（service-level objective）。

离线业务(batch job)：和用户不存在交互，对延时不敏感的应用称为离线业务。例如：Hadoop生态下的MapReduce作业、Spark作业、机器学习的训练作业、视频转码服务等。这些作业对于其完成时间的容忍度较高，故称为“延时不敏感”。离线业务通常没有严格的SLO 。

表1 在线服务和离线服务对比

混合部署（co-location）：是指将在线业务和离线业务混合部署在同一集群和服务器上。

传统的数据中心中，之所以将在/离线服务分开部署管理，实属无奈之举：

• 混部会带来底层共享资源（CPU、内存、网络、磁盘等）的竞争，会导致在线业务性能下降，并且这种下降是不可预测的
• 在/离线服务分属不同的研发、产品团队，成本管理是分开的
• 在/离线服务使用不同的资源调度管理系统，无法统一调度

如果能够将离线服务跑在在线服务的机器上，充分利用在线服务的空闲资源，则能够显著提升资源利用率降低服务器成本。

图3 在/离线业务混部

随着云原生理念、容器和微服务的普及，Kubernetes 逐步统治了容器编排领域，成为数据中心的基础设施。将在/离线业务统一使用 Kubernetes 调度管理，日渐成熟。

接下来，本章节会详细讲解如何基于 Kubernetes 实现在/离线业务的混部，在复杂的基础设施架构下，面对众多的共享资源，如何实现多维度的资源隔离，最小化在/离线业务之间的性能干扰，保证在线业务的运行性能、提升离线业务运行效率。

Kubernetes native feature

因为要基于Kubernetes 实现在/离线业务的混部，所以需要先了解 Kubernetes 有哪些功能能够帮助实现混部，以及 Kubernetes 本身存在哪些问题。

Pod Priority

pod是有优先级（pod priority）的，相应字段是pod.spec.priority，它表示了pod的重要程度，值越大优先级越高。调度器调度的时候会优先调度高优先级的pod，Kubelet在驱逐过载节点的pod时，会优先驱逐低优先级的pod。

所以，可以将离线任务设置较小的pod priority。

Pod QoS

Pod有三种QoS class：

• Best Effort： 如果pod的cpu/memory资源的request和limit都没有设置，则该pod属于Best
  Effort类型
• Guaranteed：如果pod的cpu/memory资源的request和limit都设置了，并且每个资源的request值等于limit值，则该pod属于Guaranteed类型
• Burstable: 剩下的则是Burstable类型

其中，Guaranteed pod对于 SLO 要求最高，有最高的资源保证；Burstable pod对于 SLO 要求次之，仅保证 request 部分的资源；Best Effort pod 对于 SLO 要求最低，资源无法保证。

表2 不同 QoS class pod 的 OOM Score

Best Effort类型pod的 OOM Score 是最大的，也就是说在发生系统OOM的时候，首先kill的就是Best Effort类型的pod。

当节点上内存、磁盘等非可压缩资源负载过高时，kubelet会驱逐上面的pod，保证节点稳定性，驱逐的顺序是： Best Effort、Burstable、Guaranteed。

所以，是不是可以将离线任务归为Best Effort class 呢？

Kubelet CGroup Manager

Kubernetes 是使用 cgroups 来实现pod的资源限制的。

图4 pod cpu cgroups

图4 是Kubernetes cpu cgroups的层级，三种不同的颜色表示三种不同的QoS class：

• kubepods 的cpu.share 只在kubelet启动的时候设置一次
• besteffort和burstable的cpu.share，每隔1分钟更新一次. 有pod创建删除也会触发更新
• pod的cpu.share和cfs quota只在创建时设置，后面不再更新

图5 pod memory cgroups

图5 是Kubernetes memory cgroups的层级，三种不同的颜色表示三种不同的QoS class：

• kubepods 的memory.limit_in_bytes 只在kubelet启动时设置一次
• besteffort和burstable的memory.limit_in_bytes，后面不会更新
• pod的memory.limit_in_bytes只在创建时设置，后面不会更新

之所以在这讲一下Kubernetes pod cgroups的层级组织结构和动态更新策略，是因为我们开发的资源隔离组件也是通过更改cgroups配置来实现资源隔离的。如果不知道Kubernetes原生的cgroups管理策略，很容易发生更新失效或者冲突，引发故障。

K8S 本身存在的问题

• 静态调度

Kubernetes是使用的静态调度。静态调度是指根据容器的资源请求（resource request）进行调度，而不考虑节点的实际负载。所以，经常会发生节点负载很低，但是调度不了新的pod上去的情况。

Kubernetes为什么会使用静态调度呢？因为要实现一个基于节点负载进行动态调度的通用框架是很困难的。而静态调度实现简单、管理方便，但是对于用户的要求要高一些，如果 resource request 配置的不合理，可能会导致节点之间负载不均衡以及利用率较低。

• 隔离性较弱

Kubernetes 是没有区分在线业务和离线业务的，当前的cgroups层级组织结构也很难将在/离线业务区分开，很难实现动态的资源分配和动态的资源隔离。所以，也无从谈起在/离线业务的性能隔离，顶多就是不同pod之间的隔离。

而 Kubernetes 对于pod之间的资源隔离也是很弱的，仅仅通过cgroups在cpu维度使用cpu.shares控制发生cpu争用时的时间片分配比例，使用cfs quota限制cpu使用上限；内存维度使用memory limit in bytes限制使用上限。

如果贸然将在/离线业务混部在同一台机器上，是无法保证在线业务的SLO的。

 

篇幅有限，下一篇明日同步！

如果你想提前知道他们的经验总结和独家干货，可以私信我，我给你发本地文档方便保存噢。

如果你喜欢这篇文章的话，别忘了 转发、收藏、留言互动！

还有，关注我！关注我！关注我！

 

大佬们分别是： 张晓龙——网易数帆轻舟技术总监。负责基础设施研发 /运维至今，在虚拟化、网络、容器、大规模基础设施管理以及分布式系统等技术架构有多年经验，当前主要兴趣点在云原生技术方向。 李岚清——网易数帆轻舟业务部资深系统开发工程师。具有多年Kubernetes开发运维经验，负责在/离线业务混部、容器网络编排等多个项目，推动和协助网易内部多个业务实现容器化。 陈林亮——网易数帆轻舟资深云计算开发工程师。具有多年云计算开发，运维及优化经验，参与开发网易云计算1.0至当前3.0多个云平台。目前专注在在/离线业务混部、容器编排资源优化等方向。