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内部执行，因此咱们就能够利用这些特性：

这样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：

说完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″

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

上一场景所提到的嵌套overlay的问题，是在OpenStack中使用Docker集群的广泛问题，以下图所描述：

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

最终能够实现容器和容器之间组网，容器和虚机之间组网等模式，Neutron会做为IPAM存在，咱们能够随意地定义网络：

这样咱们能够把不少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 Horizon上用拖拖拽拽的方式建立Rancher环境：

最终经过Murano的编排，建立了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 是能够计算出来的，有一个公式能够计算，小于这个值也能够，可是这样传输效率就过低。