Docker容器實戰(四) - 紛紛擾擾,終歸塵土

伴隨着Docker公司的容器技術生態在雲計算市場中站穩了腳跟，圍繞着Docker項目進行的各個層次的集成與創新產品，也如雨後春筍般出如今這個新興市場當中。
而Docker公司，不失時機地發佈了Docker Compose、Swarm和Machine「三件套」，在重定義PaaS走出了最關鍵的一步。

這段時間大量圍繞着Docker項目的網絡、存儲、監控、CI/CD，甚至UI項目紛紛出臺，涌現出如Rancher、Tutum這樣在開源與商業上均取得了巨大成功的創業公司。

2014~2015年間，容器社區真是熱鬧非凡。

繁榮背後,更多擔心,即對Docker公司商業化戰略的種種顧慮。

Docker項目此時已經成爲Docker公司一個商業產品。而開源，只是Docker公司吸引開發者羣體的一個重要手段。
不過這麼多年來，開源社區的商業化其實都是相似的思路，無非是高不高調、心不心急的問題罷了。

真正令大多數人不滿意的是Docker公司在Docker開源項目的發展上，始終保持絕對權威,並在多場合挑戰其餘玩家（CoreOS、RedHat，谷歌微軟）的切身利益。

其實在Docker項目剛剛興起時
Google也開源了一個在內部使用多年、經歷過生產環境驗證的Linux容器

1 lmctfy（Let Me Container That For You）

然而，面對Docker項目的強勢崛起，這個對用戶沒那麼友好的Google容器項目根本沒有招架之力。因此，知難而退的Google公司，向Docker公司表示了合做的願望：關停這個項目，和Docker公司共同推動一箇中立的容器運行時（container runtime）庫做爲Docker項目的核心依賴。

不過，Docker公司並無認同這個明顯會削弱本身地位的提議，還在不久後，本身發佈了一個容器運行時庫

2 Libcontainer

此次匆忙的、由一家主導的、並帶有戰略性考量的重構，成了Libcontainer被社區長期詬病代碼可讀性差、可維護性不強的一個重要緣由。

至此，Docker公司在容器運行時層面上的強硬態度，以及Docker項目在高速迭代中表現出來的不穩定和頻繁變動的問題，開始讓社區叫苦連天。

這種情緒在2015年達到了一個小高潮，容器領域的其餘幾位玩家開始商議「切割」Docker項目的話語權 --- 成立一箇中立的基金會。
2015年6月22日，由Docker公司牽頭，CoreOS、Google、RedHat等公司共同宣佈，Docker公司將Libcontainer捐出，並更名爲

3 runc

交由一個徹底中立的基金會管理，而後以runc爲依據，你們共同制定一套容器和鏡像的標準和規範。
這套標準和規範，就是

4 OCI（ Open Container Initiative ）

OCI的提出，意在將容器運行時和鏡像的實現從Docker項目中徹底剝離出來

• 一方面能夠改善Docker公司在容器技術上一家獨大的現狀
• 另外一方面也爲其餘玩家不依賴於Docker項目構建各自的平臺層能力提供了可能

OCI更可能是高端玩家出於自身利益一個妥協結果
儘管Docker是OCI的發起者和創始成員，卻不多在OCI的技術推動和標準制定等事務上扮演關鍵角色，也沒動力推動這些所謂標準。
這也是OCI組織效率持續低下的根本緣由。

眼看着OCI無力改變Docker公司容器領域一家獨大現狀，Google和RedHat等第二把武器擺上了檯面。

Docker之因此不擔憂OCI威脅，就在於它的Docker項目是容器生態的事實標準，而它所維護的Docker社區也足夠龐大。
但是，一旦這場鬥爭被轉移到容器之上的平臺層，或者說PaaS層，Docker公司的競爭優點捉襟見肘
在這個領域裏，像Google和RedHat這樣的成熟公司，都擁有着深厚的技術積累
而像CoreOS這樣的創業公司，也擁有像Etcd這樣被普遍使用的開源基礎設施項目。
但是Docker公司呢？它卻只有一個Swarm。

因此此次，Google、RedHat等開源基礎設施領域玩家們，發起名爲

5 CNCF（Cloud Native Computing Foundation）

的基金會

基金會但願，以 Kubernetes 項目爲基礎，創建一個由開源基礎設施領域廠商主導的、按照獨立基金會方式運營的平臺級社區，來對抗以Docker公司爲核心的容器商業生態。

CNCF社區就須要至少確保兩件事情

5.1 在容器編排,Kubernetes具有強大優點

在容器編排領域，Kubernetes項目須要面對來自Docker公司和Mesos社區兩個方向的壓力。

• Swarm擅長是跟Docker生態的無縫集成
• Mesos擅長大規模集羣的調度與管理

這兩個方向，也是大多數人作容器集羣管理項目時最容易想到的兩個出發點
也正由於如此，Kubernetes項目若是繼續在這兩個方向上作文章恐怕就不太明智了。

Kubernetes選擇的應對方式是

Borg

Kubernetes項目早期的GitHub Issue和Feature大多來自於Borg和Omega系統的內部特性
落到Kubernetes項目上，就是Pod、Sidecar等功能和設計模式。

Kubernetes項目的基礎特性是Google公司在容器化基礎設施領域多年來實踐經驗的沉澱與昇華
是Kubernetes項目可以從一開始就避免同Swarm和Mesos社區同質化的重要手段!

5.2 CNCF社區必須以Kubernetes項目爲核心，覆蓋足夠多場景

如何把這些先進的思想經過技術手段在開源社區落地，並培育出一個認同這些理念的生態？
RedHat就發揮了重要做用。

當時Kubernetes團隊規模很小，可以投入的工程能力也十分緊張，而這偏偏是RedHat的長處
更可貴的是，RedHat是世界上爲數很少的、能真正理解開源社區運做和項目研發真諦的合做夥伴。
因此，RedHat與Google聯盟的成立，不只保證了RedHat在Kubernetes項目上的影響力，也正式開啓了容器編排領域「三國鼎立」的局面。

Mesos社區與容器技術的關係，更像是「借勢」，而不是這個領域真正的參與者和領導者
這個事實，加上它所屬的Apache社區固有的封閉性，致使了Mesos社區雖然技術最爲成熟，卻在容器編排領域鮮有創新
這也是爲什麼Google很快就把注意力轉向了激進的Docker公司
Docker公司對Mesos社區也是相似的見解,因此從一開始，Docker公司就把應對Kubernetes項目的競爭擺在了首要位置：一方面，不斷強調「Docker Native」的「重要性」，另外一方面，與Kubernetes項目在多個場合進行了直接的碰撞。

發展態勢，很快超過Docker公司的預期。
Kubernetes項目並無跟Swarm項目展開同質化的競爭，因此「Docker Native」的說辭並無太大的殺傷力
相反地，Kubernetes項目讓人耳目一新的設計理念和號召力，很快就構建出了一個不同凡響的容器編排與管理的生態。

就這樣，Kubernetes項目在GitHub上的各項指標開始一騎絕塵，將Swarm項目遠遠地甩在了身後。
有了這個基礎，CNCF社區就能夠放心地解決第二個問題了。

在已經囊括了容器監控事實標準的

6 Prometheus

項目以後


CNCF社區迅速在成員項目中添加了

• Fluentd

• jagerTracing

• CNI

等一系列容器生態的知名工具和項目。
而在看到了CNCF社區對用戶表現出來的巨大吸引力以後，大量的公司和創業團隊也開始專門針對CNCF社區而非Docker公司制定推廣策略。

面對這樣的競爭態勢，Docker公司決定更進一步
在2016年，Docker公司宣佈了一個震驚全部人的計劃：放棄現有的Swarm項目，將容器編排和集羣管理功能所有內置到Docker項目中
顯然，Docker公司意識到了Swarm項目目前惟一的競爭優點，就是跟Docker項目的無縫集成。那麼，如何讓這種優點最大化呢？那就是把Swarm內置到Docker項目當中。

實際上，從工程角度來看，這種作法的風險很大。
內置容器編排、集羣管理和負載均衡能力，當然可使得Docker項目的邊界直接擴大到一個完整的PaaS項目的範疇，但這種變動帶來的技術複雜度和維護難度，長遠來看對Docker項目是不利的。
不過，在當時的大環境下，Docker公司的選擇恐怕也帶有一絲背注一擲的意味。

而Kubernetes的應對策略則是反其道而行之，開始在整個社區推動「民主化」架構
從API到容器運行時的每一層，Kubernetes項目都爲開發者暴露出了能夠擴展的插件機制
鼓勵用戶經過代碼的方式介入到Kubernetes項目的每個階段。
Kubernetes項目的這個變革的效果立竿見影，很快在整個容器社區中催生出了大量的、基於Kubernetes API和擴展接口的二次創新工做，好比：

• 熱度極高的微服務治理項目Istio

• 普遍採用的有狀態應用部署框架Operator

• 開源創業項目 --- Rook,經過Kubernetes的可擴展接口，把Ceph這樣的重量級產品封裝成簡單易用的容器存儲插件

就這樣，在這種鼓勵二次創新的總體氛圍當中，Kubernetes社區在2016年以後獲得了空前的發展
不一樣於以前侷限於「打包、發佈」這樣的PaaS化路線，這一次容器社區的繁榮，是一次徹底以Kubernetes項目爲核心的「百花爭鳴」。

面對Kubernetes社區的崛起和壯大，Docker公司也不得不面對本身豪賭失敗的現實
但在早前拒絕了微軟的天價收購以後，Docker公司實際上已經沒有什麼迴旋餘地，只能選擇逐步放棄開源社區而專一於本身的商業化轉型。

因此，從2017年開始，Docker公司先是將Docker項目的容器運行時部分

• Containerd

捐贈給CNCF社區，標誌着Docker項目已經全面升級成爲一個PaaS平臺
緊接着，Docker公司宣佈將Docker項目更名爲

• Moby

而後交給社區自行維護，而Docker公司的商業產品將佔有Docker這個註冊商標。

Docker公司這些舉措背後的含義很是明確：它將全面放棄在開源社區同Kubernetes生態的競爭，轉而專一於本身的商業業務
而且經過將Docker項目更名爲Moby的舉動，將本來屬於Docker社區的用戶轉化成了本身的客戶。

2017年10月，Docker公司出人意料地宣佈，將在本身的主打產品Docker企業版中內置Kubernetes項目
持續了近兩年之久的「編排之爭」落下帷幕!

2018年1月30日，RedHat斥資2.5億美圓收購CoreOS

2018年3月28日，一切紛爭的始做俑者，Docker公司的CTO Solomon Hykes宣佈辭職，紛紛擾擾的容器技術圈子，至此塵埃落定。

7 總結

容器技術圈子在短短几年裏發生了不少變數，但不少事情其實也都在情理之中。就像Docker這樣一家創業公司，在經過開源社區的運做取得了巨大的成功以後，就不得不面對來自整個雲計算產業的競爭和圍剿。而這個產業的壟斷特性，對於Docker這樣的技術型創業公司其實天生就不友好。

在這種局勢下，接受微軟的天價收購，在大多數人看來都是一個很是明智和實際的選擇。但是Solomon Hykes卻多少帶有一些理想主義的影子，既然不甘於「寄人籬下」，那他就必須帶領Docker公司去對抗來自整個雲計算產業的壓力。
只不過，Docker公司最後選擇的對抗方式，是將開源項目與商業產品緊密綁定，打造了一個極端封閉的技術生態。而這，其實違背了Docker項目與開發者保持親密關係的初衷。

相比之下，Kubernetes社區，正是以一種更加溫和的方式，承接了Docker項目的未盡事業，即：以開發者爲核心，構建一個相對民主和開放的容器生態。
這也是爲什麼，Kubernetes項目的成功實際上是必然的。

Docker公司在過去五年裏的風雲變幻，以及Solomon Hykes本人的傳奇經歷，都已經在雲計算的長河中留下了濃墨重彩的一筆。

參考

• Github
• docker官網
• Docker實戰
• 深刻剖析Kubernetes