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 是能夠計算出來的，有一個公式能夠計算，小於這個值也能夠，可是這樣傳輸效率就過低。