技术分享：OpenStack Magnum社区及项目介绍
今天主要跟大家简单介绍下Magnum社区和Magnum项目的一些介绍。Magnum到现在为止，功能做的其实不是很多，希望通过这次机会能和大家多多讨论下，看看怎样让Magnum提供更好的容器服务。
1.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的主要概念，在这个图的右边，主要有这么几个：Bay、Baymodel、Node、Pod、Service、RC、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。
Q&A
问：我观察到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。