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

Posted 2021-05-01 hadoop123

点击hadoop123关注我哟

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

---

hadoop123编者语

这是 【为什么用Yarn来做Docker容器调度引擎】第二篇（点击左下角“阅读原文”，可查看第一篇）。本文比较完整的介绍了YARN朝着通用资源管理系统前行过程的曲折，以及目前YARN在长服务方面支持的能力。借助强大的Hadoop社区以及众多commmiter的努力，2015一年时间，YARN在资源管理方面突飞猛进，相信在2016年，会有越来越多的公司开始意识到这一点，并开始尝试在YARN上运行长服务。

需要注意的是，YARN是资源管理系统，只负责资源的管理和调度，至于服务依赖等问题，通常通过上层framework解决，这也是Apache Twill（http://twill.apache.org/，在YARN基础上封装的API，方便用户在YARN上开发应用程序）和Apache Slider（http://slider.apache.org/，支持将HBase，Storm系统等以服务形式运行在YARN上）两个项目出现的原因。下图是Hortonworks公司最近公布的YARN生态图（标题为“YARN with Slider”）：

---

Hulu（北京）大数据团队招聘

Hulu（北京）大数据团队招聘【Docker On YARN/Mesos】方向的工程师/高级工程师，如果你在这方面有一定的研究深度和实践经验（Docker、YARN或Mesos之一亦可），并对该方向有强烈的兴趣，欢迎投递简历，邮箱： dongxicheng AT yahoo.com （AT 换成 @）。

注：Hulu内部【Docker On YARN/Mesos】平台被称为voidbox，是Hulu下一代PAAS平台的基础。更多关于voidbox的介绍，可直接在百度或google中搜索“voidbox”。

---

没想到在群里给人的回复整理出来的内容，发到微博上发现对大家还是有帮助的。原文只是纯粹从开发的角度来看的，这里再补充补充几点生态方面的：

1. Yarn 因为诞生于Hadoop这个大数据的始作俑者项目，所以在大数据领域具有先天优势。

和HDFS有天然的集成。其上支撑了Spark,MR等大数据领域的扛顶之座，最近发布版本也明显加快，对于长任务的支持也越来越优秀。说了这么多，就是说，Yarn的社区绝对不用担心，Yarn的发展自然也不用担心。

2. Yarn之前之所以没有脱离大数据生态，成为一个通用的资源管理调度组件(虽然一开始他就是朝着这个目标的)，我觉得有两点：

• 习惯的力量。因为Yarn是从MR里剥离出来的，大家自然而然的认为Yarn必须活在Hadoop生态群里。我在之前的一篇课程里，反复强调，Hadoop是一个软件集合，包含分布式存储，资源管理调度，计算框架三个部分。他们之间没有必然的关系，是可以独立开来的。
  

• Yarn确实对HDFS有些耦合，比如ContainerLocalization等就需要HDFS的支持。这个问题还是比较容易解决的。
  

• 固有的认为Yarn适合批量任务的调度，而不适合服务。其实从13年开始Yarn社区就一直在加强这块。到目前的2.6,2.7版本，我认为是足以支持长任务的。
  

说到长任务，我之前在群里也和人有讨论，并做了下总结，

Yarn做long running services 需要考虑一下几个点：

1. Fault tolerance. 主要是AM的容错。

2. Yarn Security. 如果开启了安全机制，令牌等的失效时间也是需要注意的。

3. 日志收集

4. 还有就是资源隔离和优先级。这个我觉得可以通过容器能很好的解决。

关于这块可以参考Jira https://issues.apache.org/jira/browse/YARN-896.

我看这个Jira 13年就开着了。说明这事还是需要一个过程。

AM容错，我看从2.4版本(看的源码，也可能更早的版本就已经支持)就已经支持 keep containers across attempt 的选项了。什么意思呢？就是如果AM挂掉了，在Yarn重新启动AM的过程中，所有由AM管理的容器都会被保持而不会被杀掉。除非Yarn多次尝试都没办法把AM再启动起来(默认两次)。 这说明从底层调度上来看，已经做的很好了。

第二个是Yarn以及HDFS的安全令牌机制，有个失效时间。这个就不具体阐述。总之是因为一开始确实没有给LRS程序考虑。

日志收集在2.6版本已经是边运行边收集了。

资源隔离的话，Yarn做的不好，目前有效的是内存，对其他方面一直想做支持，但一直有限。这估计也是很多最后选择Mesos的缘由。但是现在这点优势Mesos其实已经荡然无存，因为Docker容器在资源隔离上已经做的足够好。Yarn和Docker一整合，就互补了。

容器技术使得所有应用可以被操作系统运行起来。并且可以吻合Yarn内核对资源控制的要求。但是我们可能需要对被容器包括起来应用更细致的控制。 我们先来看两个概念。

哑应用：所谓哑应用指的是无法和分布式系统直接进行交互，分布式系统也仅仅透过容器能进行生命周期的控制，比如关闭或者开启的应用。典型的比如mysql,nginx等这些基础应用。他们一般有自己特有的交互方式，譬如命令行或者socket协议或者HTTP协议。

伴生组件：因为有了哑应用的存在，操作系统为了能够和这些应用交互，所以有了伴生组件的存在。这些伴生组件和哑应用具有相同的生命周期。伴生组件其实是哑应用的Proxy,从而使得哑应用可以和分布式系统进行交流。典型的比如，某个服务被关停后，该事件会被操作系统获知，操作系统会将该事件发送给Nginx的伴生组件，伴生组件转化为Nginx能够识别的指令，将停止的服务从Nginx的ProxyBackend列表中剔除。

所以，Yarn管理的其实还是Java的Container，如果该Container同时也是伴生组件，则该Java Container可以直接和第三方应用做交互。否则就需要借助另外一个伴生组件做中转，从而实现对任意，第三方应用的统一管理。

这个方案就奠定了，Yarn可以作为一个通用的资源调度引擎，将包括存储，应用等都囊括进来，同时也自然而然的集成了大数据平台。我觉得从这来来看，更像Google的Borg了。

---