背景

“云原生技術(shù)有利于各組織在公有云、私有云和混合云等新型動態(tài)環(huán)境中，構(gòu)建和運行可彈性擴展的應(yīng)用。云原生的代表技術(shù)包括容器、服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明式API?！?/p>

聊容器技術(shù)避不開云原生，聊云原生也避不開容器技術(shù)。容器技術(shù)和云原生就是一對雙螺旋體，容器技術(shù)催生了云原生思潮，云原生生態(tài)推動了容器技術(shù)發(fā)展。從2013年docker（container）技術(shù)誕生，到2015年CNCF這個云原生領(lǐng)域重量級聯(lián)盟便成立，這不是歷史的巧合而是歷史的必然。作為云原生關(guān)鍵技術(shù)之一的容器，從2013年誕生以來一直是行業(yè)關(guān)注的焦點之一。借用一張業(yè)界廣泛引用的云原生容器技術(shù)進階圖來了解一下容器技術(shù)和云原生誕生的歷史背景。

先讓我們一起來看看容器技術(shù)發(fā)展的歷史紀年表，先直觀感受一下這片如火如荼的熱土吧！

1979年，Unix v7系統(tǒng)支持chroot，為應(yīng)用構(gòu)建一個獨立的虛擬文件系統(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 進入了 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)起頭并進。

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)。2017年底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ù)萌芽期

容器技術(shù)需要解決的核心問題之一運行時的環(huán)境隔離。容器的運行時環(huán)境隔離，目標是給容器構(gòu)造一個無差別的運行時環(huán)境，用以在任意時間、任意位置運行容器鏡像。由于docker的布道，大家習(xí)慣性認為容器的運行時環(huán)境隔離就是OS虛擬化，或則容器等于namespace + cgroup + 安全防護機制。我不太贊同這種看法，這個只是一段歷史時期、一種容器運行時的實現(xiàn)技術(shù)，還有很多種其它可能的技術(shù)方案來實現(xiàn)容器運行環(huán)境。所以，回到需求的本源：容器需要運行時隔離技術(shù)來保證容器的運行環(huán)境符合預(yù)期。習(xí)慣上，大家把這種實現(xiàn)容器隔離技術(shù)的組件叫做容器運行時。

從另外一個角度看，容器隔離技術(shù)解決的是資源供給問題。為啥需要容器隔離技術(shù)來解決資源供給問題呢？成也蕭何，敗也蕭何！摩爾定律實在太過強大，它讓我們有了越來越多的計算資源可以使用。10年前做小型機時，小型機的典型規(guī)格是32路8核CPU，現(xiàn)在一臺4路PC服務(wù)器計算能力都超過10年前的小型機服務(wù)器。小型機的典型用法是把整機切分為多個分區(qū)使用。觀察當(dāng)下云服務(wù)硬件發(fā)展趨勢，越來越有熟悉的感覺，我們在把小型機相關(guān)技術(shù)“軍轉(zhuǎn)民”。現(xiàn)在我們一臺PC服務(wù)器擁有了非常強大的、能和十年前小型機媲美的計算能力，巧合的是當(dāng)下PC服務(wù)器的典型用法也和十年前的小型機用法類似，切割為1-8vCPU的虛擬機/容器使用。

為什么人們總是習(xí)慣于把一個大的服務(wù)器資源切分為小的分區(qū)使用而不是研發(fā)能夠充分發(fā)揮大型服務(wù)器整機計算能力的軟件呢？個人認為背后有兩個制約因素：

待解決問題本身內(nèi)在的并行度有限。隨著多核多處理器系統(tǒng)的日益普及，IT行業(yè)從2004年開始進行串行編程到并行編程的升級改造。開始階段針對特定行業(yè)應(yīng)用的并行化改造效果非常明顯，但是后來發(fā)現(xiàn)隨著并行度提高改造成本越來越大、收益卻越來越低。受阿姆達爾定律制約，解決特定問題的并行度超過一定臨界點之后收益將逐漸變小。所以一味提高系統(tǒng)并行度并不是經(jīng)濟的做法。

人類智力有限。受人類智力限制，系統(tǒng)越復(fù)雜、并行度越高，軟件越容易出故障，軟件維護代價成指數(shù)級增長。所以，從軟件工程看，大家也趨向于接口化、模塊化、單元化的軟件架構(gòu)設(shè)計，盡量控制軟件的復(fù)雜度，降低工程成本。

從經(jīng)驗看，1-8個CPU的并行度是軟件工程的舒適區(qū)，這個也是容器化、微服務(wù)等技術(shù)背后的驅(qū)動因素之一。

有點跑題了。。。總之，基于隔離的資源供給不是偽需求。對于軟件運行環(huán)境的隔離要求，從操作系統(tǒng)出現(xiàn)之初就有了。多任務(wù)分時操作系統(tǒng)和進程虛擬地址都是為了解決多個任務(wù)運行在同一臺主機上的資源共享問題，讓每個進程都以為自己獨占主機。當(dāng)然僅僅是進程隔離是遠遠不夠的?？v觀當(dāng)前的資源隔離技術(shù)，我們大致可以將資源隔離技術(shù)分成5類：

進程隔離。OS以進程作為Task運行過程的抽象，進程擁有獨立的地址空間和執(zhí)行上下文，本質(zhì)上OS對進程進行了CPU和內(nèi)存虛擬化。但是進程之間還共享了文件系統(tǒng)、網(wǎng)絡(luò)協(xié)議棧、IPC通信空間等多種資源，進程之間因為資源爭搶導(dǎo)致的干擾很嚴重。這個層級的隔離適合在不同的主機上運行單個用戶的不同程序，由用戶通過系統(tǒng)管理手段來保證資源分配與安全防護等問題。

OS虛擬化。OS隔離，也就是大家常說的操作系統(tǒng)虛擬化（OS virtualization），是進程隔離的升華版。進程隔離是為每個進程實現(xiàn)了單獨的地址空間及CPU上下文，OS隔離則是利用操作系統(tǒng)分身術(shù)為每一組進程實例構(gòu)造出一個獨立的OS環(huán)境，以進一步虛擬化文件系統(tǒng)、網(wǎng)絡(luò)協(xié)議棧、IPC通信空間、進程ID、用戶ID等OS資源。OS隔離需要解決三個核心問題：獨立視圖、訪問控制及安全防護。Chroot、Linux namespace機制為進程組實現(xiàn)獨立視圖，cgroup對進程組進行訪問控制，而Capabilities、Apparmor、seccomp等機制則實現(xiàn)安全防護。當(dāng)然，OS是一個非常復(fù)雜、動態(tài)變化的系統(tǒng)，OS分身術(shù)雖然讓進程組感覺有了獨立的OS，但是真實實現(xiàn)還是一個OS實例，所以整體防護能力還是堪憂。

硬件虛擬化。OS虛擬化是實現(xiàn)OS內(nèi)核的分身術(shù)，而硬件虛擬化則是實現(xiàn)硬件設(shè)備的分身術(shù)。硬件虛擬化技術(shù)的出現(xiàn)，讓同一個物理服務(wù)器上能夠同時運行多個操作系統(tǒng)，每個操作系統(tǒng)都認為自己在管理一臺完整的服務(wù)器。不同操作系統(tǒng)之間是嚴格隔離的，Guest操作系統(tǒng)對硬件的訪問都是受VMM或CPU的嚴格監(jiān)管的。硬件虛擬化既有很好的安全性，也有很好的隔離性，缺點就是引入的硬件虛擬化層導(dǎo)致了額外的性能開銷。

硬件分區(qū)。這個是傳統(tǒng)小型機體系采用的資源分隔技術(shù)，就是從硬件或固件層徹底把一臺大型服務(wù)器分隔為多個硬件單元，從而獲得最高等級的安全性和隔離性。但是小型機作為一個逐步?jīng)]落的技術(shù)路線，其不足之處還是顯而易見的：資源分隔粒度不靈活、系統(tǒng)成本偏高、系統(tǒng)可擴展性受限。

語言運行時隔離。對于Java、nodejs等需要language runtime的managed language，我們還有一個選項，就是在language runtime里實現(xiàn)隔離。針對函數(shù)計算等云原生服務(wù)，理論上在語言運行時實現(xiàn)隔離機制是最優(yōu)路徑。但是這條路線目前實現(xiàn)上還有不少現(xiàn)實的制約，所以目前多數(shù)函數(shù)計算還是采用的容器/VM技術(shù)來實現(xiàn)的隔離。

在OS虛擬化這條技術(shù)路線上，最大的技術(shù)貢獻來源于Google。2003-2006年，Google陸續(xù)發(fā)布的“三駕馬車”，奠定了大數(shù)據(jù)計算的框架，隨后進一步創(chuàng)造了“云”的概念。也是從這時期開始，進程隔離技術(shù)進入了一個更高級的階段。在 Google 提出的云計算框架下，被隔離的進程不僅僅是一個與外界隔絕但本身卻巍然不動的 Jail，它們更需要像一個個輕便的容器，除了能夠與外界隔離之外，還要能夠被控制與調(diào)配，從而實現(xiàn)分布式應(yīng)用場景下的跨平臺、高可用、可擴展等特性。2006年，Google推出Process Containers，用來對一組進程進行限制、記賬、隔離資源（CPU、內(nèi)存、磁盤 I/O、網(wǎng)絡(luò)等）。由于技術(shù)更加成熟，Process Container 在 2006 年正式推出后，第二年就進入了 Linux 內(nèi)核主干，并正式更名為 Cgroups，標志著 Linux 陣營中“容器”的概念開始被重新審視和實現(xiàn)。在 2008 年，通過將 Cgroups 的資源管理能力和 Linux Namespace （命名空間）的視圖隔離能力組合在一起，一項完整的容器技術(shù) LXC （Linux Container）出現(xiàn)在了 Linux 內(nèi)核中，這就是如今被廣泛應(yīng)用的容器技術(shù)的實現(xiàn)基礎(chǔ)。

總體看，在2013年docker被發(fā)明以前，Linux操作系統(tǒng)已經(jīng)大體上解決了容器核心技術(shù)之一的運行環(huán)境隔離技術(shù)，或者說Linux OS虛擬化技術(shù)已經(jīng)基本上成型了。雖然容器運行環(huán)境隔離技術(shù)已經(jīng)基本就位，我們?nèi)孕璧却硗庖豁楆P(guān)鍵技術(shù)才能迎來容器技術(shù)的騰飛時刻。

技術(shù)迸發(fā)期

2013年之前，云計算行業(yè)一直在為云原生的正確打開姿勢而操心。Platform as a Service（PaaS）看起來是個有前途的方向。2006年Fotango公司發(fā)布的Zimi服務(wù)，可以說是PaaS行業(yè)的鼻祖，具有按使用付費、免運維（Serverless）、API化配置和服務(wù)等典型云原生的特征；2008年Google推出GAE；2011年P(guān)ivotal發(fā)布Cloud Foundry。這些早期的PaaS平臺進行了非常有益的探索，推動了云計算生態(tài)的健康發(fā)展，但是這些早期探索技術(shù)并沒有形成大的行業(yè)趨勢，而是局限在一些的特定的領(lǐng)域。直到Docker開源，大家才如夢方醒，原來不是方向不對，而是應(yīng)用分發(fā)和交付的手段不行。

Docker真正核心的創(chuàng)新是容器鏡像（docker image），一種新型的應(yīng)用打包、分發(fā)和運行機制。容器鏡像將應(yīng)用運行環(huán)境，包括代碼、依賴庫、工具、資源文件和元信息等，打包成一種操作系統(tǒng)發(fā)行版無關(guān)的不可變更軟件包。

容器鏡像打包了整個容器運行依賴的環(huán)境，以避免依賴運行容器的服務(wù)器的操作系統(tǒng)，從而實現(xiàn)“build once，run anywhere”。

容器鏡像一但構(gòu)建完成，就變成read only，成為不可變基礎(chǔ)設(shè)施的一份子。

操作系統(tǒng)發(fā)行版無關(guān)，核心解決的是容器進程對操作系統(tǒng)包含的庫、工具、配置的依賴，但是容器鏡像無法解決容器進程對內(nèi)核特性的特殊依賴。這個在實際使用容器的過程中也經(jīng)常跳進這個大坑：

Docker的宣傳口號是“Build，Ship and Run Any App，Anywhere”。我們已經(jīng)理解了docker通過container image解決“Run Anywhere”的機制，那么“Run Any App”是如何實現(xiàn)的呢？其實也是依賴container image，用戶可以打包任何容器進程所依賴的環(huán)境，而不用改造應(yīng)用來適配PaaS定義的運行環(huán)境。真是“Run Any App”一舉打破了PaaS行業(yè)面臨的困境，創(chuàng)造出了無限的可能性，大力推動了云原生的發(fā)展。讓我們一起來向這個偉大的創(chuàng)意致敬！

至此，容器技術(shù)體系已經(jīng)解決了最核心的兩個問題：如何發(fā)布軟件和如何運行軟件，騰飛時刻即將到來。2014年前司前老板對我說“別成天搞Linux kernel了，要不你看看docker？” 經(jīng)過短暫的調(diào)研，我給了前老板一個簡單而清晰的回答，“無它，唯打包工具爾！”因為這個回答，云原生為我打開的一扇大門就悄悄關(guān)上了?；叵胍幌職v史，有時也挺懊悔的，因為自己太年輕而沒有看清楚容器技術(shù) + 編排系統(tǒng)的威力，更沒有體會到云原生即將到來的氣息！

Docker作為一個單機軟件打包、發(fā)布、運行系統(tǒng)，其價值是非常巨大的；但是僅僅將docker技術(shù)局限在單機范圍不能發(fā)揮這個創(chuàng)新技術(shù)的最大價值，自然下一步業(yè)界希望基于docker技術(shù)構(gòu)建一個云化的集群系統(tǒng)，來對業(yè)務(wù)容器進行編排管理。

聊到容器編排系統(tǒng)，我們需要從Google聊起。2008年，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)資源進行分發(fā)。Google 在 GAE 中使用了一個能夠?qū)?LXC 進行編排和調(diào)度的工具 —— Borg （Kubernetes 的前身）。Borg 是 Google 內(nèi)部使用的大規(guī)模集群管理系統(tǒng)，可以承載十萬級的任務(wù)、數(shù)千個不同的應(yīng)用、同時管理數(shù)萬臺機器。Borg 通過權(quán)限管理、資源共享、性能隔離等來達到高資源利用率。它能夠支持高可用應(yīng)用，并通過調(diào)度策略減少出現(xiàn)故障的概率，提供了任務(wù)描述語言、實時任務(wù)監(jiān)控、分析工具等。如果說一個個隔離的容器是集裝箱，那么 Borg 可以說是最早的港口系統(tǒng)，而 LXC + Borg 就是最早的容器編排框架。

2013年docker推出之后迅速席卷全球，2014年Google基于內(nèi)部使用的Borg系統(tǒng)創(chuàng)建了開源項目Kubernetes（簡稱K8S），用于解決大規(guī)模集群的容器部署、運行、管理等問題。Kubernetes在容器的基礎(chǔ)上增加了一層的新的管理抽象Pod，以便更好地利用容器進行應(yīng)用的功能模塊切分。得益于 Google 在大規(guī)模集群基礎(chǔ)設(shè)施建設(shè)的強大積累，脫胎于 Borg 的 K8S 很快成為了行業(yè)的標準應(yīng)用，堪稱容器編排的必備工具。

作為回應(yīng)，Docker公司在2015年發(fā)布的Docker 1.12版本中也加入了一個容器集群管理系統(tǒng)Docker swarm，以及配套的Docker machine、Docker Compose等工具，力圖構(gòu)建完善的容器編排系統(tǒng)，和Kubernetes展開正面競爭。從此，容器江湖分為兩大陣營：Google派和Docker派；而容器編排系統(tǒng)則是Kubernetes，Docker Swarm和Apache Mesos三國并立。各大派系的競爭愈演愈烈，逐漸延伸到行業(yè)標準的建立之爭。讓我們一起來回憶一下這段風(fēng)起云涌的江湖歷史吧！

2013年Docker公司推出docker之后，緊接著CoreOS 應(yīng)運而生。CoreOS 是一個基于 Linux 內(nèi)核的輕量級操作系統(tǒng)，專為云計算時代計算機集群的基礎(chǔ)設(shè)施建設(shè)而設(shè)計，擁有自動化、易部署、安全可靠、規(guī)模化等特性。其在當(dāng)時有一個非常顯眼的標簽：專為容器設(shè)計的操作系統(tǒng)。借著 Docker 的東風(fēng)，CoreOS 迅速在云計算領(lǐng)域躥紅，一時間，Docker + CoreOS 成為業(yè)內(nèi)容器部署的黃金搭檔。同時，CoreOS 也為 Docker 的推廣與社區(qū)建設(shè)做出了巨大的貢獻。然而，日漸壯大的 Docker 似乎有著更大的“野心”。不甘于只做“一種簡單的基礎(chǔ)單元”的 Docker，自行開發(fā)了一系列相關(guān)的容器組件，同時收購了一些容器化技術(shù)的公司，開始打造屬于自己的容器生態(tài)平臺。

顯然，這對于 CoreOS 來說形成了直接的競爭關(guān)系。2014 年末，CoreOS 推出了自己的容器引擎 Rocket （簡稱 rkt），試圖與 Docker 分庭抗禮。rkt 和 Docker 類似，都能幫助開發(fā)者打包應(yīng)用和依賴包到可移植容器中，簡化搭環(huán)境等部署工作。rkt 和 Docker 不同的地方在于，rkt 沒有 Docker 那些為企業(yè)用戶提供的“友好功能”，比如云服務(wù)加速工具、集群系統(tǒng)等。反過來說，rkt 想做的，是一個更純粹的業(yè)界標準。

上面這段材料引至于“從虛擬化到云原生——容器技術(shù)的發(fā)展史”，為什么大段大段地引用這部分材料呢？這里面最關(guān)鍵的脈絡(luò)是由于技術(shù)公司之間的商業(yè)競爭，在競爭合作之間尋找平衡從而導(dǎo)致了標準規(guī)范的誕生，而標準規(guī)范的誕生是整個云原生生態(tài)最重要的基石。

容器引擎（docker vs rocket）、容器編排（Docker swarm vs Kubernetes vs Apache Mesos）的相互競爭的結(jié)果就是大家坐下來談接口標準。2015年6月，Docker帶頭成立OCI，旨在“制定并維護容器鏡像格式和容器運行時的正式規(guī)范（OCI Specifications）”，其核心產(chǎn)出是OCI Runtime Spec（容器運行時規(guī)范）、OCI Image Spec（鏡像格式規(guī)范）、OCI Distribution Spec（鏡像分發(fā)規(guī)范）。

所以O(shè)CI組織解決的是容器的構(gòu)建、分發(fā)和運行問題。一個月之后，Google帶頭成立了Cloud Native Computing Foundation（CNCF），旨在“構(gòu)建云原生計算 —— 一種圍繞著微服務(wù)、容器和應(yīng)用動態(tài)調(diào)度的、以基礎(chǔ)設(shè)施為中心的架構(gòu)，并促進其廣泛使用”。所以CNCF組織解決的是應(yīng)用管理及容器編排問題。這兩個圍繞容器的基金會對云原生生態(tài)的發(fā)展發(fā)揮了非常重要的作用，二者不是競爭而是相輔相成，共同制定了一系列行業(yè)事實標準。這些行業(yè)事實標準的確立，各行業(yè)注入了無限活力，基于接口的標準的具體實現(xiàn)不斷涌現(xiàn)，呈現(xiàn)出一片百花齊放的景象。

其中，與容器相關(guān)的最為重要的幾個規(guī)范包括：CRI、CNI、CSI、OCI Distribution Spec、OCI Image Spec、OCI Runtime Spec和Shimv2。其中的CRI、OCI Image Spec、OCI Runtime和Shimv2規(guī)范和阿里云沙箱容器關(guān)系非常密切。

所以，非常感謝這個云原生、容器技術(shù)迸發(fā)的黃金期，一群有創(chuàng)意的人走到一起共同創(chuàng)造了這幾個關(guān)鍵的規(guī)范，為各個廠商提供各具特色且遵循規(guī)范的技術(shù)實現(xiàn)提供了可能性。

商用探索期

經(jīng)過5年的技術(shù)發(fā)展期，容器技術(shù)基本成熟，云原生體系也具雛型。從2017年開始，各大云廠商開始試水容器服務(wù)及進步的云原生服務(wù)。從目前的商業(yè)形態(tài)看，容器相關(guān)的公共云服務(wù)大致可以劃分為三種形態(tài)：

通用容器編排服務(wù)。在容器編排系統(tǒng)三國殺結(jié)果出來以前，基于多方下注策略構(gòu)建的容器編排服務(wù)系統(tǒng)。其中AWS是自研的編排系統(tǒng)，Azure的ACS同時支持Docker Swarm、DC/OS和Kubernetes，阿里云ACS則是支持Docker swarm和Kubernetes。Google和華為則是堅定支持Kubernetes而未推出支持其它容器編排系統(tǒng)的容器服務(wù)。隨著Kubernetes一統(tǒng)容器編排江湖，這條路線的容器服務(wù)日漸式微，Azure更是在今年初直接終止了ACS服務(wù)。

Kubernetes容器編排服務(wù)。Google是理所當(dāng)然最早試水Kubernetes容器編排服務(wù)的大廠，也較早開展了K8S容器編排服務(wù)。隨著2017年各大廠在CNCF這張談判桌上達成了Kubernetes兼容性認證流程，Kubernetes編排服務(wù)市場迎來一輪大爆發(fā)，到2018年各大云廠商的K8S容器編排服務(wù)就完整就位了。

Serverless容器實例服務(wù)。從2017年開始，行業(yè)開始試水Serverless容器實例服務(wù)，把用戶從維護容器基礎(chǔ)設(shè)施的繁重任務(wù)中解放出來從而聚焦業(yè)務(wù)本身。Google Cloud Run核心目標是支持Knative，所以其使用形態(tài)上附加了不少約束條件。

從上圖可以看出，從2014年開始探索公共云容器服務(wù)，特別是經(jīng)過2017-2018年這兩年的搶跑期，容器服務(wù)的基本商業(yè)形態(tài)已經(jīng)比較明晰了。發(fā)展態(tài)勢可以概括為：

行業(yè)對容器化的接受程度已經(jīng)很高，容器化普及率也是逐年提升。

容器編排系統(tǒng)已經(jīng)一戰(zhàn)定江山，K8S成為事實上的容器編排之王。

Serverless容器實例服務(wù)受到市場的歡迎，客戶群體日益擴大。

長期看托管容器編排服務(wù)和Serverless容器實例服務(wù)將長期共存，協(xié)同滿足客戶對服務(wù)成本和彈性能力的需求。

商用模式探索期間，核心目標是快速試錯引導(dǎo)和確認客戶需求，構(gòu)建適用的產(chǎn)品形態(tài)。這個期間的產(chǎn)品技術(shù)架構(gòu)的構(gòu)建思路是利用現(xiàn)有成熟技術(shù)快速搭建商用形態(tài)，在試錯過程中不斷前行。

其中，容器編排托管服務(wù)節(jié)點級的典型架構(gòu)是利用IaaS系統(tǒng)生成VM，然后在VM里面部署kubelet、docker、containerd、runC等容器服務(wù)組件，也就是VM + 容器的技術(shù)架構(gòu)。一個VM可以承載同一個用戶的多個容器/Pod實例。而Serverless容器實例服務(wù)的節(jié)點級架構(gòu)更直接，在一個VM里面只部署一個容器/Pod實例，從而實現(xiàn)Serverless。這種短平快的打法快速推進了商用模型的探索，起到了非常重要的歷史作用，但是其在彈性能力、部署密度、資源成本方面的歷史局限性還是很大的。

商用拓展期

到2019年，容器服務(wù)的商業(yè)形態(tài)以及市場趨勢已經(jīng)很明顯了，行業(yè)整體進入了商業(yè)拓展階段，對外宣傳吸引更多的客戶群體，對內(nèi)苦練內(nèi)功提升產(chǎn)品技術(shù)競爭力，行業(yè)正在經(jīng)歷從“有”到“優(yōu)”的技術(shù)升級。行業(yè)正在經(jīng)歷這個技術(shù)升級的歷史階段，還談不上結(jié)論，只能一起來聊聊趨勢及預(yù)判。本系列專題的關(guān)注點是容器隔離技術(shù)，所以先不聊商業(yè)拓展和容器編排而聚焦于容器引擎技術(shù)發(fā)展趨勢。到現(xiàn)在為止，我們大體上可以把容器引擎技術(shù)劃分為兩代：

Container on VM。也就是按照分層設(shè)計思路，通過IaaS + PaaS的架構(gòu)構(gòu)建容器服務(wù)，這個是商用探索階段的典型架構(gòu)?；诟鞔笤茝S商成熟的IaaS基礎(chǔ)設(shè)施生產(chǎn)虛擬機，在虛擬機里面部署容器服務(wù)組件。這種架構(gòu)采用的是lift and shift策略，把容器服務(wù)的運維責(zé)任從用戶轉(zhuǎn)移到云廠商。采用和用戶相同的軟件組件，只是轉(zhuǎn)移運維責(zé)任，有利于引導(dǎo)客戶逐步上云、接受云原生思維。但是這個時期云廠商提供的服務(wù)是單純的運維托管，相對用戶自建容器服務(wù)并沒有太明顯的技術(shù)優(yōu)勢，甚至受多租戶隔離的限制部分使用體驗還不如用戶自建容器服務(wù)。

Container with hardware virtualization。如果沿用Container on VM的分層設(shè)計架構(gòu)，云廠商很難構(gòu)建獨有的技術(shù)優(yōu)勢。對于Serverless容器實例服務(wù)，服務(wù)交付平面已經(jīng)從IaaS的硬件接口上移到OS Syscall，所以不要遵循VM + 容器的分層設(shè)計思路。我們需要從需求本源出發(fā)，容器服務(wù)需要高性能、強隔離、夠安全和低成本的容器引擎。當(dāng)前行業(yè)研發(fā)熱點之一就是如何構(gòu)建這樣一個容器引擎，具體技術(shù)思路請留意后續(xù)系列文章。

小結(jié)

總結(jié)來看，容器服務(wù)生態(tài)大概經(jīng)歷了四個階段，分別解決或試圖解決不同的問題：

技術(shù)萌芽期：解決了容器運行環(huán)境的隔離問題

技術(shù)迸發(fā)期：解決了軟件分發(fā)及容器編排問題

商用探索期：確認了容器的商用服務(wù)形態(tài)

商用拓展期：擴大適用場景和部署規(guī)模，通過技術(shù)創(chuàng)新提升產(chǎn)品競爭力

閑言碎語

聊了這么多歷史，讓我們再來閑聊一下docker這個公司和docker這門技術(shù)吧！

2019年11月13日，私有云基礎(chǔ)設(shè)施公司Mirantis在其官方博客宣布，收購Docker公司企業(yè)級業(yè)務(wù)，包括接管它的700多個客戶，這標志著Docker公司從2013年開始的商業(yè)化探索徹底失敗。在不了解容器發(fā)展歷史的人看來，這種結(jié)果很難理解，Docker是容器熱潮的開創(chuàng)者，容器則是這一輪云計算技術(shù)演進的開啟者，為什么明明站在風(fēng)口上了，卻仍然飛不起來？

其實，Docker今天的命運，在4年前就決定了。2014年Kubernetes發(fā)布后，迅速吸引了包括Redhat在內(nèi)的一批重量級成員，并在一年之后迅速發(fā)布Kubernetes 1.0以支撐正式商用。作為回應(yīng)Docker公司主導(dǎo)成立了OCI，旨在為容器鏡像格式和運行時制定一個開放標準，從而繼續(xù)占據(jù)容器生態(tài)的話語權(quán)。但是2015年7月CNCF成立之后，迅速彎道超車開辟新的戰(zhàn)場，主攻容器編排與應(yīng)用管理。隨后2016年Kubernetes社區(qū)制定了容器運行時的接口規(guī)范CRI，只要實現(xiàn)這個CRI規(guī)范的容器運行時就可以和K8S生態(tài)對接，從引發(fā)了容器引擎的研發(fā)熱潮。cri-containerd，cri-o，frakti等引擎不斷涌現(xiàn)，加上原有的rkt引擎，docker變成了容器引擎蕓蕓眾生中的一員。從哪兒來到哪兒去，docker又回到了最初的狀態(tài)，一個單機版軟件打包運行工具，基本上完美錯過了云原生浪潮。

但是在相當(dāng)長的時期內(nèi)，docker這個客戶端容器管理工具（UI）還是會長期存在的，畢竟強大的用戶群體在哪兒。但是在云服務(wù)廠商的技術(shù)棧中，docker的地位會越來越弱，逐步被K8S專用的容器引擎替代。雖然現(xiàn)在docker的群眾基礎(chǔ)依然強大，但是星星之火已經(jīng)點燃，趨勢已然顯現(xiàn)，剩下的只是時間問題！

原文標題：容器技術(shù)之發(fā)展簡史

文章出處：【微信公眾號：Linuxer】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。

責(zé)任編輯：haq