Crane如何做到利用率提升3倍稳定性还不受损？

作为云平台用户，我们都希望购买的服务器物尽其用，能够达到最大利用率。然而要达到理论上的节点负载目标是很的，计算节点总是存在一些装箱碎片和低负载导致的闲置资源。下图展示了某个生产系统的CPU资源现状，从图中可以看出，浪费主要来自以下几个方面：

1. 业务需求与节点可调度资源很难完全匹配，因此在每个节点上都可能剩余一些碎片资源无法被分配出去。
2. 业务通常为了绝对稳定，会申请超出自身需求的资源，这会导致业务锁定了资源但事实上未能有效利用。
3. 资源用量存在波峰波谷，很多在线业务都是有着规律性的服务高峰和低峰的，如通常白天负载较高，资源用量较大，而夜间在线访问降低，资源用量也会跌入低谷。

Crane提供了Request推荐、副本数推荐、HPA推荐以及EPA等业务优化能力，能辅助业务自动化决策进行资源配置优化。然而在较大的组织中，业务改需要所有业务组件负责人的支持和配合，周期长、见效慢。如何在不改造业务的前提下，迅速提升集群资源利用率，在提升部署密度的同时保证延迟敏感和高优业务的稳定性和服务质量不受干扰，Crane混部能力给出了答案。

Crane提供了高优敏感业务与低优批处理业务的混部能力，能将集群利用率提升3倍！

混部的核心挑战

所谓混部，就是将不同优先级的工作负载混合部署到相同集群中。一般来说，支撑在线服务的延迟敏感型（Latency Sensitive）业务优先级较高，支撑离线计算的高吞吐型（Batch）业务优先级通常较低。

看起来将这些不同类型的业务部署在相同集群，复用计算资源，就可以有效提升资源利用率，那么为什么混部只有在顶尖科技公司才有大规模应用呢？理想很美好，现实很骨感，如果只是简单的将不同业务类型部署到一起，而不进行任何层面的资源隔离，那么在线业务服务质量必然会被影响，这也是为什么混部难以落地的核心原因。

干扰的来源

Kubernetes将计算资源分为不可压缩资源和可压缩资源。不可压缩资源是指物理内存等被应用程序独占的资源，在某个时刻一旦分配给某个进程，就不可以再被重新分配；可压缩资源是指比如可以分时复用的CPU资源，多个进程可以共享同一CPU核，虽然在CPU在某个时钟周期只为单一任务服务，但从宏观时间维度，CPU是可以同时服务于多个进程的。当多个进程都有CPU需求时，这些需求交给操作系统统一分配和调度。当多个进程争抢资源时，可能会导致应用性能下降，这便是我们所说的干扰。

USE方法（Utilization，Saturation，Errors）是性能测试领域中广泛采用的指导理论。在评估系统性能时，通过资源利用率，饱和度和错误率，来迅速的定位资源的瓶颈和错误所在。如下图所示，针对不同资源都可以通过USE方法指导我们如何进行干扰检测。

首先从资源维度，干扰可能发生在任何一个资源维度，比如常见的CPU以及CPU相关的L1,、L2、LLC缓存、内存带宽、磁盘IO、网络IO等。其次从干扰发生的层级来看，干扰可能发生在应用代码、操作系统、硬件等不同层级。

对于应用而言，任何一环都可能成为干扰的来源；同时这些因素之间也会互相关联，例如应用网络流量上升，不仅会造成带宽的抢占，通常还会导致CPU资源消耗上升；又比如一个应用虽然计算逻辑简单，但需要频繁访问内存数据，如果此时缓存失效，则应用需要访问物理内存，而CPU负载会因为忙等而上升。

因此判断干扰是否发生，进一步寻找干扰源，并通过技术手段避免干扰是复杂的，这是干扰检测自动化门槛高的核心原因，如何能在关联的因素中识别干扰以及绕过表象找到真实的干扰源是混部需要解决的核心问题。

Crane的混部方案

Crane为混部场景提供了一套开箱即用的解决方案，借助Kubernetes CRD，该方案可灵活适配于多优先级的在线混部场景以及在离线混部场景，混部方案的能力概览如下：

• 节点负载画像与弹性资源回收 Crane实时采集节点利用率数据，并基于多种预测算法计算出未来的闲置资源，为节点构建画像，并将其以扩展资源形式更新成节点可调度资源。弹性资源的多少随高优业务真实用量变化，高优业务用量上升，弹性资源减少。
• 弹性资源再分配 低优业务使用弹