焕然一新的 Mesos

小引

MesosCon 北京将于 6 月 20 日到 22 日在北京国家会议中心举行。这是 Linux 基金会主办的一年一度的 Mesos 盛会。报名详情请见这里，购票记得使用7 折优惠码MCA1730。

闲言碎语

很早的时候，就想找个机会，静下心来，好好写一篇介绍Mesos 的文章，好让国内对Mesos 感兴趣的同学能有更深入的了解，同时吸引更多志同道合的小伙伴加入社区。苦于项目上的压力，接二连三的deadline，以及作为一个重度拖延症患者与生俱来的自我开脱能力，这篇blog post 就一直在我的backlog 里面。拖沓至今，恰逢 MesosCon Asia 将于 6 月 20 日至 22 日在北京国家会议中心举办，同时即将发布 Mesos 1.3 即将发布，希望借此机会，能在这篇文章里跟大家分享 Mesos 最近几个版本的关键性功能，以及对 Mesos 未来的一点思考与探讨。

言归正传

最近两年，Mesos 有了很大的变化，尤其自 Mesos 1.0 发布以来，项目发展的步伐明显变快，每一个新版本都在保持稳定性的同时，都包含了一些关键性的功能。在此，我们着重为大家介绍 Mesos 1.1 的嵌套容器 (Nested Container) 与任务组 (Task Group)。

Nested Container and Task Group (嵌套容器与任务组）

熟悉容器的同学，可能已经对 Pod 有一定的了解，我们可以这样定义 Pod 的：在同一机器共同管理下的一组容器共享着部分资源（如网络、储存卷等），却又允许每个容器享有别的专有资源（如容器镜像、资源限额等）。以下，是在生产环境中 Pod 的使用场景：

• 在主应用程序容器旁运行一个辅助容器（如日志收集、备份等）。
• 在主应用程序容器旁运行一个配适器容器（如监测终端、队列消耗等）。
• 在一个 Pod 里运行一系列中转任务，其任务不影响 Pod 里其余任务的正常运行（如正在备份数据至持久化储存卷的任务）。
• 保证历史遗留却重要的应用能与所支持的进程性能隔离。
• 部署一组有着相同生命周期的容器，调度器针对这些容器进行统一调度。

为了在 Mesos 支持以上生产环境中所需要的真实场景，我们给 Mesos 定义了两个最新概念：任务组（Task Group）和嵌套容器（Nested Container）：

一点 Mesos 的背景知识

在 Mesos 的世界，很长的一段时间里，一直有着执行器（Executor）和任务（Task）的概念，每台机器允许运行多个执行器的同时，每个执行器允许运行多个任务，更为详细地说，每个执行器是运行在一个容器当中（称之为执行器容器），同时，每个任务运行在执行器容器中。请看以下简要示意图：

1. 调度器部署任务：

2. 任务运行在执行器里，同时执行器在容器中运行：

3. 执行器可运行多个任务：

4. Agent 可以运行多个执行器：

任务组（Task Group）

在此之前，支持 Pod 场景的限制在于，现有的 Scheduler 和 Executor API 不能原子性地（atomically）发送一组任务给 Executor，尽管一个 Scheduler 可以使用现有的 API 部署多个任务在同一个 Executor 上，但这些任务是以单个事件的形式抵达 Executor（一次只传递一个任务），由于任何一个任务有可能在其传递的过程中被遗漏（如网络分隔等原因），多任务传递的原子性得不到保证。所以，基于最新的任务组，我们能保证用户定义的任务组能够全部原子性地传递到 Executor，这就是我们给任务组定义的“全有或全无”机制。

若想了解更多关于任务组，请阅读任务组API 用户文档。

嵌套容器（Nested Container）

嵌套容器，顾名思义，指的是嵌套于另一容器当中的容器，他们共享着network namespace 于储存卷且允许享有其各自的容器镜像和资源限额。

我们通过定义新的Agent API 来管理嵌套容器，任何被授权的管理者或执行器，都可以利用这个新的API 来部署、管理、清理嵌套容器。与此同时，我们支持嵌套容器的多层嵌套，最多嵌套32 层（由Linux Kernel pid namespace 和user namespace 等因素决定）。

以下是利用新的Agent API 部署嵌套容器的简要工作流程：

1. 执行器发送 LAUNCH_NESTED_CONTAINER 的命令给 Agent：

2. 基于执行器部署嵌套容器的命令，Agent 在执行器容器中部署了一个嵌套容器：

3. 执行器发送 WAIT_NESTED_CONTAINER 的命令给 Agent，让其监控此嵌套容器的状态:

4. 根据指定的容器 ID，Agent 监控嵌套容器并等待其运行中止或结束，一旦此嵌套容器中止或结束任务，Agent 将发送其退出状态（exit status）给执行器：

在不久的将来，我们还将为嵌套容器开发更多的特性，如嵌套容器的资源隔离（目前所有嵌套容器共享其执行器容器的资源，如 CPU、GPU、内存等）、嵌套容器的资源使用统计数据等。如果有同学对某些特性感兴趣、有更好的建议、或希望为 Mesos 容器化贡献力量，欢迎跟我们联系（ Mesos Slack Channel : @gilbert @jieyu）。

今天就码到这吧，本来想把 Mesos 1.2 的标志特性 Debug Container 也一起概括进来的，但考虑到内容较多，还是留给下次好了。接下来即将发布的几个 Mesos 新版本，都将会包含一些非常重要的特性，如 Mesos 1.3 的 multi-role 和 hierarchy-role 、Mesos 1.4 的 Resource Provider 和对 CSI（最新容器储存标准）的支持，我们对此充满信心，敬请期待！

最后，同学们要是对 Mesos 容器化的发展方向及开发状态感兴趣，欢迎加入到我们的 Mesos 容器化工作组，我们会根据大家的讨论及各大公司的需求，一同决定 Mesos 容器化各项特性的优先级，欢迎各位同学给我们多提意见与建议！

作者简介

宋子豪，Apache Mesos PMC/Committer，现任 Mesosphere 分布式系统工程师，自 2015 年起专注于 Mesos 容器领域的开发，主要参与贡献了 Unified Containerizer、Pods 等关键性功能。宋子豪毕业于加州大学圣巴巴拉分校，计算机工程硕士。目前关注云计算及分布式系统。

俞捷博士，现任美国 Mesosphere 公司架构师，技术总监。从 2013 年起担任 Apache Mesos 项目管理委员会委员，是代码的主要贡献者之一。现在主要负责容器，存储和网络方面的开发与维护。在 Mesosphere 之前，曾在 Twitter 担任高级软件工程师，参与 Twitter Mesos 集群的开发与维护。博士毕业于美国密西根大学计算机科学与工程系，从事并行计算方面的研究，曾多次在国际顶级会议和杂志上发表研究论文。本科毕业于复旦大学软件工程系。