云计算容器服务该何去何从

标签：openstack   docker   云计算   开源项目   paas   

容器技术最近很火，各家项目纷纷提出自己的支持方案，比如 OpenStack、CF、Mesos，以及一堆本身就基于容器的平台方案，更是跟容器技术脱不开关系。

容器是个啥？它不是虚拟机这样单纯的底层虚拟化，也不是纯应用，它恰好位于两者之间，位置极其重要。简直就像是 IP 协议层一样，无论自顶向下还是自底向上都无法绕开。

这也直接导致了暧昧已久的 IaaS 领域和 PaaS 领域正式开始正面的冲突。

在 IaaS 工程师们看来，做 PaaS 无非就是提供几个应用模板嘛，原来虚机不好做，现在有了 Docker，瞬间给你把服务整起来。更别提还有最近出来搅局的 hyper，虚机号称要跟容器比性能，那原来熟悉虚机的工程师可是太喜欢了。

而在 PaaS 工程师们看来，IaaS 就该老老实实地做底层物理资源给抽象成虚拟资源的事。原来底层都是虚机的时候，感觉好复杂，什么 SR-IOV，Libvirt/KVM，SDN，Overlay，Ceph……搞 PaaS 的人一般看不懂。而现在有了一堆现成提供 Docker 的容器平台，再往上就是应用了，都是做软件的人可以做的事情了，所以以后其实 IaaS 就没那么关键了。

这些讨论就像当年的单内核和微内核之争一样，是不光涉及到技术，还涉及到模式的关键战役。

可以说，看起来现在已经到了一个很关键的节骨眼上，中间这一层的设计将决定未来至少十年内云计算产业的形态。

当前状况

姑且放下这些争论，我们来看一下 IaaS 领域的 Top 开源项目 OpenStack 现在是怎么对待容器的。

目前有三种方案：

• Nova-Docker：把容器作为虚机管起来。基本上其它组件都不需要动。唯一的问题就是容器毕竟不是虚机，比如需要提供一些额外的参数支持啦，需要引入组的概念啦，需要性能的优化啦。这导致玩 PaaS 的人很不喜欢。
• Heat Docker Driver：用 Heat 来管容器。Heat 大家都知道，是个十分灵活且强大的解释引擎，理论上 Docker 需要的支持它都能有。唯一的问题是 Heat 毕竟是个解释引擎，它本质上还是要基于其它服务提供的 API。由于不是个运维引擎，导致运行时的管理没法保障，比如自动的资源调度啊，网络功能啊，等等。如果这些都做了，那就等于在更高一层上重复发明轮子了。
• Magnum：玩容器的人看问题当然基本上都是从应用层往上开始考虑。一帮人兴冲冲跑去 Nova 项目谈，应该怎么支持基于容器的 DevOps 啊，应用模板啊，Nova 组一帮做系统的人就傻了，这事我们咋能干？这分明是 PaaS 该做的事情。但架不住大家都觉得 Docker 很火啊，我们肯定还是要玩点花样的，于是一个新的项目诞生了。但玩应用的人毕竟不懂系统，调研了下，发现现在能管理 Docker 的开源方案还真有几个，比如 Swarm 和 Kubernetes。太好了，那么，怎么把 Swarm 和 Kubernetes 这样的 PaaS 平台给集成到 OpenStack 这样的 IaaS 平台上呢？这个听起来好像也不懂唉，有人又想起 Heat 来了，一拍脑袋，可以先拿 Heat 来装一套啊。每次需要的时候就调个 Heat 命令，动态的装一套。所有问题看起来都解决了，皆大欢喜啊，真是皆大欢喜！

就这样，最为关键的容器服务提供这一层反而有意无意的被大家忽略了。

思考云计算

某位名人说过，我之所以能看得远，是因为站在了前人的肩膀上。

让我们抛开系统和应用之争，姑且也大胆地站在前人的肩膀上来重新发明轮子。

首先还是要忍不住重复强调，信息技术的领域最为核心的思想就是分层和抽象。历史上，在不同位置进行分层和抽象，诞生了小型机，诞生了处理器，诞生了编程语言，诞生了 Web 服务，诞生了云计算……

抛开 IaaS，抛开 PaaS，云计算到底要提供啥？这个问题大家都知道，是服务。

啥叫服务？用户需要操作系统，可以直接给你一个；用户需要一个运行环境，可以直接给你一个；用户需要一套软件，也可以直接给你一个；用户需要一套方案，这个目前还没法直接给你一个，属于外包公司的业务。

那么，对于云平台的设计者来说，就是要提供这些不同层次的服务给用户，这才有了所谓的 IaaS 和 PaaS。所以，要记住，各种 XaaS 是呈献给用户的服务层次的不同，根本不是设计层次和技术方案的不同。

就好比你买了一个手机，可以玩游戏，也可以打电话。游戏和电话是手机提供给你的不同服务形态而已，并非说游戏是一种特殊的手机，电话是另外一种特殊的手机。

OK，那么，下面的问题就是讨论为了满足用户的这些需求，在设计上该如何分层。前人总结出了计算、存储、网络这三个根本的基础业务。其中计算又是最核心和最直接的。

我们来看直接面向用户的计算业务。数据中心里面放着的都是物理机器，物理机器上可以装操作系统，操作系统上可以装各种软件，可以运行虚拟机，可以运行容器。无论物理机、虚拟机、容器，都是属于计算资源。统统都应该用云平台给实现和供应出来。

如果说 IDC 是让用户可以拿物理机作为计算资源载体，那么现在的云计算是更进一步，让用户可以直接忽略计算资源的实际载体，无论是操作系统还是应用，直接提供给你即可，无需关心具体的载体。

总之一句话，云计算就是要方便提供计算资源！

问题与方向

Magnum 目前被认为 OpenStack 里面最有活力的容器项目，但是很可惜，一开始的路子就是偏的。

Magnum 的定位是提供一套 OpenStack API，底下可以兼容/依赖多种第三方的容器管理平台。OpenStack 本来就是要做一套资源管理平台，现在是用别人的，意味着这跟 OpenStack 其实关系不大。但是如果抛开 OpenStack，上面封装的一套 OpenStack API 又没有了意义。第三方的管理平台都有自己现成的 API。

真正的 Container as a Service，其实应该是在 OpenStack 中实现一套容器平台，而不是在 OpenStack 中安装了别人的一套平台，然后进行了 API 的封装。

或许有人会猜测，之所以不做底下的实现，可能跟 Nova-Docker 有关。

如果只谈技术，其实很容易在 Nova 中实现真正的 Container as a Service。在 Nova 看来，都是计算节点，但计算节点可以带上各自的类型，比如有的计算节点是物理机、有的是虚拟机、有的是容器甚至容器组。不同的类型意味着底层不同的驱动。用一套抽象的资源调度的框架（参考 Mesos 的二层调度机制），带上不同的底层 framework，问题很容易得到解决。

但偏偏是现在已经有了 Nova-Docker，已经有了 Magnum，不知道要经过多少波折才可能走到这个方向上来。或许在 OpenStack 的大环境下，是一件太困难的事情了。

或许，这就是开源的魅力，分分合合，曲折中前行。

转载请注明：http://blog.csdn.net/yeasy/article/details/46545837

云计算容器服务该何去何从

标签：openstack   docker   云计算   开源项目   paas   

原文地址：http://blog.csdn.net/yeasy/article/details/46545837