OpenStack 与 Rancher 融合的新玩法

OpenStack是开源Iaas云的事实标准,功能大而全,除了能管理虚机同时也能管理容器,OpenStack项目中的Magnum、Kuryr、Kolla、Murano、Nova-docker等都是与容器场景很不错的结合点;而Rancher不同,Rancher是为容器而生,只是顺道做了一些VM的管理工作,与OpenStack不同的是针对VM的管理,Rancher并不是对标AWS,Rancher相对来说要精简很多,当然Rancher对容器的掌控要远强于OpenStack。本次分享给大家带来Rancher与OpenStack能够融合使用的一些玩法。

我会分为几个场景来讲解一下,这样对OpenStack不是太了解的朋友而言可以更直观一些。

场景一:使用OpenStack的VM来提供Rancher Host

这种结合是最先能想到的,可以说是顺理成章的需求。Rancher添加以OpenStack的VM为Host资源,我觉得主要有两种方式:custom host方式和docker-machine driver方式。

第一种方式,我们都知道Rancher在Add Host时可以用在目标主机执行一条shell的方式来添加host,而OpenStack在创建VM的时候可以在注入一个执行脚本,这个脚本会在VM创建完毕后在VM的OS内部执行,所以我们就可以利用这些特性:

OpenStack 与 Rancher 融合的新玩法

这样VM在创建完毕后会自动成为Rancher的一个Host资源,这里一点小建议就是VM的镜像最好是自带Docker,这样可以注入的脚本中省去安装Docker Engine的过程,可以大幅提升速度。

第二种方式就是利用docker-machine driver,而且openstack driver也是docker-machine的官方驱动之一,不过这个driver的参数确实太多,易用性上差很多。除了使用openstack driver,其实我们完全可以使用generic driver,openstack对主机秘钥有很好的管理,所以我们完全可以使用openstack和Rancher的api,利用generic driver来简化openstack driver的复杂性,当然前提是VM的镜像最好还是自带Docker Engine:

OpenStack 与 Rancher 融合的新玩法

说完Host资源,我们看看存储方面。OpenStack对存储的支持区分的比较细,对象存储、块存储、文件系统都有各自的项目来支持,如swift、cinder、manila等,存储系统对接的不仅仅是Rancher,Docker Engine本身也要处理好一些优化细节。

对于对象存储Swift,可以作为Docker registry的backend存储,我们可以registry服务部署到VM上,然后镜像的存储放在swift上。另外,目前convoy backup可以备份到AWS S3上,对于国内用户来说比较麻烦,实际上完全可以备份到swift上,当然需要在convoy上添加这个驱动的支持,或者可以把swift配置成S3的接口,这样也可以和convoy结合起来使用。

对于块存储Cinder,更多的结合场景在Docker Engine上,Docker有很多种storage driver,也就是我们熟知的rootfs可以有多种形式,常用的有aufs、devicemapper、overlayfs等,通常VM的flavor根磁盘都比较小,所以我们需要用cinder创建一块盘来挂载到/var/lib/docker上或者直接指定这块盘为devicemapper对应的设备。

对于文件系统manila,manila本身能够创建一个对外的NFS服务,也可以创建一个glusterfs集群服务,这样也可以和convoy能够有很好的集成。目前相对对象存储和块存储 ,Manila的成熟度还不是太高。

计算存储之后便是网络,我们都知道Rancher中Cattle的网络使用ipsec,ipsec本身就是一种overlay技术,而OpenStack的Neutron很多也会使用GRE/VXLAN之类的overlay网络,这样容器之间的网络通信就变成overlay嵌套overlay,性能上必然打打折扣,所以OpenStack与Rancher结合使用时,强烈建议Neutron使用vlan网络。

当然可能由于各种环境因素必须在neutron中使用overlay,此时VM的网卡的mtu需要设置成1400或者1450,那么同样需要对Docker容器的mtu做设置,否则容器内一些应用层的协议(HTTP)将会无法正常使用。DOCKER_OPTS=”$DOCKER_OPTS –mtu=1400″

OpenStack 与 Rancher 融合的新玩法

场景二:构建容器与虚机的混合网络

上一场景所提到的嵌套overlay的问题,是在OpenStack中使用Docker集群的普遍问题,如下图所描述:

OpenStack 与 Rancher 融合的新玩法

这种性能的损耗是巨大的,繁荣的OpenStack社区孵化的一个子项目Kuryr就是解决这个需求场景的。Kuryr本质上就是把容器内namespace的port与neutron port绑定,这个neutron port根据不同neutron-plugin-agent略有不同:

OpenStack 与 Rancher 融合的新玩法

最终可以实现容器和容器之间组网,容器和虚机之间组网等模式,Neutron会作为IPAM存在,我们可以随意地定义网络:

OpenStack 与 Rancher 融合的新玩法

这样我们可以把很多Neutron的特性带入到容器网络中,诸如安全组、浮动ip、Qos、Lbaas、Fwaas等等。

目前Kuryr只支持CNM(libnetwork),在OpenStack N版的release周期中会放出对CNI(主要是Kubernetes)的支持,届时Rancher 1.2也将会支持CNI,这样两者可以有一个很好的结合,后期可长期关注这个方向。

场景三:使用Murano来快速部署Rancher

Murano是OpenStack的应用市场,将应用基于Murano约定的打包标准打包后放入应用市场,用户就可以在OpenStack中快速部署该应用,这个理念非常类似Rancher的Catalog,只不过它是基于VM的。如果需要在OpenStack中快速部署一套简单的Rancher环境,那么使用Murano是个不错的选择。

OpenStack 与 Rancher 融合的新玩法

我们可以在OpenStack Horizon上用拖拖拽拽的方式创建Rancher环境:

OpenStack 与 Rancher 融合的新玩法

最终通过Murano的编排,创建了Rancher服务环境 ,并自动生成部署图:

OpenStack 与 Rancher 融合的新玩法

这种主要是方便、快速创建一套Rancher环境,我目前只是做了个demo,如果更完善还需要把Rancher的HA模式放进来。

场景四:利用Rancher Catalog快速部署OpenStack

玩过OpenStack的朋友都深知其复杂性,对于一个新手来说,刚上来部署OpenStack来个三天三夜不是什么新鲜事。OpenStack的快速部署需求引出了一些开源项目和商用产品,诸如openstack-ansible、kolla、fuel、magicstack等等。

在这其中kolla的理念比较特殊,它立志于以容器方式部署openstack服务,从而能够实现快速部署甚至滚动升级降级等特性。 Rancher本身就是管理容器的利器,完全可以把openstack当做Catalog中的一个应用来部署,这个服务Rancher也已经开始支持https://github.com/rancher/op...,目前实现也比较初级不支持controller的HA,可以将其加到Catalog里面体验一下。

有几点注意事项:

  1. Host必须开启KVM,可以使用这个命令查看一下 egrep -c ‘(vmx|svm)’ /proc/cpuinfo,返回是0说明没开启,各种OS开启KVM可Google之。

  2. 计算节点的libvirtd进程不能在运行在base OS中。

  3. 各个节点需要两块网卡,一块用于API通信,一块用于Neutron网络,网络需要提前配置好。

  4. 部署的过程需要拉取很多镜像,需要耐心的等待。

Q & A

Q:

Rancher现在只有IPSec 这种网络方案吗?性能会有问题吗?

A:

Rancher-net组件目前只支持ipsec。ipsec网络本身是overlay网络,同时还有密钥加密,所以性能上会差一点。不过在Rancher 1.2的发布计划中,会支持CNI,这样我们可以把calico weave等网络组件集成进来,用户可以根据自己的实际业务场景 选择不同的网络组件,Rancher对CNI的支持已经开始开发了。

Q:

Kuryr现在可以对接Rancher吗?

A:

Kuryr 现在暂时不可以,Kuryr目前也是在支持CNI的迭代中,需要等Rancher和Kuryr都完毕后,两面就可以打通了。Kuryr之前的计划应该是在OpenStack N版会添加CNI的支持,差不多就是今年10月份左右。

Q:

【当然可能由于各种环境因素必须在Neutron中使用overlay,此时VM的网卡的mtu需要设置成1400或者1450,那么同样需要对docker容器的mtu做设置,否则容器内一些应用层的协议(HTTP)将会无法正常使用。】关于这一点,是明确要求1400或1450还是说可以小于1400即可?因为强制只能是这两个值应该有点特别原因吧?

A:

特别的原因就是GRE/VXLAN的包头太大了,设置mtu拆包的时候不能用默认的1500 否则数据包就是无法识别了。1400/1450 是可以计算出来的,有一个公式可以计算,小于这个值也可以,但是这样传输效率就太低。

相关推荐