数人云

数人云

数人云官网
用户手册

用户手册

数人云用户手册
Mesos中文文档

Mesos中文文档

开源, 欢迎大家修改优化

五个小技巧,快速创建Docker镜像

宁静胡同 发表了文章 • 0 个评论 • 25 次浏览 • 2017-01-06 14:51 • 来自相关话题

毫无疑问,容器是DevOps世界一个突破性的技术。镜像创建对于部署和发布环节都非常重要。那么如何效率地创建和使用镜像来提升部署速度呢?以下是作者的经验和分享,大家不妨一试——


1. 尽可能多地缓存网络下载

通常部署需要从Internet下载成百上千MB的数据。因此部署常受到网速慢或者断网的困扰。

而缓存得越多,部署得就会越快。最终的目标是实现Docker镜像离线一键部署。


2. 把Docker镜像看做Plain OS Golden Image

Docker很强力,但是我们也有很多VM或者裸机部署。为了避免供应商锁定,通常需要选择是否用Docker支持部署,最好两种场景都实施部署持续集成。

举例来说,如果使用kitchen来做持续集成。默认情况下,使用自定义Docker镜像来测试。当IMAGE_NAME指定为ubuntu:14.04时,可以很肯定ubuntu:14.04系统对于部署非常适用。


3. 审核Docker镜像里所有包和服务的安装

从镜像起一个Docker容器,然后列出并检查所有安装的包/服务。

为什么要这么做?首先我们希望Docker镜像尽可能地小,镜像交付就会很快速。其次,包/服务越多,问题也会越多,例如包冲突,TCP端口占有问题。一些服务的安装后脚本甚至会改变关键性的全局配置文件或者留下不可预期的flagfile。所以最好让Docker镜像保持傻傻的单纯。


4. Docker构建的最后清理关闭所有服务

如果不这么做,服务会在Docker镜像的最后阶段被杀掉。在/var/lock/*下的服务的lockfile如果没有被正确使用,当测试新建镜像的部署时,服务可能会启动失败,导致测试无效。


5. 添加验证步骤,确保镜像正常

当有改变发生时,我们时不时需要重构Docker镜像。为了确保一切正常,我们可以在Docker构建过程中添加自动验证逻辑。


这是一个简单的例子,实践了上述提到的技巧。
########## How To Use Docker Image ###############
## docker run -t -d --privileged -p 8022:22 \
## denny/mydockertest:v1 /usr/sbin/sshd -D
##
##################################################

FROM denny/sshd:v1
MAINTAINER Deny <denny@dennyzhang.com>
ARG devops_branch=master
ARG working_dir=/root/chef
##################################################
# Install basic packages
RUN apt-get -yqq update && \
apt-get -yqq install curl && \
apt-get -yqq install openssh-server && \
apt-get install -y sudo lsb-release && \
# Install chef
curl -L https://www.opscode.com/chef/install.sh | bash && \
# clean up files to make this docker layer smaller
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################
# checkout code
RUN bash /root/git_update.sh ${working_dir} \
git@github.com:DennyZhang/chef_community_cookbooks.git \
${devops_branch} && \
echo "cookbook_path [\"${working_dir}/${devops_branch}/mdmdevops/community_cookbooks\", \
\"${working_dir}/${devops_branch}/mdmdevops/cookbooks\"]" \
> /root/client.rb

# Chef all-in-one deployment. This step takes minutes
RUN echo "{\"run_list\": [\"recipe[all-in-one::predownload]\"]}" \
> /root/client.json && \
chef-solo --config /root/client.rb -j /root/client.json && \
# Clean up to make docker image smaller
rm -rf /tmp/* /var/tmp/* && \
rm -rf /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################

# Shutdown services
RUN service couchbase-server stop || true && \
service elasticsearch stop || true && \
service nagios3 stop || true && \
service apache2 stop || true && \
service haproxy stop || true && \
service nagios-nrpe-server stop || true && \
rm -rf /run/apache2/apache2.pid && \
rm -rf /var/log/apache2/* && \
rm -rf /usr/local/var/run/vagrant_ubuntu_trusty_64.pid && \
rm -rf /root/docker.rb /root/docker.json

# Verify docker image
RUN test -f /var/chef/cache/couchbase-server-enterprise_4.1.0-ubuntu14.04_amd64.deb && \
test -f /var/chef/cache/elasticsearch-2.3.3.deb && \
test -f /etc/apt/sources.list.d/ruby2.1-repo.list && \
test -f /etc/apt/sources.list.d/haproxy-repo.list && \
dpkg -s haproxy | grep "1.6.5"

# Clean up to make docker image smaller
RUN rm -rf /tmp/* /var/tmp/* /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean

EXPOSE 22
CMD ["/usr/sbin/sshd", "-D"]
##################################################



作者:Denny Zhang
文章来源:https://dennyzhang.github.io/d ... .html 查看全部

毫无疑问,容器是DevOps世界一个突破性的技术。镜像创建对于部署和发布环节都非常重要。那么如何效率地创建和使用镜像来提升部署速度呢?以下是作者的经验和分享,大家不妨一试——




1. 尽可能多地缓存网络下载

通常部署需要从Internet下载成百上千MB的数据。因此部署常受到网速慢或者断网的困扰。

而缓存得越多,部署得就会越快。最终的目标是实现Docker镜像离线一键部署。


2. 把Docker镜像看做Plain OS Golden Image

Docker很强力,但是我们也有很多VM或者裸机部署。为了避免供应商锁定,通常需要选择是否用Docker支持部署,最好两种场景都实施部署持续集成。

举例来说,如果使用kitchen来做持续集成。默认情况下,使用自定义Docker镜像来测试。当IMAGE_NAME指定为ubuntu:14.04时,可以很肯定ubuntu:14.04系统对于部署非常适用。


3. 审核Docker镜像里所有包和服务的安装

从镜像起一个Docker容器,然后列出并检查所有安装的包/服务。

为什么要这么做?首先我们希望Docker镜像尽可能地小,镜像交付就会很快速。其次,包/服务越多,问题也会越多,例如包冲突,TCP端口占有问题。一些服务的安装后脚本甚至会改变关键性的全局配置文件或者留下不可预期的flagfile。所以最好让Docker镜像保持傻傻的单纯。


4. Docker构建的最后清理关闭所有服务

如果不这么做,服务会在Docker镜像的最后阶段被杀掉。在/var/lock/*下的服务的lockfile如果没有被正确使用,当测试新建镜像的部署时,服务可能会启动失败,导致测试无效。


5. 添加验证步骤,确保镜像正常

当有改变发生时,我们时不时需要重构Docker镜像。为了确保一切正常,我们可以在Docker构建过程中添加自动验证逻辑。


这是一个简单的例子,实践了上述提到的技巧。
########## How To Use Docker Image ###############
## docker run -t -d --privileged -p 8022:22 \
## denny/mydockertest:v1 /usr/sbin/sshd -D
##
##################################################

FROM denny/sshd:v1
MAINTAINER Deny <denny@dennyzhang.com>
ARG devops_branch=master
ARG working_dir=/root/chef
##################################################
# Install basic packages
RUN apt-get -yqq update && \
apt-get -yqq install curl && \
apt-get -yqq install openssh-server && \
apt-get install -y sudo lsb-release && \
# Install chef
curl -L https://www.opscode.com/chef/install.sh | bash && \
# clean up files to make this docker layer smaller
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################
# checkout code
RUN bash /root/git_update.sh ${working_dir} \
git@github.com:DennyZhang/chef_community_cookbooks.git \
${devops_branch} && \
echo "cookbook_path [\"${working_dir}/${devops_branch}/mdmdevops/community_cookbooks\", \
\"${working_dir}/${devops_branch}/mdmdevops/cookbooks\"]" \
> /root/client.rb

# Chef all-in-one deployment. This step takes minutes
RUN echo "{\"run_list\": [\"recipe[all-in-one::predownload]\"]}" \
> /root/client.json && \
chef-solo --config /root/client.rb -j /root/client.json && \
# Clean up to make docker image smaller
rm -rf /tmp/* /var/tmp/* && \
rm -rf /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################

# Shutdown services
RUN service couchbase-server stop || true && \
service elasticsearch stop || true && \
service nagios3 stop || true && \
service apache2 stop || true && \
service haproxy stop || true && \
service nagios-nrpe-server stop || true && \
rm -rf /run/apache2/apache2.pid && \
rm -rf /var/log/apache2/* && \
rm -rf /usr/local/var/run/vagrant_ubuntu_trusty_64.pid && \
rm -rf /root/docker.rb /root/docker.json

# Verify docker image
RUN test -f /var/chef/cache/couchbase-server-enterprise_4.1.0-ubuntu14.04_amd64.deb && \
test -f /var/chef/cache/elasticsearch-2.3.3.deb && \
test -f /etc/apt/sources.list.d/ruby2.1-repo.list && \
test -f /etc/apt/sources.list.d/haproxy-repo.list && \
dpkg -s haproxy | grep "1.6.5"

# Clean up to make docker image smaller
RUN rm -rf /tmp/* /var/tmp/* /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean

EXPOSE 22
CMD ["/usr/sbin/sshd", "-D"]
##################################################



作者:Denny Zhang
文章来源:https://dennyzhang.github.io/d ... .html

DevOps 新年计划清单:对失败的准备 say no

宁静胡同 发表了文章 • 0 个评论 • 44 次浏览 • 2016-12-28 19:30 • 来自相关话题

随着2016年接近尾声,又到了为明年做准备的时候啦。今天的文章里邀请了国外三位嘉宾Andrew Phillips, Tim Buntel,和 TJ Randall,看看业界的思想者们对于DevOps世界新一年有哪些展望,为大家提供一些参考。

1.新浪潮——“下一代平台”将要来临

在2017年,将会有一种聚焦于容器编排框架的“下一代平台”项目,以及将工具重组的PaaS平台,例如OpenShift 或者 Cloud Foundry。对于跨机资源管理和调度框架的需求会持续增长,生态链上的供应商会甩掉身上的重负、快速地跟随上这个趋势。同时在容器标准化上会有一个更清晰的认识,容器自动化也会成为一种必需。

2.应用新定义将成为约定俗成的标准

未来将不再定义应用为“虚拟化设备概念”,就此开启从“为每个应用版本制作亚马逊机器镜像”到软件交付的新阶段。

3.迎刃而上的企业需求

随着下一代平台的实现以及容器自动化,在企业需求上面将会有更多关注点,比如接口控制,审计跟踪和网络技术,在编排层实现“虚拟防火墙”。我们也会看到一波波的案例,充分感受到“它们比看起来的要困难得多”。

4.数据科学/大数据遍地开花

数据科学/大数据项目数量会有一个提升,围绕着测试、持续集成和持续交付将会有各自不同的挑战。更多的商业关注会提高大家对于集群管理工具的接受度,因为多数大数据框架都是运行在它们之上的。

5.软件开发强调分析与监测

自动化进程会产生大量的数据,而自动操作的软件发布越来越多。管理发布的关键信息量十分庞大,散布在一堆工具里。团队需要简化数据来做商业报告,为了更深入地进行使用操作、工作情况的调查,要明确和强调其中不寻常的数据。

6.Serverless Architecture,不再纸上谈兵

PaaS我们已经听了很多年,在这一层之下,Serverless Architecture可以让代码运行而不需要提供或者管理服务器。不再需要提供服务器,也不需要应用一直运行,Serverless Architecture还提供了完全自动化的的水平扩展能力。它们并不是很新的东西(比如AWS Lambda 2014年就出来了),明年有望实现更广泛的使用,而不再只是会议上的一个话题了。

7.企业的应用迁移之路

在古董、过渡和现代应用栈之间的巨大鸿沟,让企业在人员招聘、员工分配和预算上都承受了巨大的压力。新平台面向用户的解决方案有越来越多的成功案例——比如云计算和容器方面——会让公司在新架构应用迁移上投入更多。

8.敏捷驱动和瀑布式交付模式的完美结合

Pipeline和发布编排会成为应用交付进程中非开发人员最时髦的流行词,这些方法会在交付过程中提供企业需要的一致性,以及IT团队需要更快交付解决方案的灵活性。

Benjamin Franklin 曾经说过, “By failingto prepare, you are preparing to fail” 。 
2017 将会成为行业内有巨大变革的一年—— 
你,准备好了吗?

作者:Divesh Rupani 文章来源:https://blog.xebialabs.com/201 ... 2017/ 查看全部
随着2016年接近尾声,又到了为明年做准备的时候啦。今天的文章里邀请了国外三位嘉宾Andrew Phillips, Tim Buntel,和 TJ Randall,看看业界的思想者们对于DevOps世界新一年有哪些展望,为大家提供一些参考。

1.新浪潮——“下一代平台”将要来临

在2017年,将会有一种聚焦于容器编排框架的“下一代平台”项目,以及将工具重组的PaaS平台,例如OpenShift 或者 Cloud Foundry。对于跨机资源管理和调度框架的需求会持续增长,生态链上的供应商会甩掉身上的重负、快速地跟随上这个趋势。同时在容器标准化上会有一个更清晰的认识,容器自动化也会成为一种必需。

2.应用新定义将成为约定俗成的标准

未来将不再定义应用为“虚拟化设备概念”,就此开启从“为每个应用版本制作亚马逊机器镜像”到软件交付的新阶段。

3.迎刃而上的企业需求

随着下一代平台的实现以及容器自动化,在企业需求上面将会有更多关注点,比如接口控制,审计跟踪和网络技术,在编排层实现“虚拟防火墙”。我们也会看到一波波的案例,充分感受到“它们比看起来的要困难得多”。

4.数据科学/大数据遍地开花

数据科学/大数据项目数量会有一个提升,围绕着测试、持续集成和持续交付将会有各自不同的挑战。更多的商业关注会提高大家对于集群管理工具的接受度,因为多数大数据框架都是运行在它们之上的。

5.软件开发强调分析与监测

自动化进程会产生大量的数据,而自动操作的软件发布越来越多。管理发布的关键信息量十分庞大,散布在一堆工具里。团队需要简化数据来做商业报告,为了更深入地进行使用操作、工作情况的调查,要明确和强调其中不寻常的数据。

6.Serverless Architecture,不再纸上谈兵

PaaS我们已经听了很多年,在这一层之下,Serverless Architecture可以让代码运行而不需要提供或者管理服务器。不再需要提供服务器,也不需要应用一直运行,Serverless Architecture还提供了完全自动化的的水平扩展能力。它们并不是很新的东西(比如AWS Lambda 2014年就出来了),明年有望实现更广泛的使用,而不再只是会议上的一个话题了。

7.企业的应用迁移之路

在古董、过渡和现代应用栈之间的巨大鸿沟,让企业在人员招聘、员工分配和预算上都承受了巨大的压力。新平台面向用户的解决方案有越来越多的成功案例——比如云计算和容器方面——会让公司在新架构应用迁移上投入更多。

8.敏捷驱动和瀑布式交付模式的完美结合

Pipeline和发布编排会成为应用交付进程中非开发人员最时髦的流行词,这些方法会在交付过程中提供企业需要的一致性,以及IT团队需要更快交付解决方案的灵活性。

Benjamin Franklin 曾经说过, “By failingto prepare, you are preparing to fail” 。 
2017 将会成为行业内有巨大变革的一年—— 
你,准备好了吗?

作者:Divesh Rupani 文章来源:https://blog.xebialabs.com/201 ... 2017/

Docker 1.13最实用命令行:终于可以愉快地打扫房间了

宁静胡同 发表了文章 • 0 个评论 • 157 次浏览 • 2016-12-16 10:35 • 来自相关话题

Docker1.13出来已经有一段时间了,新版本添加了许多有用的命令,本文作者从处女座的洁癖(此处有雾)出发,告诉大家一些整理环境的小技巧。打扫房间再也不需费时又费力了,简单的命令,就可以轻松地把物品分门别类(容器、镜像、网络、存储卷……)地整理好^_^

在1.13版本中,Docker向CLI添加了一些有用的命令,让环境更加整洁。你可能已经体验了很长时间乱糟糟的开发环境——无用的容器,挂起的Docker镜像,弃置的volume,被遗忘的网络……所有这些过时的事物占据了宝贵的资源,最终导致环境无法使用。在之前的文章中曾经提到用各种各样的命令保持环境的整洁,例如:docker rm -f $(docker ps -aq)

强制地删除所有正在运行的、暂停的以及终止的容器。同样地,也有命令可以删除挂起的镜像、网络和volume。

尽管上述命令解决了问题,但是它们要么专有,要么冗长或者难用。而新加入的命令直截了当又简单好用,现在就开始一一介绍吧。



管理命令

为了整理CLI,Docker 1.13引进了新的管理命令,如下:
systemcontainerimagepluginsecret

Docker的老版本中已经有了 network, node, service, swarm 和 volume 。这些新命令组子命令过去作为root命令直接实现。举个例子:docker exec -it [container-name] [some-command]
exec 命令现在是 container 下面的一个子命令,这个命令相当于:docker container exec -it [container-name] [some-command]

个人猜测为了兼容性的考虑,旧语句眼下还会使用一段时间。


Docker系统

现在有一个新管理命令 system 。它有4个子命令分别是 df, events, info 和 prune 。命令 docker system df 提供Docker整体磁盘使用率的概况,包括镜像、容器和(本地)volume。所以我们现在随时都可以查看Docker使用了多少资源。

如果之前的命令展示出 docker 已经占用了太多空间,我们会开始清理。有一个包办一切的命令:docker system prune

这个命令会删除当前没有被使用的一切项目,它按照一种正确的序列进行清理,所以会达到最大化的输出结果。首先删除没有被使用的容器,然后是volume和网络,最后是挂起的镜像。通过使用 y 回复来确认操作。如果想在脚本中使用这个命令,可以使用参数 --force 或者 -f 告诉Docker不要发来确认请求。


Docker容器

我们已经知道许多 docker container 的子命令。它们过去(现在也是)是 docker 的直接子命令。可以通过下面的命令得到完整的子命令列表:docker container --help

在列表中会看到一个 prune 命令。如果使用它,那么只会删除无用的容器。因此这条命令比 docker system prune 命令更局限。使用 --force 或者 -f 同意可以让CLI不再进行确认请求。


Docker网络

这里也有一个 prune 命令:docker network prune
删除所有孤立的网络。


Docker Volume

volume也有新的 prune 命令了:docker volume prune
删除所有(本地)没有被容器使用的volume。


Docker镜像

新的镜像命令也是 prune 子命令。--force 用法如上面一样, --all 可以删除所有不用的镜像,不只挂起的镜像。docker image prune --force --all

这个命令可以删除所有不使用的镜像并且不再请求确认。


总结

Docker 1.13不仅通过引入admin command添加了一些需要的命令,也让我们找到了一些非常有用的清理环境的命令。笔者最爱的命令莫过于 docker system prune,让环境一直保持干净整齐。


本文作者:Gabriel Schenker
原文链接:https://lostechies.com/gabriel ... ited/ 查看全部

Docker1.13出来已经有一段时间了,新版本添加了许多有用的命令,本文作者从处女座的洁癖(此处有雾)出发,告诉大家一些整理环境的小技巧。打扫房间再也不需费时又费力了,简单的命令,就可以轻松地把物品分门别类(容器、镜像、网络、存储卷……)地整理好^_^



在1.13版本中,Docker向CLI添加了一些有用的命令,让环境更加整洁。你可能已经体验了很长时间乱糟糟的开发环境——无用的容器,挂起的Docker镜像,弃置的volume,被遗忘的网络……所有这些过时的事物占据了宝贵的资源,最终导致环境无法使用。在之前的文章中曾经提到用各种各样的命令保持环境的整洁,例如:
docker rm -f $(docker ps -aq)


强制地删除所有正在运行的、暂停的以及终止的容器。同样地,也有命令可以删除挂起的镜像、网络和volume。

尽管上述命令解决了问题,但是它们要么专有,要么冗长或者难用。而新加入的命令直截了当又简单好用,现在就开始一一介绍吧。



管理命令

为了整理CLI,Docker 1.13引进了新的管理命令,如下:
  • system
  • container
  • image
  • plugin
  • secret


Docker的老版本中已经有了 network, node, service, swarm 和 volume 。这些新命令组子命令过去作为root命令直接实现。举个例子:
docker exec -it [container-name] [some-command]

exec 命令现在是 container 下面的一个子命令,这个命令相当于:
docker container exec -it [container-name] [some-command]


个人猜测为了兼容性的考虑,旧语句眼下还会使用一段时间。


Docker系统

现在有一个新管理命令 system 。它有4个子命令分别是 df, events, info 和 prune 。命令 docker system df 提供Docker整体磁盘使用率的概况,包括镜像、容器和(本地)volume。所以我们现在随时都可以查看Docker使用了多少资源。

如果之前的命令展示出 docker 已经占用了太多空间,我们会开始清理。有一个包办一切的命令:
docker system prune


这个命令会删除当前没有被使用的一切项目,它按照一种正确的序列进行清理,所以会达到最大化的输出结果。首先删除没有被使用的容器,然后是volume和网络,最后是挂起的镜像。通过使用 y 回复来确认操作。如果想在脚本中使用这个命令,可以使用参数 --force 或者 -f 告诉Docker不要发来确认请求。


Docker容器

我们已经知道许多 docker container 的子命令。它们过去(现在也是)是 docker 的直接子命令。可以通过下面的命令得到完整的子命令列表:
docker container --help


在列表中会看到一个 prune 命令。如果使用它,那么只会删除无用的容器。因此这条命令比 docker system prune 命令更局限。使用 --force 或者 -f 同意可以让CLI不再进行确认请求。


Docker网络

这里也有一个 prune 命令:
docker network prune

删除所有孤立的网络。


Docker Volume

volume也有新的 prune 命令了:
docker volume prune

删除所有(本地)没有被容器使用的volume。


Docker镜像

新的镜像命令也是 prune 子命令。--force 用法如上面一样, --all 可以删除所有不用的镜像,不只挂起的镜像。
docker image prune --force --all


这个命令可以删除所有不使用的镜像并且不再请求确认。


总结

Docker 1.13不仅通过引入admin command添加了一些需要的命令,也让我们找到了一些非常有用的清理环境的命令。笔者最爱的命令莫过于 docker system prune,让环境一直保持干净整齐。


本文作者:Gabriel Schenker
原文链接:https://lostechies.com/gabriel ... ited/

版本更新 | Mesos调度器Swan v0.2来啦

宁静胡同 发表了文章 • 0 个评论 • 68 次浏览 • 2016-12-13 19:10 • 来自相关话题

数人云Mesos调度器Swan开源已经一个月啦,在社区和大家的共同呵护下成长了许多。正值双十二又一波剁手节来临之际,小数带来了Swan v0.2的新版本,添加了很多新功能,大家快来看看吧——



Feature List
Uri  支持:支持自定义资源,支持多资源下载PortIndex:支持端口命名,健康检测支持portIndex,portName和portValueCli:命令行工具Heathcheck:支持mesos自带的healthcheck,http和tcp两种Raft:高可用,分布式数据复制和leader选举Proxy:自带proxy功能,支持负载均衡DNS:自带DNS功能,支持域名解析一容器一IP:支持IP地址固定分配,一容器一IPConstraints:支持约束条件,UNIQUE和LIKE



Fork me on GitHub!
https://github.com/Dataman-Cloud/swan


关于数人云Mesos调度器Swan

Swan是基于Mesos Restful API编写的应用调度框架,可以帮助用户轻松发布应用,实现应用的滚动更新,并根据用户指定的策略做应用的健康检测和故障转移。 查看全部

数人云Mesos调度器Swan开源已经一个月啦,在社区和大家的共同呵护下成长了许多。正值双十二又一波剁手节来临之际,小数带来了Swan v0.2的新版本,添加了很多新功能,大家快来看看吧——





Feature List
  • Uri  支持:支持自定义资源,支持多资源下载
  • PortIndex:支持端口命名,健康检测支持portIndex,portName和portValue
  • Cli:命令行工具
  • Heathcheck:支持mesos自带的healthcheck,http和tcp两种
  • Raft:高可用,分布式数据复制和leader选举
  • Proxy:自带proxy功能,支持负载均衡
  • DNS:自带DNS功能,支持域名解析
  • 一容器一IP:支持IP地址固定分配,一容器一IP
  • Constraints:支持约束条件,UNIQUE和LIKE




Fork me on GitHub!
https://github.com/Dataman-Cloud/swan


关于数人云Mesos调度器Swan

Swan是基于Mesos Restful API编写的应用调度框架,可以帮助用户轻松发布应用,实现应用的滚动更新,并根据用户指定的策略做应用的健康检测和故障转移。

避无可避:Mesos安全问题的几点思考

宁静胡同 发表了文章 • 0 个评论 • 48 次浏览 • 2016-12-13 16:48 • 来自相关话题

小数今天为大家抱来的内容,是有关Mesos的一个安全问题。这个问题可以说是目前行业内容器管理工具的一个通病,Mesos的团队已经在尝试解决它,那么在正式的解决方案出来前,我们也可以有办法来避免它——看看本文作者是如何思考的。

笔者研究Mesos已经很长时间了,在大多数情况下,享受着围绕Mesos整个生态系统的成长过程。为了应用(或者微服务)交付而在一个大平台上统一管理服务器是一件非常酷的事情。虽然有一些学习曲线,但是Mesos是一个非常好的应用配置工具,同时还可以把它看做统一架构进行规模扩展以及应用管理。

但是每一个技术都存在自己的缺陷和问题,我们必须诚实和开放地对待,才能让它更好地应用于企业生产。Mesos也不例外。

身份验证,开or关?

大多数开源项目都是这样开始的:“如果我们做到了X,Y和Z,那么我们就可以做到这件很酷的事情了!”然后只考虑目标用户的安全需求,这是它们的通病。Mesos团队已经踏上了从无(或者可选)到有的企业级安全之路,但是现阶段,现在仍有一些可以值得考虑的事情,让Mesos安装更加安全。

Mesos之父Ben Hindman是这样说的,“对于没有身份验证的用户来说,我们不希望在升级的时候打破他们的集群。身份验证将在默认有足够时间的情况下让应用框架升级。当一些应用框架可以身份验证同时另外其他应用框架并不支持这种升级路径时,我们开启了一种混合模式来应对。”

现在Mesos的安装默认是没有应用框架的身份验证的,也没有限制可以看到哪些应用框架。如果你使用命令行开关,可以修改这个默认行为,但是涉及到的应用框架仍然是默认打开的。本篇文章的目的即在于督促大家尽可能地在环境中使用命令行开关。

而行业标准和Mesos的做法完全相反——提供一个关闭安全的选项——但是默认它是开启的。虽然这样会使最初的部署更加困难,但这恰恰是Mesos需要的(从Ben的评论中得出的推断,他们或许正打算这么做)。

Mesos的核心安全问题

接下来的这些产生了核心的问题:
默认情况下,Mesos允许没有身份验证。通常情况下,一些形式的身份验证是需要的。越来越多的OAuth访问控制被使用。 参见Stormpath或者DigitalOcean诸如此类的API认证方案。Mesos使用“角色(role)”来决定哪一个应用框架访问资源。默认情况下,应用框架可以注册为任何角色。持久化磁盘(例如数据库或者合同目录)可以由Mesos进行资源分配。访问被角色限定(历史版本中的最近点)控制,让它们可以用于多个应用框架上的多个应用。这也使得任意和可访问应用框架有相同角色的应用框架可以被访问。Mesos可以根据需要通过mesos fetcher给集群中的节点分配agent。所以agent的分配,将是这一弱点的限定因素,实际上相当简单——一个应用框架可以要求它的agent下载到集群中的任意一台服务器上。公共应用框架开发框架。
 所以Mesos的默认安装,任何机器都可以点击应用框架的REST API,我可以注册一个自己架构的应用框架。Mesos系统自动批准注册,所以没有人员参与决策;注册(也叫:调度器订阅)意味着没有授权也会批准,并且会回复注册信息。考虑添加应用框架的频率很低,这应该是一个有人员参与的决策处。注意,更早期的应用框架开发使用libmesos所以可能滥用这种默认,但是那样更加困难,因此不太可能被利用。新应用框架可以申请存在其他应用框架的角色,之后只需等待Mesos传递给我正确的资源,就可以访问这些静态资源。这些资源可能包含任何分配给这个角色的持久化存储磁盘,可以读写(因为目前Mesos只支持读写)。

再次强调,这是一个已知的问题,Mesos团队正在解决它。但是现在,用户需要根据自己的环境来决定是否需要自己实现。

解决之道

解决方法也很简单,有命令行选项开启应用框架身份验证,限制哪一种应用框架使用哪一种角色。但是需要把它们都打开——它们默认都是关闭的——观察Mesos集群的日志,没有显示应用框架注册是默认登录设置来登录的。注意角色管理是额外的开销,但是适用于应用框架还不是一个大的安全负担,除非频繁不断地从系统里添加/移除应用框架(非常不可能的情况)。系统目前如此设计的原因是一些应用框架并不支持身份验证,所以在生产环境之前将这项功能开启进行测试也是很有必要的。

这个问题的风险大吗?坦白地说,这取决于实现过程。如果Mesos问题集群把敏感信息放在持久化存储磁盘上,风险可能很高。如果问题集群没有这样做,仍然存在架构设计上的风险以及认证的缺失,但是可用数据——Mesos之外如何保护它——决定了它会受到何种攻击。修改运行应用的配置参数的能力是更深层的考虑;HTTP单独重定向也可能很麻烦。

总结

简而言之,这个过渡期的存在,让我们更加意识到Mesos安全的重要性,因为一个未能共同遵守规范的实践,让项目的其他地方受到类似安全设计决策的影响,目前它已经在修复身份验证这个问题。

因为是过程中的不同阶段,所以实现几乎总是和调研时发掘出不同的信息或者问题。有时间多做几个应用框架后,会把信息升级,用一个“正常者”和一个“攻击者”进行测试。安全上来说,在有足够充分的文件说明的情况下,优先彻底检验问题是最好的,但我选择在准备好可能很长的证据之前先通知社区。

本文的意义在于帮助大家使用Mesos的时候绕掉那些已知的坑,建议大家使用“命令行”开关,阅读打开身份认证的指导,然后再实现它。并且建议限制角色,至少打开验证应用框架的开关并在环境中测试它是否工作。然后再畅游Mesos的世界,享受它带来的种种便利。

Note:虽然开源技术都有这样那样的问题,但是作为出色的Mesos技术框架,那些在大规模生产集群下使用的知名企业众多,小数顺便再盘点下—— 
国外有:Airbnb,Apple,Cisco,eBay,PayPal,Time Warner Cable,Twitter,Uber, Netflix,Bloomberg,Verizon…… 国内有:小米,新浪微博,爱奇艺,去哪儿网……

本文作者: DON MACVITTIE 原文链接: https://devops.com/mesos-secur ... ions/ 查看全部

小数今天为大家抱来的内容,是有关Mesos的一个安全问题。这个问题可以说是目前行业内容器管理工具的一个通病,Mesos的团队已经在尝试解决它,那么在正式的解决方案出来前,我们也可以有办法来避免它——看看本文作者是如何思考的。



笔者研究Mesos已经很长时间了,在大多数情况下,享受着围绕Mesos整个生态系统的成长过程。为了应用(或者微服务)交付而在一个大平台上统一管理服务器是一件非常酷的事情。虽然有一些学习曲线,但是Mesos是一个非常好的应用配置工具,同时还可以把它看做统一架构进行规模扩展以及应用管理。

但是每一个技术都存在自己的缺陷和问题,我们必须诚实和开放地对待,才能让它更好地应用于企业生产。Mesos也不例外。

身份验证,开or关?

大多数开源项目都是这样开始的:“如果我们做到了X,Y和Z,那么我们就可以做到这件很酷的事情了!”然后只考虑目标用户的安全需求,这是它们的通病。Mesos团队已经踏上了从无(或者可选)到有的企业级安全之路,但是现阶段,现在仍有一些可以值得考虑的事情,让Mesos安装更加安全。

Mesos之父Ben Hindman是这样说的,“对于没有身份验证的用户来说,我们不希望在升级的时候打破他们的集群。身份验证将在默认有足够时间的情况下让应用框架升级。当一些应用框架可以身份验证同时另外其他应用框架并不支持这种升级路径时,我们开启了一种混合模式来应对。”

现在Mesos的安装默认是没有应用框架的身份验证的,也没有限制可以看到哪些应用框架。如果你使用命令行开关,可以修改这个默认行为,但是涉及到的应用框架仍然是默认打开的。本篇文章的目的即在于督促大家尽可能地在环境中使用命令行开关。

而行业标准和Mesos的做法完全相反——提供一个关闭安全的选项——但是默认它是开启的。虽然这样会使最初的部署更加困难,但这恰恰是Mesos需要的(从Ben的评论中得出的推断,他们或许正打算这么做)。

Mesos的核心安全问题

接下来的这些产生了核心的问题:
  1. 默认情况下,Mesos允许没有身份验证。通常情况下,一些形式的身份验证是需要的。越来越多的OAuth访问控制被使用。 参见Stormpath或者DigitalOcean诸如此类的API认证方案。
  2. Mesos使用“角色(role)”来决定哪一个应用框架访问资源。默认情况下,应用框架可以注册为任何角色。
  3. 持久化磁盘(例如数据库或者合同目录)可以由Mesos进行资源分配。访问被角色限定(历史版本中的最近点)控制,让它们可以用于多个应用框架上的多个应用。这也使得任意和可访问应用框架有相同角色的应用框架可以被访问。
  4. Mesos可以根据需要通过mesos fetcher给集群中的节点分配agent。所以agent的分配,将是这一弱点的限定因素,实际上相当简单——一个应用框架可以要求它的agent下载到集群中的任意一台服务器上。
  5. 公共应用框架开发框架。

 所以Mesos的默认安装,任何机器都可以点击应用框架的REST API,我可以注册一个自己架构的应用框架。Mesos系统自动批准注册,所以没有人员参与决策;注册(也叫:调度器订阅)意味着没有授权也会批准,并且会回复注册信息。考虑添加应用框架的频率很低,这应该是一个有人员参与的决策处。注意,更早期的应用框架开发使用libmesos所以可能滥用这种默认,但是那样更加困难,因此不太可能被利用。新应用框架可以申请存在其他应用框架的角色,之后只需等待Mesos传递给我正确的资源,就可以访问这些静态资源。这些资源可能包含任何分配给这个角色的持久化存储磁盘,可以读写(因为目前Mesos只支持读写)。

再次强调,这是一个已知的问题,Mesos团队正在解决它。但是现在,用户需要根据自己的环境来决定是否需要自己实现。

解决之道

解决方法也很简单,有命令行选项开启应用框架身份验证,限制哪一种应用框架使用哪一种角色。但是需要把它们都打开——它们默认都是关闭的——观察Mesos集群的日志,没有显示应用框架注册是默认登录设置来登录的。注意角色管理是额外的开销,但是适用于应用框架还不是一个大的安全负担,除非频繁不断地从系统里添加/移除应用框架(非常不可能的情况)。系统目前如此设计的原因是一些应用框架并不支持身份验证,所以在生产环境之前将这项功能开启进行测试也是很有必要的。

这个问题的风险大吗?坦白地说,这取决于实现过程。如果Mesos问题集群把敏感信息放在持久化存储磁盘上,风险可能很高。如果问题集群没有这样做,仍然存在架构设计上的风险以及认证的缺失,但是可用数据——Mesos之外如何保护它——决定了它会受到何种攻击。修改运行应用的配置参数的能力是更深层的考虑;HTTP单独重定向也可能很麻烦。

总结

简而言之,这个过渡期的存在,让我们更加意识到Mesos安全的重要性,因为一个未能共同遵守规范的实践,让项目的其他地方受到类似安全设计决策的影响,目前它已经在修复身份验证这个问题。

因为是过程中的不同阶段,所以实现几乎总是和调研时发掘出不同的信息或者问题。有时间多做几个应用框架后,会把信息升级,用一个“正常者”和一个“攻击者”进行测试。安全上来说,在有足够充分的文件说明的情况下,优先彻底检验问题是最好的,但我选择在准备好可能很长的证据之前先通知社区。

本文的意义在于帮助大家使用Mesos的时候绕掉那些已知的坑,建议大家使用“命令行”开关,阅读打开身份认证的指导,然后再实现它。并且建议限制角色,至少打开验证应用框架的开关并在环境中测试它是否工作。然后再畅游Mesos的世界,享受它带来的种种便利。

Note:虽然开源技术都有这样那样的问题,但是作为出色的Mesos技术框架,那些在大规模生产集群下使用的知名企业众多,小数顺便再盘点下—— 
国外有:Airbnb,Apple,Cisco,eBay,PayPal,Time Warner Cable,Twitter,Uber, Netflix,Bloomberg,Verizon…… 国内有:小米,新浪微博,爱奇艺,去哪儿网……

本文作者: DON MACVITTIE 原文链接: https://devops.com/mesos-secur ... ions/

DevOps:谁说我只是自动化工具?

宁静胡同 发表了文章 • 0 个评论 • 45 次浏览 • 2016-12-13 16:31 • 来自相关话题

关于DevOps,每个人都有不同的认识。有人坚持它是一种方法论,然而在实践中为了脱离缓慢的手工作业,自动化工具必不可少。从职责传递到自助服务,DevOps为满足业务的快速交付而生,却存在学习上的瓶颈。
然后谢天谢地,容器来了……

参加了大大小小许多DevOps和软件工程的会议。每当”DevOps究竟意味着什么”这个话题被提起时,总是会有一个这样的论点出现:

DevOps不是一系列可以连贯起来的工具,你用了它们就可以说自己做的是DevOps。DevOps是一种方法论,让开发和运维团队能够更紧密工作的一套过程。最终的目标是消除在软件发布的过程中手动作业和耗费时间的部分,实现更多成功的部署和更频繁的发布。

它完全正确。然而,话虽如此,祝不使用自动化工具的DevOps或者持续交付……好运。

为什么自动化工具是先决条件

假设这样一个场景:你处在一个研发工作室,创业公司甚至是大型企业。你有很多开发人员,他们中的少数一些被称为“Ops小组”“DevOps魔法师”或者“云运维”,在企业中他们可能被称为“基础设施运营专家”(如果你们有更有趣的名字也可以在下方留言)。但不管怎样,他们的人使用开发团队所写的代码,并确保它们能够在生产级别的环境上可靠运行。
开发写代码并添加新特性从开发到运维,一个传递发生了现在它是运维的麻烦了……运维挥动服务器魔法,把问题解决了!

听着很耳熟?主要的问题是什么呢?运维和开发的分离这件事在整个发布过程中发生得过早了。它随着传递发生,从此变成了一个问题。在技术团队中有服务器魔法师当然很棒,因为开发人员不用再担心如何处理服务器问题,但是它确实是一个把你从DevOps的喜悦中拉下来的瓶颈。

自助服务:开发人员需要它,运维也是

DevOps的目的是团队紧密工作,缩短反馈回路。

做一些改变,让它们在测试环境中提交、合并、站住脚来确保一切都如预期那样。看起来不错?然后让新功能平滑地上生产,交到用户的手里。出现了问题?回滚一下,迅速地修复它,然后在不停机的情况下发布更新。

然而写代码的开发人员和理解及维护云平台的运维人员减慢了反馈回路,经常慢如爬行动物。

写代码的开发人员最适合做发布(在他们的计划中方便的时候),测试,监控性能,以及解决任何突然出现的问题。可是为什么没有工作流程是默认如此的呢?

很多情况下,服务器魔法师或者运维团队是唯一理解云平台所有事物的人。没有为开发者或者试图了解幕后情况的人提供的自助服务。

听起来运维团队处在一个非常强大的位置,但实际上它是非常痛苦和充满压力的。在给用户提供软件后你多少会明白,发布和维护是你职责所在,如果出错了要在第一线调试它,通常一忙就是一天24小时。

那为什么这是一个如此常见的场景呢?(提示,通常和工具有关)。

你选择的工具可能重要,也可能无关紧要

在一天结束的时候,运维人员、开发人员、安全保障人员、项目经理等等都对新软件发布的过程很满意,它实现了快速交付满足了业务需求。你可以通过很多方式到达这个目标。如果你是通过类似自助的方式,那么恭喜。

讲个故事。

在之前的一份工作里,我们采用了一种配置管理工具,插在Jenkins上,集成了很多开源系统,很高兴地自动化了一个大型、多区、遵从PCI并且流畅跑在AWS上的服务器。我们让非技术人员添加和部署新项目成为可能,可以为每个变化进行完整测试。一切看起来都很好,除了一个大问题:我们构建了类似自助服务的东西,但是它对公司95%的人来说是一个黑盒。开发把他们的代码给我们,他们可以检查日志,查看图表,看各项性能,但是当碰到钉子的时候,就是我们的职责了。
 
所以怎样才能让更多的人能够明白我们搭建的主机系统如何工作?我们用来连接一切的工具和用户配置让学习的复杂度大大提高。

然后……容器来了。

为什么容器可以帮上忙

你知道我一定会提容器的,对不对?在过去几年的DevOps大会上,容器和其应用基本是一个必谈的话题。

容器改变了开发和运维之间的分离境地,改进了他们之间的传递进程。开发人员能够更接近项目来确保他们的更新在传递给本地镜像创建人员之前可以成功部署。标准变得更加成熟和有意义,让更多人专注于应用程序而不是服务器。

容器已经催生了很多颇有竞争力的解决方案,提供一个平台来代替自助服务。因此运维团队和开发团队可以把关注点放在生产更多高效的进程和结果。所以在实践中它是什么样的?

当容器和DevOps碰撞

每一个软件公司如果着手开发一个改变游戏规则的产品,在前进的道路上,不管是从基础架构、还是人员管理和软件发布的角度,都会不可避免遇到可伸缩性的问题。随着团队的成长,和服务器的扩展,公司不仅需要关注产品线路图的执行,还需要变成云计算自动化领域的专家。能够最快速地执行新想法就会有显著的优势。如果你仍然手动登录服务器或者尝试再造一个云平台的车轮,那么就是在伤害你的公司。

而最近的一些容器技术或者容器服务平台可以帮助你从别人的硬件中解放出来,让公司更加专注于产品——
 
开发者能够通过友好的用户界面管理自己的服务器硬件需求开发者可以减少一个数量级的反馈回路时间,这意味着更多的代码更快的发布运维不用再尝试将一堆工具拢在一起做一个内部的PaaS,它很难做,很难管理,很难修补,很难保证安全运维可以更进一步地专注在应用监控、性能表现上,给予开发一些有价值的反馈来快速提升产品业务可以更灵活地延伸到全球范围,根据业务需求进行扩展,更新用户平台不需要时间和成本上的花费更多的资金可以用来雇佣人才专注于产品研发

所以,拥有了容器技术的DevOps,是否有了新的定义?

当然小数要补充一句,容器不是万能的,用在适合的地方最好。


文章作者:Phil Dougherty
原文链接:https://blog.containership.io/ ... isite 查看全部

关于DevOps,每个人都有不同的认识。有人坚持它是一种方法论,然而在实践中为了脱离缓慢的手工作业,自动化工具必不可少。从职责传递到自助服务,DevOps为满足业务的快速交付而生,却存在学习上的瓶颈。
然后谢天谢地,容器来了……



参加了大大小小许多DevOps和软件工程的会议。每当”DevOps究竟意味着什么”这个话题被提起时,总是会有一个这样的论点出现:

DevOps不是一系列可以连贯起来的工具,你用了它们就可以说自己做的是DevOps。DevOps是一种方法论,让开发和运维团队能够更紧密工作的一套过程。最终的目标是消除在软件发布的过程中手动作业和耗费时间的部分,实现更多成功的部署和更频繁的发布。

它完全正确。然而,话虽如此,祝不使用自动化工具的DevOps或者持续交付……好运。

为什么自动化工具是先决条件

假设这样一个场景:你处在一个研发工作室,创业公司甚至是大型企业。你有很多开发人员,他们中的少数一些被称为“Ops小组”“DevOps魔法师”或者“云运维”,在企业中他们可能被称为“基础设施运营专家”(如果你们有更有趣的名字也可以在下方留言)。但不管怎样,他们的人使用开发团队所写的代码,并确保它们能够在生产级别的环境上可靠运行。
  • 开发写代码并添加新特性
  • 从开发到运维,一个传递发生了
  • 现在它是运维的麻烦了……
  • 运维挥动服务器魔法,把问题解决了!


听着很耳熟?主要的问题是什么呢?运维和开发的分离这件事在整个发布过程中发生得过早了。它随着传递发生,从此变成了一个问题。在技术团队中有服务器魔法师当然很棒,因为开发人员不用再担心如何处理服务器问题,但是它确实是一个把你从DevOps的喜悦中拉下来的瓶颈。

自助服务:开发人员需要它,运维也是

DevOps的目的是团队紧密工作,缩短反馈回路。

做一些改变,让它们在测试环境中提交、合并、站住脚来确保一切都如预期那样。看起来不错?然后让新功能平滑地上生产,交到用户的手里。出现了问题?回滚一下,迅速地修复它,然后在不停机的情况下发布更新。

然而写代码的开发人员和理解及维护云平台的运维人员减慢了反馈回路,经常慢如爬行动物。

写代码的开发人员最适合做发布(在他们的计划中方便的时候),测试,监控性能,以及解决任何突然出现的问题。可是为什么没有工作流程是默认如此的呢?

很多情况下,服务器魔法师或者运维团队是唯一理解云平台所有事物的人。没有为开发者或者试图了解幕后情况的人提供的自助服务。

听起来运维团队处在一个非常强大的位置,但实际上它是非常痛苦和充满压力的。在给用户提供软件后你多少会明白,发布和维护是你职责所在,如果出错了要在第一线调试它,通常一忙就是一天24小时。

那为什么这是一个如此常见的场景呢?(提示,通常和工具有关)。

你选择的工具可能重要,也可能无关紧要

在一天结束的时候,运维人员、开发人员、安全保障人员、项目经理等等都对新软件发布的过程很满意,它实现了快速交付满足了业务需求。你可以通过很多方式到达这个目标。如果你是通过类似自助的方式,那么恭喜。

讲个故事。

在之前的一份工作里,我们采用了一种配置管理工具,插在Jenkins上,集成了很多开源系统,很高兴地自动化了一个大型、多区、遵从PCI并且流畅跑在AWS上的服务器。我们让非技术人员添加和部署新项目成为可能,可以为每个变化进行完整测试。一切看起来都很好,除了一个大问题:我们构建了类似自助服务的东西,但是它对公司95%的人来说是一个黑盒。开发把他们的代码给我们,他们可以检查日志,查看图表,看各项性能,但是当碰到钉子的时候,就是我们的职责了。
 
所以怎样才能让更多的人能够明白我们搭建的主机系统如何工作?我们用来连接一切的工具和用户配置让学习的复杂度大大提高。

然后……容器来了。

为什么容器可以帮上忙

你知道我一定会提容器的,对不对?在过去几年的DevOps大会上,容器和其应用基本是一个必谈的话题。

容器改变了开发和运维之间的分离境地,改进了他们之间的传递进程。开发人员能够更接近项目来确保他们的更新在传递给本地镜像创建人员之前可以成功部署。标准变得更加成熟和有意义,让更多人专注于应用程序而不是服务器。

容器已经催生了很多颇有竞争力的解决方案,提供一个平台来代替自助服务。因此运维团队和开发团队可以把关注点放在生产更多高效的进程和结果。所以在实践中它是什么样的?

当容器和DevOps碰撞

每一个软件公司如果着手开发一个改变游戏规则的产品,在前进的道路上,不管是从基础架构、还是人员管理和软件发布的角度,都会不可避免遇到可伸缩性的问题。随着团队的成长,和服务器的扩展,公司不仅需要关注产品线路图的执行,还需要变成云计算自动化领域的专家。能够最快速地执行新想法就会有显著的优势。如果你仍然手动登录服务器或者尝试再造一个云平台的车轮,那么就是在伤害你的公司。

而最近的一些容器技术或者容器服务平台可以帮助你从别人的硬件中解放出来,让公司更加专注于产品——
 
  • 开发者能够通过友好的用户界面管理自己的服务器硬件需求
  • 开发者可以减少一个数量级的反馈回路时间,这意味着更多的代码更快的发布
  • 运维不用再尝试将一堆工具拢在一起做一个内部的PaaS,它很难做,很难管理,很难修补,很难保证安全
  • 运维可以更进一步地专注在应用监控、性能表现上,给予开发一些有价值的反馈来快速提升产品
  • 业务可以更灵活地延伸到全球范围,根据业务需求进行扩展,更新用户平台不需要时间和成本上的花费
  • 更多的资金可以用来雇佣人才专注于产品研发


所以,拥有了容器技术的DevOps,是否有了新的定义?

当然小数要补充一句,容器不是万能的,用在适合的地方最好。


文章作者:Phil Dougherty
原文链接:https://blog.containership.io/ ... isite

由浅入深 | 如何优雅地写一个Mesos Framework

宁静胡同 发表了文章 • 0 个评论 • 92 次浏览 • 2016-12-07 14:25 • 来自相关话题

>上周小数羞涩出镜,和数人云架构师春明一起为大家进行了在线直播的干货分享,今天小数抱来了实录,大家可以一睹为快啦!
本文从Mesos的基础概念讲起,不懂Mesos的小伙伴也完全没有问题,一步一步教你写出优雅的Framework,让Mesos更加强大好用:)



今天主要和大家聊一聊Mesos、Marathon,以及数人云刚刚开源不久的一个Mesos Framework——Swan。


什么是Mesos


微服务概念起来之后,很多大型互联网公司需要把资源(比如说几千台机器、几万台机器)抽象工作,让更多人来使用。之前大家的做法比较粗暴,一个部门分几百台机器,一个项目分几百台机器,然后把程序裸跑在一些硬件或者虚拟机上,但这个过程中资源的利用率不是很高。

另一方面,有些增加资源的场景中,增加一些机器非常缓慢,安装、做机器的provision等等都很困难。因此一些聪明的工程师就萌生了一个想法:能不能把这些资源都抽象,需要的时候分配给不同的人来使用?这个背景诞生了Mesos,即资源调度的工具。资源调度器Mesos不是创新,它源自于Google Omega的论文,由Twitter的公司最早推出来。
   
最近一段时间使用Mesos的API以及看代码时间比较多,接下和大家分享一下我对Mesos内部的理解。


Mesos的内部构成

Mesos master&slave
首先,Mesos是一个分布式的架构,它分Mesos master和Mesos slave,slave和master分别有不同的职责。从Mesos的源代码可以看出Mesos实现得比较优雅——它是一个C++代码。代码中有大量的关键词叫process,它不是传统意义上的进程,而是一种抽象的libprocess,libprocess是它最核心的库。如果大家以前使用过Erlang的语言就知道libprocess实际是对Erlang的IO和通讯模型的一个抽象。

libprocess,在Erlang里面也叫进程,实际上是一个虚拟进程,在运行Erlang的VM上。它最优的特点是消息在不同的process之间传递,它抽象了process,消息传递其实是一个事件的库。向process里发一个消息,这个消息不是直接打到process,而是中间有一个buffer的过程。

这样做的优点是特别适合分布式的系统,以前最常用的做法是监听网络端口,有包来了,有一个模块专门负责解这个包,解开一个协议后把这个协议发到后面一个处理进程,这个处理的进程可能是IO操作,可能去做其它事情,然后里面有很多IO上的Block,最后构造出一个response,通过一个socket传给客户端。这是最常用的一个写网络程序的办法,但是这里有一个大的IO上Block的地方——后面处理的逻辑依赖于解包的逻辑。如果处理逻辑很快,但解包逻辑很慢,后面会拖慢,都在等解包。

后来人们想到一种IO处理的方式,让任何一个东西都是分离的,比如从某一个端口收到一个消息,有一个单独的进程,一个线程或者其它的东西去处理这个唯一的请求。这个线程很重,后来大家又发明了一些其它的东西,比如golang里面去搞一个channel,Erlang里面去搞一个process。libprocess实际上做了IO方面的事情, Mesos大量使用这个模型。
   
Zookeeper
Mesos底层实际上依赖于Zookeeper,为了保证分布式存储最终一致性。在Mesos运行过程中产生了一些数据,最终都会落在Zookeeper。因为Mesos是多个master,为了达到HA的需求,只要一个master活的,那么整个服务就能得到保证。
   
protobuf
Mesos内部在通信里面选择了protobuf协议。好处是比较流行,各个语言的库都比较多,结构化的语义也比较强,所以Mesos内部选择了protobuf。
   
至此,简单介绍了Mesos内部的一些动作。接下来介绍Mesos提出的一些概念。


Mesos概念解析


Mesos master&slave   
Mesos是一个分布式的系统,分master和slave, master的部分主要协调任务的分发、一些资源的调度。slave是负责执行的部分,比如一个任务最终是slave去执行的。当然,可以配在master执行。Mesos是一个双层调度,slave处于下层,也就是说可以动态的增加或者减少一些slave而不影响整个的任务池资源的变化,不影响上一层的任务。
  
Executor
Executor是真正的执行任务的逻辑。Mesos平台不太区分需要执行什么任务,所以它给用户一些灵活性,可以写不同的Executor。比如最常用的Mesos运行容器的部分,就是一个Executor。还有Map Reduce的大型任务,一个Map、一个Reduce, Executor都可以执行。它的表现形式可以是一个二进制,Mesos在运行时,slave会把Executor从远程一个URL上拉下来,然后开始执行Executor。
   
Scheduler
Scheduler的意思是调度, Mesos master和slave把资源收上来之后,再把这些任务交给Scheduler,由Scheduler决定应该运行什么Task。
   
Framework
Framework是双层调度的上一层,也就是由Framework来决定到底该执行什么任务,然后执行多少这样的任务。
   
Offer
Offer是Mesos资源的抽象,比如说有多少CPU、多少memory,disc是多少,都放在Offer里,打包给一个Framework,然后Framework来决定到底怎么用这个Offer。
  
Task
Task实际上是运行的小任务。有两大类Task,一大类我们叫Long Running Task,比如Docker的一个进程或者其它的进程。另外一类是Batch类型任务,这类应用非常广泛,比如说Map Reduce这么一个小任务或者是定时任务。


Mesos内部工作原理


这里分别介绍一下刚才提到的这些名词,说一说它们都是如何工作的。

Mesos master & slave
Mesos master是整个集群的核心,master为了保证高可用其实是可以跑多个master,分布式系统为了保证尽量的高可用,其实是可以有多个master在那儿运行的。比如倒了几个master,不会影响整个服务。Mesos master主要内部的工作有:Framework注册或者Framework出了什么问题,它来保证Framework的生命周期;slave的添加、slave的异常、slave的任务分配,我把它叫做slave的Lifecycle;Task Management,比如说Mesos master可能记录了哪些Task运行在哪些slave上;Resource Allocation&Offer,就是说slave有什么资源汇报给master,然后由master把这些任务交给注册在这个master上的一些Framework。
   
slave可以动态添加和减少,它lost不会影响整个服务,只是把这个事件(比如说一个slave掉了)由master去通知Framework。在Mesos slave代码里有大量执行器,即Executor的逻辑,因为所有Executor都是在slave上执行的,包括把Executor从远程拉下来、开始执行Executor、开始执行launch task,维护task的生命周期,task fail了如何去做等等。

Mesos Framework
Mesos的定位是一些资源的调度,它把任务的调度交给了Framework来做,Mesos只关心资源以及把资源给了谁, Framework来决定哪些资源怎么去使用。Mesos鼓励Framework在上面共生。想象一下,作为一个大型公司,有很多的资源,有核心的一组人来维护Mesos的集群,不断的往Mesos上添加资源和减少资源,而把Framework执行的能力交给其它的组、需要资源的那些组,各个组就可以写自己的Framework,丢到整个大的Mesos集群上来执行了。Mesos框架上和执行上各种各样的Framework,而Mesos本身也不了解为什么Framework工作,它只是知道把Offer给Framework,然后Framework告诉它来执行什么样的Executor。
   
两个比较流行的Framework
Marathon Framework,它的任务偏Long Running,核心是application。因为Mesos只关注task本身,task偏向于小任务,不会产生什么巨大的效应,而在企业里面尤其是弹性应用,更多是一个应用,它有很多的实例来执行,这就是Marathon来做的。
  
Chornous是一个偏Job、定时任务类型,如果把定时任务以Docker形式发出来,这个Chornous是非常适合的。传统的的Cron Job也是解决这类问题, Cron Job其实有很大的痛点,因为Cron Job是跑在主机上的,主机有limit的限制,如何把Cron Job放在多机上,需要有一个很好的哈希算法。到底如何把一堆单台机器很难执行的多个job水平分布在很多机器上,很麻烦。但是有了这个Chornous的Framework,事情就变得简单多了。
   
Scheduler/Scheduler Driver
它们俩区分度不是太大,有一些区分。Scheduler是做任务分配的,它从master上得到一个Offer的事件,拿到Offer后,决定到底接受这个Offer还是拒绝,接受这个Offer之后,把什么样的Task放在这个Offer上, Framework也开始占用这个Offer,这是Scheduler做的事情。Scheduler Driver其实是偏消息通信的那一部分,而Scheduler可定制化特别强,在代码里看到Scheduler其实是一个java的abstract glass,相当于一个interface,Framework自己去实现这么一个东西。如果想写一个Framework,其实大部分时间在如何写好一个Scheduler实现这一部分。
   
Executor/Executor Driver
如果Executor和Scheduler是对应的, Executor就是执行的这一部分。Mesos container这个Executor是Mesos自己提供的,不用写Executor就可以launch一个Docker的任务。但如果有一些自己的需求,就需要去实现一个Executor,比如七牛和乐视实现了一些Executor。

举例来说,处理图片、处理文件的Executor,偏向于这种小任务,写一个Executor来实现这个interface,最终打成一个二进制,放在一个URL里面。在Framework,slave就可以把这个Executor拉下来,然后执行这个Tasks。Executor是一个独立的二进制,它和master、和slave之间的通信是要支持RBC的。


Marathon


刚才已经提到了Marathon基本的功能,Marathon作为一个Long Running上一层的调度机制,为用户做了很多有意义的事情。单纯一个Mesos的话做不了什么,因为Task的力度特别小,Mesos的功能更偏重于资源的管理、资源的调度,Marathon更偏向于一些任务。

Marathon提出了几个概念,最核心的概念叫application,还有Group的application,是一组的application。一个application是什么呢?比如一个Rails的任务、NodeJS任务或者其它的一些任务,在部署的时候并不是部署一个Task,而是部署非常多的Task,application就是一组Task。这个Task在Marathon里面叫instance,可以选择scale down或者scale up这些instance,这些任务最终交给Mesos,Mesos调度到不同的slave上。

围绕着这个application,Marathon就提供了一些概念叫Group,Group是一组application。举例来说,在内部可能有很多的微服务,这些微服务达到同一个目标,比如说服务之间还有调用、还有依赖,这时去发一个Group application就比较好用。但实际工作中,因为生产级别的服务对稳定性的要求很高, Group之间其实假设服务和服务之间是有一定的依赖。
  
Marathon提供了一个有意思的feature—— rolling update。假如有APP的新版本上来,它可以通过一定的机制去发多个版本,而且可以多个版本共存。如果那个新版本没有问题的话,可以继续preceeding deployment。如果有问题的话,可以Rollback。这时有两个概念Deployment和Version,可以选定哪一个Version,想Rollback哪个Version。Deployment是每次update,每次更新、每次重新的Deployment、每次scale,都会在内部生成一个Deployment,和应用一对多有关。有趣的是Deployment之间是不可以重叠的,Deployment是一种部署排队的机制,Deployment不可以多个同时进行,既想update又想scale,会让Marathon崩溃。
  
Marathon scale和rolling update的功能都非常有用,比如新浪微博现在有一个大的事件,需要更多的Task顶上来,立刻 scale up,只要资源足够就可以无限多的Task生成。Rollback,如果有一个版本有问题,可以瞬间Rollback到以前一个健康的版本。
  
虽然Mesos对下面的资源做了一些抽象,但是有时候有一些倾向性,比如希望CPU使用率比较高的一些任务调度到CPU比较好的机器上,需要一种在调度上的倾向性来满足刚才的场景。很多调度器都有类似的功能,叫Constraints,比如一台主机的label,要把Task打到一组主机这样的Label上或者是Host name like,这是Marathon做的,Mesos不用做这类的事情。
  
Marathon的接口非常友好,都是HTTP的接口。Mesos的接口by design不是面向最终用户,所以它的接口并不是那么友好。马拉松的UI也非常漂亮,尤其是新版。


Mesos调度器Swan


最后介绍一下Swan(https://github.com/Dataman-Cloud/swan )这个项目,Swan是最近数人云做的一个Mesos的Framework,定位是做一个General Purpose Long Running Task的Framework。数人云使用马拉松较长时间,发现不太满足需求,比如很难做一些定制化,控制不住它的发展趋势。我们希望研发一款工具既有马拉松的功能又自主可控、添加一些想要的featur,具体的feature会在下文中逐一介绍。

我们希望这个通用性的Framework在任何情况下,服务不会受到影响。因为Mesos HA这方面已经做得很好,所以Framework不会是单点,首先Swan要支持HA,因为受到Swarmkit启发比较大, Swarmkit天生就是Raft协议,在一堆manager中只要有一个活的,就能健康的对外服务。
   
Marathon没怎么做服务发现,无非是把端口暴露出来,哪个任务在哪些IP和端口上,通过API的形式告诉给外面。Swan里内置服务发现,会有一个列表告诉外面哪些服务跑在哪些端口、哪些APP上。

DNS是服务发现的另一种。主流的一些Framework都把DNS这个功能放在了比较核心的位置,比如K8s里面的SkyNet,Mesos曾经以前有Mesos DNS,以及Swarmkit,Swarm的服务发现分为DNS Round Robin和IPVS两种,把DNS放在Swan这个模块里更加的可控。它不单是一个DNS,同时是一个DNS的代理。这样最终能实现的效果,在企业内部通过我们的DNS和用户的DNS来混搭,来达到一种Mesos内部和外部互相调用,在浏览器上既可以访问Mesos内部的东西又可以访问外面的东西,达到比较完美的效果。

Proxy,并不单是Proxy,还有负载均衡。最常见的Proxy的工具有HAProxy或者nginx。 HAProxy和nginx虽然很优秀、性能很好,缺点是可控性太差,很难控制它。HA可编程的能力很差,Nginx可编程的能力不错,新浪微博有一个项目叫upsync-module,非常优秀。之前评估过这个项目,发现集成这两个的难度很大。
  
我的分享就到这里,谢谢大家。 查看全部
>上周小数羞涩出镜,和数人云架构师春明一起为大家进行了在线直播的干货分享,今天小数抱来了实录,大家可以一睹为快啦!
本文从Mesos的基础概念讲起,不懂Mesos的小伙伴也完全没有问题,一步一步教你写出优雅的Framework,让Mesos更加强大好用:)



今天主要和大家聊一聊Mesos、Marathon,以及数人云刚刚开源不久的一个Mesos Framework——Swan。


什么是Mesos


微服务概念起来之后,很多大型互联网公司需要把资源(比如说几千台机器、几万台机器)抽象工作,让更多人来使用。之前大家的做法比较粗暴,一个部门分几百台机器,一个项目分几百台机器,然后把程序裸跑在一些硬件或者虚拟机上,但这个过程中资源的利用率不是很高。

另一方面,有些增加资源的场景中,增加一些机器非常缓慢,安装、做机器的provision等等都很困难。因此一些聪明的工程师就萌生了一个想法:能不能把这些资源都抽象,需要的时候分配给不同的人来使用?这个背景诞生了Mesos,即资源调度的工具。资源调度器Mesos不是创新,它源自于Google Omega的论文,由Twitter的公司最早推出来。
   
最近一段时间使用Mesos的API以及看代码时间比较多,接下和大家分享一下我对Mesos内部的理解。


Mesos的内部构成

Mesos master&slave
首先,Mesos是一个分布式的架构,它分Mesos master和Mesos slave,slave和master分别有不同的职责。从Mesos的源代码可以看出Mesos实现得比较优雅——它是一个C++代码。代码中有大量的关键词叫process,它不是传统意义上的进程,而是一种抽象的libprocess,libprocess是它最核心的库。如果大家以前使用过Erlang的语言就知道libprocess实际是对Erlang的IO和通讯模型的一个抽象。

libprocess,在Erlang里面也叫进程,实际上是一个虚拟进程,在运行Erlang的VM上。它最优的特点是消息在不同的process之间传递,它抽象了process,消息传递其实是一个事件的库。向process里发一个消息,这个消息不是直接打到process,而是中间有一个buffer的过程。

这样做的优点是特别适合分布式的系统,以前最常用的做法是监听网络端口,有包来了,有一个模块专门负责解这个包,解开一个协议后把这个协议发到后面一个处理进程,这个处理的进程可能是IO操作,可能去做其它事情,然后里面有很多IO上的Block,最后构造出一个response,通过一个socket传给客户端。这是最常用的一个写网络程序的办法,但是这里有一个大的IO上Block的地方——后面处理的逻辑依赖于解包的逻辑。如果处理逻辑很快,但解包逻辑很慢,后面会拖慢,都在等解包。

后来人们想到一种IO处理的方式,让任何一个东西都是分离的,比如从某一个端口收到一个消息,有一个单独的进程,一个线程或者其它的东西去处理这个唯一的请求。这个线程很重,后来大家又发明了一些其它的东西,比如golang里面去搞一个channel,Erlang里面去搞一个process。libprocess实际上做了IO方面的事情, Mesos大量使用这个模型。
   
Zookeeper
Mesos底层实际上依赖于Zookeeper,为了保证分布式存储最终一致性。在Mesos运行过程中产生了一些数据,最终都会落在Zookeeper。因为Mesos是多个master,为了达到HA的需求,只要一个master活的,那么整个服务就能得到保证。
   
protobuf
Mesos内部在通信里面选择了protobuf协议。好处是比较流行,各个语言的库都比较多,结构化的语义也比较强,所以Mesos内部选择了protobuf。
   
至此,简单介绍了Mesos内部的一些动作。接下来介绍Mesos提出的一些概念。


Mesos概念解析


Mesos master&slave   
Mesos是一个分布式的系统,分master和slave, master的部分主要协调任务的分发、一些资源的调度。slave是负责执行的部分,比如一个任务最终是slave去执行的。当然,可以配在master执行。Mesos是一个双层调度,slave处于下层,也就是说可以动态的增加或者减少一些slave而不影响整个的任务池资源的变化,不影响上一层的任务。
  
Executor
Executor是真正的执行任务的逻辑。Mesos平台不太区分需要执行什么任务,所以它给用户一些灵活性,可以写不同的Executor。比如最常用的Mesos运行容器的部分,就是一个Executor。还有Map Reduce的大型任务,一个Map、一个Reduce, Executor都可以执行。它的表现形式可以是一个二进制,Mesos在运行时,slave会把Executor从远程一个URL上拉下来,然后开始执行Executor。
   
Scheduler
Scheduler的意思是调度, Mesos master和slave把资源收上来之后,再把这些任务交给Scheduler,由Scheduler决定应该运行什么Task。
   
Framework
Framework是双层调度的上一层,也就是由Framework来决定到底该执行什么任务,然后执行多少这样的任务。
   
Offer
Offer是Mesos资源的抽象,比如说有多少CPU、多少memory,disc是多少,都放在Offer里,打包给一个Framework,然后Framework来决定到底怎么用这个Offer。
  
Task
Task实际上是运行的小任务。有两大类Task,一大类我们叫Long Running Task,比如Docker的一个进程或者其它的进程。另外一类是Batch类型任务,这类应用非常广泛,比如说Map Reduce这么一个小任务或者是定时任务。


Mesos内部工作原理


这里分别介绍一下刚才提到的这些名词,说一说它们都是如何工作的。

Mesos master & slave
Mesos master是整个集群的核心,master为了保证高可用其实是可以跑多个master,分布式系统为了保证尽量的高可用,其实是可以有多个master在那儿运行的。比如倒了几个master,不会影响整个服务。Mesos master主要内部的工作有:Framework注册或者Framework出了什么问题,它来保证Framework的生命周期;slave的添加、slave的异常、slave的任务分配,我把它叫做slave的Lifecycle;Task Management,比如说Mesos master可能记录了哪些Task运行在哪些slave上;Resource Allocation&Offer,就是说slave有什么资源汇报给master,然后由master把这些任务交给注册在这个master上的一些Framework。
   
slave可以动态添加和减少,它lost不会影响整个服务,只是把这个事件(比如说一个slave掉了)由master去通知Framework。在Mesos slave代码里有大量执行器,即Executor的逻辑,因为所有Executor都是在slave上执行的,包括把Executor从远程拉下来、开始执行Executor、开始执行launch task,维护task的生命周期,task fail了如何去做等等。

Mesos Framework
Mesos的定位是一些资源的调度,它把任务的调度交给了Framework来做,Mesos只关心资源以及把资源给了谁, Framework来决定哪些资源怎么去使用。Mesos鼓励Framework在上面共生。想象一下,作为一个大型公司,有很多的资源,有核心的一组人来维护Mesos的集群,不断的往Mesos上添加资源和减少资源,而把Framework执行的能力交给其它的组、需要资源的那些组,各个组就可以写自己的Framework,丢到整个大的Mesos集群上来执行了。Mesos框架上和执行上各种各样的Framework,而Mesos本身也不了解为什么Framework工作,它只是知道把Offer给Framework,然后Framework告诉它来执行什么样的Executor。
   
两个比较流行的Framework
Marathon Framework,它的任务偏Long Running,核心是application。因为Mesos只关注task本身,task偏向于小任务,不会产生什么巨大的效应,而在企业里面尤其是弹性应用,更多是一个应用,它有很多的实例来执行,这就是Marathon来做的。
  
Chornous是一个偏Job、定时任务类型,如果把定时任务以Docker形式发出来,这个Chornous是非常适合的。传统的的Cron Job也是解决这类问题, Cron Job其实有很大的痛点,因为Cron Job是跑在主机上的,主机有limit的限制,如何把Cron Job放在多机上,需要有一个很好的哈希算法。到底如何把一堆单台机器很难执行的多个job水平分布在很多机器上,很麻烦。但是有了这个Chornous的Framework,事情就变得简单多了。
   
Scheduler/Scheduler Driver
它们俩区分度不是太大,有一些区分。Scheduler是做任务分配的,它从master上得到一个Offer的事件,拿到Offer后,决定到底接受这个Offer还是拒绝,接受这个Offer之后,把什么样的Task放在这个Offer上, Framework也开始占用这个Offer,这是Scheduler做的事情。Scheduler Driver其实是偏消息通信的那一部分,而Scheduler可定制化特别强,在代码里看到Scheduler其实是一个java的abstract glass,相当于一个interface,Framework自己去实现这么一个东西。如果想写一个Framework,其实大部分时间在如何写好一个Scheduler实现这一部分。
   
Executor/Executor Driver
如果Executor和Scheduler是对应的, Executor就是执行的这一部分。Mesos container这个Executor是Mesos自己提供的,不用写Executor就可以launch一个Docker的任务。但如果有一些自己的需求,就需要去实现一个Executor,比如七牛和乐视实现了一些Executor。

举例来说,处理图片、处理文件的Executor,偏向于这种小任务,写一个Executor来实现这个interface,最终打成一个二进制,放在一个URL里面。在Framework,slave就可以把这个Executor拉下来,然后执行这个Tasks。Executor是一个独立的二进制,它和master、和slave之间的通信是要支持RBC的。


Marathon


刚才已经提到了Marathon基本的功能,Marathon作为一个Long Running上一层的调度机制,为用户做了很多有意义的事情。单纯一个Mesos的话做不了什么,因为Task的力度特别小,Mesos的功能更偏重于资源的管理、资源的调度,Marathon更偏向于一些任务。

Marathon提出了几个概念,最核心的概念叫application,还有Group的application,是一组的application。一个application是什么呢?比如一个Rails的任务、NodeJS任务或者其它的一些任务,在部署的时候并不是部署一个Task,而是部署非常多的Task,application就是一组Task。这个Task在Marathon里面叫instance,可以选择scale down或者scale up这些instance,这些任务最终交给Mesos,Mesos调度到不同的slave上。

围绕着这个application,Marathon就提供了一些概念叫Group,Group是一组application。举例来说,在内部可能有很多的微服务,这些微服务达到同一个目标,比如说服务之间还有调用、还有依赖,这时去发一个Group application就比较好用。但实际工作中,因为生产级别的服务对稳定性的要求很高, Group之间其实假设服务和服务之间是有一定的依赖。
  
Marathon提供了一个有意思的feature—— rolling update。假如有APP的新版本上来,它可以通过一定的机制去发多个版本,而且可以多个版本共存。如果那个新版本没有问题的话,可以继续preceeding deployment。如果有问题的话,可以Rollback。这时有两个概念Deployment和Version,可以选定哪一个Version,想Rollback哪个Version。Deployment是每次update,每次更新、每次重新的Deployment、每次scale,都会在内部生成一个Deployment,和应用一对多有关。有趣的是Deployment之间是不可以重叠的,Deployment是一种部署排队的机制,Deployment不可以多个同时进行,既想update又想scale,会让Marathon崩溃。
  
Marathon scale和rolling update的功能都非常有用,比如新浪微博现在有一个大的事件,需要更多的Task顶上来,立刻 scale up,只要资源足够就可以无限多的Task生成。Rollback,如果有一个版本有问题,可以瞬间Rollback到以前一个健康的版本。
  
虽然Mesos对下面的资源做了一些抽象,但是有时候有一些倾向性,比如希望CPU使用率比较高的一些任务调度到CPU比较好的机器上,需要一种在调度上的倾向性来满足刚才的场景。很多调度器都有类似的功能,叫Constraints,比如一台主机的label,要把Task打到一组主机这样的Label上或者是Host name like,这是Marathon做的,Mesos不用做这类的事情。
  
Marathon的接口非常友好,都是HTTP的接口。Mesos的接口by design不是面向最终用户,所以它的接口并不是那么友好。马拉松的UI也非常漂亮,尤其是新版。


Mesos调度器Swan


最后介绍一下Swan(https://github.com/Dataman-Cloud/swan )这个项目,Swan是最近数人云做的一个Mesos的Framework,定位是做一个General Purpose Long Running Task的Framework。数人云使用马拉松较长时间,发现不太满足需求,比如很难做一些定制化,控制不住它的发展趋势。我们希望研发一款工具既有马拉松的功能又自主可控、添加一些想要的featur,具体的feature会在下文中逐一介绍。

我们希望这个通用性的Framework在任何情况下,服务不会受到影响。因为Mesos HA这方面已经做得很好,所以Framework不会是单点,首先Swan要支持HA,因为受到Swarmkit启发比较大, Swarmkit天生就是Raft协议,在一堆manager中只要有一个活的,就能健康的对外服务。
   
Marathon没怎么做服务发现,无非是把端口暴露出来,哪个任务在哪些IP和端口上,通过API的形式告诉给外面。Swan里内置服务发现,会有一个列表告诉外面哪些服务跑在哪些端口、哪些APP上。

DNS是服务发现的另一种。主流的一些Framework都把DNS这个功能放在了比较核心的位置,比如K8s里面的SkyNet,Mesos曾经以前有Mesos DNS,以及Swarmkit,Swarm的服务发现分为DNS Round Robin和IPVS两种,把DNS放在Swan这个模块里更加的可控。它不单是一个DNS,同时是一个DNS的代理。这样最终能实现的效果,在企业内部通过我们的DNS和用户的DNS来混搭,来达到一种Mesos内部和外部互相调用,在浏览器上既可以访问Mesos内部的东西又可以访问外面的东西,达到比较完美的效果。

Proxy,并不单是Proxy,还有负载均衡。最常见的Proxy的工具有HAProxy或者nginx。 HAProxy和nginx虽然很优秀、性能很好,缺点是可控性太差,很难控制它。HA可编程的能力很差,Nginx可编程的能力不错,新浪微博有一个项目叫upsync-module,非常优秀。之前评估过这个项目,发现集成这两个的难度很大。
  
我的分享就到这里,谢谢大家。

MesosCon D2 | Google系统构建的故事,Mesos之父登场

宁静胡同 发表了文章 • 0 个评论 • 107 次浏览 • 2016-11-23 14:29 • 来自相关话题

经历了干货满满的第一天,MesosCon Asia第二天的内容同样精彩,依旧是三个重量级 Keynote 开场:Mesos 的 Nested Container,Google系统构建、以及Mesos之父登台畅谈未来……小数已经迫不及待了,闲话少叙,我们快开始吧!

传送门:MesosCon第一天全记录

Support for Nested Containers, aka Pods, in Mesos








Pod 这个概念用在容器圈始于 Kubernetes,Mesos 也引入了类似的概念,Nested Container:通过 Container Executer 下再启动 Container 和 Task 来实现嵌套。

Mesos 的 Nested Container 支持任意级的嵌套,不仅可以复用现有的所有 isolators,还支持动态创建嵌套容器。








所有 Nested Container,或者说 Pod 中的容器 Cgroup 和 Net Namespace 都是共享的,但是 MNT Namespace 不共享,这样就能实现同一 Pod 中的容器可以通过 localhost 进行网络通信。








任意级嵌套是个很有意思的功能,通过这样的设计,可以方便为目标容器创建 Debug 子容器,并能保证整个设计的统一完整性。








之后,Yu Jie 通过 DC/OS 简单展示了使用 Unified Container 来创建 Nested Containers 的过程,包含了针对持久化卷的 producer-consumer 和针对网络联通性的 server-client 两个例子。

How to replace a Jet Engine of your System in-Flight








来自 Google 构建系统的分享,讲述了她们实现复杂在线分布式系统 Zero Downtime 迁移的心路历程。







Google 的体量之大即使是外人也能有所感觉,即使是它的构建系统,也不能接受有不可用的情况,所以 Zero Downtime 系统迁移是必经之路。








通过上图我们能简单的对新旧版本的架构有一个整体的认识。








做这样的大型系统的在线迁移,除了底层资源调度基础架构(Borg inside Google, or Mesos) 的支持以外,同样避免不了人的操作,因此就需要做好演练,总结出 checklist,这样能够避免多部门合作时大家因为疲惫或者兴奋而犯一些超级简单的错误。而且一定要有失败预案,一旦发现有问题,要能够明确回滚的步骤,这同样需要底层调度系统的支持。

Mesos + DC/OS, not Mesos versus DC/OS








Ben 花了 10 种的时间向大家介绍了下 Mesos 和来自美国的 DC/OS 的关系及未来的发展方向,肯定了 Mesos 作为 kernel 的作用,表达了围绕其建立起来的 DC/OS 。








Ben 为了解释 Mesos 和 DC/OS 的关系,列了未来 OPs 的挑战,而解决这些挑战的方式,就是在 Mesos 核心周围,建立起 DC/OS 这个完整的工具链。








Mesos 的优势还体现在数据处理和分析的框架应用上,然而如果只有 Mesos + DC/OS,也不能更好的满足这些方面的挑战,这样就引出了 DC/OS SDK。












Mesos DC/OS SDK 就像是操作系统中应用和 Kernel 交互的借口层一样,主要负责抽象应用生命周期管理,目标是使有状态任务能更简单的运行在 Mesos + DC/OS 之上。

除了这三个重量级 Keynote 之外,Day two 的其他 session 也是干货满满,比如同样来之 Mesosphere 的 “Writing Stateful Frameworks - Challenges and Solutions” 就展开讲解了 DC/OS SDK 如何能帮助到有状态服务。另外,如果你对 HA 感兴趣,就不应该错过来自 IBM 的 Mesos HA 去 zookeeper 的分享。“CNI: Onwards and Upwards” 详实的讲解和丰富的 Demo 将 Mesos Unified Container 关于网络的实现细节和未来发展规划都摊开了揉碎了放在你面前。


至此,为期两天的 Mesos Con Asia 杭州之行圆满结束。数人云一直坚持国内Mesos技术的落地与实践,也在大会上进行了演讲分享,视频请点击[“此处”](http://t.cn/RfXcKiR),实录小数会在之后为大家奉上,敬请期待:)

意犹未尽,不只是为技术,也为美丽的杭州,妙曼的西湖。 查看全部
经历了干货满满的第一天,MesosCon Asia第二天的内容同样精彩,依旧是三个重量级 Keynote 开场:Mesos 的 Nested Container,Google系统构建、以及Mesos之父登台畅谈未来……小数已经迫不及待了,闲话少叙,我们快开始吧!

传送门:MesosCon第一天全记录

Support for Nested Containers, aka Pods, in Mesos


1.jpg



Pod 这个概念用在容器圈始于 Kubernetes,Mesos 也引入了类似的概念,Nested Container:通过 Container Executer 下再启动 Container 和 Task 来实现嵌套。

Mesos 的 Nested Container 支持任意级的嵌套,不仅可以复用现有的所有 isolators,还支持动态创建嵌套容器。


2.jpg



所有 Nested Container,或者说 Pod 中的容器 Cgroup 和 Net Namespace 都是共享的,但是 MNT Namespace 不共享,这样就能实现同一 Pod 中的容器可以通过 localhost 进行网络通信。


3.jpg



任意级嵌套是个很有意思的功能,通过这样的设计,可以方便为目标容器创建 Debug 子容器,并能保证整个设计的统一完整性。


4.jpg



之后,Yu Jie 通过 DC/OS 简单展示了使用 Unified Container 来创建 Nested Containers 的过程,包含了针对持久化卷的 producer-consumer 和针对网络联通性的 server-client 两个例子。

How to replace a Jet Engine of your System in-Flight


5.jpg



来自 Google 构建系统的分享,讲述了她们实现复杂在线分布式系统 Zero Downtime 迁移的心路历程。


6.jpg


Google 的体量之大即使是外人也能有所感觉,即使是它的构建系统,也不能接受有不可用的情况,所以 Zero Downtime 系统迁移是必经之路。

7.jpg




通过上图我们能简单的对新旧版本的架构有一个整体的认识。


8.jpg



做这样的大型系统的在线迁移,除了底层资源调度基础架构(Borg inside Google, or Mesos) 的支持以外,同样避免不了人的操作,因此就需要做好演练,总结出 checklist,这样能够避免多部门合作时大家因为疲惫或者兴奋而犯一些超级简单的错误。而且一定要有失败预案,一旦发现有问题,要能够明确回滚的步骤,这同样需要底层调度系统的支持。

Mesos + DC/OS, not Mesos versus DC/OS


9.jpg



Ben 花了 10 种的时间向大家介绍了下 Mesos 和来自美国的 DC/OS 的关系及未来的发展方向,肯定了 Mesos 作为 kernel 的作用,表达了围绕其建立起来的 DC/OS 。

10.jpg




Ben 为了解释 Mesos 和 DC/OS 的关系,列了未来 OPs 的挑战,而解决这些挑战的方式,就是在 Mesos 核心周围,建立起 DC/OS 这个完整的工具链。



11.jpg


Mesos 的优势还体现在数据处理和分析的框架应用上,然而如果只有 Mesos + DC/OS,也不能更好的满足这些方面的挑战,这样就引出了 DC/OS SDK。

12.jpg


13.jpg



Mesos DC/OS SDK 就像是操作系统中应用和 Kernel 交互的借口层一样,主要负责抽象应用生命周期管理,目标是使有状态任务能更简单的运行在 Mesos + DC/OS 之上。

除了这三个重量级 Keynote 之外,Day two 的其他 session 也是干货满满,比如同样来之 Mesosphere 的 “Writing Stateful Frameworks - Challenges and Solutions” 就展开讲解了 DC/OS SDK 如何能帮助到有状态服务。另外,如果你对 HA 感兴趣,就不应该错过来自 IBM 的 Mesos HA 去 zookeeper 的分享。“CNI: Onwards and Upwards” 详实的讲解和丰富的 Demo 将 Mesos Unified Container 关于网络的实现细节和未来发展规划都摊开了揉碎了放在你面前。


至此,为期两天的 Mesos Con Asia 杭州之行圆满结束。数人云一直坚持国内Mesos技术的落地与实践,也在大会上进行了演讲分享,视频请点击[“此处”](http://t.cn/RfXcKiR),实录小数会在之后为大家奉上,敬请期待:)

意犹未尽,不只是为技术,也为美丽的杭州,妙曼的西湖。

数人云工程师手记 | MesosCon第一天全纪录

宁静胡同 发表了文章 • 0 个评论 • 93 次浏览 • 2016-11-23 14:23 • 来自相关话题

1月18日,杭州。
MesosCon Asia在凯越酒店隆重举行。中国联通、IBM、Dynatrace等公司先后进行了演讲,分享他们关于Mesos的技术实践。数人云程师第一时间整理出了精彩的演讲内容,让大家先睹为快。








Opening address








全球已经进行过 52 次的 Meetups;
3 次 MesosCon,前两次分别是在美国和欧洲;
越来越多的使用者和贡献者(过去一年超过 130% 的增长);
3名新加入的 committers,全部来自中国;








被各种各样的行业使用,包括传统行业,很多没有 IT 背景的行业认可了 Mesos;







Hybird-cloud, multi-cloud is the future!







Multi-tenancy is the future!

Embracing modern workloads without losing "IT"












IBM 希望通过中间层的控制来向多种 workload 提供统一的基于 Mesos 的资源管理;包括 Spark,K8s 以及 IBM Spectrum;








而且通过 IBM 的 Spark Session Scheduler 可以提供更好的 performance;







最后,还进行了一个很有意思的 live demo,Fantastic Icon Maker! 大家可以进去试一下,里面用到了 Mesos,Spark,Deep learning,GPU渲染等,还是有点儿意思的。

(Demo二维码见下图)







China Unicom Calls for DC/OS














中国联通的核心系统业务规模还是非常可观的;在网用户量 1.6 亿+, 日话单 80 亿+,日接口访问 2 亿+。








如此庞大的系统的容器化,可以想见必定困难重重,但是联通基本完成了它,并开始以平台的形式提供能力输出,形成自有的 IT 生态。

小结一下,联通DC/OS 后的收获:

* 性能,使用率有所提高;
* 需求上线效率提高;
* 故障事件率下降。

他们的总结心得,也非常值得分享给大家:

* 开源时代更要求有自主研发;
* 填坑只能需要多在这条路上走,谁走都算走,可以从别人那学习经验;
* 顺理业务和依赖要自己来;
* 认清了需要从软件开发组织形式、开发模式上去主动适应调整。

我认为最后一点非常重要,这个是很多甲方还没体会到,或者说还没认可的一点,联通之所以在容器化这条路上进步这么快,主动适应和调整是起到了至关重要的作用。

还在犹豫的,该抓紧了。


What happens when Containers Fail?








来自 APM 公司 Dynatrace,Founded in Austria back in 2005 拥有 >8000 customers across all industries;








他们提到了一个容器化或者微服务化之后,一个容器挂掉之后有可能会带来不可控的问题,类似 The Mushroom Cloud Effect;

{<16>}!(/content/images/2016/11/4-3.jpg)

因此,他们公司,可以提供容器时代,应用或者服务之间的可视化依赖关系,这样就很好的分析问题,也可以提前做更充分的测试;














从上图可以看出,他们对依赖的定义按层次可以分成:应用/服务/基础架构组件 三部分,有兴趣的同学可以留意后续放出的资料。

还有很多有意思的 session,包括 Unified Container,容器安全相关的技术点,以及 Mesos HTTP API 等等,还有来自 EMC 的 Mesos on ARM 里讲到的尝试在树莓派上编译 Mesos等等有趣的分享,这里就不展开一一介绍了,大家可以期待后续的内容。

##Shipping Mesos Cluster with Swarm

数人云CTO肖德时进行了50分钟的演讲,老肖表示讲high了停不住呀。小数就不多说,大家点击[“此处”](http://t.cn/RfXcKiR)看直播回放吧^_^









最后,来个Mesos大牛们在杭州的合影吧^_^ 查看全部

1月18日,杭州。
MesosCon Asia在凯越酒店隆重举行。中国联通、IBM、Dynatrace等公司先后进行了演讲,分享他们关于Mesos的技术实践。数人云程师第一时间整理出了精彩的演讲内容,让大家先睹为快。




1.jpg



Opening address


2.jpg



全球已经进行过 52 次的 Meetups;
3 次 MesosCon,前两次分别是在美国和欧洲;
越来越多的使用者和贡献者(过去一年超过 130% 的增长);
3名新加入的 committers,全部来自中国;


3.jpg



被各种各样的行业使用,包括传统行业,很多没有 IT 背景的行业认可了 Mesos;

4.jpg



Hybird-cloud, multi-cloud is the future!


5.jpg


Multi-tenancy is the future!

Embracing modern workloads without losing "IT"


2-6.jpg


2-7.jpg


IBM 希望通过中间层的控制来向多种 workload 提供统一的基于 Mesos 的资源管理;包括 Spark,K8s 以及 IBM Spectrum;


2-8.jpg



而且通过 IBM 的 Spark Session Scheduler 可以提供更好的 performance;

2-9.jpg



最后,还进行了一个很有意思的 live demo,Fantastic Icon Maker! 大家可以进去试一下,里面用到了 Mesos,Spark,Deep learning,GPU渲染等,还是有点儿意思的。

(Demo二维码见下图)

2-10.jpg



China Unicom Calls for DC/OS



3-11.jpg


3-12.jpg



中国联通的核心系统业务规模还是非常可观的;在网用户量 1.6 亿+, 日话单 80 亿+,日接口访问 2 亿+。


3-13.jpg



如此庞大的系统的容器化,可以想见必定困难重重,但是联通基本完成了它,并开始以平台的形式提供能力输出,形成自有的 IT 生态。

小结一下,联通DC/OS 后的收获:

* 性能,使用率有所提高;
* 需求上线效率提高;
* 故障事件率下降。

他们的总结心得,也非常值得分享给大家:

* 开源时代更要求有自主研发;
* 填坑只能需要多在这条路上走,谁走都算走,可以从别人那学习经验;
* 顺理业务和依赖要自己来;
* 认清了需要从软件开发组织形式、开发模式上去主动适应调整。

我认为最后一点非常重要,这个是很多甲方还没体会到,或者说还没认可的一点,联通之所以在容器化这条路上进步这么快,主动适应和调整是起到了至关重要的作用。

还在犹豫的,该抓紧了。


What happens when Containers Fail?


4-1.jpg



来自 APM 公司 Dynatrace,Founded in Austria back in 2005 拥有 >8000 customers across all industries;


4-2.jpg



他们提到了一个容器化或者微服务化之后,一个容器挂掉之后有可能会带来不可控的问题,类似 The Mushroom Cloud Effect;

{<16>}!(/content/images/2016/11/4-3.jpg)

因此,他们公司,可以提供容器时代,应用或者服务之间的可视化依赖关系,这样就很好的分析问题,也可以提前做更充分的测试;


4-4.jpg


4-5.jpg




从上图可以看出,他们对依赖的定义按层次可以分成:应用/服务/基础架构组件 三部分,有兴趣的同学可以留意后续放出的资料。

还有很多有意思的 session,包括 Unified Container,容器安全相关的技术点,以及 Mesos HTTP API 等等,还有来自 EMC 的 Mesos on ARM 里讲到的尝试在树莓派上编译 Mesos等等有趣的分享,这里就不展开一一介绍了,大家可以期待后续的内容。

##Shipping Mesos Cluster with Swarm

数人云CTO肖德时进行了50分钟的演讲,老肖表示讲high了停不住呀。小数就不多说,大家点击[“此处”](http://t.cn/RfXcKiR)看直播回放吧^_^

肖.jpg





最后,来个Mesos大牛们在杭州的合影吧^_^

合影1.jpg


合影2.jpg

三分天下,分久必合:IBM的Kubernetes on Mesos探索之路

宁静胡同 发表了文章 • 0 个评论 • 129 次浏览 • 2016-11-10 14:54 • 来自相关话题

今天是数人云容器三国演义Meetup嘉宾演讲实录第四弹。说完了各家容器技术的实战,那么最后来看容器技术的融合——IBM正在探索的一条道路。

我叫马达,名字很好记,挂的title是IBM软件架构师,但我更喜欢下面这个角色: kube-mesos社区负责人;我在Mesos和Kubernetes两个社区都有不同的贡献。国内我是较早一批进入Mesos社区的,2014年开始通过meetup认识了很多技术圈的朋友,后来由于公司的需要就转到了Kubernetes,目前在team里主要做的是Kubernetes on Mesos。
 
很多人对Kuberneteson Mesos有疑问,说这两个东西放在一起到底有没有价值。前段时间有人在微信群里问我是不是为了集成而集成,搞一个噱头,大家一起去玩这个事情。这方面我会讲一下,以及Kuberneteson Mesos现在已经有将近一年没有人维护了,所以现在我们接手以后有很多事情要做,包括后面的很多功能要完善。

kube-mesos历史
 
Kubernetes on Mesos,现在我一般是叫kube-mesos。Kubernetes on Mesos这个项目最早从2014年开始,从Kubernetes刚开始的时候,Mesosphere就投入精力把它们做一个集成。后来Mesosphere出了自己的DC/OS,就不再投入资源了。2015年的时候版本跟得很紧,从0.3一直到0.7十几个release,到了2016年最后一个版本release是0.7.2,到今年的1月份就很少release了。9月,IBM开始接手,因为IBM整个产品都是基于这个Kuberneteson Mesos为基础的。这时IBM把它重新定义成一个孵化器的项目,把它从Kubernetes Github里面拆出来,放到Kubernetes孵化项目里面。






9月,当我们跑Kuberneteson Mesos这个项目的时候也是得到了很大的支持,现在的Sponsor是Google的Tim,他主要会帮我们一起去review Kubernetes on Mesos后面的roadmap,以及什么时候升级为Kuberentes的顶级项目。现在有一个叫Champion的角色类,Champion这个角色来自红帽的David,他会和我们做一些daily的review,看一下process和一些BUG。这是我们现在在Github上的一个ID,所以现在我主要负责Kubernetes后面的一些roadmap,也希望大家一起去共享这个项目,因为后面有很多非常有意思的项目,不仅要改Kuberntes、Mesos,还有我们一些新的想法。下面是Github的地址 (https://github.com/kubernetes- ... work/ ),到Github可以找到相关的资料。

为什么kube-mesos?






为什么要做这样一个项目,把两个社区或者两个比较复杂的东西放在一起。大家看一个环境的时候,现在讨论最多的是容器,但真正到一个数据中心或者企业环境,你会发现其中会有各种各样的workload,Kubernetes on Mesos只是其中的一部分。在作业管理和应用管理这一层的话,比如跑大数据会希望用Spark;跑管理容器相关的时候,可以跑一些Kubernetes 、Marathon这样的功能。但这时候是分开的,不同的workload使用不同的框架。再往下一层的时候,这些workload,是可以把资源共享、可以把资源重新抽象出来。

这就是Mesos最开始提的事情,把资源重新抽象出来,抽象出一个资源池,有CPU、有memory。这也是为什么Mesos在描述自己的时候,它会说抽象出一个资源池,在Google的Omega文章里面,它也会提把Mesos定义为第二代调度的策略,两级的调度出来scheduling。Omega这个事,Google还没有实现,所以现在也无人提。

真正说容器、说Docker的时候,最早它只是一个运行环境,每一台机器上一个Docker agent,然后把机器提起来,负责一些起停监控等。我们把资源管理用Mesos抽象出来,上层的应用管理可以放Kubernetes,也可以放Marathon、Spark。一些用户已经搭建了环境,底层是Mesos,上面的容器化是跑Kubernetes,大数据跑Spark。Hadoop那些的话,我们当时是在测试Myriad项目的一些功能,有许多问题和经验,有机会可以聊一下。






容器基本都在PaaS这一层,IaaS那一层Openstack搞定所有的事情。Paas这一层抽象出来,就是是Mesos上面加Kubernetes,包括上面真正的运行环境加Docker。各个厂商当你做一个完整的solution,统一用户的管理、统一的界面,都是差不多的。做整个流程时,你不希望用户还去在意下面是跑Mesos还是Kubernetes,于是对外最后就把它抽象成业务的一个逻辑和一个业务的描述。






IBM从1992年的时候开始做自己的产品叫LSF,就是说在九几年的时候像PDS、SGE,早期的HPC, 网络计算基本上都属于这一期的。大家都比较像,workload的管理和资源管理都放在一起了。但等到2003年的时候,资源管理那一层,IBM在做新产品的时候资源管理层又做了一遍,而且是有这样的需求,一些大的银行用户里面LSF和Symphony两个是需要同时跑在一起的,而且由于它们业务上的问题,白天的时候大部分资源给Symphony这个产品,晚上的时候有一部分资源要给LSF,即另外一个产品。
 
中间资源的切换,如果是原来的话,只能去写脚本,把这个cluster一些agent重新提起来放在那边,但是下面如果把这个资源这层重新抽象出来的话,我们内部产品叫EGO,其实跟Mesos非常像,这也是为什么IBM在Mesos有很大的投入。包括我们这边有很多高级调度策略,像刚才说按时间的调度,包括一些资源的分配和资源的共享。
 
从2003年的时候,IBM就开始做这样相应的事情,资源管理是一层,上面的workload pattern是一层。放眼整个开源社区,我们发现Kubernetes对容器的管理这一方面做得更好一点,所以最后选的还是Kuberneteson Mesos整体的架构。当2006年我们在做DCOS类似Paas平台这样一个产品的时候,最终定出来的方案就是说Kubernetes on Mesos。可以看到整个产品的架构从零几年开始做,而且基本验证了至少现在是一个正确的方向。
 
待解决问题






Kuberneteson Mesos现在将近有一年没有再发布新的版本了,目前有很多问题。第一个,Kubernetes on Mesos这个项目到年底、明年年初最主要做这个项目就是要把整个refactor一下,最主要的原因是现在的Kuberneteson Mesos对Kubernetes的代码依赖非常严重。它集成的时候是把Kubernetes里面很多组件拿过来,在外面再包一下,它是代码级别的改造。我在9月份刚开始接受那个项目的时候,经常会有Kubernetes主干的人告诉我,我们这块有interface变了,你要赶紧去看一下,要不然可能就编译不过,问题是它的改动基本都是内部的interface,其实对我外部的像RESTful API这些东西是不需要变的。所以在这块最主要做的是要把它分离出来,跟Mesos、Kubernetes集成的这些interface和这些接口,我们都希望通过它的RESTful API来做。
 
这部分还有一个更大的topic,11月份的KubeCon与Google在讨论这个事情,Google前两天也有人在做——希望Kubernetes可以提供一种资源管理的功能,无论是它本身提供还是它提供资源管理这一层,希望Spark可以利用这样的一个功能,而不是说Spark再去写,希望做这样的集成。我们也是希望Kubernetes可以更友好的去支持资源管理这一层。基于之前的那些经验,我们会在社区里推动它,至少它对resource manager的支持,不仅仅是对Mesos的支持。因为我知道Horon work也在做Kubernetes on Yarn,就是说这个Yarn也是资源管理这一层,Yarn、Mesos包括我们内部的一些资源管理EGO, 很多都是属于空层这一层,所以Kubernetes把它定位成一个container管理的软件,下面是可以把它完全抽象出来,让它更好的接受资源管理这个东西。
 
就代码级别来看的话,其实Swarm对资源管理层支持得更好,因为它默认自己是需要有资源管理这一层的,它把自身Swarm和内部这个调度都重新写成了一个resources manager资源管理。虽然它没有Mesos强,但是跟Mesos是一样的,所以它很容易就接到Mesos里面去。但Kubernetes现在是不用做这样的事情,它把整个全都揉到一起,所以这在后续的KuberCon,我们也需要更多人去讨论,是希望它能把这个东西得抽象出来,而不是说我们自己再去搞这样的东西。
 
revocable resources在Mesos里面基本上是资源的借入借出。现在的revocable resources,Mesos只支持超频(Oversubscription),这个功能现在只是超频这个部分,但现在在跟Mesos的社区讨论的时候,我们希望做这种资源的共享和资源的抢占。所谓资源的共享,举一个例子,我们在跟用户去做大数据和long running service两个同时在跑的一个环境里面的时候,对于大数据的机器是预留下来的,Mesos里面用它的动态预留或者静态预留,应该是这部分的机器留在那儿了,因为这部分机器是相对来说比较好的,无论是网络还是存储。大数据跑起来经常会有一些数据的迁移,所以它的网络经常会被压得比较满,再把一些优先级别比较高的应用放在上面网络性能会比较差一点。但大数据的workload又不是时时的占满,经常会有一些空闲,所以也希望它预留下来的这一部分是可以借出去,借给Kubernetes一部分,Kubernetes在上面可以跑,比如跑一些测试,一些build,就跑这些其实优先级并没有那么高的应用,那么从大数据的资源池借来部分resource基本就变成了revocable resources。

但是现在Kubernetes并不支持这件事情,它并没有去描述哪些作业是可以跑在上面、哪些是不能跑在上面。因为借来这个resource也会被高优先级的资源抢占掉,有可能是被杀掉,所以像一些数据库、一些比较重要的Service是不能跑在上面的,因为你会跑一些低优先级的作业,这样只是说有更多的资源可以用。
 
当上面去跑两个framework的时候,你跑Kubernetes和Spark,你会发现它俩之间是需要互相访问一些数据的,有的时候是运行结果,有一些是中间的数据。我们希望可以用地址去寻址,但是Kubernetes的DNS基本上在Spark里面又可以跑,所以你这个时候最希望的是什么?Kubernetes的DNS跟Web的DNS可以通了,可以互相访问。这不光是DNS的事情,包括下面Spark的作业,因为我们在做propose的时候,Spark其实跑在Mesos上了,无论你的Spark master是通过Kubernetes把它拉起来还是自己手动提起来,至少作业的那部分是重头,作业是希望它们可以互相访问的,所以除了DNS可以互通,底层的network也是需要互通的。
 
与Mesos集成这部分是跟resource相关的,因为在Kubernetes里边现在有太多自己的namespace和Quota。Mesos还有一套,有自己的role和 Quota。现在社区里面在做支持一个framework注册多个role,用多个role的身份注册到Mesos上面,还在做层级的role,就像一个树状结构。因为这块有一些需求是这样的,在做部门的时候, Mesos做下层资源管理时,大部分时间你是按部门的层级下来的。现在有很多人在做了,最后就变成部门一下划线,子部门一,然后再下划线,以这种形式做成一个role,但是这种更多的是做成一个tree,而且每个树状结构彼此之间是要再做一层调度的,再做一层DNS的算法调度。

无论如何,现在Mesos还不支持那么多,但是现在Kubernetes自己有一套,Mesos自己也有一套,做起来会比较麻烦,你会发现Mesos给你分配了,有可能Kubernetes限制一下,你就分不出去了;或者说Kubernetes你感觉可以分了,但是你到那边去又调不出来,所以这两个是需要统一的。但统一有一个问题,Kubernetes做这件事情的时候,它并没有认为这些事情应该是需要resourcemanager或者cloud provide参与的,这个事情也是需要在社区propose,它的Quota和namespace需要参考下面的resourcemanager资源分配的那一层。
 
Kubernetes在做scheduler,其实这只是一个特例的case,特例的case是需要有一些加强的,包括Mesos。Kuberneteson Mesos,Kubernetes本身可以有service affinity,包括它自己可以去选择node selector等等功能,但是这些信息Mesos是不知道的,因为Mesos发offer的时候,它只管自己的事,比如说我有两个framework,可能那个资源换过来以后能达到更好的效果,但Mesos不知道这事,所以Mesos这块本身需要加强,Kubernetes需要哪些resource,Mesos应该知道的。分出来了以后,Kubernetes也有一层的调度,如何来更好的做这样的事情。最终会变成Mesos要两层的调度:第一层,Mesos做一层,然后资源调度尽量的分出,尽量大家都匹配好;第二层,再交给Kubernetes去做这样的调度。






图中标红的这部分,现在去下这个包,装下来的时候,你会看到,这个东西它改了,scheduler它改了,它还有一个executor,这个executor下面还有一个minion进程,然后再去起这两个子进程。而Kubernetes也改了,它用下面Kubernetespackage的包来做,不用那个command了,它重新改了command。唯一没改的就是API和proxy。但是当refactor以后,我们希望这两个地方都不要改了,我们真正release的时候只有一个scheduler去做这个资源的交互。只有executor来做这样的事情,其它的事情还是希望走它原来的逻辑来做。
 
这其中对Kubernetes本身是有一些变化的,是需要跟Kubernetes去做这样的事情,因为只有单独这个项目想把它做得那么流畅的话,不太现实。最主要的原因是Kubernetes现在自己并没有完全的去接受,并没有完全去把这个东西做成一个插件。虽然它的scheduler已经把它放到plugin里面,但它现在做得也并不是特别好。在后续的工作里面,借着子社区的建设,我们也会逐渐希望Kubernetes把这个底层的资源调度做得更好,而不是像现在这样所有都攒在一起。Kubernetes在资源管理这一层,资源管理像Mesosresource manager这样的一层,它如果两边都做,不见得能做得那么好。

我们现在做Kubernetes、做上层的时候,更在意的是它的功能。Kubernetes在announce一个新版本的时候,1.4去测10万还是几万请求压力时,它强调的一是请求不停,service不停,它并没有强调资源的调度是否OK。那个只是service的一部分,因为如果在上面加一个Spark、加一个其它的大数据上的东西,Mesos也有问题,Mesos短作业做得特不是别好,性能有时候上不来,你需要把scheduler inverval调得非常低,比如调到五百毫秒以内才可以去用一用,社区也有提这个事。






现在我们在做revocable resource时也有问题,比如Kubernetes跟其它的framework去交互,集成的时候Mesos下面走executor,现在所有的Kubernetes都在一起的,你如果去借了资源的话,你有可能revocable resource和regular resource都放在同一个Kubernetes上跑。但是Mesos为了能够完全清理所有的东西,它杀的时候直接把这东西全杀了,把executor下面所有的东西都杀掉了。当去杀这个revocable resource的时候,你会发现下面有可能顺带的把那些你不想杀的东西都杀掉了,把regular resource杀掉了。

现在我还没有最终的解决方案,办法之一是起两个Kubernetes。但是Kubernetes设计的时候,它希望你一个节点去起一个东西,不要起那么多。revocable resource这块到底该如何做大家可以一起讨论一下,因为Mesos有自己的一套策略,Kubernetes也有自己的策略。我们也在跟Mesos社区提这个事情,要提供一个机制去杀task,如果task执行不了,再去杀executor。但是这个项目貌似并没有特别高的量级,我们也在想办法要么去改Mesos、要么去改Kubernetes,让它把这块做得更好。毕竟如果误杀,整个功能就没有特别大的意义了。其实作业上经常会有混合的形式。
 
现在Kubernetes有这么多namespace,该怎么办?Mesos一直想做multiple role,从去年年底、今年年初design document就已经出来了,但是一直没做。它的功能是把Kubernetes作为一个frameworks,它可以role1、role2、role3这三个role注册到Mesos里面,Mesos里面会根据它自己现有DRF相对三个role来分配资源。往上对应的话,有可能role1就对应namespace1,role2就对应amespace2,role3是amespace3,这样跟Kubernetes就可能对得起来。比如它的Quota是管理文件这些事情,它的资源可以跟Mesos的Quota,上面这两个可以通起来的。






这也是我们一直在想做的事情,Mesos和Kuberentes的统一资源管理,希望它把multiplerole做出来。最后你会发现web interface主要是从Kubernetes进来,比如创建一个interface,Kubernetes里面会有一个interface,下面底层是紧接着Mesos带着一个role,所以所有资源的管理都可以穿得起来。但是现在是变成这样了,Kubernetes是以一个role分到Mesos上面,然后在里面自己再去做。这样其实相当于把资源管理分开了,Kubernetes自己管一层,Mesos自己再管一层,最好还是希望Mesos可以去把整个所有的资源管理都管到一块去。
 







后面是一些细节,一个是scheduler enhancement,因为一旦引入了两级调度,如果还是跟原来一样其实没有任何意义,像K8S service这些事情现在都做得不是很好。Kuberneteson Mesos里面会有很多像like,像constraint,比较像Marathon的一些概念在里边,这并不是一个很好的事情,Kubernetes本身就应该有Kubernetes自己的东西在里面。另一个像对资源的管理和这些Policy,像它动态预留或者静态预留的一些资源,包括它对Quoto的管理,现在也是希望Kubernetes可以去完全支持,而不是自己再来一套。
 
最后,这是需要跟Mesos一起去work的,一旦有了Service,一旦有了node selector,、希望Mesos能够知道这件事情,然后在做调度的时候也考虑这件事情,而不是盲目的分,分完了半天不能用,再还回去,因为想用那个节点有可能别人已经用了。并不是所有人都按套路出牌,说没有这个level就不用了,这个事情需要Mesos来统一控制的。这也是为什么希望有一个资源管理层,可以控制所有的resource。
 
网络这一层,当你去架到大数据架到longrunning framework以后,像DNS、network连接,底层是要把它打通的。否则有很多case无法运行,比如一些Spark的数据要连到K8S里面,它永远是通过K8S ingress resource这些东西往上push。
 
kube-mesos时间表






这是一个大概的时间表,在10月底或者11月初,希望Kuberneteson Mesos在新的code branch可以release版本,延续它之前的版本叫0.7。这个版本大概会留半年到一年。到2016年底、2017年初的时候,计划把refactor这个事情做完,我们现在最主要的事情避免这个项目对Kubernetes本身代码级别的依赖太强,希望通过interface、API搞定这件事情。到2017年的时候,刚才提到的一些主要的feature,像revocable resource以及前期的资源调度,会把它们加进去。

在2017年一季度应该会有一个0.9的release。在2017年最主要做的事情是production,production不是跑两个测试就是production,IBM有一个基于Kubernetes on Mesos的产品,基于产品也会做system test,做一种longivity test,大概一百台机器跑一个月,所以会以产品的形式来release。当它们都做完了以后,我们才会说Kubernetes on Mesos1.0可以上production。那个时候如果大家有兴趣的话可以去试一下,有很多的公司也想把两个不同的workload、公司内部所有的资源统一在一起,上面运行不同的workload。
 
希望大家多到社区贡献,刚开始是有很多讨论都可以把它involve进来,因为到后面项目比较多的时候有可能有一些miss。谢谢大家! 查看全部

今天是数人云容器三国演义Meetup嘉宾演讲实录第四弹。说完了各家容器技术的实战,那么最后来看容器技术的融合——IBM正在探索的一条道路。



我叫马达,名字很好记,挂的title是IBM软件架构师,但我更喜欢下面这个角色: kube-mesos社区负责人;我在Mesos和Kubernetes两个社区都有不同的贡献。国内我是较早一批进入Mesos社区的,2014年开始通过meetup认识了很多技术圈的朋友,后来由于公司的需要就转到了Kubernetes,目前在team里主要做的是Kubernetes on Mesos。
 
很多人对Kuberneteson Mesos有疑问,说这两个东西放在一起到底有没有价值。前段时间有人在微信群里问我是不是为了集成而集成,搞一个噱头,大家一起去玩这个事情。这方面我会讲一下,以及Kuberneteson Mesos现在已经有将近一年没有人维护了,所以现在我们接手以后有很多事情要做,包括后面的很多功能要完善。

kube-mesos历史
 
Kubernetes on Mesos,现在我一般是叫kube-mesos。Kubernetes on Mesos这个项目最早从2014年开始,从Kubernetes刚开始的时候,Mesosphere就投入精力把它们做一个集成。后来Mesosphere出了自己的DC/OS,就不再投入资源了。2015年的时候版本跟得很紧,从0.3一直到0.7十几个release,到了2016年最后一个版本release是0.7.2,到今年的1月份就很少release了。9月,IBM开始接手,因为IBM整个产品都是基于这个Kuberneteson Mesos为基础的。这时IBM把它重新定义成一个孵化器的项目,把它从Kubernetes Github里面拆出来,放到Kubernetes孵化项目里面。

Mesos_Meetup0002.jpg


9月,当我们跑Kuberneteson Mesos这个项目的时候也是得到了很大的支持,现在的Sponsor是Google的Tim,他主要会帮我们一起去review Kubernetes on Mesos后面的roadmap,以及什么时候升级为Kuberentes的顶级项目。现在有一个叫Champion的角色类,Champion这个角色来自红帽的David,他会和我们做一些daily的review,看一下process和一些BUG。这是我们现在在Github上的一个ID,所以现在我主要负责Kubernetes后面的一些roadmap,也希望大家一起去共享这个项目,因为后面有很多非常有意思的项目,不仅要改Kuberntes、Mesos,还有我们一些新的想法。下面是Github的地址 (https://github.com/kubernetes- ... work/ ),到Github可以找到相关的资料。

为什么kube-mesos?

Mesos_Meetup0003.jpg


为什么要做这样一个项目,把两个社区或者两个比较复杂的东西放在一起。大家看一个环境的时候,现在讨论最多的是容器,但真正到一个数据中心或者企业环境,你会发现其中会有各种各样的workload,Kubernetes on Mesos只是其中的一部分。在作业管理和应用管理这一层的话,比如跑大数据会希望用Spark;跑管理容器相关的时候,可以跑一些Kubernetes 、Marathon这样的功能。但这时候是分开的,不同的workload使用不同的框架。再往下一层的时候,这些workload,是可以把资源共享、可以把资源重新抽象出来。

这就是Mesos最开始提的事情,把资源重新抽象出来,抽象出一个资源池,有CPU、有memory。这也是为什么Mesos在描述自己的时候,它会说抽象出一个资源池,在Google的Omega文章里面,它也会提把Mesos定义为第二代调度的策略,两级的调度出来scheduling。Omega这个事,Google还没有实现,所以现在也无人提。

真正说容器、说Docker的时候,最早它只是一个运行环境,每一台机器上一个Docker agent,然后把机器提起来,负责一些起停监控等。我们把资源管理用Mesos抽象出来,上层的应用管理可以放Kubernetes,也可以放Marathon、Spark。一些用户已经搭建了环境,底层是Mesos,上面的容器化是跑Kubernetes,大数据跑Spark。Hadoop那些的话,我们当时是在测试Myriad项目的一些功能,有许多问题和经验,有机会可以聊一下。

Mesos_Meetup0004.jpg


容器基本都在PaaS这一层,IaaS那一层Openstack搞定所有的事情。Paas这一层抽象出来,就是是Mesos上面加Kubernetes,包括上面真正的运行环境加Docker。各个厂商当你做一个完整的solution,统一用户的管理、统一的界面,都是差不多的。做整个流程时,你不希望用户还去在意下面是跑Mesos还是Kubernetes,于是对外最后就把它抽象成业务的一个逻辑和一个业务的描述。

Mesos_Meetup0005.jpg


IBM从1992年的时候开始做自己的产品叫LSF,就是说在九几年的时候像PDS、SGE,早期的HPC, 网络计算基本上都属于这一期的。大家都比较像,workload的管理和资源管理都放在一起了。但等到2003年的时候,资源管理那一层,IBM在做新产品的时候资源管理层又做了一遍,而且是有这样的需求,一些大的银行用户里面LSF和Symphony两个是需要同时跑在一起的,而且由于它们业务上的问题,白天的时候大部分资源给Symphony这个产品,晚上的时候有一部分资源要给LSF,即另外一个产品。
 
中间资源的切换,如果是原来的话,只能去写脚本,把这个cluster一些agent重新提起来放在那边,但是下面如果把这个资源这层重新抽象出来的话,我们内部产品叫EGO,其实跟Mesos非常像,这也是为什么IBM在Mesos有很大的投入。包括我们这边有很多高级调度策略,像刚才说按时间的调度,包括一些资源的分配和资源的共享。
 
从2003年的时候,IBM就开始做这样相应的事情,资源管理是一层,上面的workload pattern是一层。放眼整个开源社区,我们发现Kubernetes对容器的管理这一方面做得更好一点,所以最后选的还是Kuberneteson Mesos整体的架构。当2006年我们在做DCOS类似Paas平台这样一个产品的时候,最终定出来的方案就是说Kubernetes on Mesos。可以看到整个产品的架构从零几年开始做,而且基本验证了至少现在是一个正确的方向。
 
待解决问题

Mesos_Meetup0006.jpg


Kuberneteson Mesos现在将近有一年没有再发布新的版本了,目前有很多问题。第一个,Kubernetes on Mesos这个项目到年底、明年年初最主要做这个项目就是要把整个refactor一下,最主要的原因是现在的Kuberneteson Mesos对Kubernetes的代码依赖非常严重。它集成的时候是把Kubernetes里面很多组件拿过来,在外面再包一下,它是代码级别的改造。我在9月份刚开始接受那个项目的时候,经常会有Kubernetes主干的人告诉我,我们这块有interface变了,你要赶紧去看一下,要不然可能就编译不过,问题是它的改动基本都是内部的interface,其实对我外部的像RESTful API这些东西是不需要变的。所以在这块最主要做的是要把它分离出来,跟Mesos、Kubernetes集成的这些interface和这些接口,我们都希望通过它的RESTful API来做。
 
这部分还有一个更大的topic,11月份的KubeCon与Google在讨论这个事情,Google前两天也有人在做——希望Kubernetes可以提供一种资源管理的功能,无论是它本身提供还是它提供资源管理这一层,希望Spark可以利用这样的一个功能,而不是说Spark再去写,希望做这样的集成。我们也是希望Kubernetes可以更友好的去支持资源管理这一层。基于之前的那些经验,我们会在社区里推动它,至少它对resource manager的支持,不仅仅是对Mesos的支持。因为我知道Horon work也在做Kubernetes on Yarn,就是说这个Yarn也是资源管理这一层,Yarn、Mesos包括我们内部的一些资源管理EGO, 很多都是属于空层这一层,所以Kubernetes把它定位成一个container管理的软件,下面是可以把它完全抽象出来,让它更好的接受资源管理这个东西。
 
就代码级别来看的话,其实Swarm对资源管理层支持得更好,因为它默认自己是需要有资源管理这一层的,它把自身Swarm和内部这个调度都重新写成了一个resources manager资源管理。虽然它没有Mesos强,但是跟Mesos是一样的,所以它很容易就接到Mesos里面去。但Kubernetes现在是不用做这样的事情,它把整个全都揉到一起,所以这在后续的KuberCon,我们也需要更多人去讨论,是希望它能把这个东西得抽象出来,而不是说我们自己再去搞这样的东西。
 
revocable resources在Mesos里面基本上是资源的借入借出。现在的revocable resources,Mesos只支持超频(Oversubscription),这个功能现在只是超频这个部分,但现在在跟Mesos的社区讨论的时候,我们希望做这种资源的共享和资源的抢占。所谓资源的共享,举一个例子,我们在跟用户去做大数据和long running service两个同时在跑的一个环境里面的时候,对于大数据的机器是预留下来的,Mesos里面用它的动态预留或者静态预留,应该是这部分的机器留在那儿了,因为这部分机器是相对来说比较好的,无论是网络还是存储。大数据跑起来经常会有一些数据的迁移,所以它的网络经常会被压得比较满,再把一些优先级别比较高的应用放在上面网络性能会比较差一点。但大数据的workload又不是时时的占满,经常会有一些空闲,所以也希望它预留下来的这一部分是可以借出去,借给Kubernetes一部分,Kubernetes在上面可以跑,比如跑一些测试,一些build,就跑这些其实优先级并没有那么高的应用,那么从大数据的资源池借来部分resource基本就变成了revocable resources。

但是现在Kubernetes并不支持这件事情,它并没有去描述哪些作业是可以跑在上面、哪些是不能跑在上面。因为借来这个resource也会被高优先级的资源抢占掉,有可能是被杀掉,所以像一些数据库、一些比较重要的Service是不能跑在上面的,因为你会跑一些低优先级的作业,这样只是说有更多的资源可以用。
 
当上面去跑两个framework的时候,你跑Kubernetes和Spark,你会发现它俩之间是需要互相访问一些数据的,有的时候是运行结果,有一些是中间的数据。我们希望可以用地址去寻址,但是Kubernetes的DNS基本上在Spark里面又可以跑,所以你这个时候最希望的是什么?Kubernetes的DNS跟Web的DNS可以通了,可以互相访问。这不光是DNS的事情,包括下面Spark的作业,因为我们在做propose的时候,Spark其实跑在Mesos上了,无论你的Spark master是通过Kubernetes把它拉起来还是自己手动提起来,至少作业的那部分是重头,作业是希望它们可以互相访问的,所以除了DNS可以互通,底层的network也是需要互通的。
 
与Mesos集成这部分是跟resource相关的,因为在Kubernetes里边现在有太多自己的namespace和Quota。Mesos还有一套,有自己的role和 Quota。现在社区里面在做支持一个framework注册多个role,用多个role的身份注册到Mesos上面,还在做层级的role,就像一个树状结构。因为这块有一些需求是这样的,在做部门的时候, Mesos做下层资源管理时,大部分时间你是按部门的层级下来的。现在有很多人在做了,最后就变成部门一下划线,子部门一,然后再下划线,以这种形式做成一个role,但是这种更多的是做成一个tree,而且每个树状结构彼此之间是要再做一层调度的,再做一层DNS的算法调度。

无论如何,现在Mesos还不支持那么多,但是现在Kubernetes自己有一套,Mesos自己也有一套,做起来会比较麻烦,你会发现Mesos给你分配了,有可能Kubernetes限制一下,你就分不出去了;或者说Kubernetes你感觉可以分了,但是你到那边去又调不出来,所以这两个是需要统一的。但统一有一个问题,Kubernetes做这件事情的时候,它并没有认为这些事情应该是需要resourcemanager或者cloud provide参与的,这个事情也是需要在社区propose,它的Quota和namespace需要参考下面的resourcemanager资源分配的那一层。
 
Kubernetes在做scheduler,其实这只是一个特例的case,特例的case是需要有一些加强的,包括Mesos。Kuberneteson Mesos,Kubernetes本身可以有service affinity,包括它自己可以去选择node selector等等功能,但是这些信息Mesos是不知道的,因为Mesos发offer的时候,它只管自己的事,比如说我有两个framework,可能那个资源换过来以后能达到更好的效果,但Mesos不知道这事,所以Mesos这块本身需要加强,Kubernetes需要哪些resource,Mesos应该知道的。分出来了以后,Kubernetes也有一层的调度,如何来更好的做这样的事情。最终会变成Mesos要两层的调度:第一层,Mesos做一层,然后资源调度尽量的分出,尽量大家都匹配好;第二层,再交给Kubernetes去做这样的调度。

Mesos_Meetup0007.jpg


图中标红的这部分,现在去下这个包,装下来的时候,你会看到,这个东西它改了,scheduler它改了,它还有一个executor,这个executor下面还有一个minion进程,然后再去起这两个子进程。而Kubernetes也改了,它用下面Kubernetespackage的包来做,不用那个command了,它重新改了command。唯一没改的就是API和proxy。但是当refactor以后,我们希望这两个地方都不要改了,我们真正release的时候只有一个scheduler去做这个资源的交互。只有executor来做这样的事情,其它的事情还是希望走它原来的逻辑来做。
 
这其中对Kubernetes本身是有一些变化的,是需要跟Kubernetes去做这样的事情,因为只有单独这个项目想把它做得那么流畅的话,不太现实。最主要的原因是Kubernetes现在自己并没有完全的去接受,并没有完全去把这个东西做成一个插件。虽然它的scheduler已经把它放到plugin里面,但它现在做得也并不是特别好。在后续的工作里面,借着子社区的建设,我们也会逐渐希望Kubernetes把这个底层的资源调度做得更好,而不是像现在这样所有都攒在一起。Kubernetes在资源管理这一层,资源管理像Mesosresource manager这样的一层,它如果两边都做,不见得能做得那么好。

我们现在做Kubernetes、做上层的时候,更在意的是它的功能。Kubernetes在announce一个新版本的时候,1.4去测10万还是几万请求压力时,它强调的一是请求不停,service不停,它并没有强调资源的调度是否OK。那个只是service的一部分,因为如果在上面加一个Spark、加一个其它的大数据上的东西,Mesos也有问题,Mesos短作业做得特不是别好,性能有时候上不来,你需要把scheduler inverval调得非常低,比如调到五百毫秒以内才可以去用一用,社区也有提这个事。

Mesos_Meetup0008.jpg


现在我们在做revocable resource时也有问题,比如Kubernetes跟其它的framework去交互,集成的时候Mesos下面走executor,现在所有的Kubernetes都在一起的,你如果去借了资源的话,你有可能revocable resource和regular resource都放在同一个Kubernetes上跑。但是Mesos为了能够完全清理所有的东西,它杀的时候直接把这东西全杀了,把executor下面所有的东西都杀掉了。当去杀这个revocable resource的时候,你会发现下面有可能顺带的把那些你不想杀的东西都杀掉了,把regular resource杀掉了。

现在我还没有最终的解决方案,办法之一是起两个Kubernetes。但是Kubernetes设计的时候,它希望你一个节点去起一个东西,不要起那么多。revocable resource这块到底该如何做大家可以一起讨论一下,因为Mesos有自己的一套策略,Kubernetes也有自己的策略。我们也在跟Mesos社区提这个事情,要提供一个机制去杀task,如果task执行不了,再去杀executor。但是这个项目貌似并没有特别高的量级,我们也在想办法要么去改Mesos、要么去改Kubernetes,让它把这块做得更好。毕竟如果误杀,整个功能就没有特别大的意义了。其实作业上经常会有混合的形式。
 
现在Kubernetes有这么多namespace,该怎么办?Mesos一直想做multiple role,从去年年底、今年年初design document就已经出来了,但是一直没做。它的功能是把Kubernetes作为一个frameworks,它可以role1、role2、role3这三个role注册到Mesos里面,Mesos里面会根据它自己现有DRF相对三个role来分配资源。往上对应的话,有可能role1就对应namespace1,role2就对应amespace2,role3是amespace3,这样跟Kubernetes就可能对得起来。比如它的Quota是管理文件这些事情,它的资源可以跟Mesos的Quota,上面这两个可以通起来的。

Mesos_Meetup0009.jpg


这也是我们一直在想做的事情,Mesos和Kuberentes的统一资源管理,希望它把multiplerole做出来。最后你会发现web interface主要是从Kubernetes进来,比如创建一个interface,Kubernetes里面会有一个interface,下面底层是紧接着Mesos带着一个role,所以所有资源的管理都可以穿得起来。但是现在是变成这样了,Kubernetes是以一个role分到Mesos上面,然后在里面自己再去做。这样其实相当于把资源管理分开了,Kubernetes自己管一层,Mesos自己再管一层,最好还是希望Mesos可以去把整个所有的资源管理都管到一块去。
 


Mesos_Meetup0010.jpg


后面是一些细节,一个是scheduler enhancement,因为一旦引入了两级调度,如果还是跟原来一样其实没有任何意义,像K8S service这些事情现在都做得不是很好。Kuberneteson Mesos里面会有很多像like,像constraint,比较像Marathon的一些概念在里边,这并不是一个很好的事情,Kubernetes本身就应该有Kubernetes自己的东西在里面。另一个像对资源的管理和这些Policy,像它动态预留或者静态预留的一些资源,包括它对Quoto的管理,现在也是希望Kubernetes可以去完全支持,而不是自己再来一套。
 
最后,这是需要跟Mesos一起去work的,一旦有了Service,一旦有了node selector,、希望Mesos能够知道这件事情,然后在做调度的时候也考虑这件事情,而不是盲目的分,分完了半天不能用,再还回去,因为想用那个节点有可能别人已经用了。并不是所有人都按套路出牌,说没有这个level就不用了,这个事情需要Mesos来统一控制的。这也是为什么希望有一个资源管理层,可以控制所有的resource。
 
网络这一层,当你去架到大数据架到longrunning framework以后,像DNS、network连接,底层是要把它打通的。否则有很多case无法运行,比如一些Spark的数据要连到K8S里面,它永远是通过K8S ingress resource这些东西往上push。
 
kube-mesos时间表

Mesos_Meetup0011.jpg


这是一个大概的时间表,在10月底或者11月初,希望Kuberneteson Mesos在新的code branch可以release版本,延续它之前的版本叫0.7。这个版本大概会留半年到一年。到2016年底、2017年初的时候,计划把refactor这个事情做完,我们现在最主要的事情避免这个项目对Kubernetes本身代码级别的依赖太强,希望通过interface、API搞定这件事情。到2017年的时候,刚才提到的一些主要的feature,像revocable resource以及前期的资源调度,会把它们加进去。

在2017年一季度应该会有一个0.9的release。在2017年最主要做的事情是production,production不是跑两个测试就是production,IBM有一个基于Kubernetes on Mesos的产品,基于产品也会做system test,做一种longivity test,大概一百台机器跑一个月,所以会以产品的形式来release。当它们都做完了以后,我们才会说Kubernetes on Mesos1.0可以上production。那个时候如果大家有兴趣的话可以去试一下,有很多的公司也想把两个不同的workload、公司内部所有的资源统一在一起,上面运行不同的workload。
 
希望大家多到社区贡献,刚开始是有很多讨论都可以把它involve进来,因为到后面项目比较多的时候有可能有一些miss。谢谢大家!