Magnum主要包括如下概念。
1.Bay
Bay在Magnum中表示为一个集群，目前通过Magnum可以创建Kubernetes和Swarm集群。
2.BayModel
Baymodel是集群配置模板，保障多级群创建时配置数据一致性。OpenStack采用Flavor定义虚拟机或者物理机的规格，在Magnum中则采用BayModel定义Docker集群的规格，如集群管理节点的Flavor，计算节点的Flavor等。
3.节点
表征一个物理机或者虚拟机机。
4.Pod
事实上，Pod是从Kubernets引入的一个概念。Pod是Kubernetes的基本调度单元。业务相关的多个容器组成一个Pod，部署在一个物理节点上。如对于互联网应用，可以将Web前端、应用服务器、后端数据库等分别运行在容器中，并组成一个Pod。Pod的初衷是希望可以简化部署和管理，同时Pod内的多个容器可以共享CPU、Volume、Network Namespace/IP和Port空间等资源。受Docker技术的限制，目前部分资源并不能在Pod内的多个业务相关容器间共享，但是Google正在朝这一方向努力。
5.服务
服务也是从Kubernetes引入的概念。服务是Kubernetes的基本操作单元，它对真实应用进行抽象，实现前端访问与后端应用的解耦。每个服务后端都有多个应用容器，对于一个前端请求，服务selector决定具体承接请求的应用容器。服务对外提供单一访问接口，前端无须了解后端如何运作，也不感知后端应用容器的故障、IP变化等，这给后端扩展和维护带来了很大的便利。
6.复制控制器（Replication Controller）
复制控制器从分布式应用高可用、可扩展性角度考虑，保证任何时刻Magnum集群中正在运行的Pod副本的数量。如果系统中Pod副本数量少于预设值，则复制控制器会对Pod进行复制，创建并启动新的Pod；反之，如果当前Pod数量大于预设值，则复制控制器会“杀死”多余的Pod。
复制控制器使用预定义的Pod模板创建Pod，而Pod在创建成功后，Pod与Pod模板之间的关联就解除了。修改Pod模板不会对Pod有任何影响。
复制控制器的主要用法如下。
（1）重调度
当节点故障时，复制控制器确保集群中运行态Pod的数量。
（2）弹性扩展
通过修改复制控制器的副本预设值，可以水平扩展或收缩运行态Pod规模。
（3）滚动升级
使用复制控制器逐个替换Pod版本，可以实现Pod的滚动升级。
7.容器（Container）
在Magnum中即为Docker容器。Magnum的逻辑架构如图12-14所示。
图12-14 Magnum的逻辑架构
图12-15和12-16更清晰地刻画了Magnum各逻辑概念在Bay中的具体映射。Magnum目前支持两个Bay：Kubernetes和Swarm，后续会增加对mesos的支持。Magnum通过swagger实现了一套Kubernetes API，可以通过Kubernets的Rest Api与后端的Kubernetes进行交互。同样的，Bay创建完成后，Magnum也可以选择与Swarm交互操纵Docker容器。
从图12-14可以看到，Magnum控制节点主要有两个部件：API服务器和Conductor。用户首先通过Magnum的Python客户端访问API Rest服务器，之后，请求通过AMQP消息队列发送到Conductor进程。API Rest服务器可水平扩展，支持以单进程或多进程形态运行。目前，Conductor仅限于单进程，开发者们正试图增强Conductor的可扩展性。Magnum Conductor进程连接到后端Kubernetes、Swarm API端点，交由后端Bay对象对请求进行处理。
Magnum的特点如下：
图12-15 Kubernetes Bay
图12-16 Docker Swarm Bay
1）对Bay、容器、节点、Pod和Service进行抽象。
2）将Kubernets和Docker作为后端容器技术进行集成。
3）与Keystone集成，支持多租户安全。
4）与Neutron集成，支持Kubernetes多租户网络安全。