关于云计算:云原生架构下复杂工作负载混合调度的思考与实践

作者：实验室小陈 / 大数据凋谢实验室

近年来，云原生的概念席卷了整个云计算畛域，以 Kubernetes 为代表的云原生技术所带来的改革引发了企业沉思，越来越多的企业逐渐将基础架构向云原生架构迁徙，业务利用也以听从云原生十二因素规范进行开发部署。技术交付理念的改革同时也放慢了企业数字化和智能化转型的过程。

云原生技术初期人造适宜微服务架构，而随着整个云原生技术的疾速倒退和云原生基础架构的一直夯实，企业逐步开始将传统大数据的剖析型利用和计算型利用“搬上”云原生架构。至此，云原生基础架构作为企业外部的对立基础架构已成为必然趋势。然而，将云原生基础架构作为对立的基础架构也势必面临着根底平台整合后的兼容性问题，例如：传统大数据工作如何在云原生架构下进行编排和调度、大数据中所提倡的计算数据本地化如何在云原生架构下完满落地等。因而，尽管对立云原生基础架构是大势所趋，但仍然有很长的路要走。

星环科技是云原生技术的晚期实践者，为推动对立云原生基础架构进行了多方面摸索，数据云平台产品 TDC 即是星环在对立云原生基础架构方面多年积攒和实际的产物。TDC 笼罩了剖析云、数据云、利用云三方面性能，在一个平台内满足企业对于三类云平台的建设要求，蕴含数据仓库、流式引擎、剖析工具、DevOps 等利用，可能同时应答多样、简单的工作负载场景。为此，星环科技底层云平台多年来做了不少工作，接下来就分享下星环科技在对立云原生基础架构下对于简单工作负载混合调度器的思考与实际。

对立云原生基础架构

在对立云原生基础架构的概念呈现后，如何解决多类型工作负载的编排和调度成为了一个亟待解决的问题，包含但不限于 MicroService、BigData、AI、HPC 类型的工作负载。对于 MicroService 则是云原生架构人造反对的，所以如何满足其余类型的工作负载的编排、调度是迫切需要解决的，典型的如 Spark、TensorFlow 等社区代表计算工作，HDFS、HBase 等大数据存储服务。而以 Kubernetes 为外围的开源社区针对这些需要也做了相应的尝试，比方通过 Spark Operator 以及 TensorFlow Operator 等解决了工作编排的问题，然而调度相干的能力依然有缺失的。除此之外还有一些大数据生态的企业级个性也是原生 Kubernetes 调度能力无奈反对的。为此，咱们针对如何解决在对立基础架构背景下 Kubernetes 所缺失的调度能力进行了调研和思考。

﹀

大数据 / AI 生态调度器

让咱们来回顾下在大数据 /AI 生态的相干调度器的个性，次要调研对象为 Mesos 和 YARN。

Mesos

Mesos 诞生于加州大学伯克利分校，后经开源后在 Twitter 被大规模应用，技术原型参考 Google 外部的调度器进行设计实现。Mesos 是一个具备两级调度架构的框架，其自身次要专一于做基于 DRF 算法的资源分配，具体提交的工作资源如何管控和调配则是由特定的 Framework 实现。因而，在如此灵便的架构下，开发者们有非常广阔的施展空间。然而因为其本身并没有可能提供太多功能个性导致没有建设起相应的生态，使得越来越多使用者望而生畏，转而寻求其余我的项目。Mesos 的个性总结如下：

两级调度架构，更加灵便
专一于基于 DRF 算法的资源分配
可自定义 Framework 来实现特定工作的资源调度和治理
反对在线、离线、HPC 类型任务调度
YARN

YARN 是 Hadoop 2.0 版本中公布的一款原生的资源管理和调度框架。随着 YARN 的公布，Hadoop 彻底确立了本人在大数据畛域的外围位置，所有的大数据组件和服务均能够由 YARN 进行调度和治理。尽管其架构相比 Mesos 不够灵便，然而 YARN 相比 Mesos 有 Hadoop 弱小的生态背书，其倒退堪称逆风逆水，相干个性和能力也被企业所推崇，解决了企业中对于资源调度和治理的诸多问题。其个性总结如下：

单级调度架构，不够灵便
反对层次化的资源队列，能够映射多租户和企业组织架构
反对资源共享、弹性调度、偏心调度
反对多种大数据工作编排调度
反对在线、离线、HPC 类型任务调度

﹀

Kubernetes 原生调度器

相比于大数据 /AI 生态调度器，Kubernetes 原生调度器在微服务、无状态利用等畛域具备得天独厚的劣势，而在对立云原生基础架构背景下，Kubernetes 原生调度器所透出的能力有余则被一直放大。上面列举了一些 Kubernetes 原生调度器的有余点：

不反对多租户模型下的资源调度
不反对大数据、AI 类型工作的调度
不反对资源队列
不反对资源共享和弹性调度
不反对细粒度资源管控
不反对利用感知调度
调度排序算法繁多

﹀

Kubernetes 生态调度器

Volcano

Volcano（https://volcano.sh/zh/）我的项目是华为云开源的 Kubernetes 原生批处理零碎，能够反对批处理任务调度，补足了 Kubernetes 原生调度器在这方面的能力缺失。Volcano 的架构如下所示：

其次要个性包含但不限于如下：

反对批处理工作、MPI 工作、AI 任务调度
反对对立 Workload 定义，通过新增 CRD Job 来编排和调度不同工作负载
反对繁多 Job 异构 Pod 模板定义，突破 Kubernetes 原生资源解放
反对资源队列、资源共享和弹性调度
反对组调度、偏心调度等多种调度策略

尽管 Volcano 我的项目自身足够优良，提供了很多 Kubernetes 原生调度器不具备的新个性，但在对立云原生基础架构这样的背景下，依然可能会存在一些限度，比方：

部署模式为如果多调度器模式（与 Kubernetes 原生调度器共存），则可能呈现和原生调度器的资源调度抵触问题，因而更适宜于在专有集群部署；2. 以后版本中不反对多级层次化的资源队列，使得在企业多租户场景下不可能很好的进行映射。

YuniKorn

YuniKorn（https://yunikorn.apache.org/）我的项目为 Cloudera 发动并开源的我的项目，定位于跨平台的通用调度器，其三层架构设计可能实现对底层多种平台的适配，以后能够反对 Kubernetes，YARN 的反对还在开发中。YuniKorn 我的项目的诞生是为了可能实现批处理工作、长时运行服务以及有状态服务都能够由对立调度器调度。YuniKorn 的架构如下所示：

其次要个性包含但不限于如下：

架构设计灵便，能够实现跨平台
反对批处理工作、长时运行服务、有状态服务调度
反对层次化的资源池 / 队列定义
反对队列间的资源偏心调度
反对基于偏心策略的跨队列的资源抢占
反对 GPU 资源调度

YuniKorn 我的项目创立之初也是调研了如 kube-batch（Volcano 中的外围性能实现）这样的我的项目后进行设计，因而设计层面相比 kube-batch 多了一些思考，优良的设计进一步也为对立调度器的实现奠定了根底。但因为其 shim 层为适配各个底层平台须要一直补齐这一层的能力，以此来跟上社区的节奏，因而也不能算是齐全兼容 Kubernetes 原生的调度器。

Scheduling Framework v2

在 Kubernetes 生态倒退炽热的同时，社区也没有停下脚步。从 Kubernetesv1.16 版本开始引入新的 Scheduling Framework，从而进一步解放对于调度器的扩大能力。核心思想是将 Pod 调度过程中的每个环节都尽可能插件化，并把原有的调度算法 / 策略全副用插件的模式重写，从而来适配新的 Scheduling Framework。扩大点如下图所示：

基于这样的扩大能力，社区兴趣小组也发动了 Scheduler-Plugins（https://github.com/kubernetes…）我的项目，来呈现出基于 Scheduling Framework v2 能够实现哪些 Kubernetes 原生调度器不具备的能力。以后曾经实现了如 GangScheduling、ElasticQuota、CapacityScheduling、LoadAwareScheduling 等插件。开发者能够间接基于该我的项目编译 scheduler 或将该我的项目插件引入自定义的 scheduler 进行编译，从而保障既能齐全兼容 Kubernetes 原生调度器的全副能力，又能够享受到扩大插件带来的益处。

﹀

TDC 中的思考与实际

在对立云原生基础架构背景下，TDC 也面临着如何解决多种工作负载混合调度的问题。基于对开源社区相干我的项目的调研和 TDC 本身痛点的思考，针对调度器提出了如下需要：

全局惟一的调度器，避免资源调度抵触
反对多租户场景下的资源调度
反对多种工作负载的正当调度
反对资源共享和弹性调度
反对细粒度的资源管控
反对多种调度算法
反对利用感知调度
反对多种调度策略

联合上述 Kubernetes 生态调度器的倒退和现状，咱们基于社区原生的扩大能力 Scheduling Framework v2 设计了一款适宜 TDC 需要场景的调度器 — Transwarp Scheduler。

﹀

Transwarp Scheduler 设计

借鉴社区优良开源我的项目的设计思维，Transwarp Scheduler 中有两个外围：一是齐全基于 Scheduling Framework 进行扩大实现，保障对社区原有能力的齐全兼容性；二是在此基础上进行形象封装，减少资源队列的定义来满足 TDC 在资源调度层面的性能需要。而为缩小用户在应用 Transwarp Scheduler 时的迁徙和学习老本，Transwarp Scheduler 中没有减少新的 Workload 相干的 CRD。

资源队列

资源队列是一个 CRD，咱们将其命名为 Queue。其具备如下个性：

反对层次化定义
反对队列间按权重资源共享
反对队列间的资源借用和回收
反对队列间的偏心调度
反对队列内的细粒度资源管控
反对队列内的多种排序算法

通过这样的资源队列定义，能够利用其层次化定义能力来模仿企业多租户场景中的资源配额治理，并做到共享和弹性配额，以冲破原生 Kubernetes 中所反对的 ResourceQuota 的硬配额限度，实现更细粒度的资源管控。同时，每个队列外部又能够指定准确的排序算法，从而满足不同组织部门的特定需要，在反对原生 Kubernetes 调度器能力的根底上一直补齐在大数据 /AI 场景下通常须要的资源队列的调度治理能力。为了能够在调度过程中将 Pod 的调度和资源队列进行关联，咱们通过扩大 SchedulingFramework 的插件来实现，次要插件如下：

1. QueueSort 插件： 实现 Sort 扩大点，依据 Pod 所属 Queue 的排序算法进行排序，默认不同队列之间基于 HDRF 算法进行偏心调度。

2. QueueCapacityCheck 插件： 实现 PreFilter 扩大点，对 Queue 的资源应用状况进行检查和预处理。

3. QueueCapacityReserve 插件： 实现 Reserve 扩大点，对确定应用 Queue 的资源进行锁定；实现 UnReserve 扩大点，对调度 / 绑定失败然而曾经锁定的 Queue 资源进行开释。

4. QueuePreemption 插件：PostFilter 扩大点，实现资源回收时的抢占性能。

资源队列绑定

除了资源队列的 CRD 外，咱们同样新增资源队列绑定的 CRD，命名 QueueBinding。之所以增加 QueueBinding 是为了使得资源队列的定义只专一于资源调度层面工作，而不用去关注和 Kubernetes 的资源自身关联性，如资源队列和哪个命名空间绑定、资源队列容许提交多少个 Pod 等。这样的限度条件自身并不是资源队列关注的，如果尝试耦合在资源队列中定义，将使得资源队列的控制器代码减少相应的变动解决。而通过 QueueBinding 这样的 CRD，能够使得资源队列从 Kubernetes 资源相关性中解耦进去，这部分的限度查看逻辑则由 QueueBinding 的控制器来实现。Queue、QueueBinding 和 Kubernetes 资源的关系如下所示：

大数据 /AI 调度能力扩大

基于上述引入的资源队列，咱们在资源层面上进行更加精密欠缺的管制。但仅有资源管控是不够的，还须要有面向特定工作负载的调度策略，尤其是原生 Kubernetes 调度器并不特长的大数据 /AI 畛域。下述章节咱们将以大数据 /AI 畛域支流的计算框架 Spark 和 TensorFlow 的工作负载为参考，简要阐明在 Transwarp Scheduler 中实现相应的调度策略。

TensorFlow 作业调度

开源我的项目 KubeFlow 中的 tf-operator 解决了 TensorFlow 作业如何在 Kubernetes 中进行编排的问题，使得用户能够方便快捷的在 Kubernetes 中建设起单机或者分布式的 TensorFlow 作业运行。然而在 Pod 调度层面依然有可能因为资源有余导致局部 TensorFlow 的 Worker Pod 被调度，而另一部分处于 Pending 状态期待资源。TensorFlow 框架自身因为 Worker 不能都同时启动运行，将导致整个训练任务 hang 住无奈执行，因而造成了资源节约。相似问题理论是因为在 Kubernetes 中不足 GangScheduling 的调度机制导致，无奈实现作业的全副 Pod 要么都调度要么都不调度，从而将资源留给真正能够调度起来的作业。

为了补救这样的能力缺失，kube-batch、Volcano、YuniKorn 等我的项目中都对 GangScheduling 的调度策略进行了实现，并对 TensorFlow 在 Kubernetes 的工作负载定义进行了适配，使得能够在利用对应的调度器时调度策略失效。同样的在 scheduler-plugins 我的项目中也对 GangScheduling/CoScheduling 相干调度性能进行了实现。在 Transwarp Scheduler 中参考上述几个我的项目实现的特点，通过扩大 QueueSort、PreFilter、Permit、PostBind 等插件来补足了 GangScheduling 的能力，以满足 TensorFlow 类型工作的调度需要。

Spark 作业调度

Spark 我的项目同样有开源的 spark-operator 来解决其在 Kubernetes 上的编排问题，之所以 Spark 能够实现在 Kubernetes 上的运行，是因为 Spark 社区从 2.3 版本开始引入了 Kubernetes 作为 ResourceManager 的反对。但无论原生 Spark 对接 Kubernetes 的形式还是 spark-operator 部署 Spark 作业的形式，都和 TensorFlow 有类似的资源期待造成资源死锁或者节约的问题。比方同时多个 Spark 作业提交，同一时间启动的 Spark 作业的 Driver Pod 把资源全副用尽，间接导致所有的 Spark 作业没有一个能够失常执行实现，造成了资源死锁问题。

该问题的解决方案相似 TensorFlow 的 GangScheduling 的调度策略，必须达成 All-Or-Nothing 的条件，不过 Spark 作业自身并没有要求所有的 Executor 必须全副启动能力开始计算，因而只须要保障至多有多少 ExecutorPod 能够调度时能力运行，否则 Driver Pod 也不应该被调度，从而做到无效且高效的调度。在 Transwarp Scheduler 中，通过在实现 GangScheduling 的根底上减少肯定可变条件，从而满足 Spark 的作业调度。

﹀

Transwarp Scheduler 架构

依据下面的设计概述，Transwarp Scheduler 的架构和外部交互如下所示：

整个 Transwarp Scheduler 由三局部组成：

1. Scheduler： 基于 Scheduling Framework 实现调度器相干的外围性能，调度策略插件扩大均编译到 Scheduler。

2. Controller Manager： 新增 CRD Queue 的控制器和 CRD QueueBinding 的控制器。

3. Webhook： 新增 CRD Queue 的 admission webhook 扩大点和 CRD QueueBinding 的 admission webhook 扩大点。

﹀

将来瞻望

基于上述设计和实现，目前 Transwarp Scheduler 曾经能够满足 TDC 产品诸多需要，解决了原生 Kubernetes 调度器无奈反对的痛点，并会在后续的 TDC 版本中一起公布。除此之外，Transwarp Scheduler 将会一直摸索一些更 High Level 的调度策略，如利用感知、负载感知等调度策略，也会踊跃驳回和排汇社区的意见并将一些通用的设计和实现反馈社区。

云原生的概念已被提出多年，随同着生态的疾速倒退，其概念也在一直的被从新定义。星环科技的数据云平台产品 TDC 在云原生的浪潮中也在一直摸索后退，为打造世界级的数据云平台产品而一直前行。