從0.25到1.0，中小企業Mesos網絡和存儲的填坑實踐

看完海外大型企業的Mesos容器技術實踐，讓咱們視線回到國內。今天是 數人云容器三國演義Meetup嘉賓演講實錄第一彈。中小企業是如何解決Mesos使用過程當中種種問題的？Acttao技術總監何威威來告訴你答案——

今天與你們分享的是中小企業的Mesos實踐中遇到的網絡和存儲方面的具體問題。

概述

首先介紹一下Acttao的實踐狀況。Acttao如今主要運行兩個Mesos集羣，一個用於測試環境，另外一個用於生產環境。測試環境部署在KVM虛擬機裏面，生產環境在阿里雲。以前還有一個OpenStack的測試環境，後來撤掉了。有了Mesos集羣之後，咱們在開發過程當中引入了CI/CD，CI/CD要求開發人員能很方便的管理無狀態的Web服務，一個有狀態相似於MySQL、Redis等的服務，還要求Web服務可以方便的找到數據庫服務，這是要解決這三個問題。

要解決這些問題，須要咱們在Mesos的容器裏面實現一容器一IP，對於有狀態的容器須要跨主機的Volume服務，以及服務發現。

Mesos容器網絡

說一下Mesos網絡的方案。按照時間有三個階段，第一個階段在Mesos 0.25以前，在這以前Docker自己沒有容器的擴展，第二個階段是Mesos0.25到1.0之間，第三個階段就是如今1.0版本以後。Mesos 0.25以前這個方案基本上是空白的，大部分都要手動運行腳本，以空網絡起一個Docker容器，而後再運行一些好比建立網絡設備、配置IP。那時有一個Powerstrip原型的工具，其原理是替代Docker API作一些擴展，使用這種工具給Mesos容器加IP基本不會有改動，經過Mesos的API就能夠實現一容器一IP。

在Mesos0.25到1.0版本之間，這時Docker推出了網絡擴展功能，Docker容器有了原生的網絡擴展支持。典型的第三方插件有Weave、Calico等。咱們經過MarathonAPI能夠直接實現建立的容器有一個IP。

1.0以後Mesos原生支持了CNI網絡，經過Unified Container，不管是Mesos的容器仍是Docker的容器、AppC的容器，都很容易作到一個容器一個IP。

在Mesos支持CNI以前，爲了實現IP per container，Acttao最後選擇了Weave。沒有使用Docker容器的擴展，而是選擇Weave Proxy，相似於0.25以前的方案，由於它很容易集成。Weave的Proxy方式有DNS的服務發現，集成較簡單，Weave起一個Router，而後Proxy起開，起開之後在Mesos的slave設置Docker socket走Weave Proxy的socket就能夠了。

當時沒有選擇Docker Libnetwork的擴展方式，由於那時須要爲每個Docker配一個外部存儲，這也是剛纔徐春明老師說他們如今SwarmKit裏面不依賴於外部存儲的緣由。由於當時測試的Docker依賴於外部的存儲，最後測試的性能問題比較嚴重。當時他們建議用etcd，而Acttao當時用的是Zookeeper，測試時起了網絡有時候運行 docker network ls，Docker就會卡掉，基本上是掛掉的狀態。

在使用Weave Proxy時有兩個問題一直困擾着咱們。一個是Weave網絡升級，有新版本發佈時，咱們可能會選擇使用新版本，可是升級比較麻煩；另外一個問題是網絡的隔離性很差。升級時Weave Proxy要重啓，重啓了以後Mesos認爲Docker Engine掛掉了，會把任務進行從新調度，但實際上在宿主機上的容器並無掛掉。這個問題對無狀態服務影響不大，至關於有多個實例，可是對於數據庫服務來講，就會致使原先數據庫服務運行着，又調度了一個新的任務，在DNS自動發現裏一個域名會返回兩個IP，致使了一個服務是可用的，另外一個服務不可用。

因爲這個緣由，升級以前咱們把Mesos的Slave停掉，把全部Mesos管理的容器也停掉，讓master從新進行任務調度，接着把Docker也停掉了，而後安裝新版本的Weave，以後把Docker和slave啓動。在升級的中途若是宿主機裏面有數據庫服務，會有一段時間服務不可用。

Weave基於子網的網絡隔離靈活度不是很好。在Mesos考慮多租戶，一個租戶子網分配的過小，可能立刻就不夠用，後續擴大子網的過程很是麻煩，若是一開始分配的子網特別大，又會形成浪費。

針對升級網絡組件時遇到的問題可使用CNI來解決。網絡隔離的問題能夠在CNI的基礎上使用Calico解決，Calico 基於 iptable 作了防火牆的規則。

在Mesos 1.0裏配置CNI很簡單。配置network CNI配置文件的目錄以及CNI插件的目錄， Mesos就能夠啓用CNI的功能。CNI對第三方的配置也很簡單，這張圖是Weave的配置，只要一個名稱和一個type：weave-net。 Calico一樣不復雜，基本上也是配置名稱，支持CNI這個網絡插件裏面所需的配置。

使用Marathon啓用的時候比較簡單，在APP的Json文件裏面配上IP adress，配一個network的name，這個名稱就是以前配CNI裏面的名稱。而後配一些label標籤，它與防火牆有關，再配一個Discover的端口，主要用做服務發現。經過這種方式，基本上就解決了前面提到的兩個問題。

可是Acttao目前使用的仍然是Weave CNI，沒有選擇Calico方案的緣由是它的安全策略如今必須得手動配置，不能自動地和Mesos集成。若是內部使用，本身配備也是能夠的，可是後來考慮本身來寫一個marathon-calico，根據Marathon中的APP自動建立網絡安全方面的策略。

Mesos容器存儲

存儲方案也和剛纔的容器同樣是分三個階段的，中間階段均是原生支持了擴展，容器Volume的擴展之後有一個階段，以及Mesos1.0之後，直接支持Docker存儲插件。以前Acttao基於GlusterFS作了GlusterFS集羣，在每個S節點把集羣掛載上去，容器經過Docker直接掛宿主機上面目錄的功能來實現。

當Docker原生支持Volume插件之後，Acttao使用的是EMC的REX-Ray，這與其餘Volume的插件功能相似，是咱們目前瞭解到的插件中功能最全的，支持第三方存儲，好比OpenStack和一些商業存儲硬件，包括EMC。

Mesos1.0之後原生提供了Docker Volume支持服務，經過EMC提供的 dvdcli 工具實現。最開始時EMC想利用這個功能爲Mesos裏面提供外部的存儲，可是當時它基於Mesos的模塊，只能支持Mesos容器，沒法支持Docker容器。因此Mesos1.0之後直接把這個功能集成在Mesos核心。Mesos1.0之後，咱們把它也配上了，提供Mesos原生支持。它的配置比較簡單，在slave裏面安裝dvdcli，而後設置一個Volume的check_point，用做恢復，在隔離上面設置好system/linux和docker/volume，基本上就能夠啓用功能了。

在Marathon裏面使用第三方外部存儲時，須要把external_volumes的feature 開啓，真正使用時是在APP的json裏面定義卷的時候，把volume裏面的類型設置成外部的，provider設置成dvdi，由於目前只支持這一種方式，後面使用Docker Volume Plugin的名稱，基本上就可使用了。

當前最新版本的Marathon的外部卷不能使用絕對路徑，這個BUG416估計短時間內也不會獲得解決。咱們把它裏面dvdi provider的校驗規則改一下，基本上就可使用了。前端的校驗規則裏面是Mesos的容器，原先設置的時候不能使用相對路徑，把它改掉就能夠。

個人分享就到這裏，謝謝你們。