Kolla讓OpenStack與Docker相融合

Docker的出現，對OpenStack產生了一定的影響，有些聲音說：Docker會使得OpenStack遭受背棄。而事實卻與之相反，我們看到兩個社區發展的依然很好，Docker與OpenStack各有側重，分別解決了不一樣的問題，且兩者的使用場景也不太一樣。

什么是Kolla這個項目？

Kolla項目的產生，是由于OpenStack本身的復雜性，即模塊太多與配置項太復雜，其中模塊的問題是OpenStack自身數量已經很多，在此基礎上其依賴的模塊太非常之多，由于可選項的數量多導致其部署的復雜性，導致我們需要對OpenStack有非常深入的理解，才可以選擇適宜的部署方案。

不僅如此，在利用現有的部署工具Fuel，其復雜程度與代碼級同樣達到了很復雜的量，同時還有openStack-ansible（rackspace主導），它下面的項目非常多，基本上OpenStack的一個模塊就形成一個子項目。

另外，隨著OpenStack逐漸成熟，常用的Puppet代碼也已經變的復雜。因為部署復雜，所以運維也同樣面臨著各種挑戰。

對此，Kolla項目被孵化出來，有效的解決了上述復雜度的困惱。Kolla本身的含義是“膠水”（希臘語），是把OpenStack和Docker有機融合在一起。Kolla提供出兩個東西，一是生產級別的Docker鏡像，另一個是基于Ansible的部署工具，這兩個產出是可以分別獨立開來的。

為什么是Docker？

首先，先剖析一下Docker本身的優點：

（1） 固定性 ：

可以直接把容器清掉并重新通過Image創建（全新且同原本一樣）。

（2） 便捷性 ：

因為它的Image可以直接導出來，或者存在于Docker Registry服務中，所以可以帶到另外的地方做部署，而且它的體積比較小，所以很方便便攜（區別于使用puppet來部署，需要攜帶好多源）。

（3） 速度快 ：

Docker本身啟動很快，基本是秒級的啟動。

Docker社區非常龐大，通過各大公司進入到Docker社區里面做的一些貢獻，我們可以看出包括（上層的產品）谷歌、Apache都有較好的應用且成長很快，同時，Docker技術經過三年的成長，已經開始在生產環境被使用，其成長非常迅速。

所有的事物都有兩面性，Docker當然也有一些缺點。例如其驗證不夠，Docker從誕生到發展只有三年的時間，大家的驗證量還不夠多，且功能還在隨著版本的增加而增加，所以說，Docker還是略新。

詳解Kolla：

Kolla是把OpenStack部署在Docker容器里，提供快速部署的層級功能。

• Kolla的目標

（1）利用Docker產生生產級別的鏡像加速OpenStack部署。

（2）簡化OpenStack部署和運維操作。

現階段提供Ansible Playbooks進行部署，但由于對Kubernetes 的興趣，可以把 OpenStack 運行在 kubernetes上，用其本身的特點保證云平臺的靈活性和自動調度。

• Kolla的基本原則

說到Kolla的一些基本原則，首先不得不提它的“Open”，Kolla不是被某一家公司所獨占，其開發人員來自于各個公司，其中包括思科、英特爾、IBM等。其次還有Kolla所部署出來的集群基本上是一個“開箱即用”的狀態。

例如在Kolla上直接使用100個節點的機器，可以實現“直接、批量地創建機器”。Kolla優化了一些功能參數，可以做到批量起動五、六百臺機器在100個節點中，是沒有問題的。

再有，Kolla在不同的環境里面，打破了“只能用OVS”的問題，Kolla可以是不限定的，可以供用戶自由選擇。

最后，Kolla本身項目開發的validation（驗證），即保證Kolla代碼的質量。也就是OpenStack的標準流程。在CI的測試中，包括構建所有的容器鏡像，并進行部署，隨后運行一個虛擬機，來檢測Kolla是不是真的可以正常工作，不僅如此，在Newton周期里可以把多機節點附加進去，這樣一來，測試Kolla能力會更大一些。

• Kolla的功能

（1）在Liberty中，Kolla的功能如下：

首先所有服務HA都已具備，包括API、storage在L版都已經完成。不僅如此，Kolla支持多后端存儲，比如是不是開啟 Ceph 存儲，如果是便可以自動將Ceph部署出來，并自動把Glance、Nova、Cinder配置好。

Kolla還具備既可以通過RDO打包，也可以從二進制包安裝OpenStack，還支持從源代碼安裝，這樣可以保持我們使用的，是OpenStack的最新代碼。還有上述提到的Kolla被驗證的基本原則中，其默認支持100個節點的部署。

另外，Kolla對物理機的依賴很小，宿主機只要裝 kolla-py 和docker-engine中，便都可以部署OpenStack。

補充：在L版中，Kolla支持的服務是包含mariabd、rabbitmq、memcached等，并支持原子性升級。

（2）在剛剛發布的M版中，Kolla的功能如下：

針對安全性，所有在容器里面的服務都不是在root中運行的。并添加了upgrade actian，即OpenStack可以升級。同時增加了ELK，用來做日志的收集和展示。

補充：M版中，Kolla的部署時間大大縮短；使用了Namde volume 進行存儲；使用官方的 qemu 源，使用了qemu 2.3 版本，有一定性能的提升；MariaDB增加了一個新的actian叫做 mariadb-recovery。

與此同時，Kolla社區是比較活躍的，各大公司在Kolla里面代碼貢獻數量非常多，且數量比較均等。

• Kolla的結構

Kolla通過CD/CI后會生成Ansible和Image兩個產出。宿主機上安裝一個Docker Registry服務，并將鏡像上傳上去，便可以部署OpenStack，結構非常簡單，且Kolla的代碼量也很少。

在Image Dependency中，有一個base項會根據需要安裝組建，Nova把所有的子服務拆開，以容器的方式運行。

同時還有Dockerfile本身的描述能力有限，只可順序。Kolla增加了描述能力。可以增加一些變量和一些邏輯判斷實現一些復雜功能。

同Kolla的功能描述，其支持多個版本，并支持兩種安裝方式。

Kolla的部署基本是基于社區的最佳實踐，比如一個LoadBalance負載所有API服務，然后是消息隊列及數據庫，隨后是調試器，這就是它的架構。Kolla的部署非常簡單，基于Ansible，做了kolla-ansible腳本，這個腳本可以做一些與部署相關的工作，比如前期檢查等。

第二是基于 Ansible Inventory，它是一個組的概念，通過它，我們可以知道哪個機器在運行哪個服務。現在支持單機的部署，其實單機跟多機是一樣的，只是 Inventory 的文件內部不一樣，不僅如此，還支持MariaDB和RabbitMQ集群，同樣是自動創建的。

在第二點上，我們比較關心網絡問題，因為Docker網絡默認是用 Linux Bridge，如果需要在外面訪問需要通過port map的方式，但OpenStack有Newton網絡的模式，往往會非常慢，等于網絡會有許多層。所以，我們選用最簡單的：host網絡，同在物理機起是一樣的。

值得一提的是，它完全尊崇Docker的理念，一個容器一個進程。

• Kolla的特性

第一，Kolla將所有東西都容器化了，包括libvirt和ovs這種比較復雜的應用進行容器化。

第二，嚴格遵守了一個容器只有一個進程的Docker原則，包括Neutron。這點在Docker1.10是做不到的，因為在里面會創建 namespace ，在其他容器中是看不到的。

第三，物理機不會受到任何“污染”，部署完成之后，如果不想使用了，可以直接把所有的container清楚掉，便可以重新回到原始的、干凈的狀態。

當然，在整個過程中也會遇到一些問題，比如Docker的timzone，在其他的部署方式下是遇不到的，只能把容器外的時區文件映射到容器里面來實現，否則的話如果改掉外面，容器內部的時區不變，會發生時間跳過幾個小時的情況，這個時候Ceph會崩掉。

同時還有ulimit，因為一旦運行到容器里面，ulimit的數值不夠大，導致它打開文件太多出錯。還有Docker的storage有比較多的選擇，現在看來devicemapper比較慢的。

值得一提的是：插件，Kolla缺少的是插件技術，因為OpenStack項目太多，而且每個項目有不同的插件(驅動)，實現起來不一樣，不可能依靠Kolla社區來維護，如果真的實現的話，那么會大大加大它的靈活性，實現插件機制就是做集成，即將自身產品相集成。

還有它的配置文件，包括puppet、ansible部署時是把配置項變成上層的一個變量，Kolla與其不同，它是將原始配置文件寫好，不會增加用戶額外的學習成本，但這個機制暫時只能支持OpenStack的項目，使用對Apache的配置文件尚支持不了。

最后是監控問題，現在雖然有ELK做日志收集和展示，但是沒有監控，所以周期內需要做監控的事情，比如zabbix等。

補充：OpenStack與Kolla的關系

OpenStack跟Kolla的關系包含兩個項目：

第一個是nova Docker啟虛擬機，它不是創建虛擬機而是一個容器，其中Magnum是在OpenStack中管理kubernetes的生命周期，隨后通過API進行管理；

第二個項目是kuryr，因為Docker本身的網絡是比較簡單的，最早Docker是基于linux bridge來實現的，隨后Docker推出了libnetwork機制，可以根據網絡本身呈現多種實現，其中kuryr因為OpenStack Neutron頂層包括V*N，所以這個項目就是把Neutron引入到Docker的網絡當中。

 

來自： http://geek.csdn.net/news/detail/81443