轉載請註明出處：葡萄城官網，葡萄城為開發者提供專業的開發工具、解決方案和服務，賦能開發者。
在本系列前幾篇文章中，我們介紹了從Cloud Foundry到Docker等PaaS平臺的發展迭代過程。今天我們繼續來為大家介紹Docker走向落寞的原因以及大航海時代的開啟。
Docker的商業化
上篇中，我們講到了Docker專案利用自己創新的Docker Image瞬間爆紅，於是許多商家也從中發現商機，紛紛推出自己的容器產品，也想在市場中分一杯羹。
CoreOS推出了Rocket（rkt）容器，Google也開源了自己的容器專案lmctfy（Let Me Container That For You）等，但是面對Docker專案的強勢，就算是Google這種大佬也毫無招架之力。因此Google打算和Docker公司開展合作，關停自己的容器專案，並且和Docker公司一同維護開源的容器執行，但是Docker公司方面很強勢的拒絕了這個明顯會削弱自己地位的合作。
在這時Docker公司也意識到了，自己僅僅是雲端計算技術棧中的幕後英雄，只能當做平臺最終部署應用的載體。但是，要想成為這個領域的核心，就應該有自己的PaaS生態。在Docker爆火，有了充足的資金之後，Docker公司開始了瘋狂的買買買來擴充自己的實力，其中最出名的就署名Fig。Fig是出名的Docker Compose專案的前身。通過這些併購與自身研發迭代，Docker公司最終推出了以自己為核心的PaaS三件套：Docker Compose、Docker Swarm以及Docker Machine。
下面簡單為大家介紹一下Docker三件套的內容：
- Docker Compose：Compose的前身，是一個僅有兩個人維護的Docker容器編排的開源專案Fig，它的功能是：假如現在使用者需要部署一個應用A和一個資料庫B以及負載均衡C，那麼Fig就允許使用者把ABC三個容器定義在一個配置檔案中，並且指定它們的關聯關係。最後只需要一條命令fig up即可直接使用。
在Docker大火的時候，Fig專案在Github上的熱度堪比Docker，因此在2015年Docker公司將其收購，並且改名為Docker Compose，作為Docker容器的編排工具，並且使用至今。
-
Docker Swarm：Swarm是Docker的叢集管理專案，其主要的邏輯就和上一節講過的Cloud Foundry類似，可以以類似於docker run 我的映象的命令列方式，以docker run -H 我的Swarm叢集API地址 我的映象這樣將Docker執行成一個叢集並且進行管理，Swarm的出現將Docker專案從一個普通的容器升級成為PaaS平臺。
-
Docker Machine：Machine應該是Docker三件套裡最不出名的，它的功能是將虛擬機器執行成容器，並且可以以管理Docker容器的方式管理虛擬機器。
OCI的“不作為”到CNCF出現
在發展之路上，Docker公司在Docker開源專案的發展上始終保持著絕對的權威和發言權，並且在多個場合用實際行動挑戰到了其他玩家的利益；另一方面，Docker公司的商業化路徑嚴重侵害了曾經的合作公司RedHat的切身利益；再加之，Docker在2015年間的高速迭代表中現出了各種不穩定的breaking change開始讓社群叫苦不迭。
人紅是非多，更何況Docker還搶了大家的蛋糕。於是，容器領域的其他幾位玩家開始商討“切割”Docker專案的話語權。最終，Docker公司迫於壓力，於2015年6月22日，牽頭了CoreOS、Google、RedHat等公司，共同成立了一箇中立的基金會，並將自己的容器執行時LibContainer捐出，改名為RunC，基金會依據RunC共同制定了一套容器和映象的標準和規範——OCI（Open Container Initiative）。
OCI的成立，意味著容器執行時和映象的實現與Docker專案完全剝離，讓其他玩家不依賴Docker實現自己的Docker執行時成為可能。
但是，由於成立基金會只是Docker公司對這些大公司的妥協，並且其當時確實維護著數量足夠龐大的社群，因此Docker公司對基金會的成立有恃無恐，並且對標準的制定並不關心。因為在當時的大環境下，Docker自己的實現，已經就是業界統一的標準了。
由於OCI基金會發展十分緩慢，因此Google、RedHat等基礎設施領域的頭部玩家打出了手中的王牌，共同牽頭成了一個名叫CNCF（Cloud Native Computing Foundation）的基金會（這也是雲原生這個概念第一次出現在大眾視野內）。CNCF基金會成立的思想基礎是，以Kubernetes專案為基礎，建立一個由開源基礎設施領域廠商主導的按照獨立基金會方式運營的平臺級社群，來對抗以Docker為核心的容器商業生態。也正是這個基金會的成立，我們第二節的主人公Kubernetes也開始嶄露頭角。
Kubernetes的出現與發展
Kubernetes是Google公司早在2014年就釋出開源的一個容器基礎設施編排框架，和其他拍腦袋想出來的技術不同，Kubernetes的技術是有理論依據的，即：Borg。Borg是Google公司整個基礎設施體系中的一部分，Borg是Google公司整個基礎設施體系中的一部分，Google也釋出了多篇關於Borg的論文作為其理論支援。其上承載了比如MapReduce、BigTable等諸多業界的頭部技術。因此Borg系統一直以來都被譽為Google公司內部最強大的“祕密武器”，也是Google公司最不可能開源的專案，而Kubernetes就是在這樣的理論基礎上開發的。下圖是Google Omega論文所描述的Google已公開的基礎設施棧。
開源vs閉源
面對k8s的出現，一場Docker和k8s之間的容器之戰就此打響。
在這場對抗之初，由於Kubernetes開發靈感和設計思想來源於Borg，Kubernetes專案在剛釋出時就被稱為曲高和寡。太過超前的思想讓開發者無法理解，同時由於Kubernetes專案一直由Google的工程師自行維護，所以在釋出之初並沒有獲得太多的關注和成長。
然而，CNCF的成立改變了這一切，RedHat的長處就是有著成熟的社群管理體系，並且也有足夠多的工程能力，這使得Kubernetes專案在交由社群維護開始迅速發展，並且逐漸開始和Docker分庭抗禮。並且和Docker的封閉商業模式不同，Kubernetes反其道而行之主開啟源和民主化，每一個重要功能都給使用者提供了可定製化的介面，並且普通使用者也可以無許可權拉取修改Kubernetes的程式碼，社群有專門的reviewer以及approver，只要你寫的程式碼通過PR通過了程式碼稽核和批准，就會成為Kubernetes的主幹程式碼，這也大大的增加了Kubernetes的活力。並且，依託於開放性介面，基於Kubernetes的開源專案和外掛比比皆是，並且依託於優秀的架構設計，微服務等新興的技術理念也迅速落地，最終形成了一個百花齊放的穩定龐大的生態。
而Docker只能通過自己的工程師修改，在這一點上與Kubernetes相比就與遠落下風。
總結起來：
面對Kubernetes社群的崛起和壯大，Docker公司不得不承認自己的豪賭以失敗告終，從2017年開始，Docker將Docker專案的容器執行時部分Containerd捐贈給了CNCF社群，並且在當年10月宣佈將在自己的Docker企業版中內建Kubernetes專案，這也標誌著持續了近兩年的容器編排之戰落下帷幕。2018年1月，RedHat公司宣佈斥資2.5億美元收購CoreOS，2018年3月，這一切紛爭的始作俑者Docker公司的CTO Solomon Hykes宣佈辭職，至此，紛擾的容器技術圈塵埃落定，天下歸一。
總結
本文為大家介紹了Docker是如何在PaaS平臺中成為焦點，又如何一步步被Kubernetes替代。下一節我們將繼續為大家介紹Kubernetes除了社群之外，在本身的容器編排技術上是如何降維打擊Docker公司的，敬請期待。