Docker與k8s的恩怨情仇（四）-雲原生時代的閉源落幕

• 2021 年 7 月 7 日
• 筆記
• 技術解密, 程序人生, 經驗分享, 葡萄城裡

轉載請註明出處：葡萄城官網，葡萄城為開發者提供專業的開發工具、解決方案和服務，賦能開發者。

第一章：Docker與k8s的恩怨情仇（一）—成為PaaS前浪的Cloud Foundry

第二章：Docker與k8s的恩怨情仇（二）—用最簡單的技術實現「容器」

第三章：Docker與k8s的恩怨情仇（三）—後浪Docker來勢洶洶

在本系列前幾篇文章中，我們介紹了從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三件套的內容：

1. Docker Compose：Compose的前身，是一個僅有兩個人維護的Docker容器編排的開源項目Fig，它的功能是：假如現在用戶需要部署一個應用A和一個數據庫B以及負載均衡C，那麼Fig就允許用戶把ABC三個容器定義在一個配置文件中，並且指定它們的關聯關係。最後只需要一條命令fig up即可直接使用。

在Docker大火的時候，Fig項目在Github上的熱度堪比Docker，因此在2015年Docker公司將其收購，並且改名為Docker Compose，作為Docker容器的編排工具，並且使用至今。

2. Docker Swarm：Swarm是Docker的集群管理項目，其主要的邏輯就和上一節講過的Cloud Foundry類似，可以以類似於docker run 我的鏡像的命令行方式，以docker run -H 我的Swarm集群API地址 我的鏡像這樣將Docker運行成一個集群並且進行管理，Swarm的出現將Docker項目從一個普通的容器升級成為PaaS平台。

3. 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公司的，敬請期待。