DockOne技術分享：OpenStack Magnum社區及項目介紹
今天主要跟大家簡單介紹下Magnum社區和Magnum項目的一些介紹。Magnum到現在為止，功能做的其實不是很多，希望通過這次機會能和大家多多討論下，看看怎樣讓Magnum提供更好的容器服務。
Magnum社區
Mangum現在應該是OpenStack里邊比較熱門的一個和Docker集成的新項目。Magnum是去年巴黎峰會后開始的一個新的專門針對 Container的一個新項目，用來向用戶提供容器服務。從去年11月份開始在stackforge提交第一個patch，今年3月份進入 OpenStack namespace，這個項目應該是OpenStack社區從stackforge遷移到OpenStack namespace最快的一個項目。Magnum現在可以為用戶提供Kubernetes as a Service，Swarm as a Service，和這幾個平臺集成的主要目的是能讓用戶可以很方便的通過openstack云平臺來管理k8s，swarm，這些已經很成型的 docker集群管理系統，使用戶很方便的使用這些容器管理系統來提供容器服務。
通過這個圖主要是想強調下，就是Magnum社區現在發展很迅速，大家可以看一下patch set和commit的對比，基本上平均三個patch set就會產生一個commit，所以希望對docker感興趣的人，可以參與到Magnum的開發中來。
這一頁是Magnum社區的一些情況，主要列出了一些為Magnum做貢獻的公司，包括IBM，rackspace，hp，cisco等等，IBM目前在這個項目排第一位。
通常情況下，一個公司對哪些項目比較看重，或者它對OpenStack社區的最近的一些策略，都可以通過分析每個公司對OpenStack的貢獻來得到一 定的結論。如果某個公司在某個項目貢獻比較多的話，可能就意味著這個公司會在相關領域有一些動作。大家如果感興趣的話，可以通過 http://stackalytics.com/ 去研究一下自己感興趣的公司最近在OpenStack的一些動態。
在這簡單介紹下Magnum的一些主要Contributor，Adrian Otto是Rackspace的杰出工程師，Magnum和Solum的雙重PTL；Steven Dake剛剛從Redhat加入Cisco，他是Heat的創始人之一，現在Kolla的PTL，同時還在積極推動一個新項目Machine Learning-As-A-Service；Davanum Srinivas (dims)剛剛從IBM加入Mirantis，現在擔任Oslo的PTL。
2. Why Magnum
接下來我們看下為什么需要magnum, OpenStack現在和docker集成現在主要有三塊，包括nova docker driver，heat docker driver和Kilo推出的Magnum，當然還包含一些別的項目，例如Sahara，Murano，Kolla，Solum等等。
2.1 Nova docker driver
上圖是nova docker driver，這個driver是openstack和docker的第一次集成，相信對docker和openstack感興趣的人，應該都用過這個driver
這個driver的話，主要是把把Docker作為一種新的Hypervisor來處理，把所有的container當成vm來處理。提供了一個 docker的nova compute driver。我不知道@Gnep@北京-VisualOp 的Hyper是不是可以考慮先弄個driver試試，我們待會可以討論
這個driver的優點是實現比較簡單，只需要把nova compute中的一些對虛擬機操作的常用接口實現就可以，現在主要支持創建，啟動，停止，pause，unpause等虛擬機的基本操作。
另外一個是因為nova docker driver也是一個nova的compute driver，所以他可以像其他的compute driver一樣使用openstack中的所有服務，包括使用nova scheduler來做資源調度，使用heat來做應用部署，服務發現，擴容縮容等等，同時也可以通過和neutron集成來管理docker網絡。也支 持多租戶，為不同的租戶設置不同的quota，做資源隔離等等。IBM現在的SuperVessel Cloud使用的就是這個Driver
他的缺點也很明顯，因為docker和虛擬機差別也挺大的，docker還有一些很高級的功能是VM所沒有的，像容器關聯，就是使不同容器之間能 夠共享一些環境變量，來實現一些服務發現的功能，例如k8s的pod就是通過容器關聯來實現的。另外一個是端口映射，k8s的pod也使用了端口映射的功 能，可以把一個pod中的所有container的port都通過net container export出去，便于和外界通信。還有一個是不同網絡模式的配置，因為docker的網絡模式很多，包括host模式，container模式等等，以 上的所有功能都是nova docker driver不能實現的。
2.2 Heat Docker Driver
上圖是heat docker driver，因為nova docker driver不能使用docker的一些高級功能，所以社區就想了另一個方法，和heat去集成，因為heat采用的也是插件模式，所以就在heat實現 了一個新的resource，專門來和docker集成。這個heat插件是直接通過rest api和docker交互的，不需要和nova，cinder，neutron等等來進行交互。
所以這個driver的優點是首先它完全兼容docker的api，因為我們可以在heat template里邊去定義我們關心的參數，可以實現docker的所有高級功能，用戶可以在heat template定義任意的參數。另外因為和heat集成了，所以默認就有了multi tenat的功能，可以實現不同docker應用之間的隔離。
但是他的缺點也非常明顯，因為他是heat直接通過rest api和docker交互的，所以heat docker driver沒有資源調度，用戶需要在template中指定需要在哪一臺docker服務器上去部署應用，所以這個driver不適合大規模應用,因為 沒有資源調度。另外因為沒有和neutron去交互，所以網絡管理也只能用docker本身的網絡管理功能，沒有subnet，網絡隔離也做得不是太好， 需要依賴于用戶手動配置flannel或者ovs等等
3. Magnum簡介
所以社區就推出了Magnum這個項目。上圖是Magnum的一個架構圖。
3.1 Magnum主要概念
它的結構其實很簡單，首先我們看下magnum的主要概念，在這個圖的右邊，主要有這么幾個：baymodel, bay, node, pod, rc, service, container
Bay：bay在magnum主要表示一個集群，現在通過magnum可以創建k8s和swarm的bay，也就是k8s和swarm的集群。
Baymodel：baymodel是flavor的一個擴展，flavor主要是定義虛擬機或者物理機的規格，baymodel主要是定義一個 docker集群的一些規格，例如這個集群的管理節點的flavor，計算節點的flavor，集群使用的image等等，都可以通過baymodel去 定義。
Node主要是指Bay中的某個節點。
Container就是具體的某個docker容器。
Pod, replication controller和service的意思和在k8s的意思是一樣的。在這簡單介紹下這三個概念。
Pod是Kubernetes最基本的部署調度單元，可以包含多個container，邏輯上表示某種應用的一個實例。比如一個web站點應用由 前端、后端及數據庫構建而成，這三個組件將運行在各自的容器中，那么我們可以創建包含三pod，每個pod運行一個服務。或者也可以將三個服務創建在一個 pod，這個取決于用戶的應用需求。一個pod會包含n 1個container，多出來的那一個container是net container，專門做路由的
Service：可以理解為是pod的一個路由，因為pod在運行中可能被刪除或者ip發生變化，service可以保證pod的動態變化對訪問端是透明的
Replication Controller：是pod的復制抽象，用于解決pod的擴容縮容問題。通常，分布式應用為了性能或高可用性的考慮，需要復制多份資源，并且根據負載 情況動態伸縮。通過replicationController，我們可以指定一個應用需要幾份復制，Kubernetes將為每份復制創建一個pod， 并且保證實際運行pod數量總是與預先定義的數量是一致的(例如，當前某個pod宕機時，自動創建新的pod來替換)。
3.2 Magnum主要服務
接下來看下magnum中的主要服務，現在主要有兩個服務，一個是magnum-api，一個是magnum-conductor。具體如上圖所示。
Magnum-api和其它的項目的api的功能是一樣的，主要是處理client的請求，將請求通過消息隊列發送到backend，在magnum，后臺處理主要是通過magnum-conductor來做的。
magnum現在支持的backend有k8s，Swarm，Docker等等，Magnum conductor的主要作用是將client的請求轉發到對用的backend，backend在Magnum的官方術語叫CoE(Container Orchestration Engine)
3.3 Magnum工作流程
第一步需要創建baymodel，就是為需要提供容器服務的bay創建一些集群的定義規格。
第二步就可以在第一步創建的baymodel基礎上創建bay了，用戶可以選擇使用Kubernetes或者Swarm，未來還會有Mesos。
第三步，當bay創建完成后，用戶就可以通過調用Magnum API和后臺的k8s或者swarm交互來創建container了
3.4 Magnum Notes
另外想強調一下，Magnum現在沒有調度模塊，因為現在支持的CoE有Swarm和Kubernetes，所以對Container的調度，完 全是通過Kubernetes和Swarm本身的調度器來工作的，Magnum只是負責將用戶創建container的請求進行轉發，轉發到對應的 CoE，最終的請求由具體的backend去調度。
Magnum現在也支持對Docker進行管理，但是因為沒有調度，目前建議對Docker的管理通過Swarm Bay來進行管理，因為Swarm是Docker官方的Docker集群管理工具。
Magnum現在還支持Multi tenant，每個租戶可以有自己的bay，baymodel，pod，service，rc等等，這樣可以保證不同租戶的資源隔離。每個租戶只能看到和操作屬于自己的資源。
Magnum現在本身不管理docker的網絡，都是通過上層的CoE自己去管理的，例如Kubernetes的bay現在通過flannel去管理，其實用的還是tunnel技術。
3.5 Magnum Bay
上圖是Magnum目前支持的兩個bay，Kubernetes和Swarm，Bay創建完成后，可以直接通過Magnum API和Kubernetes或者Swarm交互創建container。Magnum現在自己通過swagger實現了一套kubernetes api，magnum通過kubernetest的rest api來和后臺的kubernetes交互。
3.6 Magnum Roadmap
3.6.1網絡
第一個是網絡，網絡永遠是熱門話題，不管是在哪次峰會，現在Magnum也碰到了同樣的問題：Container的網絡怎樣管理，現在主要是通過 Kubernetes依賴于overlay network的flannel來管理，但是因為flannel的性能和擴展性的問題，Magnum社區正在討論對網絡方面進行改進，例如和 libnetwork或者neutron集成。這個bp在這 https://blueprints.launchpad.net/magnum/ spec/native-docker-network，非常歡迎對Docker網絡感興趣的人參與討論及實現。Magnum現在非常需要對網絡比較熟的人來共同推動這個bp。我現在在調查libnetwork，看能不能在Magnum去使用。
3.6.2 Mesos支持
另外一個是因為現在能夠提供容器服務的工具很多，Mesos也是比較流行的一個，所以Magnum正在計劃把Mesos集成進來，提供容器服務。這個bp在這 https://blueprints.launchpad.net/magnum/ spec/mesos-bay-type 第一版的Mesos支持，會是Mesos Marathon這樣一個組合。因為如果不依賴一個framework的話，mesos很難去使用。
3.6.3 Magnum界面
還有就是Magnum打算在L版做一個GUI界面，讓用戶更簡單的使用Magnum。現在這個bp正在review https://review.openstack.org/#/c/188958/
3.7 使用Magnum
3.7.1 檢查所有Baymodel
首先是通過命令”Magnum baymodel-list”查看Magnum中現在的所有的baymodel，可以看到現在主要有兩個OOB的baymodel：kubernetes和swarm
3.7.2 查看Baymodel詳細信息
通過“baymodel-show”查看Kubernetes Baymodel的詳細信息
3.7.3 創建Kubernetes Bay
通過“bay-create”創建了一個有兩個minions節點的kubernetes bay
3.7.4 檢查Kubernetes Bay拓撲結構
因為Kubernetes的bay實際上是heat的一個stack，所以創建后，可以通過horizon查看stack拓撲結構的顯示，從這里邊可以看到heat創建kubernetes bay的所有對象。
3.7.5 檢查Magnum Bay
我們可以通過bay-list查看bay的狀態，從這個圖可以看到Kubernets Bay已經創建完成了
3.7.6創建Kubernetes Pod
在Kubernetes bay的基礎上通過“pod-create”創建一個nginx pod，在這主要是通過Magnum的命令行創建這個pod。
3.7.7檢查Kubernetes Pod
創建完成后，可以通過Magnum “pod-list”，“pod-show”來查看pod狀態
3.7.8 Swarm相關
我們可以用同樣的方法來創建swarm的bay，通過swarm的bay來提供container service。
4. 問題
問：我觀察到k8s里面的cloud-provider里面有了openstack的插件。想問下，這個cloud-provider在magnum里是否有使用？如果使用了，是如何使用的？
答：現在Magnum在和Kubernetes社區合作，這個是Kubernetes社區貢獻給Magnum社區的，但是現在還沒用。
問：magnum現在是可以創建swarm集群，但是swarm沒有pod/service/Replication Controller的概念，這個magnum后期會有這方面的計劃把這些概念引入swarm集群么？
答：暫時沒有，現在Magnum還是分開管理k8s和swarm對象的，magnum api端的調用就可以指定用戶用的是k8s還是swarm。
問：magnum可以作為獨立模塊使用嗎？
答：現在還不行，因為需要依賴heat和keystone
問：我看你的命令截圖，想問下底層架構是openstack嗎？
答：是的，Magnum是OpenStack生態圈的一員，主打Container Service。
問：架構圖中左邊最下面那個micro os是docker引擎的載體？這是相當于還是要起一個實例嗎？能不能去掉這個載體，由openstack直接提供統一的docker引擎。
答：因為現在micro os已經提供了，所以社區暫時么有計劃通過openstack去提供，可能不想重復造輪子。
問：Magnum支持GUI的 L版什么時候出 ，會區分個人版和企業版嗎，會收費嗎？
答：L版會有個draft的gui，不收費的。openstack社區都是免費的
問：bay可以動態擴容嗎
答：可以，通過magnum bay-update
問：在magnum的網絡解決上libnetwork和Neutron區別在什么地方，各自的優勢是什么，現在有哪些難點需要解決？
答：這個我還在調查 現在還沒有一些結論 具體的可以關注這個bp https://blueprints.launchpad.net/magnum/ spec/native-docker-network ,我會定期的去append一些調查結果.希望對網絡感興趣的人 參與到 https://blueprints.launchpad.net/magnum/ spec/native-docker-network 這個bp的討論中來
問：Magnum的Blueprint寫著“Add support for mesos bay type”，bay type支持mesos, k8s, swarm，這個以后真的能做到統一抽象嗎？這三者之間差異化還不小。Magnum社區是怎么考慮的？
答：這是個非常難解的問題，這個可能還得需要在開發中，和社區討論，看能不能有一個折中的辦法：能抽象的盡量抽象，不能抽象的再定制。我們可以在OpenStack ML討論。
問：Magnum相對Kubernetes的優勢
答：magnum相對與Kubernetes的優勢主要有這么幾個：1）多租戶，不同的租戶有不同bay，baymodel等等 2）openstack為Kubernetes提供底層的基礎設施服務，openstack負責IaaS，Kubernetes負責 PaaS，Magnum負責聯通Kubernetes和openstack
問：magnum沒有顯式創建master node，是不是創建bay的時候就創建了k8s/swarm的master節點？多個k8s/swarm cluster就是創建多個bay就ok了？
答：答案都是yes，Magnum會自動創建Master節點。