所有的资源管理零碎都须要解决资源的无效利用、工作的无效响应、调度策略的灵便配置这三个最根本问题。那么在分布式的场景下，YARN和Kubernetes是怎么解决的呢？本篇进行介绍。

— Apache YARN —

YARN全称为（Yet Another Resource Negotiator），是一个集群共享的调度框架，有良好的可伸缩性，以及调度器自身有十分高的可靠性。YARN的架构如下图所示，其中ResourceManager管制整个集群，并管理应用程序对根底计算资源的调配。它将各个资源局部（计算、内存、带宽等）安顿给根底NodeManager（YARN 的每节点代理）。ResourceManager还与 Application Master一起分配资源，与NodeManager一起启动和监督它们的根底应用程序。在此上下文中，Application Master承当了以前的TaskTracker的一些职责，ResourceManager承当了 JobTracker 的角色。

Application Master治理一个在YARN内运行的应用程序的每个实例，并负责协调来ResourceManager的资源，并通过 NodeManager监督容器的执行和资源应用（CPU、内存等的资源分配）。从YARN 角度讲，Application Master 是用户代码，因而存在潜在的平安问题。NodeManager治理一个YARN集群中的每个节点。NodeManager提供针对集群中每个节点的服务，从监督对一个容器的终生治理到监督资源和跟踪节点衰弱。NodeManager治理形象容器，这些容器代表着可供一个特定应用程序应用的针对每个节点的资源。Container是YARN中资源的形象，封装了某节点上一定量的资源（内存，CPU），Container的运行由Application Master向资源所在的NodeManager发动。

一个MapReduce Job的调度过程如下图所示，个别会蕴含提交Job、启动Application Master、申请资源需要、通过后通过Container来进行数据处理这四步。这个流程也同样实用于Spark、Flink等计算引擎。通过YARN的这套资源管理体系，所有的中短期的计算工作都能够无效的失去对立的治理与调度。

调度能力是YARN的外围能力，YARN社区一共提供了FIFO、Fair和Capacity三种调度模型，用户也能够继承ResourceScheduler的接口实现自定义的调度器。FIFO Scheduler顾名思义是最简略的调度器，提交的作业依照提交工夫先后顺序或者依据优先级秩序将其放入线性队列相应的地位，在资源调度时，依照队列的先后顺序、先进先出地进行调度和资源分配。这种调度器过于简略，在理论的生产中，利用不是很多，毕竟须要调度的作业是有不同的优先级的。

在一些多用户的场景下，如大型团体每天夜间通过不同用户运行不同利用须要的批处理数据加工工作，利用的数量可能是数十个之多，集群资源在用户之间调配的公平性就比拟重要。为了应答多租户的需要，社区推出了Capacity Scheduler，让不同的组织应用各自的资源，相互之间不影响，同时进步整个集群的利用率和吞吐量。Capacity Scheduler将资源分为多个队列，每个队列调配一部分资源，不同组织或用户的利用运行在其各自的队列中，从而做到资源隔离。在一个状况容许的状况下，为了晋升集群吞吐，也容许队列之间的资源抢占。

Fair Scheduler将资源划分到多个资源池中，每个资源池设定资源分配最低保障和最高下限，管理员也能够指定资源池的优先级，优先级高的资源池将会被调配更多的资源，当一个资源池有残余时，能够长期将残余资源共享给其余资源池。Fair Scheduler先将用户的工作挂载到如下图的树形队列的叶子节点上，期待后续的资源调度。每个调度周期开始后，Scheduler抉择集群中的一个节点，从树形队列的根节点登程，每层队列都依照依照作业的优先级或者依据偏心策略来抉择一个子队列，最初在叶子节点上依照偏心策略来抉择一个App，而后为这个App在对应的节点上调配适配的资源从而开始计算工作。

为了更好的反对生产需要，Fair Scheduler还反对抢占式调度，如果某个资源池长时间未能调配到偏心共享量的资源，调度器则会杀死过多分配资源的资源池的工作，以腾出资源并调配到这个资源池中供对应的任务调度。此外，它还提供了一个基于工作数目的负载平衡机制，从而将零碎工作尽可能平衡的调配到各个节点上。

— Google Kubernetes —

Kubernetes是Google的开源我的项目，用来治理Docker集群, 继承了Borg的长处，实现了编排、部署、运行以及治理容器利用，下图是Kubernetes的总体架构。Kubernetes提供资源池化治理，能够将整个集群内的CPU、GPU、内存、网络和硬盘等资源形象为一个资源池，能够依据利用的资源需要灵便的依据资源池中的实时资源状况进行调度；Kubernetes蕴含一个对立的调度框架，能够治理最多数千个服务器和数万个容器，同时提供插件化的接口让第三方来定制和扩大新的调度零碎；此外Kubernetes反对通过ConfigMap等形式来动静的调整利用配置，从而具备动静调配的根底能力。咱们将基于这些根底技术来开发反对简单利用平台的调度零碎。

对于Kubernetes的具体介绍，能够查看往期文章：Docker和Kubernetes的前世今生（下）

— 小结—

本篇介绍了两个分布式资源管理技术YARN和Kubernetes。开源社区从2018年开始，多个我的项目如Spark、Flink、Tensorflow等都开始从YARN转向基于Kubernetes的治理和调度。长期上看，作为Hadoop集群的资源管理零碎，YARN十分无效的实现了其技术价值，但受限于其架构设计，很难往一个通用的数据中心调度零碎演进。星环科技在2017年曾经实现外部大数据平台从YARN切换到Kubernetes，下一篇将从存储、计算、资源调度等方面介绍星环大数据技术体系。