近年來，云原生 （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 ，全面擁抱容器技術與云原生。

?

總結

以上是生活随笔為你收集整理的从虚拟化到云原生——容器技术的发展史的全部內容，希望文章能夠幫你解決所遇到的問題。

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