混部之殇-论云原生资源隔离技术之CPU隔离(一)

作者

蒋彪，腾讯云高级工程师，10+年专注于操作系统相关技术，Linux内核资深发烧友。目前负责腾讯云原生OS的研发，以及OS/虚拟化的性能优化工作。

导语

混部，通常指在离线混部(也有离在线混部之说)，意指通过将在线业务(通常为延迟敏感型高优先级任务)和离线任务(通常为 CPU 消耗型低优先级任务)同时混合部署在同一个节点上，以期提升节点的资源利用率。其中的关键难点在于底层资源隔离技术，严重依赖于 OS 内核，而现有的原生 Linux kernel 提供的资源隔离能力在面对混部需求时，再次显得有些捉襟见肘(或至少说不够完美)，仍需深度 Hack，方能满足生产级别的需求。

(云原生)资源隔离技术主要包括 CPU、memory、IO 和网络，4个方面。本文聚焦于 CPU 隔离技术和相关背景，后续(系列)再循序渐进，逐步展开到其他方面。

背景

无论在 IDC，还是在云场景中，资源利用率低都绝对是大部分用户/厂商面临的共同难题。一方面，硬件成本很高(大家都是靠买，而且绝大部分硬件(核心技术)掌握于别人手中，没有定价权，议价能力也通常很弱)，生命周期还很短(过几年还得换新)；另一方面，极度尴尬的是这么贵的东西无法充分利用，拿 CPU 占用率来说，绝大部分场景的平均占用率都很低(如果我拍不超过20%(这里指日均值，或周均值)，相信大部分同学都不会有意见，这就意味着，贼贵的东西实际只用了不到五分之一，如果你还想正经的居家过日子，想必都会觉得心疼。

因此，提升主机(节点)的资源利用率是一项非常值得探索，同时收益非常明显的任务。解决思路也非常直接，

常规的思维模式：多跑点业务。说起来容易，谁没试过呢。核心困难在于：通常的业务都有明显的峰谷特征

你希望的样子可能是这样的：

但现实的样子多半是这样的：

而在为业务做容量规划是，需要按 Worst Case 做(假设所有业务的优先级都一样)，具体来说，从 CPU 层面的话，就需要按 CPU 峰值(可能是周峰值、甚至月/年峰值)的来规划容量(通常还得留一定的余量，应对突发)，

而现实中大部分情况是：峰值很高，但实际的均值很低。因此导致了绝大部分场景中的 CPU 均值都很低，实际 CPU 利用率很低。

前面做了个假设：“所有业务的优先级都一样”，业务的 Worst Case 决定了整机的最终表现(资源利用率低)。如果换种思路，但业务区分优先级时，就有更多的发挥空间了，可以通过牺牲低优先级业务的服务质量(通常可以容忍)来保证高优先级业务的服务质量，如此能部署在适量高优先级业务的同时，部署更多的业务(低优先级)，从而整体上提升资源利用率。

混部(混合部署)因此应运而生。这里的“混”，本质上就是“区分优先级”。狭义上，可以简单的理解为“在线+离线”(在离线)混部，广义上，可以扩展到更广的应用范围：多优先级业务混合部署。

其中涉及的核心技术包括两个层面：

1. 底层资源隔离技术。(通常)由操作系统(内核)提供，这是本(系列)文章的核心关注点。
2. 上层的资源调度技术。(通常)由上层的资源编排/调度框架(典型如 K8s)提供，打算另做系列文章展开，仍请期待。

混部也是业界非常热门的话题和技术方向，当前主流的头部大厂都在持续投入，价值显而易见，也有较高的技术门槛(壁垒)。相关技术起源甚早，颇有渊源，大名鼎鼎的 K8s(前身 Borg)其实源于 Google 的混部场景，而从混部的历史和效果看，Google 算是行业内的标杆，号称 CPU 占用率(均值)能做到60%，具体可参考其经典论文：

https://dl.acm.org/doi/pdf/10.1145/3342195.3387517

https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43438.pdf

当然，腾讯(云)在混部方向的探索也很早，也经历了几次大的技术/方案迭代