DockOne技术分享：OpenStack Magnum社区及项目介绍

今天主要跟大家简单介绍下Magnum社区和Magnum项目的一些介绍。Magnum到现在为止，功能做的其实不是很多，希望通过这次机会能和大家多多讨论下，看看怎样让Magnum提供更好的容器服务。

Magnum社区

Mangum现在应该是OpenStack里边比较热门的一个和Docker集成的新项目。Magnum是去年巴黎峰会后开始的一个新的专门针对Container的一个新项目，用来向用户提供容器服务。从去年11月份开始在stackforge提交第一个patch，今年3月份进入OpenStack namespace，这个项目应该是OpenStack社区从stackforge迁移到OpenStack namespace最快的一个项目。Magnum现在可以为用户提供Kubernetes as a Service，Swarm as a Service，和这几个平台集成的主要目的是能让用户可以很方便的通过openstack云平台来管理k8s，swarm，这些已经很成型的docker集群管理系统，使用户很方便的使用这些容器管理系统来提供容器服务。

通过这个图主要是想强调下，就是Magnum社区现在发展很迅速，大家可以看一下patch set和commit的对比，基本上平均三个patch set就会产生一个commit，所以希望对docker感兴趣的人，可以参与到Magnum的开发中来。

这一页是Magnum社区的一些情况，主要列出了一些为Magnum做贡献的公司，包括IBM，rackspace，hp，cisco等等，IBM目前在这个项目排第一位。

通常情况下，一个公司对哪些项目比较看重，或者它对OpenStack社区的最近的一些策略，都可以通过分析每个公司对OpenStack的贡献来得到一定的结论。如果某个公司在某个项目贡献比较多的话，可能就意味着这个公司会在相关领域有一些动作。大家如果感兴趣的话，可以通过 http://stackalytics.com/ 去研究一下自己感兴趣的公司最近在OpenStack的一些动态。

在这简单介绍下Magnum的一些主要Contributor，Adrian Otto是Rackspace的杰出工程师，Magnum和Solum的双重PTL；Steven Dake刚刚从Redhat加入Cisco，他是Heat的创始人之一，现在Kolla的PTL，同时还在积极推动一个新项目Machine Learning-As-A-Service；Davanum Srinivas (dims)刚刚从IBM加入Mirantis，现在担任Oslo的PTL。

2. Why Magnum

接下来我们看下为什么需要magnum, OpenStack现在和docker集成现在主要有三块，包括nova docker driver，heat docker driver和Kilo推出的Magnum，当然还包含一些别的项目，例如Sahara，Murano，Kolla，Solum等等。

2.1 Nova docker driver

上图是nova docker driver，这个driver是openstack和docker的第一次集成，相信对docker和openstack感兴趣的人，应该都用过这个driver

这个driver的话，主要是把把Docker作为一种新的Hypervisor来处理，把所有的container当成vm来处理。提供了一个docker的nova compute driver。我不知道@Gnep@北京-VisualOp 的Hyper是不是可以考虑先弄个driver试试，我们待会可以讨论

这个driver的优点是实现比较简单，只需要把nova compute中的一些对虚拟机操作的常用接口实现就可以，现在主要支持创建，启动，停止，pause，unpause等虚拟机的基本操作。

另外一个是因为nova docker driver也是一个nova的compute driver，所以他可以像其他的compute driver一样使用openstack中的所有服务，包括使用nova scheduler来做资源调度，使用heat来做应用部署，服务发现，扩容缩容等等，同时也可以通过和neutron集成来管理docker网络。也支持多租户，为不同的租户设置不同的quota，做资源隔离等等。IBM现在的SuperVessel Cloud使用的就是这个Driver

他的缺点也很明显，因为docker和虚拟机差别也挺大的，docker还有一些很高级的功能是VM所没有的，像容器关联，就是使不同容器之间能够共享一些环境变量，来实现一些服务发现的功能，例如k8s的pod就是通过容器关联来实现的。另外一个是端口映射，k8s的pod也使用了端口映射的功能，可以把一个pod中的所有container的port都通过net container export出去，便于和外界通信。还有一个是不同网络模式的配置，因为docker的网络模式很多，包括host模式，container模式等等，以上的所有功能都是nova docker driver不能实现的。

2.2 Heat Docker Driver

上图是heat docker driver，因为nova docker driver不能使用docker的一些高级功能，所以社区就想了另一个方法，和heat去集成，因为heat采用的也是插件模式，所以就在heat实现了一个新的resource，专门来和docker集成。这个heat插件是直接通过rest api和docker交互的，不需要和nova，cinder，neutron等等来进行交互。

所以这个driver的优点是首先它完全兼容docker的api，因为我们可以在heat template里边去定义我们关心的参数，可以实现docker的所有高级功能，用户可以在heat template定义任意的参数。另外因为和heat集成了，所以默认就有了multi tenat的功能，可以实现不同docker应用之间的隔离。

但是他的缺点也非常明显，因为他是heat直接通过rest api和docker交互的，所以heat docker driver没有资源调度，用户需要在template中指定需要在哪一台docker服务器上去部署应用，所以这个driver不适合大规模应用,因为没有资源调度。另外因为没有和neutron去交互，所以网络管理也只能用docker本身的网络管理功能，没有subnet，网络隔离也做得不是太好，需要依赖于用户手动配置flannel或者ovs等等

3. Magnum简介

所以社区就推出了Magnum这个项目。上图是Magnum的一个架构图。

3.1 Magnum主要概念

它的结构其实很简单，首先我们看下magnum的主要概念，在这个图的右边，主要有这么几个：baymodel, bay, node, pod, rc, service, container

Bay：bay在magnum主要表示一个集群，现在通过magnum可以创建k8s和swarm的bay，也就是k8s和swarm的集群。

Baymodel：baymodel是flavor的一个扩展，flavor主要是定义虚拟机或者物理机的规格，baymodel主要是定义一个docker集群的一些规格，例如这个集群的管理节点的flavor，计算节点的flavor，集群使用的image等等，都可以通过baymodel去定义。

Node主要是指Bay中的某个节点。

Container就是具体的某个docker容器。

Pod, replication controller和service的意思和在k8s的意思是一样的。在这简单介绍下这三个概念。

Pod是Kubernetes最基本的部署调度单元，可以包含多个container，逻辑上表示某种应用的一个实例。比如一个web站点应用由前端、后端及数据库构建而成，这三个组件将运行在各自的容器中，那么我们可以创建包含三pod，每个pod运行一个服务。或者也可以将三个服务创建在一个pod，这个取决于用户的应用需求。一个pod会包含n 1个container，多出来的那一个container是net container，专门做路由的

Service：可以理解为是pod的一个路由，因为pod在运行中可能被删除或者ip发生变化，service可以保证pod的动态变化对访问端是透明的

Replication Controller：是pod的复制抽象，用于解决pod的扩容缩容问题。通常，分布式应用为了性能或高可用性的考虑，需要复制多份资源，并且根据负载情况动态伸缩。通过replicationController，我们可以指定一个应用需要几份复制，Kubernetes将为每份复制创建一个pod，并且保证实际运行pod数量总是与预先定义的数量是一致的(例如，当前某个pod宕机时，自动创建新的pod来替换)。

3.2 Magnum主要服务

接下来看下magnum中的主要服务，现在主要有两个服务，一个是magnum-api，一个是magnum-conductor。具体如上图所示。

Magnum-api和其它的项目的api的功能是一样的，主要是处理client的请求，将请求通过消息队列发送到backend，在magnum，后台处理主要是通过magnum-conductor来做的。

magnum现在支持的backend有k8s，Swarm，Docker等等，Magnum conductor的主要作用是将client的请求转发到对用的backend，backend在Magnum的官方术语叫CoE(Container Orchestration Engine)

3.3 Magnum工作流程

第一步需要创建baymodel，就是为需要提供容器服务的bay创建一些集群的定义规格。

第二步就可以在第一步创建的baymodel基础上创建bay了，用户可以选择使用Kubernetes或者Swarm，未来还会有Mesos。

第三步，当bay创建完成后，用户就可以通过调用Magnum API和后台的k8s或者swarm交互来创建container了

3.4 Magnum Notes

另外想强调一下，Magnum现在没有调度模块，因为现在支持的CoE有Swarm和Kubernetes，所以对Container的调度，完全是通过Kubernetes和Swarm本身的调度器来工作的，Magnum只是负责将用户创建container的请求进行转发，转发到对应的CoE，最终的请求由具体的backend去调度。

Magnum现在也支持对Docker进行管理，但是因为没有调度，目前建议对Docker的管理通过Swarm Bay来进行管理，因为Swarm是Docker官方的Docker集群管理工具。

Magnum现在还支持Multi tenant，每个租户可以有自己的bay，baymodel，pod，service，rc等等，这样可以保证不同租户的资源隔离。每个租户只能看到和操作属于自己的资源。

Magnum现在本身不管理docker的网络，都是通过上层的CoE自己去管理的，例如Kubernetes的bay现在通过flannel去管理，其实用的还是tunnel技术。

3.5 Magnum Bay

上图是Magnum目前支持的两个bay，Kubernetes和Swarm，Bay创建完成后，可以直接通过Magnum API和Kubernetes或者Swarm交互创建container。Magnum现在自己通过swagger实现了一套kubernetes api，magnum通过kubernetest的rest api来和后台的kubernetes交互。

3.6 Magnum Roadmap

3.6.1网络

第一个是网络，网络永远是热门话题，不管是在哪次峰会，现在Magnum也碰到了同样的问题：Container的网络怎样管理，现在主要是通过Kubernetes依赖于overlay network的flannel来管理，但是因为flannel的性能和扩展性的问题，Magnum社区正在讨论对网络方面进行改进，例如和libnetwork或者neutron集成。这个bp在这 https://blueprints.launchpad.net/magnum/ spec/native-docker-network，非常欢迎对Docker网络感兴趣的人参与讨论及实现。Magnum现在非常需要对网络比较熟的人来共同推动这个bp。我现在在调查libnetwork，看能不能在Magnum去使用。

3.6.2 Mesos支持

另外一个是因为现在能够提供容器服务的工具很多，Mesos也是比较流行的一个，所以Magnum正在计划把Mesos集成进来，提供容器服务。这个bp在这 https://blueprints.launchpad.net/magnum/ spec/mesos-bay-type 第一版的Mesos支持，会是Mesos Marathon这样一个组合。因为如果不依赖一个framework的话，mesos很难去使用。

3.6.3 Magnum界面

还有就是Magnum打算在L版做一个GUI界面，让用户更简单的使用Magnum。现在这个bp正在review https://review.openstack.org/#/c/188958/

3.7 使用Magnum

3.7.1 检查所有Baymodel

首先是通过命令”Magnum baymodel-list”查看Magnum中现在的所有的baymodel，可以看到现在主要有两个OOB的baymodel：kubernetes和swarm

3.7.2 查看Baymodel详细信息

通过“baymodel-show”查看Kubernetes Baymodel的详细信息

3.7.3 创建Kubernetes Bay

通过“bay-create”创建了一个有两个minions节点的kubernetes bay

3.7.4 检查Kubernetes Bay拓扑结构

因为Kubernetes的bay实际上是heat的一个stack，所以创建后，可以通过horizon查看stack拓扑结构的显示，从这里边可以看到heat创建kubernetes bay的所有对象。

3.7.5 检查Magnum Bay

我们可以通过bay-list查看bay的状态，从这个图可以看到Kubernets Bay已经创建完成了

3.7.6创建Kubernetes Pod

在Kubernetes bay的基础上通过“pod-create”创建一个nginx pod，在这主要是通过Magnum的命令行创建这个pod。

3.7.7检查Kubernetes Pod

创建完成后，可以通过Magnum “pod-list”，“pod-show”来查看pod状态

3.7.8 Swarm相关

我们可以用同样的方法来创建swarm的bay，通过swarm的bay来提供container service。

4. 问题

问：我观察到k8s里面的cloud-provider里面有了openstack的插件。想问下，这个cloud-provider在magnum里是否有使用？如果使用了，是如何使用的？

答：现在Magnum在和Kubernetes社区合作，这个是Kubernetes社区贡献给Magnum社区的，但是现在还没用。

问：magnum现在是可以创建swarm集群，但是swarm没有pod/service/Replication Controller的概念，这个magnum后期会有这方面的计划把这些概念引入swarm集群么？

答：暂时没有，现在Magnum还是分开管理k8s和swarm对象的，magnum api端的调用就可以指定用户用的是k8s还是swarm。

问：magnum可以作为独立模块使用吗？

答：现在还不行，因为需要依赖heat和keystone

问：我看你的命令截图，想问下底层架构是openstack吗？

答：是的，Magnum是OpenStack生态圈的一员，主打Container Service。

问：架构图中左边最下面那个micro os是docker引擎的载体？这是相当于还是要起一个实例吗？能不能去掉这个载体，由openstack直接提供统一的docker引擎。

答：因为现在micro os已经提供了，所以社区暂时么有计划通过openstack去提供，可能不想重复造轮子。

问：Magnum支持GUI的 L版什么时候出 ，会区分个人版和企业版吗，会收费吗？

答：L版会有个draft的gui，不收费的。openstack社区都是免费的

问：bay可以动态扩容吗

答：可以，通过magnum bay-update

问：在magnum的网络解决上libnetwork和Neutron区别在什么地方，各自的优势是什么，现在有哪些难点需要解决？

答：这个我还在调查 现在还没有一些结论 具体的可以关注这个bp https://blueprints.launchpad.net/magnum/ spec/native-docker-network ,我会定期的去append一些调查结果.希望对网络感兴趣的人 参与到 https://blueprints.launchpad.net/magnum/ spec/native-docker-network 这个bp的讨论中来

问：Magnum的Blueprint写着“Add support for mesos bay type”，bay type支持mesos, k8s, swarm，这个以后真的能做到统一抽象吗？这三者之间差异化还不小。Magnum社区是怎么考虑的？

答：这是个非常难解的问题，这个可能还得需要在开发中，和社区讨论，看能不能有一个折中的办法：能抽象的尽量抽象，不能抽象的再定制。我们可以在OpenStack ML讨论。

问：Magnum相对Kubernetes的优势

答：magnum相对与Kubernetes的优势主要有这么几个：1）多租户，不同的租户有不同bay，baymodel等等 2）openstack为Kubernetes提供底层的基础设施服务，openstack负责IaaS，Kubernetes负责PaaS，Magnum负责联通Kubernetes和openstack

问：magnum没有显式创建master node，是不是创建bay的时候就创建了k8s/swarm的master节点？多个k8s/swarm cluster就是创建多个bay就ok了？

答：答案都是yes，Magnum会自动创建Master节点。