2013年

Docker專案開源

2013年，以AWS及OpenStack，以Cloud Foundry為代表的開源Pass專案，成了雲端計算領域的一股清流，pass提供了一種“應用託管”的能力。
當時的虛假機和雲端計算已經是比較普遍的技術了，主流用法就是租一批AWS或者OpenStack的虛擬機器，然後用指令碼或者手工的方式在機器上部署應用
Cloud Foudry這樣的Pass專案，核心元件就是一套打包和分發機制，會呼叫作業系統的Cgroups和Namespace機制 為每個應用單獨建立“沙盒”的隔離環境，然後在“沙盒”中執行這些程序，實現了多使用者、批量、隔離執行的目的。
這個“沙盒”，就是所謂的容器。
這一年還叫dotCloud的Docker公司，也是Pass熱潮中的一員。只不過，比起Heroku、Pivotal、Red Hat等大佬，dotCloud公司顯得太微不足道，主打產品跟主流的CloudFoundry社群脫節，眼看就要陣亡的時候，dotCloud公司決定開源自己的容器專案Docker
“容器”其實不是什麼新鮮的東西，不是Docker發明的，當時最熱的Pass專案Cloud Foundry中，容器也只是最底層、最不受關注的一部分。

短短几個月，Docker就迅速崛起了，然後Cloud Foundry等所有Pass社群還沒來得及成為對手，就已經被淘汰了。

Docker專案大部分和Cloud Foundry容器大部分功能和實現原理是一樣的，但是不一樣的“Docker映象”，解決了環境打包的問題，直接打包了應用執行所需要的整個作業系統，賦予了本地環境和雲端環境排程一致的能力，避免了使用者通過“試錯”來匹配不同環境之間差異的痛苦過程， 這也是Docker的精髓。
Pass的定義變成了一套以Docker容器為技術核心，以Docker映象為打包標準的“容器化”思路
2013年年底，dotClound公司正式改名為Docker公司

2014年

Docker釋出Docker Swarm

Docker釋出Docker Swarn，以一個完整的整體來對外提供叢集管理功能，最大的亮點就是完全使用Docker專案原來的容器管理API來完成叢集管理。

docker run "容器"

只需要變成

docker run -H "swarm叢集API地址" "容器"

使用者只需要使用原先的docker指令建立一個容器，這個請求就會被swarm攔截處理，通過具體的排程演算法找到一個適合的Docker Daemon。
這種方式對已經熟悉docker命令列的開發者們非常的友好。

Docker收購Fig，並改名Compose

Docker公司收購了Fig專案，後改名為（Compose）。
Fig專案在開發者面前第一次提出了“容器編排”（Container Orchestration）
在雲端計算領域，“編排”主要指使用者如何通過某些工具或者配置來完成一組虛擬機器以及關聯資源的定義、配置、建立、刪除等工作，然後由雲端計算平臺按照這些指定的邏輯來完成的過程
而容器時代，“編排”就是對Docker容器的一系列定義、配置和建立動作的管理。

Docker和Mesosphere公司的競爭

除了Docker生態外，Mesos和背後的建立公司Mesosphere也是一個非常大的熱力，Mesos是大資料最受歡迎的資源管理專案，跟Yarn專案競爭的實力派對手。
大資料關注的計算密集型離線業務，其實不像Web服務那樣適合用容器進行託管和擴容，也沒有應用打包的強烈需要，所以Hadoop、Spark等專案現在也沒在容器技術投入很大的精力，但是Mesos作為大資料套件之一，天生的兩層排程機制讓它非常容易從大資料領域獨立出來去支援更廣泛的Pass業務，所以Mesos公司釋出了Marathon專案，成為了Docker Swarm的一個強有力的競爭對手。
雖然不能提供像Swarm那樣的Docker API，但是Mesos社群擁有一個非常大的競爭力：超大規模叢集管理經驗
Mesos+Marathon組合進化成了一個排程成熟的Pass專案，同時能支援大資料業務，

Docker和CoreOS

CoreOS是一個基礎設施領域創業公司，核心產品是一個定製化的作業系統，使用者可以按照分散式叢集的方式，管理所有安裝了這個系統的節點，使用使用者在叢集裡部署應用像使用單機一樣方便
Docker專案釋出後，Corecd很快認識到可以把容器的概念無逢整合到自己的這套方案中，從而為使用者提供更高層次的Pass能力，所以CoreOS很早就成了Docker專案的貢獻者，然而在2014年結束了合作，推出了自己的容器Rocket（rkt），然而這個rkt容器完全被Docker公司壓制了。

OCI標準制定

由CoreOS、Google、RatHat等公司共同宣佈，Docker公司將Libcontainer（容器執行時庫）捐出，並改名為RunC專案，交由一個完全中立的基金會管理，以RunC為依據共同制定一套容器和映象的標準規範
，叫OCI（Open Container Initiative），意在將容器執行時和映象的實現從Docker專案中完全剝離出來，以此來壓制Docker公司一家獨大的現狀，同時也為不依賴Docker專案構建平臺層能力提供了可能。
不過並沒有改變Docker在容器領域一家獨大的現狀

Kubernetes誕生

2014年6月，基礎設施領域的領先者Google發，正式宣告了Kubernetes專案的誕生（Borg的開源版本），如同Docker橫空出世一樣，再一次改變了容器市場的格局。
微軟、RedHat、IBM、Docker加入Kubernetes社群

2015年

CNCF基金會成立

為了在容器編排地位取得絕對的優勢，同Swarm和Mesos競爭，Google、RedHat等開源基礎設施公司，共同發起了一個名為CNCF的基金會：希望以Kubernetes為基礎，建立一個由開源基礎設施領域廠商主導、按照獨立基礎會方式運營的平臺社群，來對抗以Docker公司為核心的容器商業生態。簡單的說就是打造一個圍繞Kubernetes專案的“護城河”。
Docker擅長Docker生態的無縫整合，Mesos擅長大規模叢集的排程與管理，Kubernetest選擇了Pod、Sidecar等功能和模式作為切入點（大多來自Borg和Omega系統的內部特性）。
Kubernetes的團隊規模很少，投入的工程能力有限，RedHat在這時候和Google聯盟，正式開戶了容器編排“三國鼎立”的書面。

Kubernetes來自Google公司在容器化基礎設施領域多年來實踐經驗的沉澱和昇華，在Github上的各項指標一路飆升，將Swarm專案遠遠地甩在了後邊。
同年，Kubernetes釋出Helm軟體包管理系統、kubeam安裝工具、釋出Mikibube等一列更新操作

CNCF社群迅速增加了Prometheus、Fluentd、OpenTracing、CNI等一系列容器生態的知名工具和專案
大量的公司和建立團隊將注意力投向CNCF社群而不再是Docker公司

2016年

Docker公司放棄現有的Swarm專案，將容器編排和叢集管理功能內建到Docker中

面對CNCF的競爭優勢，Docker公司宣佈放棄現有的Swarm專案，將容器編排和叢集管理功能內轉到Docker專案當中。
然而這種改變帶來的技術複雜度和維護難度，給Docker專案造成了非常不利的書面

Kuberntes支援OpenApi，給開發人員定製化提供更大的靈活性

不同於Docker公司，Kubernetes推進“民主化”架構：從API到容器執行的每一層，都給開發者暴露出了可擴充套件的外掛機制，鼓勵使用者通過程式碼的方式介入每一個階段。
Kubernetes專案的這個變革非常有效，很快在整個容器社群中催生出了大量的、基於Kubernetes API和擴充套件介面的二次創新產品：

1. 熱度極高的Istio微服務治理工具
2. 應用部署框架Operator
3. Rook開源創業專案，把Ceph重量級產品封裝成了簡單易用的容器儲存外掛
   Docker公司在Kubernetes社群的崛起和壯大後，敗下陣來。

2017年

Docker將Containerd捐獻給CNCF社群

Docker公司將容器執行時部分Containerd捐獻給CNCF社群，標誌著Docker專案你下面升級成為了一個Pass平臺，Docker公司宣佈將Docker專案改名為Moby，交給社群自行維護，而Docker公司的商業產品還佔有Docker這個註冊商標。
同年10月，Docker宣佈將在自己主打產品Docker企業版中內建Kubernetes專案，持續了兩年的容器編排之爭終於落下帷幕

2018年

RatHat宣佈2.5億美元收購CoreOS
Docker公司CTO Solomon Hykes宣佈辭職，容器技術圈子從此塵埃落定