歡迎光臨
每天分享高質量文章

OpenStack之Magnum容器編服務排引擎詳解

Magnum專案是OpenStack中的容器編排服務引擎,向上提供統一API,向下異構兼容K8S,Mesos,Swarm等容器管理平臺,是OpenStack與容器結合的官方正式專案。

說到基於 OpenStack的IaaS平臺上的Docker時,不得不提Magnum。Magnum旨在讓用戶可以直接在OpenStack環境中部署Containers,也是OpenStack和Docker集成支持度最好的專案。

 

上圖為所有Release中,各公司參與Magnum專案的Commits統計數量。不難看出,呈現出很明顯的4巨頭格局,IBM、Huawei、NEC 和 Intel。看得出來,國內華為對該專案的熱情和投入是非常高的。

談談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社區現在快速發展,也反應出了Magnum社區的一些情況。


主要列出了一些為Magnum做貢獻的公司,包括IBM、Rackspace、HPE、Cisco等等,IBM目前在這個專案排第一位。

通常情況下,一個公司對哪些專案比較看重,或者它對OpenStack社區的最近的一些策略,都可以通過分析每個公司對OpenStack的貢獻來得到一定的結論。如果某個公司在某個專案貢獻比較多的話,可能就意味著這個公司會在相關領域有一些動作。

如果大家如果感興趣的話,可以通過網站http://stackalytics.com/去研究一下自己感興趣的公司最近在OpenStack的一些動態。

為什麼是Magnum?

接下來我們看下為什麼需要Magnum、OpenStack現在和Docker集成現在主要有三塊,包括Nova Docker Driver,Heat Docker Driver和Kilo推出的Magnum,當然還包含一些別的專案,例如Sahara,Murano,Kolla,Solum等等。

Nova Docker Driver介紹


上圖是Nova Docker Driver,這個Driver是OpenStack和Docker的第一次集成,相信對Docker和OpenStack感興趣的人,應該都用過這個Driver,它把Docker作為一種新的Hypervisor來處理,把所有的Container當成VM來處理。提供了一個Docker的Nova Compute Driver。

這個Driver的優點是實現比較簡單,只需要把Nova Compute中的一些對虛擬機操作的常用接口實現就可以,現在主要支持創建,啟動,停止,暫停等虛擬機的基本操作。

另外一個是因為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不能實現的。

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 SPI和Docker交互的,所以Heat Docker Driver沒有資源調度,用戶需要在Template中指定需要在哪一臺Docker服務器上去部署應用,所以這個Driver不適合大規模應用,因為沒有資源調度。

另外因為沒有和Neutron去交互,所以網絡管理也只能用Docker本身的網絡管理功能,沒有Subnet,網絡隔離也做得不是太好,需要依賴於用戶手動配置Flannel或者OVS等等。

Magnum簡介


所以社區就推出了Magnum這個專案。上圖是Magnum的一個架構圖。

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個Container,多出來的那一個Container是Net Container,專門做路由的。

  • Service:可以理解為是Pod的一個路由,因為Pod在運行中可能被刪除或者IP發生變化,Service可以保證Pod的動態變化對訪問端是透明的。

  • Replication Controller:是Pod的複製抽象,用於解決Pod的擴容縮容問題。通常,分佈式應用為了性能或高可用性的考慮,需要複製多份資源,並且根據負載情況動態伸縮。通過Replication Controller,我們可以指定一個應用需要幾份複製,Kubernetes將為每份複製創建一個Pod,並且保證實際運行Pod數量總是與預先定義的數量是一致的(例如,當前某個Pod宕機時,自動創建新的Pod來替換)。

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)

Magnum工作流程

  • 第一步需要創建BayModel,就是為需要提供容器服務的bay創建一些集群的定義規格。

  • 第二步就可以在第一步創建的BayModel基礎上創建Bay了,用戶可以選擇使用Kubernetes或者Swarm,未來還會有Mesos。

  • 第三步,當bay創建完成後,用戶就可以通過呼叫Magnum API和後臺的k8s或者swarm交互來創建container了。

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技術。

Magnum Bay

上圖是Magnum目前支持的兩個Bay,Kubernetes和Swarm,Bay創建完成後,可以直接通過Magnum API和Kubernetes或者Swarm交互創建Container。



Magnum現在自己通過Swagger實現了一套自己的kubernetes API,Magnum通過kubernetest的Rest-API來和後臺的kubernetes交互。


簡單總結:Magnum自身作為一套 API 框架,本身呼叫其它的容器管理平臺的 API 來實現功能。目前支持的後端包括 Kubernetes、Swarm和Mesos。

如果說 Nova 是一套支持不同 Hypervisor 虛擬機平臺的 API 框架,那麼 Magnum 則是支持不同容器機制的 API 框架。Magnum Conductor是整個專案的核心,首先通過Heat部署虛擬機實體或者裸機實體上。然後通過Cloud init在虛擬機實體或者裸機實體上,呼叫Kubernetes、Swarm或者Mesos部署容器集群。

     更詳細內容,請點擊閱讀原文鏈接獲取(OpenStack技術和實戰詳解)電子書詳細信息。

溫馨提示:

請搜索“ICT_Architect”“掃一掃”二維碼關註公眾號,點擊原文鏈接獲取更多技術詳情

求知若渴, 虛心若愚

赞(0)

分享創造快樂