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

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

你可能感兴趣的:(openstack,container,Magnum)