![1.png](https://ucc.alicdn.com/pic/developer-ecology/4d685d1e32db4bc1b52d984794516d72.png)

作者 | 劉獎

# 背景

“雲原生技術有利於各組織在**公有云、私有云和混合雲**等新型動態環境中，構建和執行可彈性擴充套件的應用。雲原生的代表技術包括**容器、服務網格、微服務、不可變基礎設施和宣告式 API**。”

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

![2.png](https://ucc.alicdn.com/pic/developer-ecology/bcfb969800034e0b975c8007dc46a514.png)

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

> 1979 年，Unix v7 系統支援 chroot，為應用構建一個獨立的虛擬檔案系統檢視。
> 1999 年，FreeBSD 4.0 支援 jail，第一個商用化的 OS 虛擬化技術。
> 2004 年，Solaris 10 支援 Solaris Zone，第二個商用化的 OS 虛擬化技術。
> 2005 年，OpenVZ 釋出，非常重要的 Linux OS 虛擬化技術先行者。
> 2004 年 ~ 2007 年，Google 內部大規模使用 Cgroups 等的 OS 虛擬化技術。
> 2006 年，Google 開源內部使用的 process container 技術，後續更名為 cgroup。
> 2008 年，Cgroups 進入了 Linux 核心主線。
> 2008 年，LXC（Linux Container）專案具備了 Linux 容器的雛型。
> 2011 年，CloudFoundry 開發 Warden 系統，一個完整的容器管理系統雛型。
> 2013 年，Google 透過 Let Me Contain That For You (LMCTFY) 開源內部容器系統。
> 2013 年，Docker 專案正式釋出，讓 Linux 容器技術逐步席捲天下。
> 2014 年，Kubernetes 專案正式釋出，容器技術開始和編排系統起頭並進。
> 2015 年，由 Google，Redhat、Microsoft 及一些大型雲廠商共同創立了 CNCF，雲原生浪潮啟動。
> 2016 年 - 2017 年，容器生態開始模組化、規範化。CNCF 接受 Containerd、rkt專案，OCI 釋出 1.0，CRI/CNI 得到廣泛支援。
> 2017 年 - 2018 年，容器服務商業化。AWS ECS，Google EKS，Alibaba ACK/ASK/ECI，華為 CCI，Oracle Container Engine for Kubernetes；VMware，Redhat 和 Rancher 開始提供基於 Kubernetes 的商業服務產品。
> 2017 年 - 2019 年，容器引擎技術飛速發展，新技術不斷湧現。2017 年底 Kata Containers 社群成立，2018 年 5 月 Google 開源 gVisor 程式碼，2018 年 11 月 AWS 開源 firecracker，阿里雲釋出安全沙箱 1.0。
> 2020 年 - 202x 年，容器引擎技術升級，Kata Containers 開始 2.0 架構，阿里雲釋出沙箱容器 2.0....

整理容器技術近 20 年的發展歷史，大致可以將其分為四個歷史階段，下文將詳細介紹這四個歷史階段。

![3.jpg](https://ucc.alicdn.com/pic/developer-ecology/63b9bc2ec90c48c9ad9cb167e4068f72.jpg)

# 技術萌芽期

容器技術需要解決的核心問題之一是執行時的環境隔離。

容器的執行時環境隔離，目標是給容器構造一個無差別的執行時環境，用以在任意時間、任意位置執行容器映象。由於 docker 的佈道，大家習慣性認為容器的執行時環境隔離就是 OS 虛擬化，或者容器等於 namespace + cgroup + 安全防護機制。我不太贊同這種看法，這個只是一段歷史時期、一種容器執行時的實現技術，還有很多種其它可能的技術方案來實現容器執行環境。所以，回到需求的本源：**容器需要執行時隔離技術來保證容器的執行環境符合預期**。習慣上，大家把這種實現容器隔離技術的元件叫做容器執行時。

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

為什麼人們總是習慣於把一個大的伺服器資源切分為小的分割槽使用而不是研發能夠充分發揮大型伺服器整機計算能力的軟體呢？個人認為背後有兩個制約因素：

- **待解決問題本身內在的並行度有限**。隨著多核多處理器系統的日益普及，IT 行業從 2004 年開始進行序列程式設計到並行程式設計的升級改造。開始階段針對特定行業應用的並行化改造效果非常明顯，但是後來發現隨著並行度提高改造成本越來越大、收益卻越來越低。受阿姆達爾定律制約，解決特定問題的並行度超過一定臨界點之後收益將逐漸變小。所以一味提高系統並行度並不是經濟的做法。

- **人類智力有限**。受人類智力限制，系統越複雜、並行度越高，軟體越容易出故障，軟體維護代價成指數級增長。所以，從軟體工程看，大家也趨向於介面化、模組化、單元化的軟體架構設計，儘量控制軟體的複雜度，降低工程成本。

從經驗看，1-8 個 CPU 的並行度是軟體工程的舒適區，這個也是容器化、微服務等技術背後的驅動因素之一。

有點跑題了。。。總之，基於隔離的資源供給不是偽需求。對於軟體執行環境的隔離要求，從作業系統出現之初就有了。多工分時作業系統和程式虛擬地址都是為了解決多個任務執行在同一臺主機上的資源共享問題，讓每個程式都以為自己獨佔主機。當然僅僅是程式隔離是遠遠不夠的。縱觀當前的資源隔離技術，我們大致可以將資源隔離技術分成 5 類：

![4.jpg](https://ucc.alicdn.com/pic/developer-ecology/a55b23f1cd824495a64e02c854c4a32e.jpg)

- **程式隔離**。OS 以程式作為 Task 執行過程的抽象，程式擁有獨立的地址空間和執行上下文，本質上 OS 對程式進行了 CPU 和記憶體虛擬化。但是程式之間還共享了檔案系統、網路協議棧、IPC 通訊空間等多種資源，程式之間因為資源爭搶導致的干擾很嚴重。這個層級的隔離適合在不同的主機上執行單個使用者的不同程式，由使用者透過系統管理手段來保證資源分配與安全防護等問題。

- **OS 虛擬化**。OS 隔離，也就是大家常說的作業系統虛擬化（OS virtualization），是程式隔離的昇華版。程式隔離是為每個程式實現了單獨的地址空間及 CPU 上下文，OS 隔離則是利用作業系統分身術為每一組程式例項構造出一個獨立的 OS 環境，以進一步虛擬化檔案系統、網路協議棧、IPC 通訊空間、程式 ID、使用者 ID 等 OS 資源。OS 隔離需要解決三個核心問題：獨立檢視、訪問控制及安全防護。Chroot、Linux namespace 機制為程式組實現獨立檢視，cgroup 對程式組進行訪問控制，而 Capabilities、Apparmor、seccomp 等機制則實現安全防護。當然，OS 是一個非常複雜、動態變化的系統，OS 分身術雖然讓程式組感覺有了獨立的 OS，但是真實實現還是一個 OS 例項，所以整體防護能力還是堪憂。

- **硬體虛擬化**。OS 虛擬化是實現 OS 核心的分身術，而硬體虛擬化則是實現硬體裝置的分身術。硬體虛擬化技術的出現，讓同一個物理伺服器上能夠同時執行多個作業系統，每個作業系統都認為自己在管理一臺完整的伺服器。不同作業系統之間是嚴格隔離的，Guest 作業系統對硬體的訪問都是受 VMM 或 CPU 的嚴格監管的。硬體虛擬化既有很好的安全性，也有很好的隔離性，缺點就是引入的硬體虛擬化層導致了額外的效能開銷。

- **硬體分割槽**。這個是傳統小型機體系採用的資源分隔技術，就是從硬體或韌體層徹底把一臺大型伺服器分隔為多個硬體單元，從而獲得最高等級的安全性和隔離性。但是小型機作為一個逐步沒落的技術路線，其不足之處還是顯而易見的：資源分隔粒度不靈活、系統成本偏高、系統可擴充套件性受限。

- **語言執行時隔離**。對於 Java、nodejs 等需要 language runtime 的 managed language，我們還有一個選項，就是在 language runtime 裡實現隔離。針對函式計算等雲原生服務，理論上在語言執行時實現隔離機制是最優路徑。但是這條路線目前實現上還有不少現實的制約，所以目前多數函式計算還是採用的容器 / VM 技術來實現的隔離。

在 OS 虛擬化這條技術路線上，最大的技術貢獻來源於 Google。

2003 - 2006 年，Google 陸續釋出的“三駕馬車”，奠定了大資料計算的框架，隨後進一步創造了“雲”的概念。也是從這時期開始，程式隔離技術進入了一個更高階的階段。在 Google 提出的雲端計算框架下，被隔離的程式不僅僅是一個與外界隔絕但本身卻巍然不動的 Jail，它們更需要像一個個輕便的容器，除了能夠與外界隔離之外，還要能夠被控制與調配，從而實現分散式應用場景下的跨平臺、高可用、可擴充套件等特性。

2006 年，Google 推出 Process Containers，用來對一組程式進行限制、記賬、隔離資源（CPU、記憶體、磁碟 I/O、網路等）。由於技術更加成熟，Process Container 在 2006 年正式推出後，第二年就進入了 Linux 核心主幹，並正式更名為 Cgroups，標誌著 Linux 陣營中“容器”的概念開始被重新審視和實現。

在 2008 年，透過將 Cgroups 的資源管理能力和 Linux Namespace （名稱空間）的檢視隔離能力組合在一起，一項完整的容器技術 LXC （Linux Container）出現在了 Linux 核心中，這就是如今被廣泛應用的容器技術的實現基礎。

**總體看，在 2013 年 docker 被發明以前，Linux 作業系統已經大體上解決了容器核心技術之一的執行環境隔離技術，或者說 Linux OS 虛擬化技術已經基本上成型了**。雖然容器執行環境隔離技術已經基本就位，我們仍需等待另外一項關鍵技術才能迎來容器技術的騰飛時刻。

# 技術迸發期

2013 年之前，雲端計算行業一直在為雲原生的正確開啟姿勢而操心。Platform as a Service（PaaS）看起來是個有前途的方向。2006 年 Fotango 公司釋出的 Zimi 服務，可以說是 PaaS 行業的鼻祖，具有按使用付費、免運維（Serverless）、API 化配置和服務等典型雲原生的特徵；2008 年 Google 推出 GAE；2011 年 Pivotal 釋出 Cloud Foundry。這些早期的 PaaS 平臺進行了非常有益的探索，推動了雲端計算生態的健康發展，但是這些早期探索技術並沒有形成大的行業趨勢，而是侷限在一些的特定的領域。直到 Docker 開源，大家才如夢方醒，原來不是方向不對，而是應用分發和交付的手段不行。

Docker 真正核心的創新是容器映象（docker image），一種新型的應用打包、分發和執行機制。容器映象將應用**執行環境**，包括程式碼、依賴庫、工具、資原始檔和元資訊等，打包成一種**作業系統發行版**無關的**不可變更**軟體包。

- 容器映象打包了整個容器執行依賴的環境，以避免依賴執行容器的伺服器的作業系統，從而實現 “build once，run anywhere”。

- 容器映象一旦構建完成，就變成 read only，成為不可變基礎設施的一份子。

- 作業系統發行版無關，核心解決的是容器程式對作業系統包含的庫、工具、配置的依賴，但是容器映象無法解決容器程式對核心特性的特殊依賴。這個在實際使用容器的過程中也經常跳進這個大坑：

Docker 的宣傳口號是 “Build，Ship and Run Any App，Anywhere”。我們已經理解了 docker 透過container image 解決“Run Anywhere”的機制，那麼“Run Any App”是如何實現的呢？其實也是依賴 container image，使用者可以打包任何容器程式所依賴的環境，而不用改造應用來適配 PaaS 定義的執行環境。真是“Run Any App”一舉打破了 PaaS 行業面臨的困境，創造出了無限的可能性，大力推動了雲原生的發展。讓我們一起來向這個偉大的創意致敬！

![5.png](https://ucc.alicdn.com/pic/developer-ecology/5a752c36ee0b4c799aefc4a41944753a.png)

至此，容器技術體系已經解決了最核心的兩個問題：**如何釋出軟體**和**如何執行軟體**，騰飛時刻即將到來。2014 年前司前老闆對我說“別成天搞 Linux kernel 了，要不你看看 docker？” 經過短暫的調研，我給了前老闆一個簡單而清晰的回答，“無它，唯打包工具爾！”因為這個回答，雲原生為我開啟的一扇大門就悄悄關上了。回想一下歷史，有時也挺懊悔的，因為自己太年輕而沒有看清楚容器技術 + 編排系統的威力，更沒有體會到雲原生即將到來的氣息！

Docker 作為一個單機軟體打包、釋出、執行系統，其價值是非常巨大的；但是僅僅將 docker 技術侷限在單機範圍不能發揮這個創新技術的最大價值，自然下一步業界希望基於 docker 技術構建一個雲化的叢集系統，來對業務容器進行編排管理。

聊到容器編排系統，我們需要從 Google 聊起。2008 年，Google 基於 LXC 推出首款應用託管平臺 GAE （Google App Engine），首次把開發平臺當做一種服務來提供。

GAE 是一種分散式平臺服務，Google 透過虛擬化技術為使用者提供開發環境、伺服器平臺、硬體資源等服務，使用者可以在平臺基礎上定製開發自己的應用程式並透過 Google 的伺服器和網際網路資源進行分發。Google 在 GAE 中使用了一個能夠對 LXC 進行編排和排程的工具 —— Borg （Kubernetes 的前身）。Borg 是 Google 內部使用的大規模叢集管理系統，可以承載十萬級的任務、數千個不同的應用、同時管理數萬臺機器。Borg 透過許可權管理、資源共享、效能隔離等來達到高資源利用率。它能夠支援高可用應用，並透過排程策略減少出現故障的機率，提供了任務描述語言、實時任務監控、分析工具等。如果說一個個隔離的容器是集裝箱，那麼 Borg 可以說是最早的港口系統，而 LXC + Borg 就是最早的容器編排框架。

2013 年 docker 推出之後迅速席捲全球，2014 年 Google 基於內部使用的 Borg 系統建立了開源專案 Kubernetes（簡稱 K8s），用於解決大規模叢集的容器部署、執行、管理等問題。Kubernetes 在容器的基礎上增加了一層的新的管理抽象 Pod，以便更好地利用容器進行應用的功能模組切分。得益於 Google 在大規模叢集基礎設施建設的強大積累，脫胎於 Borg 的 K8s 很快成為了行業的標準應用，堪稱容器編排的必備工具。

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

> 2013 年 Docker 公司推出 docker 之後，緊接著 CoreOS 應運而生。CoreOS 是一個基於 Linux 核心的輕量級作業系統，專為雲端計算時代計算機叢集的基礎設施建設而設計，擁有自動化、易部署、安全可靠、規模化等特性。其在當時有一個非常顯眼的標籤：**專為容器設計的作業系統**。藉著 Docker 的東風，CoreOS 迅速在雲端計算領域躥紅，一時間，Docker + CoreOS 成為業內容器部署的黃金搭檔。
> 同時，CoreOS 也為 Docker 的推廣與社群建設做出了巨大的貢獻。然而，日漸壯大的 Docker 似乎有著更大的“野心”。不甘於只做“一種簡單的基礎單元”的 Docker，自行開發了一系列相關的容器元件，同時收購了一些容器化技術的公司，開始打造屬於自己的容器生態平臺。顯然，這對於 CoreOS 來說形成了直接的競爭關係。2014 年末，CoreOS 推出了自己的容器引擎 Rocket （簡稱 rkt），試圖與 Docker 分庭抗禮。rkt 和 Docker 類似，都能幫助開發者打包應用和依賴包到可移植容器中，簡化搭環境等部署工作。rkt 和 Docker 不同的地方在於，rkt 沒有 Docker 那些為企業使用者提供的“友好功能”，比如雲服務加速工具、叢集系統等。反過來說，rkt 想做的，是一個更純粹的業界標準。

上面這段材料引至於“從虛擬化到雲原生——容器技術的發展史”，為什麼大段大段地引用這部分材料呢？這裡面最關鍵的脈絡是**由於技術公司之間的商業競爭，在競爭合作之間尋找平衡從而導致了標準規範的誕生，而標準規範的誕生是整個雲原生生態最重要的基石**。

容器引擎（docker vs rocket）、容器編排（Docker swarm vs Kubernetes vs Apache Mesos）的相互競爭的結果就是大家坐下來談介面標準。2015 年 6 月，Docker 帶頭成立 OCI，旨在“制定並維護容器映象格式和容器執行時的正式規範（OCI Specifications）”，其核心產出是 OCI Runtime Spec（容器執行時規範）、OCI Image Spec（映象格式規範）、OCI Distribution Spec（映象分發規範）。所以 **OCI 組織解決的是容器的構建、分發和執行問題**。

一個月之後，Google 帶頭成立了 Cloud Native Computing Foundation（CNCF），旨在“構建雲原生計算 —— 一種圍繞著微服務、容器和應用動態排程的、以基礎設施為中心的架構，並促進其廣泛使用”。所以 **CNCF 組織解決的是應用管理及容器編排問題**。這兩個圍繞容器的基金會對雲原生生態的發展發揮了非常重要的作用，二者不是競爭而是相輔相成，共同制定了一系列行業事實標準。這些行業事實標準的確立，各行業注入了無限活力，基於介面的標準的具體實現不斷湧現，呈現出一片百花齊放的景象。

![6.jpg](https://ucc.alicdn.com/pic/developer-ecology/85bf5e2933c240d8b8f5fd3a4c246c29.jpg)

其中，與容器相關的最為重要的幾個規範包括：CRI、CNI、CSI、OCI Distribution Spec、OCI Image Spec、OCI Runtime Spec 和 Shimv2。其中的 CRI、OCI Image Spec、OCI Runtime 和 Shimv2 規範和阿里雲沙箱容器關係非常密切。

**所以，非常感謝這個雲原生、容器技術迸發的黃金期，一群有創意的人走到一起共同創造了這幾個關鍵的規範，為各個廠商提供各具特色且遵循規範的技術實現提供了可能性**。

# 商用探索期

經過 5 年的技術發展期，容器技術基本成熟，雲原生體系也具雛型。從 2017 年開始，各大雲廠商開始試水容器服務及進步的雲原生服務。從目前的商業形態看，容器相關的公共雲服務大致可以劃分為三種形態：

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

2. **Kubernetes 容器編排服務**。Google 是理所當然最早試水 Kubernetes 容器編排服務的大廠，也較早開展了 K8s 容器編排服務。隨著 2017 年各大廠在 CNCF 這張談判桌上達成了 Kubernetes 相容性認證流程，Kubernetes 編排服務市場迎來一輪大爆發，到 2018 年各大雲廠商的 K8s 容器編排服務就完整就位了。

3. **Serverless 容器例項服務**。從 2017 年開始，行業開始試水 Serverless 容器例項服務，把使用者從維護容器基礎設施的繁重任務中解放出來從而聚焦業務本身。Google Cloud Run 核心目標是支援 Knative，所以其使用形態上附加了不少約束條件。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/a63bf381988d4d4e8b0b8a83ed4c7ae0.png)

從上圖可以看出，從 2014 年開始探索公共雲容器服務，特別是經過 2017 - 2018 年這兩年的搶跑期，容器服務的基本商業形態已經比較明晰了。發展態勢可以概括為：

- 行業對容器化的接受程度已經很高，容器化普及率也是逐年提升。

- 容器編排系統已經一戰定江山，K8s 成為事實上的容器編排之王。

- Serverless 容器例項服務受到市場的歡迎，客戶群體日益擴大。

- 長期看託管容器編排服務和 Serverless 容器例項服務將長期共存，協同滿足客戶對服務成本和彈效能力的需求。

商用模式探索期間，核心目標是快速試錯引導和確認客戶需求，構建適用的產品形態。這個期間的產品技術架構的構建思路是利用現有成熟技術快速搭建商用形態，在試錯過程中不斷前行。

其中，容器編排託管服務節點級的典型架構是利用 IaaS 系統生成 VM，然後在 VM 裡面部署 kubelet、docker、containerd、runC 等容器服務元件，也就是 **VM + 容器的技術架構**。一個 VM 可以承載同一個使用者的多個容器 / Pod 例項。而 Serverless 容器例項服務的節點級架構更直接，**在一個 VM 裡面只部署一個容器 / Pod 例項，從而實現 Serverless**。這種短平快的打法快速推進了商用模型的探索，起到了非常重要的歷史作用，但是其在彈效能力、部署密度、資源成本方面的歷史侷限性還是很大的。

![8.jpg](https://ucc.alicdn.com/pic/developer-ecology/f8c114c7d24b472fb27b0b2c7c3efe64.jpg)

# 商用擴充期

到 2019 年，容器服務的商業形態以及市場趨勢已經很明顯了，**行業整體進入了商業擴充階段，對外宣傳吸引更多的客戶群體，對內苦練內功提升產品技術競爭力，行業正在經歷從“有”到“優”的技術升級**。行業正在經歷這個技術升級的歷史階段，還談不上結論，只能一起來聊聊趨勢及預判。本系列專題的關注點是容器隔離技術，所以先不聊商業擴充和容器編排而聚焦於容器引擎技術發展趨勢。到現在為止，我們大體上可以把容器引擎技術劃分為兩代：

1. **Container on VM**。也就是按照分層設計思路，透過 IaaS + PaaS 的架構構建容器服務，這個是商用探索階段的典型架構。基於各大雲廠商成熟的 IaaS 基礎設施生產虛擬機器，在虛擬機器裡面部署容器服務元件。這種架構採用的是 lift and shift 策略，把容器服務的運維責任從使用者轉移到雲廠商。採用和使用者相同的軟體元件，只是轉移運維責任，有利於引導客戶逐步上雲、接受雲原生思維。**但是這個時期雲廠商提供的服務是單純的運維託管，相對使用者自建容器服務並沒有太明顯的技術優勢，甚至受多租戶隔離的限制部分使用體驗還不如使用者自建容器服務**。

2. **Container with hardware virtualization**。如果沿用 Container on VM 的分層設計架構，雲廠商很難構建獨有的技術優勢。對於 Serverless 容器例項服務，服務交付平面已經從 IaaS 的硬體介面上移到 OS Syscall，所以不要遵循 VM + 容器的分層設計思路。我們需要從需求本源出發，容器服務需要高效能、強隔離、夠安全和低成本的容器引擎。當前行業研發熱點之一就是如何構建這樣一個容器引擎，具體技術思路請留意後續系列文章。

# 小結

總結來看，容器服務生態大概經歷了四個階段，分別解決或試圖解決不同的問題：

1. 技術萌芽期：解決了容器執行環境的隔離問題
2. 技術迸發期：解決了軟體分發及容器編排問題
3. 商用探索期：確認了容器的商用服務形態
4. 商用擴充期：擴大適用場景和部署規模，透過技術創新提升產品競爭力

# 閒言碎語

聊了這麼多歷史，讓我們再來閒聊一下 docker 這個公司和 docker 這門技術吧！

2019 年 11 月 13 日，私有云基礎設施公司 Mirantis 在其官方部落格宣佈，收購 Docker 公司企業級業務，包括接管它的 700 多個客戶，這標誌著 Docker 公司從 2013 年開始的商業化探索徹底失敗。在不瞭解容器發展歷史的人看來，這種結果很難理解，Docker 是容器熱潮的開創者，容器則是這一輪雲端計算技術演進的開啟者，為什麼明明站在風口上了，卻仍然飛不起來？

其實，Docker 今天的命運，在 4 年前就決定了。

2014 年 Kubernetes 釋出後，迅速吸引了包括 Redhat 在內的一批重量級成員，並在一年之後迅速釋出 Kubernetes 1.0 以支撐正式商用。作為回應 Docker 公司主導成立了 OCI，旨在為容器映象格式和執行時制定一個開放標準，從而繼續佔據容器生態的話語權。但是 2015 年 7 月 CNCF 成立之後，迅速彎道超車開闢新的戰場，主攻容器編排與應用管理。隨後 2016 年 Kubernetes 社群制定了容器執行時的介面規範 CRI，只要實現這個 CRI 規範的容器執行時就可以和 K8s 生態對接，從引發了容器引擎的研發熱潮。cri-containerd，cri-o，frakti 等引擎不斷湧現，加上原有的 rkt 引擎，docker 變成了容器引擎芸芸眾生中的一員。從哪兒來到哪兒去，docker 又回到了最初的狀態，一個單機版軟體打包執行工具，基本上完美錯過了雲原生浪潮。

但是在相當長的時期內，docker 這個客戶端容器管理工具（UI）還是會長期存在的，畢竟強大的使用者群體在哪兒。但是在雲服務廠商的技術棧中，docker 的地位會越來越弱，逐步被 K8s 專用的容器引擎替代。雖然現在 docker 的群眾基礎依然強大，但是星星之火已經點燃，趨勢已然顯現，剩下的只是時間問題！

## 參考文獻

- [《Cloud Native and Container Technology Landscape》](http://t.tb.cn/l0VRSzi83RGJdCOMnVTGb)
- [**《A Brief History of Containers: From the 1970s Till Now》**](https://blog.aquasec.com/a-brief-history-of-containers-from-1970s-chroot-to-docker-2016)
- [《從虛擬化到雲原生——容器技術的發展史》](https://www.chainnews.com/articles/973288192290.htm)
- [《為什麼說 2019，是屬於容器技術的時代？》](https://www.infoq.cn/article/R1p3H3_29f4TYImExsyw)
- [《阿里巴巴在安全容器上的實踐與探索》](https://www.sohu.com/a/417745570_355140)
- [《安全容器在邊緣計算場景下的實踐》](https://www.infoq.cn/article/J762pmCvyXHflVuTgy4k)
- [《展望 2020：傳統容器已死，安全容器將成為雲原生標配》](https://www.oschina.net/news/112661/containers-cloud-native)

### 課程推薦

去年，CNCF 與 阿里雲聯合釋出了《雲原生技術公開課》已經成為了 Kubernetes 開發者的一門“必修課”。
今天，阿里雲再次集結多位具有豐富雲原生實踐經驗的技術專家，正式推出《雲原生技術實踐公開課》。課程內容由淺入深，專注講解“ 落地實踐”。還為學習者打造了真實、可操作的實驗場景，方便驗證學習成果，也為之後的實踐應用打下堅實基礎。點選連結檢視課程：[https://developer.aliyun.com/learning/roadmap/cloudnative2020](https://developer.aliyun.com/learning/roadmap/cloudnative2020)

> “[阿里巴巴雲原生](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247495030&idx=1&sn=ee876096c14acf77712bb483e805d2a2&chksm=fae6e6b9cd916faf6f822b597dcd8915cced05dc1b4197f84bdb4989b92ec37bba888ff16f08&token=248822707&lang=zh_CN#rd)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

容器技術之發展簡史

相關文章