CTO愈来愈高的状况下，我是如何帮老板省下400万的？

**上篇连接：**juejin.cn/post/686596…

混部系统设计

咱们基于 Kubernetes 实现了在/离线业务混部系统，遵循如下设计原则：

• 动态调度：根据节点的真实负载实现离线业务的动态调度
• 动态资源分配和隔离：根据在线业务的负载，动态调整分配给离线业务的资源量，动态执行资源隔离策略，下降甚至消除彼此之间的性能干扰
• 插件化：不对k8s作任何in-tree的侵入式改动，全部组件要基于k8s的扩展机制开发，而且混部系统自己扩展性强
• 及时响应：当混部节点资源利用率太高，或者对在线业务产生影响时，可以及时发现，并驱逐离线业务，以保证在线业务的SLA
• 可运维、可观测：对用户和运维人员友好，接入成本低，使用成本低 image
  

图6 系统架构

Resource Reclaim

Resource Reclaim是指回收在线业务已申请的，可是目前还空闲的资源，而后给离线业务使用。这部分资源是low-quality的，没有过高的可用性保证.

咱们自定义了扩展资源colocation/cpu和colocation/memory（分别对应原生的cpu和memory），来表征上述 reclaimed resource，实现离线任务的动态调度。

图7 resource reclaim

节点上在线业务CPU Usage高，则咱们分配给离线业务的资源就会减小；在线业务CPU Usage低，则咱们就能够将更多的资源分配给离线业务。

动态调度

基于扩展资源colocation/cpu和colocation/memory 实现离线任务的动态调度，优先将离线任务调度到节点负载较低、离线任务较少的混部节点上，均衡不一样节点之间的负载、减小业务之间的资源竞争。

动态资源分配和动态资源隔离

Google 在数据中心资源管理领域，不少年之前就开始投入大量人力、物力。因为硬件在性能隔离上的局限性，Google在软件层面作了大量的改造，率先提出了多项资源隔离技术，包括cgroups、Container等（内核的不少功能特性都是业务需求触发的，而不是凭空想象出来的）。咱们对于在/离线业务的性能隔离也是主要经过cgroup来实现的。

kubelet cgroup manager 没有可扩展点，直接修改kubelet代码又会给后续的运维升级带来比较大的成本，所以咱们单独开发了一个zeus-isolation-agent运行在每一个混部节点上，经过定时动态更新cgroup来实如今/离线业务资源隔离。

图8 在/离线业务资源隔离

从CPU、内存、缓存、磁盘到网络，咱们实现了多维度的隔离策略，显著下降在/离线业务之间的互相干扰。以缓存为例，咱们对内核进行了定制化改造，给在/离线业务设置不一样的缓存回收优先级，优先回收离线业务使用的缓存。

离线业务的重调度

存在这样一种场景，刚开始时混部节点上的在线业务较少、负载较低，可以分配给离线业务的资源较多，所以用户可以调度较多的离线业务上去。可是，后来用户调度了更多的在线业务上来或者在线业务的流量飙升，致使节点上可以给离线业务的资源很是有限，离线任务执行效率会很低。假如此时，其余混部节点比较空闲，为了不离线任务的饥饿、减少业务之间的资源竞争，咱们会重调度离线任务到其余node上。

离线任务的重调度，主要有以下优势：

• 均衡各个混部节点的负载状况，避免有的节点负载较高而有的节点又过于空闲
• 避免某个节点负载太高，以致于影响到在线业务性能和稳定性
• 提升离线业务的执行效率

可是，重调度也有缺点，若是没有远程checkpoint机制，会致使重调度以前的算力被浪费。影响程度有多大，是跟单个任务的处理时长有关系的。若是处理一个任务的时长是秒级，那么重调度的影响是微乎其微的。若是处理一个任务的时长是天级别的，那么重调度的影响仍是比较大的。所以，是否使用重调度功能、重调度的触发阈值等用户都是能够实现workload级别的配置的。

落地成果

上述在/离线业务混部方案已经集成到网易轻舟容器平台NCS中，在网易内部获得普遍应用，大幅提升了服务器资源利用率，取得显著成果。

以网易传媒为例，传媒将视频转码业务做为离线业务混部到了在线业务的机器上，混部后CPU利用率从 6%-15% 提升到 55% 左右。

先了解一下视频转码服务的特色：

• CPU密集型，大量读写磁盘保存临时数据，有必定量网络IO
• Long-running pod，而不是一个run-to-complete类型的pod，它会从队列中不断取视频任务进行转码处理，没有任务的话就空闲且保持运行
• 转码单个视频的时长在秒级，所以重调度对其影响是微乎其微的

redis+视频转码

Redis业务是对于时延比较敏感的在线业务，SLO要求较高，可是其CPU利用率较低，所以咱们尝试将视频转码业务混部到了Redis专属节点上，下面咱们看一下这两个在/离业务混部的效果。

图9 Redis节点混部先后CPU利用率

从图9 能够看到，Redis节点混部前CPU利用率在8%左右，混部后达到30~35%，利用率大幅提高。

而后咱们再看一下混部先后redis的SET/GET操做的RT对比。

图10 Redis GET 操做平均响应时间

表3 Redis GET 操做平均响应时间

从图10 和 表3 能够看出，混部先后GET操做的RT 基本没有变化。

图11 Redis SET 操做平均响应时间

表4 Redis SET 操做平均响应时间

从图11 和 表4 能够看出，混部先后SET操做的RT 基本没有变化。

广告推荐+视频转码

广告推荐服务也是一个对稳定性和性能要求很高的时延敏感的在线类型业务，下面咱们看一下转码服务和广告推荐服务混部取得的效果（节点上还有其余类型的在线服务，这里咱们以时延敏感的广告推荐服务为例）。

图12 混部先后节点CPU利用率对比

从图12 能够看到，混部以前cpu利用率在10-20%之间，混部以后cpu利用率长时间维持在55%左右，利用率提高幅度较大。

混部的目的是提升资源利用率、下降成本，可是前提是不能对在线业务产生明显的性能影响。所以，咱们再看一下该广告推荐服务的某个核心性能指标在混部先后的变化：

图13 广告推荐服务请求处理时间

从图13 发现，混部先后该核心性能指标是没有任何衰减和恶化的，混部前的平均RT是6.59ms，混部后的平均RT是6.65ms:

表5 广告推荐服务混部先后的平均RT指标

总结和展望

目前，混部已经在网易获得普遍落地，取得显著成果。接下来，咱们会继续探索和实践云原生技术，基于网易轻舟将混部方案落地到更多企业，让更多企业享受到云原生的红利。

参考文献

[1] The Datacenter as a Computer
[2] Overall Data Center Costs
[3] 数据中心成本与利用率现状分析
[4] Quasar: resource-efficient and QoS-aware cluster management
[5] 浅谈混部系统研究
[6] PerfIso: Performance Isolation for Commercial Latency-Sensitive Services
[7] Borg: the Next Generation
[8] Autopilot: workload auto scaling at Google
[9] Improving Resource Efficiency in Cloud Computing

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

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

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