知識星球
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”或“掃一掃”二維碼關註公眾號，點選原文連結獲取更多技術詳情。
求知若渴, 虛心若愚
