解读 | Mesos 1.2.0 Release


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/docume ... mits/

解读——

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/ ... 1.2.0

关于更新:

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

0 个评论

要回复文章请先登录注册