作者：木環、易立

編輯：小智

時至今日，IT 圈已經進化到開源與商業不再劍拔弩張的時代。

１.時至今日，沒有人質疑容器技術的未來

現在，沒有人會否認容器技術的作用與地位。2013 年 Docker 問世，熱度迅速躥升並被大範圍使用，如此勢頭在開源界當屬少見。

DataDog 連續三年釋出 Docker 問卷調查，2017 年報告顯示 Docker 的採用率上升 40%。

調查資料顯示 2015 年起就有不少大型公司已經開始嘗試使用 Docker，並且近 60% 的企業宣稱使用 Docker 的機器規模超過 500 臺，不過 100-499 臺規模的使用比率也獲得了顯著上升。有分析認為 Docker 的出現在早期解決的是大公司痛點問題，而現在 Docker 正在尋求成為各類公司的通用平臺技術。

Sysdig 調查了 4.5 萬個企業，統計顯示平均每臺機器上會執行 10 個容器例項，甚至有企業在一臺機器上啟用 95 個容器例項。當 Docker 逐漸生產環境中不可或缺的部分之後，勢必要尋求工具更高效地管理和編排這些容器。目前市面上被廣為熟知的編排方案是 Kubernetes、Mesos、Amazon ECS、Google Engine 等，而 Docker 也推出了自己的原生系統編排方案。

２.Kubernetes  vs Docker Swarm 兩股流派

Kubernetes 出身於谷歌，是其多年大規模容器管理技術的開源版本，在容器浪潮中完成了短時間內的迅速發展，是目前容器生態中最受歡迎的開源專案。專案於 2014 年 6 月首次亮相 GitHub，即 Docker 專案開源的一年多之後；專案已經被捐贈給 CNCF（Cloud Native Computing Foundation）組織，其目標是成為“跨叢集的應用級別容器部署、擴充套件和運維自動化平臺”，它會支援包括 Docker 在內的一系列容器工具。

而 Docker Swarm 則是 Docker 主推的原生的叢集工具，意圖讓使用者像使用單機 Docker API 一樣來驅動整個叢集。2016 年 7 月釋出的 Docker1.12 把 Swarm 內建到 Docker 中，這種內建的做法引來了一些爭議，有人認為這對 Kubernetes 和 Mesos 造成了一定的威脅。

在很多人眼裡，Kubernetes 更開源、匯聚了更多的力量，而 Docker Swarm 則是 Docker 處於商業化的本心。這裡，先拋開 Kubernetes 和 Docker 的歷史背景，也不提兩者社群背後曾經有過的爭論；我們單純從技術設計的角度來看看兩者技術層面的差異。

（１）遵循的兩種網路標準

在不同的使用者環境中，如公共雲、專有云、混合雲中，容器的網路模型都有不同之處，為此容器平臺提供了外掛機制，來支援不同的網路實現。目前關於容器網路介面的配置主要有兩種標準：容器網路模型（Container Network Model， CNM）和容器網路介面（Container Network Interface，CNI）。

CNM 由 Docker 主導，吸引了 Cisco、VMware 等公司的應用；而 CNI 更歸屬社群，被運用於 Mesos、Cloud Foundry、K8S 之中。

CNM 是 Docker 主導的網路方案，而且 libnetwork 和 Docker 原生編排等能力緊密整合在一起，內建的服務發現和負載均衡等能力對於開發者而言非常友好。但是正因如此，也對網路驅動的實現帶來了一定挑戰，在 Docker 17.06 中 Swarmkit 開始支援 node scope 網路，會簡化一部分網路模型支援的複雜性。

CNI 是社群主導的網路方案，整個方案很簡潔，只提供基本的網路管理和 IPAM 管理介面，同時和其他網路能力（如 DNS，負載均衡等）保持正交。好處是網路驅動容易實現，三方編排可以方便地控制網路介面和容器物件的生命週期。不足之處則是，編排系統需要整合多個方案才能完整解決使用者的訴求，比如在 Kubernetes 中，DNS 和 Ingress 都是通過 addon 的方式實現的，這也為部署和維護引入和複雜性。

（２）兩種設計的對比

CNM 是 Docker 提出的規範。Docker 引擎中的 libnetwork 是 CNM 的預設實現，現在 CNM 已經被 Cisco Contiv, Project Calico,Weave 等專案所採納。阿里雲也提供了基於 CNM 的 VPC，MacVLAN 等網路驅動。CNM 提供了 Docker daemon 與網路驅動實現之間的控制介面。Docker 提供了原生網路驅動包括 none, bridge, overlay 以及 Macvlan/Ipvlan 等。除了 Linux 容器支援，Libnetwork 也推出了對 Windows 的支援。通過 CNM，Docker 也可以由第三方外掛獲得更多的網路驅動支援。

CNI 最早是由 CoreOS 提出的一個容器網路規範。已採納該規範的包括 Apache Mesos, Cloud Foundry, Kubernetes 等。Flannel, Project Calico 和 Weave 等專案為 CNI 提供外掛實現，阿里雲也為 Flannel 專案貢獻了支援阿里雲 VPC 的實現。CNI 最近加入 CNCF 的官方專案。Docker/Moby 社群也會在 Containerd/Swarmkit 中提供 CNI 支援。

CNM 和 CNI 都提供了外掛化的機制來提供網路支援的擴充套件性，也都支援多個網路驅動被同時使用，這些大大擴充套件了容器的靈活性和適用範圍。

然而在設計細節上還是有很多不同，比如 CNI 目前只提供了基本網路管理和 IP 地址管理介面。

Docker libnetwork 是一套完整的容器網路方案實現，不僅提供 CNM 支援 network 驅動和 IPAM plugin，還包含了 DNS、負載均衡、IP Masq 等功能。下面會深入談到其中的一些實現差異。libnetwork 和 CNM 可以讓容器方便地支援多個網路介面，實現更加靈活和安全的網路拓撲。比如，在部署一個典型的三層應用架構（web 層、應用服務層、資料庫層）時。web 層容器和資料庫容器可以分屬於兩個隔離的網路，應用服務層容器則可以同時加入這兩個網路。這樣的網路模型會比把所有容器放置到一個網路更加安全，可以防止由於 Web 層漏洞導致資料庫遭到直接攻擊。libnetwork 代理了網路 plugin 的部分行為，避免 plugin 直接操作容器的 network namespace，其優點是可以仲裁解決不同驅動可能引起的配置衝突，如路由規則等。

Kubernetes 中的網路模型相對簡單，並不需要 libnetwork 類似的衝突解決能力。比如，Pod 中容器共享相同的網路名空間，Pod 只支援一個網路介面等等。

同時這兩種方案也在不斷相互影響和互相融合，不少開源的網路方案同時支援 CNM/CNI 介面。

３.阿里雲的容器服務開啟方式

容器技術使用概況

去年阿里已經實現了電商平臺核心業務（買家鏈路）全部容器化；今年則會實現全部業務應用的容器化，除了一些核心的資料庫系統之外，主要應用和部分資料庫將都完成容器化。由於買家鏈路交易流量大，需要具備彈性，這也是電商最痛的業務部分，所以容器化的改造是先從買家鏈路開始的。

選擇 Docker 是因為它具備開源技術標準化、高效率、工具鏈豐富等優勢。在擁抱 Docker 之前，阿里已經使用了五年多自研容器技術 T4，去年開始基於 Docker 容器技術來進行應用的交付和運維，為了適配阿里內部 IT 系統架構和運維方式做了大量的優化和定製。

時下 AI 的發展備受關注，阿里雲展示了其容器服務對機器學習的支援，該解決方案可以持續觀測使用者機器學習的過程，在發生故障時進行快速修復。

除了對外提供容器服務支撐，阿里雲容器服務團隊還支撐阿里集團容器內部映象倉庫服務，提供集團內部的 Docker 映象分發的基礎設施。利用 Docker 容器技術，可以實現 IT 架構快速水平擴充套件和災備恢復。比如雙 11 時，即使有一個數據中心發生故障（比如地震或火災等不可預知的災難），要確保有能力在一兩個小時內在建立一個的虛擬資料中心，這意味著需要迅速在雲上建立數千臺虛擬機器，並部署完成對應的電商全部業務。

一方面，是 Docker 戰略伙伴

2015 年 12 月開始阿里雲在公共雲上推出了容器服務：支援 Docker 原生編排技術，使用者可以在雲端複用已有的 Docker 映象和編排模板；將容器技術和阿里雲的儲存、網路、日誌、監控等能力整合；預置了容器化 DevOps 解決方案，簡化持續整合和持續交付等。

去年容器技術公司 Docker 與阿里雲宣佈達成戰略合作，當時宣佈的合作包括三方面內容：阿里雲平臺提供 Docker Hub 在中國運營的基礎服務；阿里雲獲得 Docker 企業版的銷售權，為客戶提供企業級支援和諮詢服務；阿里雲 成為 Docker 官方支援的雲服務提供商。

其中 Docker Hub 國內服務已經在阿里雲上海雲棲大會發布。基於阿里雲的資料儲存和 CDN 能力， 加速從國內下載 Docker Hub 容器映象的速度，並且會基於此陸續推出本地化服務，可以訪問 www.docker-cn.comDocker 中國網站了解更多詳情。

Docker 近來面向企業市場推出的 Docker Enterprise Edition（Docker EE）有幾個不同版本 ；Docker EE Basic 對應原來的 Docker Engine CS， Docker EE Advanced 則對應為之前的 Docker Datacenter。其中 Docker 企業版也已經在阿里雲市場釋出。目前阿里雲與 Docker 的合作可以總結為下面三方面：Docker 雲服務對於國內開發者開服；對企業化產品的整合，包括技術和業務流程上的協同；對 Docker 技術在阿里雲能力的整合。

在談及前一段時間在圈內引起軒然大波的 Moby 專案事件時，阿里雲容器負責人易立和阿里雲容器服務產品經理湯志敏均此表達了贊同的觀點。Docker 和 Moby 主要是為了區分產品服務和開源專案的名字。Docker 公司的邏輯是把 Moby 專案交給社群，模組化拆分則提供更多的靈活性，方便應用於不同的特定領域。其實容器領域適用範圍很廣，但是 Docker Engine 並不適合所有場景，對於嵌入式裝置上、網路裝置上等所謂的 IoT 等場景，現有 Docker Engine 會比較重，而基於 Moby 可以剪裁和定製自己的容器引擎。然而此次的改變沒有與社群溝通好，引起了一些誤解，但是未來應該帶給容器生態帶來更多的活力。

而另一方面，支援 Kubernetes，成為 CNCF 金牌會員

上個月， CNCF(Cloud Native Computing Foundation) 基金會宣佈阿里雲正式成為金牌會員，當前 CNCF 最具人氣的專案非 Kubernetes 莫屬；阿里雲同時宣佈除了 Docker 最新版 Swarm mode，其容器雲服務亦將支援 Kubernetes。

阿里雲支援 Kubernetes 的研發工作從 2016 年就已經開始，主要是從與阿里雲能力的整合和簡化 Kubernetes 部署等方面入手，先後陸續支援了若干個國內外的客戶，幫助將其 Kubernetes 環境遷移到阿里雲上。

CNCF（Cloud Native Computing Foundation）是 Linux 基金會下屬定義雲端計算模型未來的重要標準化組織，從最早的容器叢集排程技術 Kubernetes，到現在覆蓋了從容器引擎、容器編排、微服務應用程式設計和運維模型等眾多內容。2017 年 2 月，阿里雲加入 Linux 基金會，並開始與 CNCF 討論合適的加入時機。由於雙方在技術方向，社群發展等方面都有合作基礎，並且阿里雲也一直致力於開源社群和 Cloud Native 的標準推動，比如阿里雲是 containerd 專案的初始成員；所以雙方的合作是水到渠成的事情。

４.一山二虎，容器編排的未來何去何從？

那麼，阿里雲怎樣看待 Docker 和 Kubernetes 背後的兩種編排體系的未來？兩者是會更加有特色的分化？還是更加趨同的直面競爭？

一方面，Docker 和 Kubernetes 將在容器編排領域有更多直接的競爭，因為對於多數應用，Docker 和 Kubernetes 的編排方案都能夠提供類似的能力，社群將在易用性、穩定性、規模、能力等多方面展開競爭，而廠商們也會努力差異化自己的產品，比如阿里雲和 Docker 合作在推動容器在企業混合雲場景的應用。良性競爭終將讓使用者收益，就像 iOS/Andriod 的競爭讓移動網際網路變得如此富有創造力一樣。

但在更高的層面，Docker 和 Kubernetes 並不是競爭對手。容器領域有足夠的想象空間可以發展；商業的成功也不僅決定於技術，生態的建設更加重要： 只有更多的廠商圍繞容器技術進行的創新，更多的應用開發商支援容器化應用交付，更多企業開始擁抱容器技術，才能讓容器商業蓬勃發展。除了編排技術本身，Docker 也在不斷完善生態建設，比如 Docker 企業版提供的認證的基礎設施、外掛和企業應用，可以為企業客戶提供安全可信的容器環境；其推出的傳統應用現代化（Modernize Traditional Applications）專案，將幫助企業使用者改造遺留系統，更好地利用容器技術。在去年底 Docker 推出 containerd 專案時得到了 Google、阿里雲、AWS 等廠商支援，因為它不但提供了一個標準化、穩定的容器執行時，也將更加便於 Kubernetes 這樣的編排方案來進行整合。在這一方面上，Docker 和 Kubernetes 更像是合作伙伴。

業界更希望看到的是各派系編排系統在良性競爭中逐漸成熟，如此整個容器生態、包括企業級使用者將會更加方便輕鬆受益於此。根據 451 Research 調查顯示，以 Docker 為首的容器技術在 2016 年創收 7.62 億美元，預計該數字將於 2020 年上升至 27 億美元。

５.寫在最後

編排系統各自著力佈局發展， Kubernetes 得到了不同廠商的支援，發行版包含 Openshift、Tectonic 等，其最新 1.6 版本在叢集規模、排程能力上都有提升；而 Docker Swarm 作為原生編排機制，提供了簡化使用者體驗，Docker 亦在 DockerCon2017 上為大家展示了其內建安全特性；Mesos 內含 Mesosphere DC/OS，最新版 Mesos 1.1 添加了如巢狀容器、任務組等關鍵性功能 。在眾多提供容器服務的廠商中，阿里雲、Azure、靈雀雲等提供了對 Kubernetes 和 Docker Swarm 的雙支援。當然，目前還有一些容器雲服務堅定地選擇只支援一種編排系統。

在 Kubernetes 和 Docker Swarm 之爭成為焦點之前，其實 Mesos 在早期是被廣泛使用。有些遺憾的是，目前 Mesos 的社群熱度似乎在遞減，而另一方面，業界明顯感受到 Kubernetes 的崛起；Sysdig 調查顯示 43% 的使用者使用 Kubernetes，而只有 9% 的使用者使用 Mesos。那為什麼比 Mesos 晚五年亮相的 Kubernetes 會實現這樣的逆轉呢？不過，兩者的 star 數量相差 7.5 倍（Kubernetes ：23965 顆 star，Mesos：3158 顆 star），不能否認的是社群貢獻的力量，這是對於技術生態的發展至關重要。

同樣，各個 IT 企業也不再偏居一偶地“閉門造車”，在提供或者使用商業軟體同時，大家越來越多地關注開源專案甚至深度參與原始碼的貢獻。Docker 雖為商業公司，也是如此：Docker 已經向 Linux 基金會的 Open Container Initiative 專案捐獻了容器映象和執行時相關規範，和參考實現（runC）；並在今年 3 月份，將其容器引擎核心 containerd 捐獻給了 CNCF；並且還會繼續開展其他標準化工作。而阿里雲則提供容器生態（K8S, Docker 等）多方面技術的支援，同時也參與開源專案貢獻和社群建設；阿里雲稱其會努力成為連線技術生態、企業和高校學術的橋樑，促進越來越多的技術合作。

不論是 CNCF 還是 OCI 都歸屬於 Linux 基金會，兩個基金會成員中有很多 IT 商業公司。OCI 開放容器專案於 2015 年 6 月 22 日由 Docker 與 Linux 聯合推出，加入的公司有 AWS、Cisco、CoreOS、IBM、Intel、Oracle、微軟等 43 名成員。CNCF 是 Google 於 2015 年 7 月 20 日聯合數家公司成立的開源組織，旗下有 Kubernetes 專案，CNCF 基金會中，除了有 eBay、ticketmaster、Twitter 等技術使用公司，還有 Cisco、Dell、Docker、Google、Huawei、IBM、阿里雲、騰訊雲等著名商業公司，也不乏才雲科技、超算雲、DaoCloud、EasyStack、諧雲科技等創業公司，共計 76 名成員。

眾人拾柴火焰高，IT 作為智慧密集型行業，流行的開源專案更容易進入快速發展的良性迴圈模式；而企業級的應用則更需要專注更專業 IT 服務，並預留特定的人力和精力。那麼，基於開源專案提供的商業服務，則可以成為完美結合；比如 RedHat Linux 和 Oracle MySQL 就是很棒的成功先例。

IT 圈已經進化到開源與商業不再劍拔弩張的時代。

作者介紹

木環，InfoQ 運維主編、高效開發運維（ID：DevOpsGeek）負責人，前程式媛。

易立，阿里資深專家，目前負責阿里雲容器服務、開發者服務的研發。之前曾在 IBM 中國開發中心工作，擔任資深技術專員；作為架構師和主要開發人員負責了一系列在雲端計算、中介軟體領域的產品研發和創新。

文章來自微信公眾號：InfoQ