共计 2527 个字符，预计需要花费 7 分钟才能阅读完成。
所有的资源管理零碎都须要解决资源的无效利用、工作的无效响应、调度策略的灵便配置这三个最根本问题。那么在分布式的场景下，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，下一篇将从存储、计算、资源调度等方面介绍星环大数据技术体系。