解读 | Mesos 1.2.0 Release

2017-03-13 10:11:58 +08:00
 dataman

Mesos 1.2.0 Release 解读

Mesos 刚刚发布了最新的 1.2.0 版本, 新版本解决了社区之前呼声比较多的几个问题,看得出 Mesos 开发组的推进进度还是非常快速而平稳的。这也是 Mesos 社区一贯的作风, 核心 Feature 稳定优先,周边功能积极支持。

根据 1.2.0 Release note 列出的几个新 Feature , 可以看到几个主要的改进都是围绕着容器相关的, 其中既包含对 Mesos Containerizer 改进, 同时也有对 Docker Containerizer 功能补充, 这些工作都是围绕之前 Mesos 社区提出的 Unified Containerier 目标来进行的。

容器化和 Docker 技术在开发者中间已经广泛流行,将来的服务标准化,容器化应该会做的越来越好, Mesos 作为调度系统的首选, 顺应潮流也是大势所趋。如何更好地支持容器化应用的调度应该是 Mesos 近期的工作重点。

数人云逐一分析 Release Note 中的各个部分:

MESOS-5931

Mesos Containerizer 实验性支持 auto backend , overlayfs 优先于 aufs ,由于 bind backend 需要事先存在,需要通过 agent 启动时的 image_provisioner_backend 参数明确指出。

解读——

相比 Docker Containerizer , Volume 一直是 Mesos Containerier 的弱点,由于 Layered 存储一开始就是 Docker 的招牌优势,目的是减少运行时容器对存储的过度使用。 Docker 当前支持 Aufs , Overlayfs , DeviceMapper 集中 CoW 形式的 Volume , Bind Mounted Volume 本质上不是一种 CoW 存储,目的更多是帮助在 Host 和主机之间做存储共享。

Docker 社区下一步主要推的是 OverlayFS 和 OverlayFS2 ,而之前生产环境应用比较广泛的 DeviceMapper 却没有在 Mesos 支持范围, 看得出 Mesos 是紧跟 Docker 脚步的。

Agent 启动增加了 image_provisioner_backend 参数, 目的是指定预先设定的 bind backend 地址。

MESOS-6402

(实验)支持 Mesos containerizer 的 rlimit 。对于使用 Mesos containerizer 来启动容器, Isolator 添加了对设置 POSIX 资源限制((rlimits )的支持。 POSIX rlimits 可以被用来控制一个进程中耗费的资源。细节见 http://mesos.apache.org/documentation/latest/posix_rlimits/。

解读——

Mesos 之前支持 isolator 如 posix/cpu, posix/mem , 以及 cgroup/cpu 等, 这次又增加了 rlimit isolator, 可以更灵活的配置 Executor 比如文件句柄数量, connection 数量等。

MESOS-6419

(实验) Teardown 未注册的 Framework 。 Master 现在对待恢复的 Framework 将和对待已经注册但是当前断开连接的 Framework 非常类似。举例来说,当通过 HTTP 请求 Framework 时,恢复的 Framework 将通过正常的“ Frameworks ”部分进行报告。它意味着不再有“孤儿任务”的概念:如果 Master 知道这个任务,任务就会运行在 Framework 之下。类似的,在恢复的 Framework 上的“ teardown ”操作现在已经正常工作了。

解读——

Teardown unregistered frameworks , 通过这个改进,目测可以 TearDown 一些超时的 Frameworks ,可以很好的清理 Frameworks 下的 tasks , 之前困扰 Swan [数人云开源 Mesos 调度器] 开发的一个问题就是如何清理 Crashed 之后的 Swan 的 task 问题,通过这个功能可以很好的帮助 Swan 解决这个问题。

MESOS-6460

(实验)容器的 Attach 和 Exec 。这个特性为正在运行的 Mesos 任务附加一个远程客户端到其 stdin, stdout 和 stderr 上提供了新的 Agent API ,也提供了一个在同一容器内启动新进程作为运行的 Mesos 任务、并附加到它的 stdin, stdout 和 stderr 上的 API 。在更高的层面,这些 API 在功能上模仿了 Docker attach 和 Docker exec 。这个特性主要是为了让用户能够调试运行中的 Mesos 任务。

解读——

针对 Docker Containerizer 的一个改进, 之前由于没有此功能 Debug 时候都是通过 Mesos task 找到对应的 Docker 容器, 接着通过 Docker 命令进入到容器当中看 Docker 运行时状态, 还好数人云的产品之前通过 Proxy 到 Docker daemon 已经解决了这个问题, 现如今如果 Mesos 能解决这个问题, 可以考虑通过 Mesos attach 到容器当中, 不过性能有待考虑, 毕竟运行时日志是个挺可怕的量。

MESOS-6758

(实验性)在 Mesos Containerizer 支持“ Basic ” Docker 私有镜像仓库验证。直到目前, Mesos Containerizer 一直假定 Bearer auth ,但是现在我们也为私有镜像仓库支持” Basic auth ”。请注意 AWS ECS 采用了 Basic authorization 但是尚不可用,因为 MESOS-5172 的重定向问题。

解读——

私有镜像仓库验证的问题一直是困扰我的问题,这次 Mesos 终于考虑到这个问题了。 之前普遍的做法,包括 Marathon 都是将私用仓库的用户名密码达成 tar 通过 fetch 功能下载到 sandbox 当中, Docker executor 启动之后发现账号后模拟登陆,其实 Docker API 早有支持,有了 Basic HTTP auth 就不用绕一大圈解决登录问题。

此外,还有 200 多个 bug 修复和改进。对于全部的版本更新说明,请移步 https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.2.0

关于更新:

从 Mesos1.1.0 滚动更新到 Mesos1.2.0 非常简单。只有一些小的调整,向后兼容的降低。更新过程中的细节请参考 http://mesos.apache.org/documentation/latest/upgrades/。

1795 次点击
所在节点    程序员
0 条回复

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/346997

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX