近年來，雲原生 （Cloud Native）可謂是 IT 界最火的概念之壹，眾多互聯網巨頭都已經開始積極擁抱雲原生。而說到雲原生，我們就不得不了解本文的主角 —— 容器（container）。容器技術可謂是撐起了雲原生生態的半壁江山。容器作為壹種先進的虛擬化技術，已然成為了雲原生時代軟件開發和運維的標準基礎設施，在了解它之前，我們不妨從虛擬化技術說起。
何謂虛擬化技術
1961 年 —— IBM709 機實現了分時系統
計算機歷史上首個虛擬化技術實現於 1961 年，IBM709 計算機首次將 CPU 占用切分為多個極短 (1/100sec) 時間片，每壹個時間片都用來執行著不同的任務。通過對這些時間片的輪詢，這樣就可以將壹個 CPU 虛擬化或者偽裝成為多個 CPU，並且讓每壹顆虛擬 CPU 看起來都是在同時運行的。這就是虛擬機的雛形。
容器的功能其實和虛擬機類似，無論容器還是虛擬機，其實都是在計算機不同的層面進行虛擬化，即使用邏輯來表示資源，從而擺脫物理限制的約束，提高物理資源的利用率。虛擬化技術是壹個抽象又內涵豐富的概念，在不同的領域或層面有著不同的含義。
這裏我們首先來粗略地講講計算機的層級結構。計算機系統對於大部分軟件開發者來說可以分為以下層級結構：
應用程序層
函數庫層
操作系統層
硬件層
各層級自底向上，每壹層都向上提供了接口，同時每壹層也只需要知道下壹層的接口即可調用底層功能來實現上層操作（不需要知道底層的具體運作機制）。
但由於早期計算機廠商生產出來的硬件遵循各自的標準和規範，使得操作系統在不同計算機硬件之間的兼容性很差；同理，不同的軟件在不同的操作系統下的兼容性也很差。於是，就有開發者人為地在層與層之間創造了抽象層：
應用層
函數庫層
API抽象層
操作系統層
硬件抽象層
硬件層
就我們探討的層面來說，所謂虛擬化就是在上下兩層之間，人為地創造出壹個新的抽象層，使得上層軟件可以直接運行在新的虛擬環境上。簡單來說，虛擬化就是通過模訪下層原有的功能模塊創造接口，來“欺騙”上層，從而達到跨平臺開發的目的。
綜合上述理念，我們就可以重新認識如今幾大廣為人知的虛擬化技術：
虛擬機：存在於硬件層和操作系統層間的虛擬化技術。
虛擬機通過“偽造”壹個硬件抽象接口，將壹個操作系統以及操作系統層以上的層嫁接到硬件上，實現和真實物理機幾乎壹樣的功能。比如我們在壹臺 Windows 系統的電腦上使用 Android 虛擬機，就能夠用這臺電腦打開 Android 系統上的應用。
容器：存在於操作系統層和函數庫層之間的虛擬化技術。
容器通過“偽造”操作系統的接口，將函數庫層以上的功能置於操作系統上。以 Docker 為例，其就是壹個基於 Linux 操作系統的 Namespace 和 Cgroup 功能實現的隔離容器，可以模擬操作系統的功能。簡單來說，如果虛擬機是把整個操作系統封裝隔離，從而實現跨平臺應用的話，那麽容器則是把壹個個應用單獨封裝隔離，從而實現跨平臺應用。所以容器體積比虛擬機小很多，理論上占用資源更少。
JVM：存在於函數庫層和應用程序之間的虛擬化技術。
Java 虛擬機同樣具有跨平臺特性，所謂跨平臺特性實際上也就是虛擬化的功勞。我們知道 Java 語言是調用操作系統函數庫的，JVM 就是在應用層與函數庫層之間建立壹個抽象層，對下通過不同的版本適應不同的操作系統函數庫，對上提供統壹的運行環境交給程序和開發者，使開發者能夠調用不同操作系統的函數庫。
在大致理解了虛擬化技術之後，接下來我們就可以來了解容器的誕生歷史。雖然容器概念是在 Docker 出現以後才開始在全球範圍內火起來的，但在 Docker 之前，就已經有無數先驅在探索這壹極具前瞻性的虛擬化技術。
容器的前身 “Jail”
1979 年 —— 貝爾實驗室發明 chroot
容器主要的特性之壹就是進程隔離。早在 1979 年，貝爾實驗室在 Unix V7 的開發過程中，發現當壹個系統軟件編譯和安裝完成後，整個測試環境的變量就會發生改變，如果要進行下壹次構建、安裝和測試，就必須重新搭建和配置測試環境。要知道在那個年代，壹塊 64K 的內存條就要賣 419 美元，“快速銷毀和重建基礎設施”的成本實在是太高了。
開發者們開始思考，能否在現有的操作系統環境下，隔離出壹個用來重構和測試軟件的獨立環境？於是，壹個叫做 chroot（Change Root）的系統調用功能就此誕生。
chroot 可以重定向進程及其子進程的 root 目錄到文件系統上的新位置，也就是說使用它可以分離每個進程的文件訪問權限，使得該進程無法接觸到外面的文件，因此這個被隔離出來的新環境也得到了壹個非常形象的命名，叫做 Chroot Jail （監獄）。之後只要把需要的系統文件壹並拷貝到 Chroot Jail 中，就能夠實現軟件重構和測試。這項進步開啟了進程隔離的大門，為 Unix 提供了壹種簡單的系統隔離功能，尤其是 jail 的思路為容器技術的發展奠定了基礎。但是此時 chroot 的隔離功能僅限於文件系統，進程和網絡空間並沒有得到相應的處理。
進入21世紀，此時的虛擬機（VM）技術已經相對成熟，人們可以通過虛擬機技術實現跨操作系統的開發。但由於 VM 需要對整個操作系統進行封裝隔離，占用資源很大，在生產環境中顯得太過於笨重。於是人們開始追求壹種更加輕便的虛擬化技術，眾多基於 chroot 擴展實現的進程隔離技術陸續誕生。
2000 年 —— FreeBSD 推出 FreeBSD Jail
在 chroot 誕生 21 年後，FreeBSD 4.0 版本推出了壹套微型主機環境***享系統 FreeBSD Jail，將 chroot 已有的機制進行了擴展。在 FreeBSD Jail 中，程序除了有自己的文件系統以外，還有獨立的進程和網絡空間，Jail 中的進程既不能訪問也不能看到 Jail 之外的文件、進程和網絡資源。
2001 年 —— Linux VServer 誕生
2001年，Linux 內核新增 Linux VServer（虛擬服務器），為 Linux 系統提供虛擬化功能。Linux VServer 采取的也是壹種 jail 機制，它能夠劃分計算機系統上的文件系統、網絡地址和內存，並允許壹次運行多個虛擬單元。
2004 年 —— SUN 發布 Solaris Containers
該技術同樣由 chroot 進壹步發展而來。2004 年 2 月，SUN 發布類 Unix 系統 Solaris 的 10 beta 版，新增操作系統虛擬化功能 Container，並在之後的 Solaris 10 正式版中完善。Solaris Containers 支持 x86 和 SPARC 系統，SUN 創造了壹個 zone 功能與 Container 配合使用，前者是壹個單壹操作系統中完全隔離的虛擬服務器，由系統資源控制和 zones 提供的邊界分離實現進程隔離。
2005 年 —— OpenVZ 誕生
類似於 Solaris Containers，它通過對 Linux 內核進行補丁來提供虛擬化、隔離、資源管理和狀態檢查 checkpointing。每個 OpenVZ 容器都有壹套隔離的文件系統、用戶及用戶組、進程樹、網絡、設備和 IPC 對象。
這個時期的進程隔離技術大多以 Jail 模式為核心，基本實現了進程相關資源的隔離操作，但由於此時的生產開發仍未有相應的使用場景，這壹技術始終被局限在了小眾而有限的世界裏。
就在此時，壹種名為“雲”的新技術正悄然萌發……
“雲”的誕生
2003 年至 2006 年間，Google 公司陸續發布了 3 篇產品設計論文，從計算方式到存儲方式，開創性地提出了分布式計算架構，奠定了大數據計算技術的基礎。在此基礎上，Google 顛覆性地提出“Google 101”計劃，並正式創造“雲”的概念。壹時間，“雲計算”、“雲存儲”等全新詞匯轟動全球。隨後，亞馬遜、IBM 等行業巨頭也陸續宣布各自的“雲”計劃，宣告“雲”技術時代的來臨。
也是從這時期開始，進程隔離技術進入了壹個更高級的階段。在 Google 提出的雲計算框架下，被隔離的進程不僅僅是壹個與外界隔絕但本身卻巍然不動的 Jail，它們更需要像壹個個輕便的容器，除了能夠與外界隔離之外，還要能夠被控制與調配，從而實現分布式應用場景下的跨平臺、高可用、可擴展等特性。
2006 年 —— Google 推出 Process Containers，後更名為 Cgroups
Process Container 是 Google 工程師眼中“容器”技術的雛形，用來對壹組進程進行限制、記賬、隔離資源（CPU、內存、磁盤 I/O、網絡等）。這與前面提到的進程隔離技術的目標其實是壹致的。由於技術更加成熟，Process Container 在 2006 年正式推出後，第二年就進入了 Linux 內核主幹，並正式更名為 Cgroups，標誌著 Linux 陣營中“容器”的概念開始被重新審視和實現。
2008 年 —— Linux 容器工具 LXC 誕生
在 2008 年，通過將 Cgroups 的資源管理能力和 Linux Namespace（命名空間）的視圖隔離能力組合在壹起，壹項完整的容器技術 LXC（Linux Container）出現在了 Linux 內核中，這就是如今被廣泛應用的容器技術的實現基礎。我們知道，壹個進程可以調用它所在物理機上的所有資源，這樣壹來就會擠占其它進程的可用資源，為了限制這樣的情況，Linux 內核開發者提供了壹種特性，進程在壹個 Cgroup 中運行的情況與在壹個命名空間中類似，但是 Cgroup 可以限制該進程可用的資源。盡管 LXC 提供給用戶的能力跟前面提到的各種 Jails 以及 OpenVZ 等早期 Linux 沙箱技術是非常相似的，但伴隨著各種 Linux 發行版開始迅速占領商用服務器市場，包括 Google 在內的眾多雲計算先鋒廠商得以充分活用這壹早期容器技術，讓 LXC 在雲計算領域獲得了遠超前輩的發展空間 。
同年，Google 基於 LXC 推出首款應用托管平臺 GAE （Google App Engine），首次把開發平臺當做壹種服務來提供。GAE 是壹種分布式平臺服務，Google 通過虛擬化技術為用戶提供開發環境、服務器平臺、硬件資源等服務，用戶可以在平臺基礎上定制開發自己的應用程序並通過 Google 的服務器和互聯網資源進行分發，大大降低了用戶自身的硬件要求。
值得壹提的是，Google 在 GAE 中使用了壹個能夠對 LXC 進行編排和調度的工具 —— Borg （Kubernetes 的前身）。Borg 是 Google 內部使用的大規模集群管理系統，可以承載十萬級的任務、數千個不同的應用、同時管理數萬臺機器。Borg 通過權限管理、資源***享、性能隔離等來達到高資源利用率。它能夠支持高可用應用，並通過調度策略減少出現故障的概率，提供了任務描述語言、實時任務監控、分析工具等。如果說壹個個隔離的容器是集裝箱，那麽 Borg 可以說是最早的港口系統，而 LXC + Borg 就是最早的容器編排框架。此時，容器已經不再是壹種單純的進程隔離功能，而是壹種靈活、輕便的程序封裝模式。
2011 年 —— Cloud Foundry 推出 Warden
Cloud Foundry 是知名雲服務供應商 VMware 在 2009 年推出的壹個雲平臺，也是業內首個正式定義 PaaS （平臺即服務）模式的項目，“PaaS 項目通過對應用的直接管理、編排和調度讓開發者專註於業務邏輯而非基礎設施”，以及“PaaS 項目通過容器技術來封裝和啟動應用”等理念都出自 Cloud Foundry。Warden 是 Cloud Foundry 核心部分的資源管理容器，它最開始是壹個 LXC 的封裝，後來重構成了直接對 Cgroups 以及 Linux Namespace 操作的架構。
隨著“雲”服務市場的不斷開拓，各種 PaaS 項目陸續出現，容器技術也迎來了壹個爆發式增長的時代，壹大批圍繞容器技術進行的創業項目陸續湧現。當然，後來的故事很多人都知道了，壹家叫 Docker 的創業公司橫空出世，讓 Docker 幾乎成為了“容器”的代名詞。
Docker 橫空出世
2013 年 —— Docker 誕生
Docker 最初是壹個叫做 dotCloud 的 PaaS 服務公司的內部項目，後來該公司改名為 Docker。Docker 在初期與 Warden 類似，使用的也是 LXC ，之後才開始采用自己開發的 libcontainer 來替代 LXC 。與其他只做容器的項目不同的是，Docker 引入了壹整套管理容器的生態系統，這包括高效、分層的容器鏡像模型、全局和本地的容器註冊庫、清晰的 REST API、命令行等等。
Docker 本身其實也是屬於 LXC 的壹種封裝，提供簡單易用的容器使用接口。它最大的特性就是引入了容器鏡像。Docker 通過容器鏡像，將應用程序與運行該程序需要的環境，打包放在壹個文件裏面。運行這個文件，就會生成壹個虛擬容器。
更為重要的是，Docker 項目還采用了 Git 的思路 —— 在容器鏡像的制作上引入了“層”的概念。基於不同的“層”，容器可以加入不同的信息，使其可以進行版本管理、復制、分享、修改，就像管理普通的代碼壹樣。通過制作 Docker 鏡像，開發者可以通過 DockerHub 這樣的鏡像托管倉庫，把軟件直接進行分發。
也就是說，Docker 的誕生不僅解決了軟件開發層面的容器化問題，還壹並解決了軟件分發環節的問題，為“雲”時代的軟件生命周期流程提供了壹套完整的解決方案。
很快，Docker 在業內名聲大噪，被很多公司選為雲計算基礎設施建設的標準，容器化技術也成為業內最炙手可熱的前沿技術，圍繞容器的生態建設風風火火地開始了。
容器江湖之爭
壹項新技術的興起同時也帶來了壹片新的市場，壹場關於容器的藍海之爭也在所難免。
2013 年 —— CoreOS 發布
在 Docker 爆火後，同年年末，CoreOS 應運而生。CoreOS 是壹個基於 Linux 內核的輕量級操作系統，專為雲計算時代計算機集群的基礎設施建設而設計，擁有自動化、易部署、安全可靠、規模化等特性。其在當時有壹個非常顯眼的標簽：專為容器設計的操作系統。
借著 Docker 的東風，CoreOS 迅速在雲計算領域躥紅，壹時間，Docker + CoreOS 成為業內容器部署的黃金搭檔。同時，CoreOS 也為 Docker 的推廣與社區建設做出了巨大的貢獻。
然而，日漸壯大的 Docker 似乎有著更大的“野心”。不甘於只做“壹種簡單的基礎單元”的 Docker，自行開發了壹系列相關的容器組件，同時收購了壹些容器化技術的公司，開始打造屬於自己的容器生態平臺。顯然，這對於 CoreOS 來說形成了直接的競爭關系。
2014 年 —— CoreOS 發布開源容器引擎 Rocket
2014 年末，CoreOS 推出了自己的容器引擎 Rocket （簡稱 rkt），試圖與 Docker 分庭抗禮。rkt 和 Docker 類似，都能幫助開發者打包應用和依賴包到可移植容器中，簡化搭環境等部署工作。rkt 和 Docker 不同的地方在於，rkt 沒有 Docker 那些為企業用戶提供的“友好功能”，比如雲服務加速工具、集群系統等。反過來說，rkt 想做的，是壹個更純粹的業界標準。
2014 年 —— Google 推出開源的容器編排引擎 Kubernetes
為了適應混合雲場景下大規模集群的容器部署、管理等問題，Google 在 2014 年 6 月推出了容器集群管理系統 Kubernetes （簡稱 K8S）。K8S 來源於我們前面提到的 Borg，擁有在混合雲場景的生產環境下對容器進行管理、編排的功能。Kubernetes 在容器的基礎上引入了 Pod 功能，這個功能可以讓不同容器之間互相通信，實現容器的分組調配。
得益於 Google 在大規模集群基礎設施建設的強大積累，脫胎於 Borg 的 K8S 很快成為了行業的標準應用，堪稱容器編排的必備工具。而作為容器生態圈舉足輕重的壹員，Google 在 Docker 與 rkt 的容器之爭中站在了 CoreOS 壹邊，並將 K8S 支持 rkt 作為壹個重要裏程碑。
2015 年 —— Docker 推出容器集群管理工具 Docker Swarm
作為回應，Docker 公司在 2015 年發布的 Docker 1.12 版本中也開始加入了壹個容器集群管理工具 Docker swarm 。
隨後，Google 於 2015 年 4 月領投 CoreOS 1200 萬美元， 並與 CoreOS 合作發布了首個企業發行版的 Kubernetes —— Tectonic 。從此，容器江湖分為兩大陣營，Google 派系和 Docker 派系。
兩大派系的競爭愈演愈烈，逐漸延伸到行業標準的建立之爭。
2015 年 6 月 —— Docker 帶頭成立 OCI
Docker 聯合 Linux 基金會成立 OCI （Open Container Initiative）組織，旨在“制定並維護容器鏡像格式和容器運行時的正式規範（“OCI Specifications”），圍繞容器格式和運行時制定壹個開放的工業化標準。
2015 年 7 月 —— Google 帶頭成立 CNCF
而戰略目標聚焦於“雲”的 Google 在同年 7 月也聯合 Linux 基金會成立 CNCF （Cloud Native Computing Foundation）雲原生計算基金會，並將 Kubernetes 作為首個編入 CNCF 管理體系的開源項目，旨在“構建雲原生計算 —— 壹種圍繞著微服務、容器和應用動態調度的、以基礎設施為中心的架構，並促進其廣泛使用”。
這兩大圍繞容器相關開源項目建立的開源基金會為推動日後的雲原生發展發揮了重要的作用，二者相輔相成，制定了壹系列行業事實標準，成為當下最為活躍的開源組織。
Kubernetes 生態壹統江湖
雖然這些年來 Docker 壹直力壓 rkt，成為當之無愧的容器壹哥，但作為壹個龐大的容器技術生態來說，Docker 生態還是在後來的容器編排之爭中敗給了 Google 的 Kubernetes 。
隨著越來越多的開發者使用 Docker 來部署容器，編排平臺的重要性日益突出。在 Docker 流行之後，壹大批開源項目和專有平臺陸續出現，以解決容器編排的問題。Mesos、Docker Swarm 和 Kubernetes 等均提供了不同的抽象來管理容器。這壹時期，對於軟件開發者來說，選擇容器編排平臺就像是壹場豪賭，因為壹旦選擇的平臺在以後的競爭中敗下陣來，就意味著接下來開發的東西在未來將失去市場。就像當初 Android、iOS 和 WP 的手機系統之爭壹樣，只有勝利者才能獲得更大的市場前景，失敗者甚至會銷聲匿跡。容器編排平臺之爭就此拉開帷幕。
2016 年 —— CRI-O 誕生
2016 年，Kubernetes 項目推出了 CRI （容器運行時接口），這個插件接口讓 kubelet（壹種用來創建 pod、啟動容器的集群節點代理）能夠使用不同的、符合 OCI 的容器運行時環境，而不需要重新編譯 Kubernetes。基於 CRI ，壹個名為 CRI-O 的開源項目誕生，旨在為 Kubernetes 提供壹種輕量級運行時環境。
CRI-O 可以讓開發者直接從 Kubernetes 來運行容器，這意味著 Kubernetes 可以不依賴於傳統的容器引擎（比如 Docker ），也能夠管理容器化工作負載。這樣壹來，在 Kubernetes 平臺上，只要容器符合 OCI 標準（不壹定得是 Docker），CRI-O 就可以運行它，讓容器回歸其最基本的功能 —— 能夠封裝並運行雲原生程序即可。
同時，CRI-O 的出現讓使用容器技術進行軟件管理和運維的人們發現，相對於 Docker 本身的標準容器引擎， Kubernetes 技術棧（比如編排系統、 CRI 和 CRI-O ）更適合用來管理復雜的生產環境。可以說，CRI-O 將容器編排工具放在了容器技術棧的重要位置，從而降低了容器引擎的重要性。
在 K8S 順利搶占先機的情況下，Docker 在推廣自己的容器編排平臺 Docker Swarm 時反而犯下了錯誤。2016 年底，業內曝出 Docker 為了更好地適配 Swarm，將有可能改變 Docker 標準的傳言。這讓許多開發者在平臺的選擇上更傾向於與市場兼容性更強的 Kubernetes 。
因此，在進入 2017 年之後，更多的廠商願意把寶壓在 K8S 上，投入到 K8S 相關生態的建設中來。容器編排之爭以 Google 陣營的勝利告壹段落。與此同時，以 K8S 為核心的 CNCF 也開始迅猛發展，成為當下最火的開源項目基金會。這兩年包括阿裏雲、騰訊、百度等中國科技企業也陸續加入 CNCF ，全面擁抱容器技術與雲原生。
結語
從數十年前在實驗室裏對進程隔離功能的探索，再到如今遍布生產環境的雲原生基礎設施建設，可以說容器技術凝聚了幾代開發者的心血，才從壹個小小的集裝箱發展到壹個大型的現代化港口。可以預見的是，從現在到未來很長壹段時間裏，容器技術都將是軟件開發和運維的重要基礎設施。