引言：提到容器，大家第一時間都會想到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鏡像創建出容器。

相關電子資料下載