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

原文作者：javaedge 原文連結 更多雲原生技術資訊可關注 阿裡巴巴雲原生技術圈

伴随着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

“ 阿裡巴巴雲原生 關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”