为什么用Yarn来做Docker容器调度引擎

Posted 2021-05-01 hadoop123

点击hadoop123关注我哟

☀ 最知名的hadoop/spark大数据技术分享基地，分享hadoop/spark技术内幕，hadoop/spark最新技术进展，hadoop/spark行业技术应用，发布hadoop/spark相关职位和求职信息，hadoop/spark技术交流聚会、讲座以及会议等。

---

hadoop123编者语

在过去一年中，Hadoop YARN取得了飞速发展，尤其是在long-running service方面，已经得到了比较完备的支持。经hulu内部测试，从hadoop 2.6.0开始，YARN对service的支持已经可以满足生产环境需求。由于YARN具备了RM HA，RM Recovery和NM Recovery三个重要特性，这使得ResourceManager重启，或者NomeManager重启时，均不会对正在运行的container产生任何影响。加之Hulu的voidbox（Docker On YARN）内置了ApplicationMaster HA特性，使得服务可以非常可靠地运行在YARN上。“为什么用Yarn来做Docker容器调度引擎”一文（祝海林在微博（微博：@祝威廉二世）发表）中提到的hulu实现，便是指的Voidbox，大家可直接在百度或google中搜索“voidbox”，前几篇文章全是关于voidbox内部实现的详细介绍。

---

先说说为什么选择yarn而不是Mesos,这个之前也和一个人讨论过。

1. 首先是可部署性。Yarn如果打包JDK后可以没有任何依赖的，Mesos因为是C/C++开发的，

安装部署可能会有库依赖。 这点我不知道大家是否看的重，反正我是看的相当重的。软件就应该是

下下来就可以Run。所以12年的时候我就自己开发了一套Java服务框架，开发完之后运行个main方法就行。

让应用包含容器，而不是要把应用丢到tomcat这些容器，太复杂，不符合直觉。

2. 二次开发。Yarn其实就是个Jar包，而且和Lucene也一样，提供了非常多的扩展接口，很多实现都是可插拔

可替换的，在xml配置下，可能就能用你的实现替换掉原来的实现，没有太大的侵入性，所以就算是未来Yarn升级，

也不会有太大问题。Mesos我不知道这种二次开发性如何。

当然， Mesos和Yarn 都非常棒，都是可编程的框架。一个系统，只要是可编程的，基本就有活了。一个硬件，不能编程，就是死的，一旦可以编程

就活了，就可以各种折腾，有各种奇思妙想可以实现。

上面是说Mesos和Yarn的选型。我再说说为啥选择要对Yarn再进行一次封装。

1. 首先，Yarn为了灵活，或者为了能够满足开发者大部分的需求，底层交互的API就显得比较原始了。自然造成开发难度很大。这个也不是我一个人觉得，现在Apache的twill,以及Hulu他们开发的时候Core那一层（大家可点击左下角“阅读原文”查看hulu的实现），其实都是为了解决这个问题。那为什么我没有用Twill呢，第一是文档实在太少，第二是有点复杂，我不需要这么复杂的东西。我觉得，Twill与其开发这么多功能，真的不如好好写写文档。

2. 还有就是为了隔离，让上层你开发的Framework可以移植。Spark是个典型,他可以跑在Mesos上，也可以跑在Yarn上 ,还可以跑在自己上面，就是因为Spark的Framework不依赖于底层的Core,这个Core其实就是适配。我封装了

Yarn后，上层的Framework是看不到的Yarn的API的。

3. 这些做好后，你想要开发组件，其实就是基于Core再开发个Framework,如果你想开发应用，就是针对Framework开发了。

Framework是个什么概念，其实就是类似Spark,类似MR,他们都是一个在Yarn之上的Framework,你开发的MR程序，Spark程序则是应用。

我们说容器解决了资源隔离，解决了库的依赖问题。同样的，Yarn对操作系统也没有任何要求，没有任何库的依赖，把Yarn和容器结合，基本上算是天作之合，整套资源管理，调度编排可以跑在一个混合的系统上(比如你的集群由100台centos,100台Ubuntu构成)，也不需要担心库的依赖。部署起来也会很简单。

---