OpenStack Magnum 项目简介

背景

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），目前限制只能存在一个实例。