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

近年来，云原生的概念席卷了整个云计算畛域，以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原生调度器不具备的新个性，但在对立云原生基础架构这样的背景下，依然可能会存在一些限度，比方：

  1. 部署模式为如果多调度器模式（与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在云原生的浪潮中也在一直摸索后退，为打造世界级的数据云平台产品而一直前行。