容器技術之發展簡史

做者 | 劉獎

背景

「雲原生技術有利於各組織在公有云、私有云和混合雲等新型動態環境中，構建和運行可彈性擴展的應用。雲原生的表明技術包括容器、服務網格、微服務、不可變基礎設施和聲明式 API。」

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

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

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 年的發展歷史，大體能夠將其分爲四個歷史階段，下文將詳細介紹這四個歷史階段。

技術萌芽期

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

容器的運行時環境隔離，目標是給容器構造一個無差異的運行時環境，用以在任意時間、任意位置運行容器鏡像。因爲 docker 的佈道，你們習慣性認爲容器的運行時環境隔離就是 OS 虛擬化，或者容器等於 namespace + cgroup + 安全防禦機制。我不太贊同這種見解，這個只是一段歷史時期、一種容器運行時的實現技術，還有不少種其它可能的技術方案來實現容器運行環境。因此，回到需求的本源：容器須要運行時隔離技術來保證容器的運行環境符合預期。習慣上，你們把這種實現容器隔離技術的組件叫作容器運行時。

從另一個角度看，容器隔離技術解決的是資源供給問題。爲啥須要容器隔離技術來解決資源供給問題呢？成也蕭何，敗也蕭何！摩爾定律實在太過強大，它讓咱們有了愈來愈多的計算資源可使用。10 年前作小型機時，小型機的典型規格是 32 路 8 核 CPU，如今一臺 4 路 PC 服務器計算能力都超過 10 年前的小型機服務器。小型機的典型用法是把整機切分爲多個分區使用。觀察當下雲服務硬件發展趨勢，愈來愈有熟悉的感受，咱們在把小型機相關技術「軍轉民」。如今咱們一臺 PC 服務器擁有了很是強大的、能和十年前小型機媲美的計算能力，巧合的是當下 PC 服務器的典型用法也和十年前的小型機用法相似，切割爲 1-8vCPU 的虛擬機/容器使用。

爲何人們老是習慣於把一個大的服務器資源切分爲小的分區使用而不是研發可以充分發揮大型服務器整機計算能力的軟件呢？我的認爲背後有兩個制約因素：

• 待解決問題自己內在的並行度有限。隨着多核多處理器系統的日益普及，IT 行業從 2004 年開始進行串行編程到並行編程的升級改造。開始階段針對特定行業應用的並行化改造效果很是明顯，可是後來發現隨着並行度提升改形成本愈來愈大、收益卻愈來愈低。受阿姆達爾定律制約，解決特定問題的並行度超過必定臨界點以後收益將逐漸變小。因此一味提升系統並行度並非經濟的作法。
• 人類智力有限。受人類智力限制，系統越複雜、並行度越高，軟件越容易出故障，軟件維護代價成指數級增加。因此，從軟件工程看，你們也趨向於接口化、模塊化、單元化的軟件架構設計，儘可能控制軟件的複雜度，下降工程成本。

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

有點跑題了。。。總之，基於隔離的資源供給不是僞需求。對於軟件運行環境的隔離要求，從操做系統出現之初就有了。多任務分時操做系統和進程虛擬地址都是爲了解決多個任務運行在同一臺主機上的資源共享問題，讓每一個進程都覺得本身獨佔主機。固然僅僅是進程隔離是遠遠不夠的。縱觀當前的資源隔離技術，咱們大體能夠將資源隔離技術分紅 5 類：

• 進程隔離。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 行業面臨的困境，創造出了無限的可能性，大力推進了雲原生的發展。讓咱們一塊兒來向這個偉大的創意致敬！

至此，容器技術體系已經解決了最核心的兩個問題：如何發佈軟件和如何運行軟件，騰飛時刻即將到來。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 組織解決的是應用管理及容器編排問題。這兩個圍繞容器的基金會對雲原生生態的發展發揮了很是重要的做用，兩者不是競爭而是相輔相成，共同制定了一系列行業事實標準。這些行業事實標準的確立，各行業注入了無限活力，基於接口的標準的具體實現不斷涌現，呈現出一片百花齊放的景象。

其中，與容器相關的最爲重要的幾個規範包括：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，因此其使用形態上附加了很多約束條件。

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

• 行業對容器化的接受程度已經很高，容器化普及率也是逐年提高。
• 容器編排系統已經一戰定江山，K8s 成爲事實上的容器編排之王。
• Serverless 容器實例服務受到市場的歡迎，客戶羣體日益擴大。
• 長期看託管容器編排服務和 Serverless 容器實例服務將長期共存，協同知足客戶對服務成本和彈性能力的需求。

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

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

商用拓展期

到 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》
• 《A Brief History of Containers: From the 1970s Till Now》
• 《從虛擬化到雲原生——容器技術的發展史》
• 《爲何說 2019，是屬於容器技術的時代？》
• 《阿里巴巴在安全容器上的實踐與探索》
• 《安全容器在邊緣計算場景下的實踐》
• 《展望 2020：傳統容器已死，安全容器將成爲雲原生標配》

課程推薦

去年，CNCF 與 阿里雲聯合發佈了《雲原生技術公開課》已經成爲了 Kubernetes 開發者的一門「必修課」。
今天，阿里雲再次集結多位具備豐富雲原生實踐經驗的技術專家，正式推出《雲原生技術實踐公開課》。課程內容由淺入深，專一講解「 落地實踐」。還爲學習者打造了真實、可操做的實驗場景，方便驗證學習成果，也爲以後的實踐應用打下堅實基礎。點擊連接查看課程：https://developer.aliyun.com/learning/roadmap/cloudnative2020

「 阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的公衆號。」