万字详解滴滴弹性云混部的落地历程

弹性云作为承载滴滴绝大部分业务的底层容器运行平台，已运行7余年，混部对于云来说并不是陌生的概念，业务上云的第一天就是运行在一个混部的环境中。

业务容器化上云，核心诉求是降本增效，其中降本主要通过混部来实现，增效主要通过云上高效的运维方式来实现。本文主要关注弹性云混部相关的部分，包括演进过程、核心技术能力、线上混部现状、以及未来规划等。

混部是指将不同的业务服务根据其相关特征，部署到相同的物理机/虚拟机上，以达到尽可能在保证重点业务服务质量的前提下，提升整个集群资源利用率，进而降低总成本。根据混部的类型，可以分为在线服务的混部和在离线服务混部两种。其中在线混部又可以分为公共集群在线业务之间的混部和隔离集群在线业务和存储服务的混部，在离线混部主要是在线业务与离线业务进行混部。

混部作为一种业界通用的降本的手段，充满着非常多的技术挑战，总结如下：

• 如何对业务进行合理的分级，不同级别的服务QoS如何定义

• 如何对业务进行精细化的画像，指导集群进行更合理的调度装箱，降低资源争抢的概率

• 单机如何进行内核层面的资源隔离策略，包括CPU、内存、IO、LLC cache、网络等资源，来保障高优业务的服务质量

• 单机如何进行性能干扰检测，指导单机驱逐和调度优化

弹性云混部详细介绍

总体架构 

弹性云混部落地过程

阶段一：公共集群在线混部

时间追溯到2017年初，当时云计算、容器、Borg、Kubernetes、Mesos 各种新技术和产品风起云涌，一时风头无两。滴滴顺应业界潮流，加入了云计算大军，在公司内部推动业务上云的方向，助力业务降本增效。既然要推动业务上云，那么首先要回答什么是“云”，滴滴内部有没有“云”，当时业务都是运行在自己的物理机资源上，“云”对于滴滴来说就像它的名字一样虚无缥缈，所以作为公司的技术底座-基础平台部就责无旁贷的承担起了建立滴滴“云底座”的责任。

对于云来说，最底层的承载实体是一个一个的容器，当时容器技术，包括docker、container、cgroup 等技术相对成熟，各大公司都在使用，但对这些大规模容器集群调度和编排策略当时有多路线，比如 kubernetes，Mesos 等。滴滴内部也是选择两个技术路线同时演进，随着时间的推进，越来越多的公司加入了 kubernetes 阵营，kubernetes 成为容器调度和编排的事实标准，滴滴最终选择投入到 kubernetes 的怀抱！

随着顺风车、网约车、引擎、地图、中台、城运服、国际化等越来越多的业务接入弹性云，构成了弹性云混部的第一个雏形——在线业务混部。在越来越多业务接入到弹性云过程中，弹性云的部署密度越来越高，调度需求越来越多样化，这给整个弹性云带来了非常大的稳定性挑战，下面分别从容器运行时环境和集群调度两个方面进行展开介绍。

上弹性云之后，多个业务的容器同时部署在一台物理机，大家都处于一个“混部”的环境中，为了提高资源利用率，会通过超卖等技术提升容器的部署密度，意味着同一台物理机上会部署更多的容器，伴随而来的是越来越严重的资源争抢，业务延迟增加，以及更频繁的毛刺出现。所以面临的第一个重要的问题就是解决资源争抢的问题，客观来讲，在总资源一定的情况下，提升容器部署密度，带来资源的争抢是必然的，也是不可避免的，所以我们要解决的问题不是消除资源争抢，而且合理分配资源争抢，尽量保障重点服务的运行质量，下面来看一下具体怎么解决这些问题。

弹性云分级保障体系

 弹性云分级保障体系

由于当前弹性云在线公共集群整体资源超卖非常严重，远超业务平均水平，建立完备的分级保障体系是进行良好混部的前提，当前分级体系的核心思路是从集群和单机两个维度提供资源的确定性，对不同优先级的服务提供不同的资源保障程度，简单总结如下：

• 根据服务的重要性和敏感性，对服务进行合理的分级，并制定相应的资源超卖规则。

• 单机层面资源（CPU、内存、磁盘IO、网络、Cache 等）分配优先保障高优服务的需求。

• 集群层面对不同级别服务提供资源保障：quota 管理和管控，k8s 分级调度能力。

k8s 调度能力支撑

 k8s 调度流程图

上图是 k8s 调度的流程图，调度的核心工作是为一个新创建的 pod 选择一个最合适的 node 进行运行，整个调度流程分为两个阶段：预选策略（Predicates）和优选策略（Priorities），过程中进行各种算法策略的选择调优，且能够加入自己定制化的各种调度策略，下面介绍调度层面如何支撑上述混部场景。

1、调度预选策略增强

• 资源限制增强

• 大规格容器单机调度限制

• IO敏感性容器调度适配

• 真实使用率调度限制

• 宿主资源争抢调度限制

• 集群拓扑打散增强

• 相同sts下tor打散策略

• 相同sts下node打散策略

• 机房内node平铺打散策略

• 定向调度策略

<