标签：执行器 容器 焕然一新 Mesos 哪些 Agent 嵌套 任务
闲言碎语
很早的时候，就想找个机会，静下心来，好好写一篇介绍 Mesos 的文章，好让国内对 Mesos 感兴趣的同学能有更深入的了解，同时吸引更多志同道合的小伙伴加入社区。苦于项目上的压力，接二连三的 deadline，以及作为一个重度拖延症患者与生俱来的自我开脱能力，这篇 blog post 就一直在我的 backlog 里面。拖沓至今，恰逢 MesosCon Asia 将于下周在北京国家会议中心举办，同时即将发布 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）的概念，每台机器允许运行多个执行器的同时，每个执行器允许运行多个任务，更为详细地说，每个执行器是运行在一个容器当中（称之为执行器容器），同时，每个任务运行在执行器容器中。请看以下简要示意图：
调度器部署任务：
任务运行在执行器里，同时执行器在容器中运行：
执行器可运行多个任务：
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 部署嵌套容器的简要工作流程：
执行器发送 LAUNCH_NESTED_CONTAINER 的命令给 Agent：
基于执行器部署嵌套容器的命令，Agent 在执行器容器中部署了一个嵌套容器：
执行器发送 WAIT_NESTED_CONTAINER 的命令给 Agent，让其监控此嵌套容器的状态:
根据指定的容器 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 集群的开发与维护。博士毕业于美国密西根大学计算机科学与工程系，从事并行计算方面的研究，曾多次在国际顶级会议和杂志上发表研究论文。本科毕业于复旦大学软件工程系。
标签：执行器,容器,焕然一新,Mesos,哪些,Agent,嵌套,任务 来源： https://blog.51cto.com/u_15127556/2734326
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。