背景
Magnum 项目是 2014 年 11 月加入 OpenStack 的年轻项目,由 Rackspace主导发起,其定位是提供容器即服务(Container as a Service)的 API 框架,计划在 2015 年 10 月推出的 Liberty
版本时成熟。
我们知道,目前 OpenStack 中 Nova 项目已经通过 nova-docker 的形式支持了 Docker 容器(把容器当虚机管)。但在实际使用中,会发现有不少的问题。毕竟,Nova 设计的初衷是管理虚拟机,而容器跟虚拟机在行为和特性上存在较大的不同,无论是管理层还是底层的虚拟化支持层都完全不同。而且,让 Nova 支持各种各样的容器机制(Docker、OpenVZ、Rocket、LXC 等)要进行修改的地方着实不少,可能跟现有框架形成冲突。
此外,Heat 项目也支持 Docker 官方插件,来直接通过 Docker 的 REST API 来管理容器,并且支持容器的高级特性。然而,不支持资源的调度和网络功能。
社区之所以接收 Magnum 项目,一方面是容器技术现在着实火热,另一方面,也是往更高一层发展提供更好的支持。
设计原理
Magnum 在设计上,希望调用其它的容器管理平台的 API 来实现功能,自身作为一套 API 框架,目前支持 Docker、Kubernetes、Swarm 等。主要优势包括多租户、多后端框架、完善的容器功能、支持资源调度等。
如果说 Nova 是一套支持不同 Hypervisor (KVM、VMWare 等虚拟机平台)的 API 框架,那么 Magnum 则是支持不同容器机制的 API 框架。
基本概念
从小往大的顺序:
- Node:容器运行的节点,可以是裸机、虚拟机甚至容器。
- Bay:一组 Node 的集合(底层同一个驱动机制),是 Magnum 中容器调度的基本单元。Bay 在租户之间是隔离的。
- BayModle:类似于 Nova 中的 flavor,定义一个 Docker 集群的规格。
下面几个是来自 Kubernetes 中的概念。
- Container:容器。
- Pod:最小的管理单元,一个或多个相互关联的容器(一般运行相同应用),运行在同一个 Minion Node 上,共享同样的数据挂载和网络空间,代表某种应用的一个实例。
- Service:由一个或者多个 Pod 组成,代表一个抽象的应用服务,对外呈现为同一个访问接口,这样访问可以通过 service 来路由,而无需具体知道 pod 的地址。
- ReplicationController:对 pod 指定副本数,RC 可以保证一直存在该数目的副本存在并运行。
主要服务
主要服务有两个,Magnum API 和 Magnum Conductor。
前者提供调用的接口,接收 client 的请求。这些请求最终扔给消息队列,最终被不同的后端机制获取进行执行。
后者则具体负责将 client 的请求转发到具体的后端机制。
转载请注明:http://blog.csdn.net/yeasy/article/details/46331679