這是一個建立於 的文章,其中的資訊可能已經有所發展或是發生改變。
【編者的話】今天主要跟大家簡單介紹下Magnum社區和Magnum項目的一些介紹。Magnum到現在為止,功能做的其實不是很多,希望通過這次機會能和大家多多討論下,看看怎樣讓Magnum提供更好的Container Service。
1.Magnum社區
Mangum現在應該是OpenStack裡邊比較熱門的一個和Docker整合的新項目。Magnum是去年巴黎峰會後開始的一個新的專門針對Container的一個新項目,用來向使用者提供Container Service。從去年11月份開始在stackforge提交第一個patch,今年3月份進入OpenStack namespace,這個項目應該是OpenStack社區從stackforge遷移到OpenStack namespace最快的一個項目。Magnum現在可以為使用者提供Kubernetes as a Service、Swarm as a Service和這幾個平台整合的主要目的是能讓使用者可以很方便的通過OpenStack雲平台來管理k8s,swarm,這些已經很成型的Docker叢集管理系統,使使用者很方便的使用這些容器管理系統來提供Container Service。
通過這個圖主要是想強調下,就是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的主要概念,在這個圖的右邊,主要有這麼幾個:Bay、Baymodel、Node、Pod、Service、RC、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,就是為需要提供Container Service的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支援
另外一個是因為現在能夠提供Container Service的工具很多,Mesos也是比較流行的一個,所以Magnum正在計劃把Mesos整合進來,提供Container Service。這個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。
Q&A
問:我觀察到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節點。
=====================================================
以上內容根據2015年6月16日晚群分享內容整理。分享人
劉光亞,2008年於西安交通大學軟體學院獲得碩士學位,目前就職於IBM Platform Computing系統科技部雲端運算部門,擔任雲端運算開發部架構師。自2013年5月開始參與OpenStack社區的開發工作,已為 OpenStack社區貢獻了200多個Patch,涉及Nova、Cinder、Heat、Magnum等項目,並擔任Magnum的Core Member。微博:platformer。 DockOne每周都會組織定向的技術分享,歡迎感興趣的同學參與。