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