共计 8080 个字符，预计需要花费 21 分钟才能阅读完成。
作者
作者田奇，腾讯高级工程师，专一大规模在离线混部，分布式资源管理调度，相熟 Kubernetes，关注云原生大数据、AI。
导语
什么是在离线混部
随着微服务、大数据、人工智能的一直倒退，为了满足业务需要，企业的 IT 环境通常运行两大类服务，一类是在线服务，一类是离线作业。
在线服务：往往长时间运行，服务流量存在周期个性，整体资源使用率不高，然而对服务 SLA 却有着极高的要求，如网页搜寻服务、电商交易服务等。
离线作业：往往是资源密集型服务，但其能够容忍较高的时延、失败工作重启，如大数据分析服务、机器学习训练服务等。
这两种类型的服务负载在分时复用、资源互补上存在极大的优化空间，使得它成为混部的首选场景，所谓 在离线混部 ，指的就是 将离线作业和在线服务部署到同一个节点，以此来进步资源利用率，缩小企业对一劳永逸的离线计算资源的老本开销。
在离线混部价值
资源利用率晋升
据 Gartner 统计，寰球数据中心均匀使用率有余 15%，每年会有微小的资源节约。
造成资源效率低下的起因，次要是以下几点：
- 业务流量周期性，对于在线服务，为了保障其流量高峰期的业务 SLA，往往依照最高峰值评估资源。比方外卖业务，峰值期（吃饭时间）可能须要 8 核 CPU，然而在低峰期（夜晚），可能就不耗费资源，导致大部分时间段资源利用率都很低，造成节约。
- 集群资源碎片，所谓资源碎片，指的是服务器还有肯定的动态资源没有被调配，然而因为此时各个维度的资源（如 CPU 和 ram）不平衡，导致没有方法再持续分配资源。因为以后支流的资源调度框架，都会采纳动态资源分配算法来分配资源，最终都会造成资源碎片，从而无奈无效利用资源。
- 在离线机房隔离，资源池划分粒度太粗，有些企业会将在线机房（次要部署在线服务如 Web）、离线机房（次要运行离线集群如 Hadoop）齐全隔离开，在这么粗的粒度划分下，在线机房有大量资源闲置，也无奈被离线服务利用，反之亦然，离线机房闲暇的时候，在线业务也无奈充分利用，无奈实现不同 IDC 之间资源池的互通。
通过在离线混部，能够充分利用节点的闲暇资源，从而进步资源利用率。
老本优化
在离线混部以后在各大中型互联网公司等都有落地，通过混部晋升资源利用率，能够取得可观的老本节俭，取得规模效应下的微小经济价值。
上面能够做一个简略的计算剖析，咱们晋升 20% 的资源利用率，能够大抵节俭的估算：
假如咱们以后所有的机器有 10w 核 CPU，均匀每台机器的资源使用率是 20%, 那么 0.2 10w = 2w 核，在业务规模不变的状况下，假如资源均匀使用率进步到 40%，咱们只须要 5w 核就能够满足业务需要，假如 CPU 的平均价格是 300 元 / 核 / 年，就能够节俭 5w 300= 1500w 元 / 年。
对于有老本管制诉求的企业，在离线混部是降本增效的首选，比方谷歌曾经将所有业务混合部署在 Borg（Kubernetes 的前身）零碎中，其 资源利用率能够达到 60%，每年能够节俭上亿美金。
挑战
调度保障
资源复用
传统模式的 Kubernetes 依照业务申请的 request 资源量进行动态调度，如果在线和离线业务都依照 request 进行调度，离线业务先调度，占满了节点的 request 资源，那么在线业务就无奈调度了，同理，如果在线业务先调度并占满了节点 request 资源，离线业务就没法调度了，传统模式的调度器将没有方法进行在线业务的资源复用。
传统的资源复用形式 ，往往会采取分时复用，就是在固定的工夫点跑离线业务，比方凌晨当前，就开始调度运行离线业务，在白天开始调度在线业务。这种模式下的资源复用， 往往工夫粒度过粗，尽管能够在一小段时间内复用在线资源，然而有比拟严格的工夫限度。
另一种是 资源预留，将一个机器的资源整体划分为在线资源、离线资源以及在离线共享资源，该形式采纳了动态划分的办法，将整机资源进行了划分，无奈进行弹性复用，而是只能将在线业务和离线业务的资源进行提前预留。尽管通过部署离线业务可能肯定水平的进步资源利用率，然而复用不够充沛，并且须要资源规格大的机器能力将资源进行动态划分。
因而，要想 高效的、自动化的 进行细粒度的资源分时复用，就必须领有 及时精确的资源预测伎俩、疾速响应资源变动的能力，以及一套能够在资源水位变动的时候进行的服务保障措施。
调度加强
因为在线业务和离线业务在工作模式上的差别，社区往往采纳不同的调度器进行调度。
混部场景下，在线调度器和离线调度器同时部署在集群中，当资源比拟缓和的时候，调度器会产生资源抵触，只能重试，此时调度器的吞吐量和调度性能会受到较大影响，最终影响调度的 SLA。
同时，大规模批量调度场景下，原生的 Kubernetes 是无奈反对的，它只反对在线业务的调度。
资源保障
在线业务和离线业务原本属于不同的工作类型，将这两种负载部署在同一个节点上，会呈现资源烦扰，所谓 资源烦扰 ，就是当资源缓和或者流量突发的时候，在线业务在资源应用上会受到离线业务的烦扰。 在离线混部最重要的指标，就是在进步单机资源利用率的同时，保障在线和离线业务的服务 SLA。
- 针对在线业务，须要保障其在业务在流量顶峰期间与没有混部之前一样，不能产生较大的烦扰，须要将其烦扰率升高到 5% 以内。
- 针对离线业务，不能因为优先级不如在线业务，就始终处于饥饿或者频繁驱赶状态，影响离线业务总的运行工夫和 SLA。
资源隔离
容器的实质是一个受限制的过程，过程之间通过 namespace 做隔离，Cgroup 做资源限度，在云原生时代，所有的业务负载都是 通过容器来管制隔离和资源限度。在离线混部场景下，尽管能够通过 Cgroup 来限度在线和离线业务的资源应用，然而以后的原生 Cgroup 在资源超售和在离线场景下，CPU、内存、网络和磁盘 IO 都存在不同的挑战。
在 CPU 方面，给创立的 Pod 指定 Limit，就能够通过 Cgroup quota 限度容器的最大资源使用量，采纳 CPU share 权重来划分不同利用的 CPU 权重，然而这种伎俩在资源不缓和的时候还能够，一旦在线服务有流量突发，此时离线业务是很难立刻退出运行的外围的，从而引发在线业务的 SLO 抖动。
为了 保障在线服务稳定性 ，广泛做法是 进行 CPU 绑核，将在线服务绑定在某个逻辑外围上，防止其余业务占用。
然而此时会呈现两个问题，一方面是 CPU 外围独占，资源利用不短缺的问题，因为一旦一个外围被独占，CPU 就无奈充分利用了，而混部的目标就是为了压迫 CPU 的资源，让其可能充沛运行；
另一方面，绑核当前，对于有并行计算要求的服务，不论是在线还是离线，都会受到并行度的影响，比方原来尽管限度最多 4 个外围，然而因为不绑核，服务其实能够并行的应用所有的 CPU，并行度能够大大提高，然而一旦将服务绑定在 4 个 CPU 上，那么其并行度就最大是 4 了。
以上场景中的矛盾置信很多落地在离线混部的厂家都遇到过。
在内存方面，离线业务往往会读取大量文件数据，导致操作系统会做 page cache，而原生操作系统对 page cache 的治理是全局的，不是容器维度的，容器在 cgroup 的资源限度机制下，往往存在 page cache 无奈及时开释的问题，导致其余容器在内存的调配上呈现抖动，甚至存在 page cache 始终被另一个 cgroup 占用，无奈清理 cgroup 的问题，在离线混部中，如果是离线业务也应用了 page cache，那么此时离线业务的资源可能无奈进行调整和压抑胜利的，就在于 page cache 没有开释。
资源烦扰
超线程技术 其实是古代 CPU 架构中十分常见的一种硬件虚拟化伎俩。
简略来说，古代 CPU 根本都是 Numa 架构的，每个 Numa 节点上会有 Socket，Socket 中存在物理核 Core，物理核上还能够开启超线程技术，让操作系统看到多个 CPU 逻辑，咱们平时用 top 命令看到的 CPU，就是指的逻辑 CPU，当没有开启超线程的时候，该逻辑 CPU 就是物理外围，然而如果开启超线程，该逻辑 CPU 可能就是物理外围上虚构进去的一个逻辑 CPU。
比方，如果进行在离线混部，在线业务和离线业务被调度到了同一个物理外围的不同逻辑核上运行，此时就会产生烦扰。
TKE 计划
TKE 针对腾讯外部自研业务上云的场景，设计和实现了混部相干计划。
调度保障
咱们采取混部节点主动上报扩大的离线资源，离线服务通过离线 Cgroup 大框隔离的形式来保障资源的弹性复用和回收。
在调度加强方面，多调度器共享状态调度的模式，第一是解决在线资源的复用调度问题，第二是解决调度抵触、调度性能、可扩展性和可靠性。
资源复用
上文讲到，传统模式的 Kubernetes 依照业务申请的 request 资源量进行动态调度，如果在线和离线业务都依照 request 进行调度，离线业务先调度，占满了节点的 request 资源，那么在线业务就无奈调度了。同理，如果在线业务先调度，离线业务就没法调度了，传统模式的调度器将没有方法进行在线业务的资源复用。
首先，在资源复用的形式上，TKE 将闲暇的在线资源进行精准预测，并通过扩大资源的形式，裸露给离线调度器，从而让离线调度器能够看到有多少离线资源是能够复用的，而后进行调度。
- 针对 request 资源能够批改的离线负载，为了让业务不感知批改资源逻辑，采纳 webhook 动静批改其 resource 中的 CPU 等原生资源表白，转变为 extend 资源表白，转换为 besteffort 类型的 Pod，供离线调度器调度计算应用。
- 针对 best-effort 类型的离线负载，咱们依据混部节点上报的扩大离线资源，弹性的复用在线资源，该扩大资源随着节点的负载水位实时变更，上文中资源抵触复用曾经讲述具体的计划。
- 针对 request 资源不可批改的离线负载（如 driver pod），此时会依照实在的 request 进行调度，那么就有可能和在线调度器发生冲突，因为在混部集群中，整个集群的 request 资源都往往曾经被在线业务装箱满了。
其次，资源复用当前，须要可能有一层限度，限度离线负载不能适度应用宿主机的资源；在底层资源限度上，针对在线和离线业务，别离限度其在不同的 Cgroup 层级上：
- 针对在线业务，还是失常的设置其资源需要，依照其 request 资源进行调度，最终依照 Kubernetes 原生的 Cgroup QoS 治理形式设置其资源限度；
- 针对离线业务中的 worker 等资源密集负载，将所有的离线 Pod 限度在一个 Cgroup 父层级结构的资源池内，也就是离线大框，该计划的长处在于既可能让离线业务充沛应用到在线闲暇资源，然而在在线资源回收的时候，又能够限制住所有的离线工作，从而保障在线服务的稳定性。
为什么不间接将离线工作当做 Kubernetes 原生的 best effort 解决呢？
起因在于 Kubernetes 机制下的 best effort 类型负载，在 Cgroup 这一层是不设置资源限度的，一旦 Pod 有异样应用资源的状况，将会引发在线资源被抢占和内存挤爆的危险，所以必须要用一个有限度的下层的 Cgroup 来进行限度。
因为 Kubernetes 原生的 Cgroup 管理器，并不反对自定义 Cgroup 层级和更新资源，因而业界往往会入侵 kubelet 代码，批改 kubelet 的 Cgroup 管理器，然而 TKE 全栈式混部对 Kubernetes 是零侵入的，通过采纳 CRI 劫持的形式，做到对 Kubernetes Quality of Service 中底层 Cgroup 的批改然而却不必批改 Kubernetes 代码，这对于客户来讲是一大亮点。
你不须要做任何解决就能够享受到极致的资源晋升成果，同时 Kubernetes 的个性和社区齐全兼容，咱们能够做到单个节点粒度的混部框架主动高低线，帮忙你再须要的时候进行混部操作。
在资源的预测和负载解决上，TKE 采纳 指数衰减滑动窗口算法，达到疾速感应资源回升，慢速感应资源降落的目标，做到自动化，细粒度的分时复用指标；之所以须要疾速感应到资源回升，是因为在线服务负载如果有回升，个别都是比拟短暂的，此时须要疾速感知，从而疾速做出资源回收和离线退位。
而在负载降落的过程中，个别不能立刻就去减小在线服务的资源，而是要保障其运行一段时间，确认是负载实在的进入安稳状态，离线能力开始复用在线资源。
首先是对原始数据分桶 ，分桶后能够打消须要存储的历史数据点，缩小数据存储量，如果采纳间接存储历史点的做法，那么 10w 容器的集群，历史的点就会成倍线性减少，而采纳分桶统计法，则能够将该值变成常量，分桶当前失去一个柱状图，利用该柱状图进行滑动窗口算法，获取资源预测的平均值和分位值；而后通过工夫衰减函数，将最近的点的权重晋升，这样能够 打消该柱状图统计进去的历史比拟长远的数据的作用，进行以后资源的短期预测。
另外，分桶的过程中采取的是非平均分桶，目标是 为了实现可能疾速的感知到资源回升，慢速的感应资源降落；咱们能够这么简略的了解，假如所有的点的权重都是一样的为 1（这些权重其实是柱状图的高），那么咱们采纳 P90 作为预测值，其实就是求柱状图的面积，如果以后大部分点都是低负载的点，P90 是比拟低的值，而后忽然有一些点负载突增，他们都会落到范畴较大的桶内，也就是宽度变大，前面的桶面积可能立马成为主导面积，那么 P90 必然立刻会往大桶内挪动；
而反过来，当负载从高负载往低负载突降的时候，低负载的点在后面的小桶内，此时小桶的宽度不够，面积无奈成为主导面积，P90 就不会那么快的升高，只有当大部分的点都变低的时候，他们在小桶的高度减少，此时小桶能力成为主导面积，P90 预测值能力降落。
调度加强
在离线混部场景下，因为每个调度器独自工作，ClusterState 的数据之间没有进行同步，那么就会产生多个调度器同时选中一个节点，然而资源写入抵触的问题。
以后的分布式资源调度计划次要是以下几种类型：
| 计划（Approach） | 资源视图（Resource choice） | 烦扰抵触（Interference） | 调配粒度（Alloc. granularity） | 集群范畴策略 |
|---|---|---|---|---|
| 全局调度器（Kubernetes/Borg） | 全局视图 | 无（串行） | 全局搜寻，单个调度单元调配 | 严格优先级 |
| 动态分区（比方 label 分区） | 固定子集 | 无（分区） | 分区隔离策略，单个调度单元调配 | 不同的调度器互相独立 |
| 两层调度（Mesos/Yarn） | 动静子集 | 乐观并发 | 全局搜寻，成堆调配，死锁或者长期期待 | 严格的偏心调度 |
| 共享状态（Omega） | 全局视图 | 乐观并发 | 每个调度器能够本人决定如何调配 | 每个调度器本人的策略 |
如果让一个调度器来实现在线和离线业务的调度，往往会导致调度器的逻辑简单，性能沉积，不便于保护和迭代。特地是在集群规模比拟大的时候，调度器在性能、可靠性、迭代速度、灵活性等方面都会受到影响。
如果间接部署两个调度器在集群中，因为多个调度器在同一个 Kubernetes 集群，他们应用同一份集群状态来实现调度，然而这里对状态的更新，多个调度器之间是没有同步的，这会导致调度呈现抵触，也就是说两个调度器会同时选中同一个节点，然而其实以后节点只够放下其中一个调度器要调度的 Pod，无奈同时搁置。
共享状态调度，无论从资源视图共享性，并发性，资源分配的灵活性以及对多调度器的灵便反对，都体现比拟杰出。因而 TKE 采纳共享状态乐观并发的调度形式，该计划对于协调器的性能和可靠性有较高要求，然而它能够做到实在的资源共享，资源视图的全局一致性，同时还能反对客户部署多个不同的调度器来针对不同场景进行调度。
TKE 设计和实现了 调度协调器，Kubernetes 调度器只须要在 reserve 阶段，开发扩大插件，进行 reserve 的提交，即可实现共享状态并发。
协调器采纳 gRPC 调用，通过音讯驱动模式来晋升其性能和吞吐量，且协调器目前是十分轻量级设计。
- Coordinator 接管到的申请与事件放入后端多维队列中
- 每个 Node 队列优先解决状态更新事件以及高优先级的资源申请
- 不同 Node 的队列并发解决
- 每个申请只执行最根本的资源抵触查看，十分轻量
资源保障
TKE 在离线混部，在单机资源保障上，联合 TencentOS 内核，提供了全维度的资源保障；在 Kubernetes 和内核侧提供了强有力的资源隔离和保障机制。
多优先级策略
在优先级上，TKE 采纳精细化的 CPUSet 编排技术，依据不同类型的服务优先级，比方高优在线业务，将其进行 cpuset 绑核，针对中优在线业务，采纳 Cgroup quota 和 cpushare 进行 CPU 资源共享，针对离线业务，则采纳离线大框将所有离线业务划分在一个离线 Cgroup 资源池下，然而能够去应用所有的 CPU 核，也能够反对离线业务独自绑定在和高优在线业务齐全互斥的 CPU 子集下。
针对须要绑核的场景，采纳超线程避让绑核调配算法，算法采纳贪婪策略，优先选取整个 Core 绑定，而不是间接依照逻辑 CPU 进行无差别调配，调度算法能够感知 CPU 拓扑逻辑。
针对内存绑定的场景，采取 Numa 感知的调度策略进行 Pod 调度。
资源隔离
除了基于传统 Cgroup 限度与隔离，比方采纳 CPU quota、CPU share 进行资源的限度和隔离，采纳 cpuset 进行绑核等，TKE 也在内核档次上进行了充沛的定制和优化，以适应云原生场景。
在 CPU 方面，为了在宏观档次应答突发流量以及超线程烦扰，TencentOS 云原生内核反对选取 BT 调度类进行离线任务调度，从而可能实现在内核级疾速缩小离线工作烦扰，同时能避免离线工作呈现饥饿状态。
BT 调度能够避免多个离线工作呈现饿死的景象，当在线服务资源耗费突增，此时为了保障在线服务，往往会压低离线服务的优先级，离线业务其工夫片会越来越少，排在队首的离线工作，因为始终跑不完，导致其余离线业务全副饿死，腾讯的内核 BT 调度，能够避免多个离线业务之间饿死，交替的执行离线业务。
在内存方面，TencentOS 内核领有 Cgroup 级别的 cache 清理性能，及时开释某个容器的 cache, 比方离线业务实现当前，就能够将其 pod 触发的 page cache 进行及时清理。
在网络和磁盘 IO 方面，云原生内核都进行了自研管制，接口都是规范 cgroup 接口，TKE 混部充分利用相干 qos 进行容器的 qos 保障。
烦扰查看
业务的 SLO 烦扰查看，一方面是 零碎档次的指标的烦扰查看 ，另一方面是 利用档次的指标的烦扰查看。
在零碎档次，TKE 采集各种系统资源指标，比方感知指令集频率 CPI，感知零碎调用等伎俩，获取零碎指标烦扰。
在 利用档次，TKE 容许在线业务设置本人的 SLO 烦扰阈值，TKE 混部零碎可能回调和查看业务的 SLO，一旦查看到业务实在的 SLO 不合乎预期，就会采取一系列措施进行干扰源打消，其中包含状态机管制的信号处理模式，通过压缩离线资源、禁止离线调度、驱赶等层层递进的伎俩，保障业务的 SLO, 以及整个节点的稳定性。
对于离线业务的 SLO，TKE 容许动静优先级调整以及弹性私有云 的形式，防止离线业务长时间期待或者频繁驱赶，保障离线业务可能在规定工夫内跑完。
总结与瞻望
本文针对在离线混部中最要害的 资源保障 和调度保障 ，论述了 TKE 的在离线混部计划，针对资源保障，通过 利用优先级划分、内核加强、烦扰查看、超线程避让 等要害伎俩，保障利用间资源隔离；针对调度保障，采纳 快感知慢回退预测算法、离线大框、共享状态调度 等伎俩，进行资源弹性复用，解决调度抵触。
将来的混部倒退，第一是无差别混部 ，混部的场景将不再局限于在离线，而是更多简单类型的负载混部，将会呈现更多不同优先等级的负载，进行多优先级资源池的池化解决，资源池间抢占和池间回收技术，充沛摸索零碎档次的资源烦扰，如 CPI 烦扰查看，eBPF 观测技术； 第二是混部 + 弹性的极致联合，混合云中 IDC 和私有云极致的资源共享，多云多集群的资源分时复用调度，以此来达到云的实质指标 – 降本增效。
参考
腾讯 TencentOS 十年云原生的迭代演进之路：
https://mp.weixin.qq.com/s/Cb…
英特尔® 超线程技术：https://www.intel.com/content…
【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！