背景

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 来路由。而无需详细知道 Pods 的地址。

• ReplicationController：对 pod 指定副本数，RC 能够保证一直存在该数目的副本存在并执行。

主要服务

主要服务有两个。Magnum API 和 Magnum Conductor。

前者提供调用的接口，接收 python-magnumclient 的请求。能够同一时候执行一个或者多个实例。这些请求终于扔给 AMQP 消息队列。发送到 magnum-conductor 服务。

后者执行在控制节点上，详细负责将 client 的请求转发到详细的后端机制（Kubernetes API 或者 Docker API）。眼下限制仅仅能存在一个实例。

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