引言：提到容器，大家第一時間都會想到Docker，畢竟Docker是目前最為流行的容器開源項目，它實現了一個容器引擎（Docker engine），并且為容器的創建和管理、容器鏡像的生成、分發和下載提供一套非常便利的工具鏈，而它的容器鏡像格式幾乎就是業界的事實標準。但其實除了Docker之外，在容器的開源生態圈中還有其它一些項目也在做自己的容器引擎，這樣的項目一般也被稱作為容器運行時（container runtime），比如：CoreOS的rkt和Mesos的容器引擎（Mesos containerizer）。在本文中，我將對Mesos容器引擎進行一個全面的介紹，解釋在Docker如此流行的情況下Mesos為什么還要堅持做自己的容器引擎，介紹Mesos容器引擎的總體架構和各核心組件，以及它對容器各相關標準規范的采納和支持。

容器和容器引擎的定義

首先我們來了解一下什么是容器。我個人對容器的定義是：一個或一組使用了cgroups做資源限定、使用了namespace做資源隔離、且使用了的鏡像文件做根文件系統的進程。如下圖1所示：

圖1

由此可見，實現容器的三大核心技術分別是：

Cgroups（Control Cgroups，控制群組）：Linux中的Cgroups包含多個不同的子系統，如：CPU、memory、device等。通過這些子系統就可以對容器能夠使用的各種資源進行限定，比如：通過CPU子系統可以限定容器使用CPU資源的相對權重和單位時間內能夠使用的的CPU時間。

Namespace（命名空間）：Linux同樣支持多個namespace，如：mount、network、pid等。通過這些namespace可以對容器進行不同維度的資源隔離，比如：通過mount namespace可以讓容器具有自己獨立的掛載空間，在主機或別的容器中發生的掛載事件對該容器就不可見，反之亦然。通過network namespace可以讓容器具有自己獨立的網絡協議棧，而不必和其所在主機共用同一個網絡協議棧。

Layered filesystem（分層文件系統）：Linux中的layered filesystem有多種不同的實現，如：AUFS、overlayfs等。通過這些layered filesystem配合mount namespace就可以快速部署出容器自己獨立的根文件系統。而且，基于同一個鏡像文件創建出來的多個容器可以共享該鏡像文件中相同的只讀分層，以達到節省主機磁盤空間的效果。

上面這三種技術都是在Linux系統中存在已久且相對成熟的技術，但讓終端用戶直接使用它們來創建和管理容器顯然并不方便。所以，容器引擎就應運而生了，它所做的主要工作就是將這三種技術在其內部有機地結合和利用起來以實現創建容器和管理容器的生命周期，并對外提供友好的接口讓用戶能夠方便的創建和管理容器。Cgroups、namespace和layered filesystem的詳細介紹我就不再本文中贅述了，感興趣的讀者可以查閱Linux中這三種技術的相關文檔。

需要指出的是，容器引擎對這三種技術的使用往往是有選擇且可定制的，比如：用戶可以通過容器引擎創建一個使用cgroups memory子系統但不使用CPU子系統的容器，這樣的容器對內存資源的使用就會受到相應的限定，但對CPU資源的使用則不受任何限定。用戶也可以創建一個使用mount namespace但不使用network namespace的容器，這樣的容器就會有自己獨立的掛載空間，但和主機共用一個網絡協議棧。Mesos容器引擎在這方面的可定制化進行得非常徹底，除了上面所說的對cgroups子系統和namespace的定制之外，Mesos容器引擎還能夠支持無鏡像文件創建容器，這是其它容器引擎所不具備的。

Mesos容器引擎產生的背景

在Docker如此流行的情況下，Mesos為什么還要堅持做自己的容器引擎呢？其實Mesos在很早期的版本就和Docker進行了集成，用戶可以通過Mesos創建一個Docker容器，在內部實現上，Mesos agent會調用Docker的命令行和Docker engine通信，以讓其創建Docker容器。這也就是意味著Mesos對容器的管理嚴重依賴于Docker engine，而這種做法的問題是：

穩定性不足：Mesos常常會被用來管理幾千甚至上萬節點的生產環境，而在如此大規模的生產環境中，穩定性是極其重要的。而在這樣的環境中，通過實測我們發現Docker engine的穩定性是有所不足的，有時會出現停止響應甚至一些莫名其妙的bug，而這樣的問題反映到Docker社區中后有時又無法及時得到解決。這就促使了Mesos的開發者開始設計和實現自己的容器引擎。

難于擴展：Mesos的用戶常常會提出一些和容器相關的新需求（比如：讓容器能夠使用GPU資源，通過CNI配置容器的網絡，等等），而這些需求都受限于Docker engine的實現，如果Docker社區拒絕采納這些需求，或有完全不同的實現方式，那Mesos作為Docker engine之上的調用方也無計可施。

眾所周知，Mesos的定位是數據中心操作系統，它是一個非常好的通用資源管理和資源調度系統，一開始就是一個“大腦級“的存在，但如果只有“大腦”沒有“四肢”（對容器的支持就是“四肢”的一種），或“四肢“掌握在別人手中，那Mesos本身和其生態圈的可持續發展顯然是受限的。所以，發展自己的“四肢”是Mesos逐步發展壯大的必然選擇。

基于上述這些原因，Mesos社區決定要做自己的容器引擎，這個容器引擎完全不依賴于Docker engine（即：和Docker engine沒有任何交互），但同時它又完美兼容Docker鏡像文件。這也就意味著，用戶可以通過Mesos在一臺沒有安裝運行Docker engine的主機上，基于任意Docker鏡像創建出容器。

Mesos容器引擎的總體架構和核心組件

首先我們來看一下Mesos的總體架構，以及容器引擎在其中的位置。?

圖2

上圖2中藍色部分是Mesos自身的組件，可以看到Mesos是典型的master + agent架構。Master運行在Mesos集群中的管理節點上，可以有多個（一般設置為三個、五個等奇數個），它們相互之間通過Zookeeper來進行leader選舉，被選舉成leader的master對外提供服務，而其他master則作為leader master的備份隨時待命。Master之上可以運行多個計算框架，它們會調用master提供的API發起創建任務的請求。Master之下可以管理任意多個計算節點，每個計算節點上都運行一個agent，它負責向master上報本節點上的計算資源，并接受master下發的創建任務的請求，將任務作為容器運行起來。而agent內部的一個組件containerizer就是用來管理容器的生命周期的（包括：容器的創建/更新/監控/銷毀），它就是Mesos的容器引擎。

我們再來進一步看一下Mesos容器引擎內部的總體架構和核心組件。?

圖3

如上圖所示，Meoss容器引擎內部包含了多個組件，主要有：launcher、provisioner（其內部又包含了store和backend兩個組件）和isolator。下面來逐一介紹這些組件的主要功能和用途。

Launcher

Launcher主要負責創建和銷毀容器，由于容器的本質其實就是主機上的進程，所以launcher在其內部實現上，主要就是在需要創建容器時，調用Linux系統調用fork()/clone()來創建容器的主進程，在需要銷毀容器時，調用Linux系統調用kill()來殺掉容器中的進程。Launcher在調用clone()時根據需要把容器創建在其自己的namespace中，比如：如果容器需要自己的網絡協議棧，那launcher在調用clone()時就會加入CLONE_NEWNET的參數來為容器創建一個自己的network namespace。

Launcher目前在Mesos中有兩種不同的實現：Linux launcher和Posix launcher，上面提到的就是Linux launcher的實現方式，Posix launcher適用于兼容Posix標準的任何環境，它主要是通過進程組（process group）和會話（session）來實現容器。在Linux環境中，Mesos agent會默認啟用Linux launcher。

Provisioner

為了支持基于鏡像文件創建容器，Mesos為其容器引擎引入了provisioner。這個組件完成的主要工作是通過store組件來下載和緩存指定的鏡像文件，通過backend組件基于指定的鏡像文件來部署容器的根文件系統。

Store

Mesos容器引擎中目前已經實現了Appc store和Docker store，分別用來支持Appc格式的鏡像和Docker鏡像，此外，Mesos社區正在實現OCI store以支持符合OCI（Open Container Initiative）標準格式的鏡像。所以基本上，針對每種不同的鏡像文件格式，Mesos都會去實現一個對應的store。而以后當OCI鏡像格式成為業界容器鏡像文件的標準格式時，我們可能會考慮在Mesos容器引擎中只保留一個OCI store。

Store下載的鏡像會被作為輸入傳給backend來去部署容器的根文件系統，且該鏡像會被緩存在agent本地的工作目錄中，當用戶基于同一鏡像再次創建一個容器時，Store就不會重復下載該鏡像，而是直接把緩存中的鏡像傳給backend。

Backend

Backend的主要工作就是基于指定鏡像來部署容器的根文件系統。目前Mesos容器引擎中實現了四個不同的backend：

AUFS：AUFS是Linux中的一種分層文件系統。AUFS backend就是借助這種分層文件系統把指定鏡像文件中的多個分層掛載組合成一個完整的根文件系統給容器使用。基于同一鏡像文件創建出來的多個容器共享相同的只讀層，且各自擁有獨立的可寫層。

Overlay：Overlay backend和AUFS backend非常類似，它是借助Overlayfs來掛載組合容器的根文件系統。Overlayfs也是一種分層文件系統，它的原理和AUFS類似， 所以，AUFS backend所具備的優點Overlay backend都有，但不同的是Overlayfs已經被Linux標準內核所接受，所以，它在Linux平臺上有更好的支持。

Copy：Copy backend的做法非常簡單，它就是簡單地把指定鏡像文件的所有分層都拷貝到一個指定目錄中作為容器的根文件系統。它的缺點顯而易見：基于同一鏡像創建的多個容器之間無法共享任何分層，這對計算節點的磁盤空間造成了一定的浪費，且在拷貝鏡像分層時也會消耗較大的磁盤I/O。

Bind：Bind backend比較特殊，它只能夠支持單分層的鏡像。它是利用bind mount這一技術把單分層的鏡像以只讀的方式掛載到指定目錄下作為容器的根文件系統。相對于Copy backend，Bind backend的速度更快（幾乎不需要消耗磁盤I/O），且多個容器可以共享同一鏡像，但缺點就是只能支持單分層鏡像，且根文件系統是只讀的，如果容器在運行時需要寫入數據，就只能通過額外掛載外部卷的方式來實現。

在用戶沒有指定使用某種backend的情況下，Mesos agent在啟動時會以如下邏輯來自動啟用一種backend：

如果本節點支持Overlayfs，啟用Overlay backend。

如果本節點不支持Overlayfs但支持AUFS，啟用AUFS backend。

如果OverlayFS和AUFS都不支持，啟用Copy backend。?
由于Bind backend的局限性較大，Mesos agent并不會自動啟用它。

Isolator

Isolator負責根據用戶創建容器時提出的需求，為每個容器進行指定的資源限定，且指引launcher為容器進行相應的資源隔離。目前Mesos內部已經實現了十多個不同的isolator，比如：cgroups isolator通過Linux cgroups來對容器進行CPU、memory等資源的限定，而CNI isolator會指引launcher為每個容器創建一個獨立network namespace以實現網絡隔離，并調用CNI插件為容器配置網絡（如：IP地址、DNS等）。

Isolator在Mesos中有著非常好的模塊化設計，且定義了一套非常清晰的API接口讓每個isolator可以根據自己所需要完成的功能去有選擇地實現。這套isolator接口貫穿容器的整個生命周期，Mesos容器引擎會在容器生命周期的不同階段通過對應的接口來調用isolator完成不同的功能。下面是一些主要的isolator接口：

• prepare()：這個接口在容器被創建之前被調用，用來完成一些準備性的工作。比如：cgroups isolator在這個接口中會為容器創建對應的cgroups。

• isolate()：這個接口在容器剛剛被創建出來但還未運行時被調用，用來進行一些資源隔離性的工作，比如：cgroups isolator在這個接口中會把容器的主進程放入上一步創建的cgroups中以實現資源隔離。

• update()：當容器所申請的資源發生變化時（如：容器在運行時申請使用更多的CPU資源），這個接口會被調用，它用來在運行時動態調整對容器的資源限定。

• cleanup()：當容器被銷毀時這個接口會被調用到，用來進行相關的清理工作。比如：cgroups isolator會把之前為容器創建的cgroups刪除。

借助于這種模塊化和接口標準化的設計，用戶可以很方便地根據自己的需求去實現一個自己的isolator，然后將其插入到Mesos agent中去完成特定資源的限定和隔離。

Mesos容器引擎對容器標準規范的支持

容器這項技術在近幾年來飛速發展，實現了爆炸式的增長。但就像任何一種成熟的技術一樣，在度過了“野蠻生長期”后，都需要制定相應的規范來對其進行標準化，讓它能夠持續穩定地發展。容器技術也不例外，目前已知的容器相關的標準規范有：

OCI（Open Container Initiative）：專注于容器鏡像文件格式和容器生命周期管理的規范，目前已經發布了1.0的版本。

CNI（Container Network Interface）：專注于容器網絡支持的規范，目前已經發布了0.6.0版本。

CSI（Container Storage Interface）：專注于容器存儲支持的規范，目前還在草案階段。

標準規范帶來的益處是顯而易見的：

對于終端用戶：標準化的容器鏡像和容器運行時能夠讓用戶不必擔心自己被某個容器引擎所“綁架”，可以更加專注于對自身業務和應用的容器化，更加自由地去選擇容器引擎。

對于網絡/存儲提供商：標準規范中定義的網絡/存儲集成接口把容器引擎的內部實現和不同的網絡/存儲解決方案隔離開來，讓各提供商只需實現一套標準化接口就可以把自己的解決方案方便地集成到各個容器引擎中去，而不必費時費力地去逐個適配不同的容器引擎。

Mesos容器引擎在設計和實現之初，就持有擁抱和采納業界標準規范的態度，是最早支持CNI的容器引擎之一，且目前正在積極實現對OCI鏡像規范的支持。CSI目前正在由Mesos社區和Kubernets社區一起主導并逐步完善，待CSI逐漸成熟后，Mesos容器引擎自然會第一時間支持。日后，作為同時支持三大標準規范的容器引擎，Mesos容器引擎自然會更好地服務上層應用框架和終端用戶，同時更加完善地支持各種主流網絡/存儲解決方案。

作者簡介：張乾，目前就職于Mesosphere，擔任Mesosphere中國區研發負責人。國內首位Apache Mesos committer，專注于各種容器相關的開源技術。?

本文為《程序員》原創文章，未經允許不得轉載，更多精彩文章請訂閱《程序員》，給我們投稿請聯系郵箱weiwei@csdn.net。

---

全天候聚焦IaaS/PaaS/SaaS最新技術動態，深度挖掘技術大咖第一手實踐，及時推送云行業重大新聞，一鍵關注，總覽國內外云計算大勢！?

總結

以上是生活随笔為你收集整理的Mesos容器引擎的架构设计和实现解析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。