转载

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集群管理系统,使用户很方便的使用这些容器管理系统来提供容器服务。

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

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

DockOne技术分享:OpenStack 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

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

上图是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

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

上图是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简介

DockOne技术分享:OpenStack 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

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

上图是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

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

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

3.7.2 查看Baymodel详细信息

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

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

3.7.3 创建Kubernetes Bay

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

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

3.7.4 检查Kubernetes Bay拓扑结构

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

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

3.7.5 检查Magnum Bay

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

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

3.7.6创建Kubernetes Pod

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

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

3.7.7检查Kubernetes Pod

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

创建完成后,可以通过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节点。

正文到此结束
Loading...