2015 年自己還只是一個(gè)容器的使用者，2016 年作為容器和云相關(guān)的開(kāi)發(fā)者，對(duì)容器生態(tài)圈也比較關(guān)注，本文整體從生態(tài)圈角度分析了一下當(dāng)前的各容器相關(guān)產(chǎn)品，作為個(gè)人年度總結(jié)(本來(lái)是打算年前發(fā)的，可惜一直拖到年后了)。

• 本文只代表個(gè)人觀(guān)點(diǎn)，難免有遺漏的地方，還請(qǐng)指正。
• 本文的視角是技術(shù)生態(tài)圈角度，而不是使用和市場(chǎng)占有角度，也就是說(shuō)該產(chǎn)品是以填補(bǔ)了技術(shù)生態(tài)圈的某個(gè)空隙而生存下來(lái)，而不是通過(guò)市場(chǎng)或者其他方式。

[[184238]]

Docker

提到容器就不能不說(shuō) Docker。容器技術(shù)雖然存在了很長(zhǎng)時(shí)間，卻因 Docker 而火。很長(zhǎng)時(shí)間里，很多人的概念里基本 Docker 就代表容器。一次一產(chǎn)品經(jīng)理朋友問(wèn)我做什么，我說(shuō)做容器相關(guān)，她表示很不懂，但說(shuō)是 Docker ，她就明白了，可見(jiàn) Docker 之火。這一年里，Docker 發(fā)布了幾個(gè)重要版本。我們先回顧下 Docker 本來(lái)是什么，再說(shuō)它的變化。

1. Docker 的鏡像機(jī)制提供了一種更高級(jí)的通用的應(yīng)用制品(artifact)包，也就是大家說(shuō)的集裝箱能力。原來(lái)各種操作系統(tǒng)或編程語(yǔ)言都有各自己的制品機(jī)制，Ubuntu 的 deb，RedHat 的 RPM，Java 的 JAR、WAR，各自的依賴(lài)管理，制品庫(kù)都不相同。應(yīng)用從源碼打包，分發(fā)到制品庫(kù)，再部署到服務(wù)器，很難抽象出一種通用的流程和機(jī)制。而有了 Docker 的鏡像以及鏡像倉(cāng)庫(kù)標(biāo)準(zhǔn)之后，這個(gè)流程終于可以標(biāo)準(zhǔn)化了。于是雨后春筍般冒出很多鏡像管理倉(cāng)庫(kù)，這在以前的制品管理領(lǐng)域是很難想象的，以前貌似也就 Java 領(lǐng)域的 nexus 和 artifactory 略完備些。
2. Docker 鏡像機(jī)制以及制作工具，取代了一部分 ansible/puppet 的職能，至少主機(jī)上的各種軟件棧以及依賴(lài)關(guān)系的定義和維護(hù)被容器替代，運(yùn)維人員的不可變基礎(chǔ)設(shè)施的夢(mèng)想被 Docker 實(shí)現(xiàn)。
3. Docker 對(duì) cgroups/namespace 機(jī)制以及網(wǎng)絡(luò)的封裝，使其很容易在本地模擬出多節(jié)點(diǎn)運(yùn)行環(huán)境，方便開(kāi)發(fā)人員開(kāi)發(fā)調(diào)試復(fù)雜的，分布式的軟件系統(tǒng)。
4. Docker 的 daemon 進(jìn)程，取代了一部分 systemd/supervisor 這樣的系統(tǒng)初始化進(jìn)程管理器的作用，通過(guò) Docker 運(yùn)行的服務(wù)，可以不受 systemd 管理，由 docker daemon 維護(hù)其生命周期。

前三點(diǎn)基本上都是容器相關(guān)或者延伸的，唯獨(dú)第四點(diǎn)，深受其他容器編排調(diào)度廠(chǎng)商的詬病。任何分布式的管理系統(tǒng)，都會(huì)在每個(gè)主機(jī)上安裝一個(gè)自己的 agent，由這個(gè) agent 管理該節(jié)點(diǎn)上的應(yīng)用進(jìn)程。從這點(diǎn)功能上來(lái)說(shuō)，和 Docker daemon 是沖突的，操作系統(tǒng)的 systemd，可以忽略不用就行，但要用 Docker 容器的話(huà)，離不開(kāi) Docker daemon 。設(shè)想一下，如果你老板讓你管理一個(gè)團(tuán)隊(duì)，但任何管理指令都只能通過(guò)另外一個(gè)人來(lái)發(fā)出，你也會(huì)感覺(jué)不爽吧?所以 Docker 和其他容器編排調(diào)度系統(tǒng)的沖突從開(kāi)始就種下了。感覺(jué)開(kāi)始 Docker 團(tuán)隊(duì)也沒(méi)思考這個(gè)問(wèn)題，自己的 Swarm 也是用獨(dú)立的 agent，但后來(lái)發(fā)現(xiàn)有點(diǎn)多余，把 Swarm 的 agent 以及調(diào)度器內(nèi)置到 Docker daemon 不就行?何況 Docker daemon 本身已經(jīng)支持了 remote API，并且這樣設(shè)計(jì)還是一個(gè)無(wú)中心的對(duì)等節(jié)點(diǎn)集群模式，部署運(yùn)維更方便。于是 Docker 的 1.12 內(nèi)置了 Swarm(準(zhǔn)確的說(shuō)是 SwarmKit)，幾個(gè)命令就將多個(gè)單機(jī)版本的 Docker daemon 變成一個(gè) cluster，還支持了 service 概念(多個(gè)容器實(shí)例副本的抽象)，1.13 支持了 stack 的概念(多個(gè) service 的組合) 和 Compose(編排定義文件)，基本上一個(gè)略完備的編排調(diào)度系統(tǒng)已經(jīng)成型。

而這個(gè)變化，也表明了和其他容器編排調(diào)度系統(tǒng)的決裂。本來(lái) Docker 作為容器的一種，大家都在上面基于容器搭建編排調(diào)度系統(tǒng)，還能和平共處。容器相當(dāng)于輪子，編排調(diào)度系統(tǒng)是車(chē)，結(jié)果有一天造輪子的廠(chǎng)商說(shuō)自己的幾個(gè)輪子直接拼接起來(lái)就稱(chēng)為一輛車(chē)了，造車(chē)的廠(chǎng)商不急才怪，這相當(dāng)于發(fā)起了『降維』攻擊。

有了編排調(diào)度系統(tǒng)，Docker 進(jìn)而推出 Store 也是順理成章。服務(wù)器端的應(yīng)用大多不是單個(gè)節(jié)點(diǎn)或進(jìn)程的應(yīng)用，需要將多個(gè)服務(wù)組裝，一直以來(lái)大家都在尋找一種方式實(shí)現(xiàn)服務(wù)器端應(yīng)用的一鍵安裝和部署。Docker 的應(yīng)用打包了編排文件以及鏡像定義，配合編排調(diào)度系統(tǒng)提供的標(biāo)準(zhǔn)環(huán)境，再用 Store 作為應(yīng)用分發(fā)，意圖已經(jīng)非常明確。但感覺(jué) Docker 這步走的略匆忙，當(dāng)前編排調(diào)度系統(tǒng)尚未成熟，就著急推出更上一層的應(yīng)用，可能會(huì)拖累后面的演進(jìn)，不過(guò)這也應(yīng)該是受商業(yè)化的壓力所致吧。

當(dāng)然 Docker 出此決策，面臨的挑戰(zhàn)也是巨大的。容器生態(tài)圈的割裂，導(dǎo)致 Docker 得以一己之力重塑自己的生態(tài)圈。Docker 推出的容器網(wǎng)絡(luò)標(biāo)準(zhǔn)(libnetwork)不被其他廠(chǎng)商接受，其他廠(chǎng)商也在降低對(duì) Docker 的依賴(lài)程度(整個(gè)后面具體分析時(shí)會(huì)提到)。Swarm 成熟度還不夠用在生產(chǎn)環(huán)境，它的網(wǎng)絡(luò)當(dāng)前只支持 overlay，尚不能支持自己的網(wǎng)絡(luò)插件標(biāo)準(zhǔn)，編排文件的完備程度也不夠。存儲(chǔ)方面，去年 Docker 收購(gòu)了 Infinit (很早就關(guān)注 Infinit，它一直宣稱(chēng)要開(kāi)源，但遲遲沒(méi)等到源碼，就聽(tīng)到了它被 Docker 收購(gòu)的消息)這家做分布式存儲(chǔ)的公司。如果 Docker 在2017年解決網(wǎng)絡(luò)和存儲(chǔ)兩個(gè)分布式系統(tǒng)的痛點(diǎn)，Swarm 的前景還是可期。

作為一個(gè)開(kāi)發(fā)者，我自己其實(shí)挺喜歡 Docker 的這種設(shè)計(jì)的，雖然它推出的有點(diǎn)晚。這種模式符合開(kāi)發(fā)團(tuán)隊(duì)對(duì)容器的漸進(jìn)式接納。比如開(kāi)始可以先將 Docker 當(dāng)做一種制品包管理工具，網(wǎng)絡(luò)用 host 模式，這種方式和在主機(jī)上維護(hù)部署多個(gè)應(yīng)用的進(jìn)程沒(méi)有區(qū)別，只是接管了依賴(lài)以及安裝包的維護(hù)。然后當(dāng)開(kāi)發(fā)流程的打包機(jī)制改造完畢，開(kāi)發(fā)人員的習(xí)慣逐漸改變，這時(shí)候就可以引入 Docker 的網(wǎng)絡(luò)解決方案，先改造應(yīng)用直接通過(guò)容器的網(wǎng)絡(luò)進(jìn)行通信，但部署和調(diào)度都沿用原來(lái)的模式。等這些都改造完，運(yùn)維也成熟了，然后開(kāi)啟 Swarm 模式，將應(yīng)用的部署和調(diào)度交給 Swarm，基本上完成了應(yīng)用的容器化改造。這就像談戀愛(ài)一樣，先約約會(huì)，牽牽小手，然后(此處省略若干字)，然后才是談婚論嫁，考慮要不要做一輩子的承諾。而其他編排系統(tǒng)呢，一上來(lái)就要用戶(hù)回答：你準(zhǔn)備把你的一切以及后半生交付給我了么?很多人就得猶豫了吧。

總結(jié)一下，這一年，Docker 已經(jīng)不是原來(lái)的 Docker，它代表一種容器方案，一個(gè)系統(tǒng)軟件，也代表一個(gè)商標(biāo)，一個(gè)公司，還代表一種容器編排調(diào)度系統(tǒng)。容器之戰(zhàn)剛剛開(kāi)始，三足鼎立，勝負(fù)未知。但無(wú)論最后結(jié)果如何，Docker 一初創(chuàng)公司，從開(kāi)發(fā)者工具切入，僅僅三年，火遍全球技術(shù)圈，攪動(dòng)整個(gè)服務(wù)器端技術(shù)棧，進(jìn)而涉足企業(yè)應(yīng)用市場(chǎng)，攜用戶(hù)以抗巨頭，前所未有。傳統(tǒng)的企業(yè)市場(chǎng)，決策權(quán)多在不懂技術(shù)的領(lǐng)導(dǎo)，所以解決方案中對(duì)開(kāi)發(fā)者是否友好，不是一個(gè)關(guān)鍵點(diǎn)，但從 Docker 以及國(guó)外最近的一些公司的案例(比如 slack，twilio 等)來(lái)看，這一現(xiàn)象正在改變，這表明了開(kāi)發(fā)者群體的成熟和話(huà)語(yǔ)權(quán)的增加，企業(yè)應(yīng)用對(duì)開(kāi)發(fā)者的友好程度將成為一個(gè)競(jìng)爭(zhēng)的關(guān)鍵點(diǎn)。

Kubernetes

我在 2015 年底分析 Kubernetes 架構(gòu)的時(shí)候，當(dāng)時(shí) 1.2 版本尚未發(fā)布。到現(xiàn)在已經(jīng)發(fā)布了 1.6 beta 版本了。去年是 Kubernetes 爆發(fā)的一年，從社區(qū)文章以及 meetup 就可以看出來(lái)。有很多文章已經(jīng)等不及開(kāi)始宣布 Kubernetes 贏得了容器之戰(zhàn)了。

Kubernetes 的優(yōu)勢(shì)是很多概念抽象非常符合理想的分布式調(diào)度系統(tǒng)，即便是你自己重新設(shè)計(jì)這樣一個(gè)系統(tǒng)，經(jīng)過(guò)不斷優(yōu)化和抽象，最后也會(huì)發(fā)現(xiàn)，不可避免的慢慢向 Kubernetes 靠近。 比如 Pod，Service，Cluster IP，ReplicationController(新的叫 ReplicaSets )，Label，以及通過(guò) Label 自由選擇的 selector 機(jī)制，以及去年引入的 DaemonSets 和 StatefulSets。

DaemonSets 用于定義需要每個(gè)主機(jī)都部署一個(gè)，并且不需要?jiǎng)討B(tài)遷移的服務(wù)，比如監(jiān)控的服務(wù)。Swarm 中尚未引入這種概念，不過(guò)這種也可能會(huì)用另外的實(shí)現(xiàn)方式，比如插件機(jī)制。通過(guò) DaemonSet 定義的服務(wù)可以理解成分調(diào)度系統(tǒng)的 agent 擴(kuò)展插件。

StatefulSets(1.5 版本之前叫 PetSets)主要是為了解決有狀態(tài)服務(wù)部署的問(wèn)題，它保證 pod 的唯一的網(wǎng)絡(luò)標(biāo)志(主要是 pod 的 hostname，ip 是否能保持不變?nèi)Q于網(wǎng)絡(luò)實(shí)現(xiàn))的穩(wěn)定性，不隨 pod 遷移重建而變化，另外支持了 PersistentVolume 規(guī)范，封裝了已有的分布式存儲(chǔ)以及 IaaS 云的存儲(chǔ)接口。

網(wǎng)絡(luò)方面，Kubernetes 推出 CNI(Container Network Interface) 網(wǎng)絡(luò)標(biāo)準(zhǔn)。這個(gè)標(biāo)準(zhǔn)比較簡(jiǎn)單，只是約定了調(diào)用命令的參數(shù)，如果想擴(kuò)展自己的實(shí)現(xiàn)，只需要寫(xiě)個(gè)命令行工具放到系統(tǒng) path 下，然后根據(jù) CNI 調(diào)用的參數(shù)來(lái)給容器分配網(wǎng)絡(luò)即可，可以用任何語(yǔ)言實(shí)現(xiàn)。它和 Kubernetes 基本沒(méi)有任何耦合，所以也可以很容易被其他調(diào)度系統(tǒng)采用(比如 Mesos)。

從 Kubernetes 的演進(jìn)可以看出，谷歌對(duì) Kubernetes 的期望在標(biāo)準(zhǔn)制定，最核心的點(diǎn)是描述能力。官方文檔 What is Kubernetes? 中有這樣一段描述：

Kubernetes is not a mere “orchestration system”; it eliminates the need for orchestration. The technical definition of “orchestration” is execution of a defined workflow: do A, then B, then C. In contrast, Kubernetes is comprised of a set of independent, composable control processes that continuously drive current state towards the provided desired state. It shouldn’t matter how you get from A to C: make it so.

它的目標(biāo)不僅僅是一個(gè)編排系統(tǒng)，而是提供一個(gè)規(guī)范，可以讓你來(lái)描述集群的架構(gòu)，定義服務(wù)的最終狀態(tài)，它來(lái)幫助你的系統(tǒng)達(dá)到和維持在這個(gè)狀態(tài)。這個(gè)其實(shí)和 Puppet/Ansible 等配置管理工具的目的是一致的，只是配置管理工具只能做達(dá)到某個(gè)狀態(tài)，沒(méi)法實(shí)現(xiàn)維持到這個(gè)狀態(tài)(沒(méi)有動(dòng)態(tài)的伸縮以及故障遷移等調(diào)度能力)，同時(shí)配置管理工具的抽象層次也比較低。它之所以選擇容器只是因?yàn)槿萜鞅容^容易降低主機(jī)和應(yīng)用的耦合，如果有其他技術(shù)能達(dá)到這個(gè)目的，支持下也不影響它的定位。所以 Kubernetes 去年推出 CRI (Container Runtime Interface) 容器標(biāo)準(zhǔn)，將 Kubernetes 和具體的容器實(shí)現(xiàn)進(jìn)一步解耦，一方面是對(duì) Docker 內(nèi)嵌 Swarm 的一種反制，另外一方面也是它的目標(biāo)的必然演進(jìn)結(jié)果。

正因?yàn)檫@樣，它讓渡出了很大一部分功能給 IaaS 云(比如網(wǎng)絡(luò)，存儲(chǔ))，也不著急推出具體的解決方案，也不著急兼容已有的各種分布式應(yīng)用，發(fā)布兩年多還在專(zhuān)心在規(guī)范定義以及系統(tǒng)優(yōu)化上。Kubernetes 系出名門(mén)，不擔(dān)心商業(yè)化的問(wèn)題，大家閨秀不愁嫁，無(wú)需迎合別人，自然有人來(lái)適應(yīng)自己。

當(dāng)然理想是美好的，現(xiàn)實(shí)是當(dāng)前已經(jīng)有大量的分布式系統(tǒng)，重復(fù)實(shí)現(xiàn)了許多 Kubernetes 已經(jīng)實(shí)現(xiàn)的功能，或者集群機(jī)制是當(dāng)前的 Kubernetes 的抽象概念沒(méi)有覆蓋到的，當(dāng)前將這些系統(tǒng)運(yùn)行到 Kubernetes 還是一件很難的事情(比如 redis cluster，hadoop，etcd，zookeeper，支持主從自動(dòng)切換的mysql集群等)，因?yàn)槿魏纬橄蠖际且該p失個(gè)性化和特殊化為代價(jià)的。這里特別說(shuō)下，以前分析 Kubernetes 的時(shí)候有人反駁我這個(gè)說(shuō)法，我這里不是說(shuō) Kubernetes 上不能運(yùn)行 zookeeper 這樣的服務(wù)，而是很難實(shí)現(xiàn)一鍵部署并且自動(dòng)伸縮以及配置自動(dòng)變更，很多情況下還是需要手動(dòng)操作接入，比如官方的這個(gè) zookeeper 例子。

CoreOS 為了解決這個(gè)問(wèn)題，推出了 operator 的概念，給不容易通過(guò) Kubernetes 當(dāng)前的抽象描述的服務(wù)(有狀態(tài)服務(wù)或者特殊的集群服務(wù))，專(zhuān)門(mén)提供一個(gè) operator，operator 通過(guò)調(diào)用 Kubernetes 的 API 來(lái)實(shí)現(xiàn)伸縮，恢復(fù)，升級(jí)備份等功能。這樣雖然和 Kubernetes 的聲明式理念相沖突，也無(wú)法通過(guò) kubectl 直接操作(kubectl 有支持插件機(jī)制的提案，未來(lái)這種需求可能通過(guò)插件實(shí)現(xiàn))，也但當(dāng)前也是一個(gè)可行的辦法。(注：本文發(fā)布后 CoreOS 的李響對(duì)這段關(guān)于 operator 的描述進(jìn)行了糾正，operator 是基于 Kubernetes 的 Third Party Resources 方式擴(kuò)展的，可以通過(guò) kubectl 操作，特此糾正)

另外，Kubernetes 在大數(shù)據(jù)方面支和 Mesos 還有差距。去年 Kubernetes 支持了 job 概念，job 生成的 pod 執(zhí)行完成后立刻退出，原來(lái)的 service 可以理解成一個(gè)死循環(huán)的 job。這樣，Kubernetes 就具有了分發(fā)批量任務(wù)的能力，但還缺乏上層的應(yīng)用接口。理論上，將 Hadoop 的 MapReduce 移植到 Kubernetes，用 Kubernetes 替代底層的 Yarn 的資源調(diào)度功能，也是可行的(只是開(kāi)腦洞，沒(méi)有具體分析)。有個(gè)打算整合 Yarn 和 Kubernetes 的項(xiàng)目已經(jīng)很久沒(méi)更新了，這兩者的整合我不太看好，兩個(gè)系統(tǒng)沖突嚴(yán)重，是互相替代的關(guān)系，不像 Mesos 和 Kubernetes 的整合(這個(gè)后面 Mesos 的段落會(huì)分析)。

部署復(fù)雜是 Kubernetes 一直被大家詬病一點(diǎn)。2015 年我做測(cè)試的時(shí)候，部署一套 Kubernetes 是一項(xiàng)很復(fù)雜的工作。去年 Kubernetes 推出了 kubeadm，很大程度的降低了部署的復(fù)雜度。當(dāng)前 Kubernetes 除了 kubelet 需要直接在主機(jī)上啟動(dòng)，其他的組件都可以通過(guò) Kubernetes 自己托管，一定程度上實(shí)現(xiàn)了『自舉』，但易用度上和 Swarm 還是有差距。

隨著 Kubernetes 的成熟，其他廠(chǎng)商開(kāi)始制作自己的發(fā)行版，比如 CoreOS。CoreOS 原來(lái)的容器思路應(yīng)該是通過(guò)自己定制的容器操作系統(tǒng)，以及 etcd ，將多個(gè) CoreOS 主機(jī)合并成一個(gè)集群，然后通過(guò)改造過(guò)的 systemd 充當(dāng) agent，上面再增加一個(gè)調(diào)度器，就可以實(shí)現(xiàn)容器編排調(diào)度，也是一種可行的思路，既然單機(jī)的服務(wù)進(jìn)程管理可以通過(guò) systemd，將多個(gè)機(jī)器的 systemd 連接起來(lái)不就是一個(gè)分布式的服務(wù)進(jìn)程管理?但后來(lái)改變了策略，估計(jì)是這種方案采納成本太高(用戶(hù)需要同時(shí)改變自己主機(jī)的操作系統(tǒng)以及應(yīng)用的部署習(xí)慣)，所以當(dāng)前的容器策略變?yōu)榱硕ㄖ? Kubernetes，推出 tectonic，CoreOS 改名為 Container Linux(應(yīng)該是為了避免產(chǎn)品和公司的名稱(chēng)重疊，另外也透露出的一個(gè)信息是產(chǎn)品重心的變更)，專(zhuān)注于主機(jī)操作系統(tǒng)(這個(gè)后面的操作系統(tǒng)部分會(huì)分析到)。

總結(jié)一下，Kubernetes 經(jīng)過(guò)一年快速發(fā)展，基本已經(jīng)非常完備。原來(lái)的 kube-proxy 的性能問(wèn)題(1.2 版本之前)，也已經(jīng)解決。建議原來(lái)處于觀(guān)望狀態(tài)的用戶(hù)可以入坑了。不過(guò)在應(yīng)用的最終 package 定義上，Kubernetes 尚未推出自己的解決方案，不確定這個(gè)是打算官方來(lái)搞，還是讓度給發(fā)行版廠(chǎng)商，不過(guò)可以預(yù)計(jì)2017年肯定會(huì)有相關(guān)方案推出。

Mesos

如果說(shuō) Kubernetes 是為了標(biāo)準(zhǔn)而生，那 Mesos 則是為了資源而生。它的理念是：

define a minimal interface that enables efficient resource sharing across frameworks, and otherwise push control of task scheduling and execution to the frameworks

定義一個(gè)最小化的接口來(lái)支持跨框架的資源共享，其他的調(diào)度以及執(zhí)行工作都委托給框架自己來(lái)控制。

也就是說(shuō)它的視角是資源視角，目標(biāo)是資源共享。這個(gè)和 Kubernetes 的目標(biāo)其實(shí)是一體兩面，一個(gè)從定義描述角度一個(gè)從資源角度。Mesos 其實(shí)是最早切入容器領(lǐng)域的，但它的容器封裝的比較簡(jiǎn)單，只是用來(lái)做簡(jiǎn)單的資源隔離，用戶(hù)一般沒(méi)什么感知。有了 Docker 以后，也引入了 Docker，但正如前面我分析的原因，Mesos 上的 Docker 一直有點(diǎn)別扭，于是 Mesos(準(zhǔn)確的說(shuō)應(yīng)該是 mesosphere DC/OS) 搞了一個(gè) Universal container，改進(jìn)了 Mesos 原來(lái)的容器，支持了 Docker 的鏡像格式，這樣用戶(hù)可以在自己的開(kāi)發(fā)環(huán)境中使用 Docker，但生產(chǎn)環(huán)境中就可以直接切換到 Mesos 自己的容器上，雖然可能有一些兼容性問(wèn)題，但鏡像格式這種變化不會(huì)太快，問(wèn)題在可控范圍內(nèi)。

這也從另外一方面表明了 Docker 的鏡像格式基本上已經(jīng)成了一個(gè)事實(shí)標(biāo)準(zhǔn)，一個(gè)容器解決方案能否切入整個(gè)生態(tài)圈的關(guān)鍵是是否支持 Docker 鏡像格式。當(dāng)然 Mesos 成員對(duì)這點(diǎn)其實(shí)也有點(diǎn)抵觸，在一些分享里強(qiáng)調(diào) Mesos 也支持部署其他類(lèi)型的軟件包格式，比如gzip等，尤其大規(guī)模服務(wù)器的場(chǎng)景，從 Docker 倉(cāng)庫(kù)拉取鏡像有瓶頸。這點(diǎn)個(gè)人不太同意，大規(guī)模服務(wù)器場(chǎng)景，從任何中心節(jié)點(diǎn)拉取任何格式的安裝包都會(huì)有問(wèn)題，所以 twitter 才搞 p2p 安裝包分發(fā)，但 Docker 鏡像也可以搞成 p2p 分發(fā)的，只要有需求，肯定有人能搞出來(lái)。

容器網(wǎng)絡(luò)方面，原來(lái) Mesos 的網(wǎng)絡(luò)解決方案就是端口映射，應(yīng)用需要適應(yīng) Mesos 做修改，對(duì)應(yīng)用傾入性比較強(qiáng)，通用性較差，所以 Mesos 支持了 Kubernetes 發(fā)起的 CNI 網(wǎng)絡(luò)標(biāo)準(zhǔn)，解決了這個(gè)問(wèn)題。

Mesos 通過(guò) framework 的機(jī)制，接管了當(dāng)前已經(jīng)存在的分布式系統(tǒng)的一部分職能，讓多個(gè)分布式系統(tǒng)共享同一個(gè)資源池變?yōu)榭赡埽萜骶幣乓仓皇? Mesos 之上的一種應(yīng)用(Marathon)。這種方式的好處是讓整合復(fù)雜的分布式系統(tǒng)變?yōu)榭赡埽驗(yàn)?framework 是編程接口，靈活度也比較高，很多不容易跑在 Kubernetes 上的復(fù)雜應(yīng)用，都可以在 Mesos 之上，比如 Hadoop 等大數(shù)據(jù)相關(guān)的系列應(yīng)用。

正因?yàn)?Mesos 和 Kubernetes 的目標(biāo)正好是一體兩面，然后能力也可以互補(bǔ)，所以很早就有人想整合 Kubernetes 和 Mesos，將 Kubernetes 跑在 Mesos 之上，這樣 Kubernetes 接管容器編排調(diào)度，替代 Marathon，Mesos 解決其他復(fù)雜的分布式應(yīng)用，實(shí)現(xiàn)多種應(yīng)用的資源共享。但 kubernetes-mesos 這個(gè)項(xiàng)目后來(lái)就不活躍了，一方面是 Kubernetes 變化太快，另外一方面估計(jì)是 mesosphere 發(fā)現(xiàn)和 Kubernetes 的競(jìng)爭(zhēng)大于合作吧。后來(lái) IBM 搞了個(gè) kube-mesos-framework 放在 Kubernetes 孵化器里孵化，不過(guò)當(dāng)前尚不能正式使用。個(gè)人感覺(jué)如果要真的很好整合，對(duì) Kubernetes 和 Mesos 兩方都需要做很大改造，但這個(gè)項(xiàng)目對(duì)生態(tài)圈來(lái)說(shuō)是一個(gè)大變數(shù)，有可能打破三足鼎立的局勢(shì)。

Mesosphere 的 DC/OS 在 Mesos 基礎(chǔ)上搞了一個(gè)分布式應(yīng)用的 package 規(guī)范。以前的應(yīng)用發(fā)布都只能發(fā)布面向單機(jī)操作系統(tǒng)的 package，Mesosphere 通過(guò) Marthon，鏡像以及配置文件，定義了一套分布式的 package 規(guī)范，用戶(hù)可以通過(guò)一個(gè)命令從倉(cāng)庫(kù)(repo)上部署復(fù)雜的分布式應(yīng)用到 Mesos。這個(gè)和 Docker 的 Store 思路類(lèi)似。

總結(jié)一下，Mesos 的優(yōu)勢(shì)是可定制性強(qiáng)，它誕生于 twitter 這樣的互聯(lián)網(wǎng)公司，也比較受互聯(lián)網(wǎng)公司歡迎。互聯(lián)網(wǎng)公司的基礎(chǔ)設(shè)施以及系統(tǒng)大多是自己研發(fā)，可以通過(guò)規(guī)范來(lái)要求自己的應(yīng)用適應(yīng)調(diào)度系統(tǒng)，所以對(duì)標(biāo)準(zhǔn)化和抽象能力的的需求不如資源共享強(qiáng)烈。它的缺點(diǎn)是周邊生態(tài)比較龐雜，接口以及規(guī)范設(shè)計(jì)上，沒(méi)有 Kubernetes 那么『優(yōu)雅』。

Rancher

既然容器之上的編排系統(tǒng)已經(jīng)三足鼎立了，各有所長(zhǎng)了，還有其他機(jī)會(huì)么?Rancher 嘗試了另外一個(gè)途徑。它自己的定義是一種 IaaS，一種基于容器的 IaaS。首先，它通過(guò)容器降低了部署成本，每個(gè)只需節(jié)點(diǎn)運(yùn)行一個(gè)命令就能部署一套 Rancher 系統(tǒng)，相對(duì)于 OpenStack 這種復(fù)雜的 IaaS 來(lái)說(shuō)就太容易了。其次，它自己的定位是專(zhuān)門(mén)運(yùn)行容器編排系統(tǒng)的 IaaS，可以在上面一鍵部署 Kubernetes，Docker Swarm，Mesos。容器編排系統(tǒng)，直接運(yùn)行到物理機(jī)上還是需要一些改造，并且有升級(jí)和運(yùn)維困難的問(wèn)題，于是 Rancher 出來(lái)了，希望抽象出一層非常薄的 IaaS 來(lái)解決這個(gè)問(wèn)題。

它的思路是既然現(xiàn)在三家紛爭(zhēng)，選哪一方都是一個(gè)艱難的決定，那不如選 Rancher 好了。Rancher 一方面可以讓幾種編排系統(tǒng)共存，另外一方面降低了以后的切換成本，這個(gè)艱難的決定可以以后再做。

另外它也推出了自己的應(yīng)用規(guī)范和應(yīng)用倉(cāng)庫(kù)(App Catalogs)，它的應(yīng)用規(guī)范也兼容其他的容器編排系統(tǒng)的定義文件，相當(dāng)于一個(gè)容器編排系統(tǒng)應(yīng)用的一個(gè)超集。這樣和基礎(chǔ)設(shè)施相關(guān)的應(yīng)用可以用 Rancher 自己的規(guī)范，和業(yè)務(wù)相關(guān)的，變化快需要?jiǎng)討B(tài)伸縮的應(yīng)用可以放到容器編排系統(tǒng)中，以后切換也不麻煩。

不過(guò) Rancher 的這個(gè)產(chǎn)品假設(shè)的問(wèn)題是，假如以后容器編排調(diào)度系統(tǒng)是一家獨(dú)大，那它的存在空間就會(huì)越來(lái)越小了。

容器平臺(tái)去向何方?CaaS，IaaS，PaaS，SaaS?

有人把容器服務(wù)叫做 CaaS(Container as a Service)，類(lèi)似于當(dāng)前 IaaS 平臺(tái)上的數(shù)據(jù)庫(kù)服務(wù)(RDB as a Service)等，是 IaaS 之上的一種新的應(yīng)用服務(wù)。但個(gè)人認(rèn)為 CaaS 其實(shí)是一個(gè)偽需求，用戶(hù)需要的并不是容器，從來(lái)也沒(méi)有人把 IaaS 叫做 VaaS(VM as a Service)，容器服務(wù)提供的是一種運(yùn)行環(huán)境，并不是具體的服務(wù)。

容器編排調(diào)度平臺(tái)首先是一個(gè)面向開(kāi)發(fā)者的的工具平臺(tái)，它上面調(diào)度的是應(yīng)用，這是和當(dāng)前 IaaS 最大的區(qū)別。當(dāng)前的 IaaS 主要面向的是管理者，調(diào)度的是資源，所以 IaaS 的使用入口主要是控制臺(tái)，雖然有 API，但指令式的 API 使用復(fù)雜度要遠(yuǎn)大于聲明式的 API，并且 API 的使用者也多是運(yùn)維工具，很少有融入業(yè)務(wù)系統(tǒng)的使用場(chǎng)景。這是由當(dāng)前 IaaS 云的歷史使命決定的。云的第一步是讓用戶(hù)把應(yīng)用從自己的機(jī)房遷移到云上，只有提供可以完全模擬用戶(hù)物理機(jī)房的環(huán)境(虛擬機(jī)模擬硬件支持全功能的OS，SDN網(wǎng)絡(luò)，云硬盤(pán)存儲(chǔ))，對(duì)應(yīng)用無(wú)侵入，用戶(hù)的遷移成本才更低。

但當(dāng)這一步完成時(shí)，用戶(hù)就會(huì)發(fā)現(xiàn)，這樣雖然省去了硬件的維護(hù)成本，但應(yīng)用的開(kāi)發(fā)維護(hù)成本并沒(méi)有降低，認(rèn)識(shí)到自己本質(zhì)的需求并不是資源，而是應(yīng)用的運(yùn)行環(huán)境。這個(gè)需求有點(diǎn)像 PaaS，但原來(lái)的 PaaS 的問(wèn)題是對(duì)應(yīng)用的侵入性太強(qiáng)，并且和開(kāi)發(fā)語(yǔ)言綁定，能直接部署的應(yīng)用有限，用戶(hù)需要的是一種更通用的 PaaS，可以叫(Generic Platform as a Service)，這個(gè)詞是我生造的，就是一種基本可以部署任何復(fù)雜應(yīng)用的平臺(tái)服務(wù)，正好容器平臺(tái)可以承擔(dān)起這樣一種職責(zé)。

容器平臺(tái)雖然都有各自的歷史背景和側(cè)重點(diǎn)，解決方案也不一樣，但最終指向的目標(biāo)卻是一致的，就是屏蔽分布式系統(tǒng)的資源管理細(xì)節(jié)，提供分布式應(yīng)用的標(biāo)準(zhǔn)運(yùn)行環(huán)境，同時(shí)定義一種分布式應(yīng)用的 package，對(duì)開(kāi)發(fā)者來(lái)說(shuō)降低分布式系統(tǒng)的開(kāi)發(fā)成本，對(duì)用戶(hù)來(lái)說(shuō)降低分布式應(yīng)用的維護(hù)成本，對(duì)廠(chǎng)商來(lái)說(shuō)降低分布式應(yīng)用的分發(fā)成本。總結(jié)一下，其實(shí)就是 DataCenter OS 或 Distributed OS。DC/OS 這個(gè)詞雖然已經(jīng)被 Mesosphere 用在自己的產(chǎn)品上了，但個(gè)人認(rèn)為它是所有容器平臺(tái)的最終目標(biāo)。當(dāng)然，這次容器浪潮是否能真的實(shí)現(xiàn)這個(gè)目標(biāo)還不好說(shuō)，但至少現(xiàn)在看來(lái)是有希望的。

于是， PaaS 會(huì)變成了 DCOS 之上的 devops 工具棧，當(dāng)前很多 PaaS 平臺(tái)正向這個(gè)方向演進(jìn)。而 IaaS 就變成了給 DCOS 提供運(yùn)行環(huán)境的服務(wù)，DCOS 接管了上層的應(yīng)用以及基礎(chǔ)服務(wù)。當(dāng)然 IaaS 之上還有其他的 SaaS 模式的服務(wù)(由于 SaaS，PaaS 的外延并沒(méi)有精確定義，很多場(chǎng)景下，把面向開(kāi)發(fā)者的 SaaS 模式的中間件叫做 PaaS 組件，我的理解是通過(guò)軟件實(shí)現(xiàn)多租戶(hù)，完全按量計(jì)費(fèi)的服務(wù)都應(yīng)該屬于 SaaS，比如對(duì)象存儲(chǔ)。這個(gè)要細(xì)說(shuō)，估計(jì)需要另外一篇文章，這里就不詳細(xì)分析了)，SaaS 模式資源利用率最高，對(duì)用戶(hù)的成本最低，用戶(hù)一般不會(huì)用獨(dú)立部署的服務(wù)去替換。這樣一來(lái)，格局就變成了用戶(hù)在 IaaS 之上部署一套 DCOS，需要獨(dú)立部署的服務(wù)以及自己開(kāi)發(fā)的服務(wù)都運(yùn)行在 DCOS 之中，其他的能抽象成標(biāo)準(zhǔn) SaaS 服務(wù)的中間件則優(yōu)先用 IaaS 提供的。相當(dāng)于 IaaS 將獨(dú)立部署的基礎(chǔ)設(shè)施服務(wù)，以及用戶(hù)自己的服務(wù)的部署和調(diào)度讓渡給了 DCOS。當(dāng)然，最后 IaaS 本身是否會(huì)直接變成一種多租戶(hù)的 DCOS，由調(diào)度資源變成直接調(diào)度應(yīng)用，也不是沒(méi)可能，但這樣調(diào)度層會(huì)面臨非常大的壓力，數(shù)據(jù)中心支撐的節(jié)點(diǎn)會(huì)受限，暫時(shí)看來(lái)兩層調(diào)度的可行性更大些。

這對(duì)整個(gè) IaaS 影響很大，所以有人說(shuō)對(duì) AWS 造成威脅的可能不是 Google Cloud，而是 Kubernets(DCOS)。但即便是 DCOS 成熟，最后如何商業(yè)化還是有很大的變數(shù)。大家理想中的那個(gè)像 Apple 的 AppStore 的服務(wù)器端應(yīng)用市場(chǎng)，最終會(huì)是由 DCOS，SaaS，還是 IaaS 服務(wù)商提供?DCOS 的優(yōu)勢(shì)是掌握了標(biāo)準(zhǔn)可以定義應(yīng)用規(guī)范，SaaS 服務(wù)商的優(yōu)勢(shì)是直接面向最終用戶(hù)，可能占據(jù)企業(yè)應(yīng)用入口，IaaS 服務(wù)商的優(yōu)勢(shì)是它掌控了應(yīng)用的運(yùn)行環(huán)境，無(wú)論在計(jì)費(fèi)模式還是反盜版上都有很大優(yōu)勢(shì)。但在私有云領(lǐng)域，IaaS 產(chǎn)品會(huì)面臨 DCOS 更大的沖擊。私有云領(lǐng)域如果多租戶(hù)隔離的需求沒(méi)那么強(qiáng)烈的情況下，部署一套 DCOS 是一種更簡(jiǎn)單高效的選擇。

容器與虛擬機(jī)之爭(zhēng)

從 Docker 技術(shù)成為熱門(mén)開(kāi)始，容器與虛擬機(jī)的爭(zhēng)論就從來(lái)沒(méi)有停止過(guò)。但去年一年，大家的注意力逐漸轉(zhuǎn)移到上層，容器和虛擬機(jī)的爭(zhēng)論算告一段落。這個(gè)主要是因?yàn)槿萜鞅旧淼耐庋釉谧兓?/p>

容器，首先它不是一個(gè)技術(shù)詞匯，它是一個(gè)抽象概念。顧名思義，就是裝東西的器皿，裝什么東西呢?應(yīng)用。

其實(shí) J2EE 領(lǐng)域很早就使用了容器(Container)概念，J2EE 的服務(wù)器也叫做 web container 或者 application container，它的目標(biāo)就是給 Java web 應(yīng)用提供一種標(biāo)準(zhǔn)化的運(yùn)行環(huán)境，方便開(kāi)發(fā)，部署，分發(fā)，只不過(guò)這種容器是平臺(tái)綁定的。

而 Linux 容器自誕生之初，就是一組進(jìn)程隔離的技術(shù)的統(tǒng)稱(chēng)。隨著容器領(lǐng)域的競(jìng)爭(zhēng)與演進(jìn)，Kubernetes 的 OCI (Open Container Initiative)標(biāo)準(zhǔn)推出，Docker，Unikernels， CoreOS 的 Rocket，Mesos 的 Universal container，Hyper 的 HyperContainer(基于 VM 的容器解決方案) 等百花齊放，容器的概念逐漸清晰，我們這里可以下個(gè)定義：

容器就是對(duì)應(yīng)用進(jìn)程的一種標(biāo)準(zhǔn)化封裝，無(wú)論是采用 linux 的 cgroup namespace 技術(shù)，還是使用虛擬化 hypervisor 技術(shù)來(lái)做這種封裝，都不是關(guān)鍵，關(guān)鍵是是目標(biāo)，容器是為應(yīng)用標(biāo)準(zhǔn)化而生。

也就是說(shuō)，最早，大家認(rèn)為容器是和虛擬機(jī)一樣的一種隔離技術(shù)，所以會(huì)拿容器和虛擬機(jī)做比較，比較二者的隔離成本，隔離安全性，但現(xiàn)在容器的外延變了，和傳統(tǒng)虛擬機(jī)的本質(zhì)差異不在于封裝技術(shù)，而在于封裝的目標(biāo)，傳統(tǒng)虛擬機(jī)封裝的目標(biāo)是操作系統(tǒng)，為操作系統(tǒng)提供虛擬化硬件環(huán)境，而容器封裝的目標(biāo)是應(yīng)用進(jìn)程，其中內(nèi)嵌的操作系統(tǒng)只是應(yīng)用的依賴(lài)而已。

另外一方面，基于虛擬機(jī)的調(diào)度系統(tǒng)，比如 OpenStack，也可以將容器作為自己的調(diào)度系統(tǒng)的 compute_driver，也就是將容器當(dāng)虛擬機(jī)使用，用來(lái)降低虛擬機(jī)的隔離成本。所以容器與虛擬機(jī)之爭(zhēng)本質(zhì)上是調(diào)度理念之爭(zhēng)，而不是隔離技術(shù)之爭(zhēng)。

容器對(duì)操作系統(tǒng)的影響

Docker 沒(méi)出現(xiàn)之前，服務(wù)器端的操作系統(tǒng)基本是傳統(tǒng) Linux 大廠(chǎng)商的天下，Ubuntu 好不容易通過(guò)自己的桌面版的優(yōu)勢(shì)贏得一席之地，一個(gè)創(chuàng)業(yè)公司試圖進(jìn)入這個(gè)領(lǐng)域基本是沒(méi)有機(jī)會(huì)的，但 Docker 的出現(xiàn)帶來(lái)了一個(gè)契機(jī)。這個(gè)契機(jī)就是一個(gè)操作系統(tǒng)需要考慮自己的目標(biāo)是管理硬件還是管理應(yīng)用。如果是管理硬件，也就是運(yùn)行在物理機(jī)上的操作系統(tǒng)，目標(biāo)就是提供內(nèi)核，管理好硬件(磁盤(pán)，網(wǎng)絡(luò)等)，而應(yīng)用層的事情交給容器，這樣硬件層的操作系統(tǒng)不需要考慮各種應(yīng)用軟件棧的兼容問(wèn)題，降低了操作系統(tǒng)的維護(hù)成本。如果是管理應(yīng)用，那就可以放棄對(duì)硬件層的管理，專(zhuān)心維護(hù)軟件棧。所以這個(gè)領(lǐng)域能冒出幾家創(chuàng)業(yè)公司的產(chǎn)品試水：

1. CoreOS 的 Container Linux 以及 Rancher 的 RancherOS 這兩個(gè) OS 的主要目標(biāo)都是接管硬件，將主機(jī)操作系統(tǒng)從復(fù)雜的軟件棧中解放出來(lái)，專(zhuān)心管理硬件和支持容器。傳統(tǒng)的 Linux 操作系統(tǒng)為維護(hù)上層軟件棧的兼容性付出了巨大的成本，發(fā)行版的一個(gè)優(yōu)勢(shì)在于提供全面軟件棧的兼容性測(cè)試。而當(dāng)二者解耦后，這個(gè)優(yōu)勢(shì)不再，競(jìng)爭(zhēng)的核心在于能否提供更好的支持容器以及系統(tǒng)和內(nèi)核的升級(jí)。
2. Alpine Linux 這個(gè)精簡(jiǎn)后的 Linux 發(fā)行版則是專(zhuān)注于維護(hù)軟件棧，給容器內(nèi)的應(yīng)用提供運(yùn)行環(huán)境。所以它可以做到非常小，默認(rèn)只有幾M大小，即便是包含 bash 進(jìn)去，也只十多M。所以 Docker 官方默認(rèn)以它作為鏡像的基礎(chǔ)系統(tǒng)。

操作系統(tǒng)的演進(jìn)和更替是一個(gè)長(zhǎng)期的工程，基本上得伴隨著硬件的淘汰，所以至少五到十年的演進(jìn)，著急不得，但可以期待。

關(guān)于技術(shù)類(lèi)創(chuàng)業(yè)的思考

技術(shù)類(lèi)創(chuàng)業(yè)，要思考清楚自己的機(jī)會(huì)是在市場(chǎng)還是在技術(shù)生態(tài)圈里占領(lǐng)一席之地。當(dāng)然前者要比后者容易，后者最終也得變?yōu)槭袌?chǎng)的應(yīng)用才能盈利，而即便是在技術(shù)生態(tài)圈中取得地位也不一定能找到商業(yè)模式，不過(guò)后者的潛力要大于前者。國(guó)內(nèi)的創(chuàng)業(yè)一般傾向與前者，而國(guó)外則多傾向與后者，所以國(guó)內(nèi)同質(zhì)化的競(jìng)爭(zhēng)比較激烈，而在差異化的生態(tài)構(gòu)建方面則缺少建樹(shù)。主要是因?yàn)閲?guó)內(nèi)的技術(shù)積累以及普及度和國(guó)外還有差距，還屬于追隨者，只有追隨并趕超之后才會(huì)有創(chuàng)新，這個(gè)和 2C 領(lǐng)域的類(lèi)似，2C 領(lǐng)域最近越來(lái)越少 C2C(Copy To China) 模式成功的案例了，2B 領(lǐng)域肯定還需要些年，不過(guò)感覺(jué)應(yīng)該也不遠(yuǎn)。

個(gè)人認(rèn)為，2017 年容器編排調(diào)度領(lǐng)域的競(jìng)爭(zhēng)會(huì)上升到應(yīng)用層面，DCOS 之上的多語(yǔ)言應(yīng)用框架(比如 微服務(wù)框架，Actor 模型框架)，各種已有應(yīng)用和基礎(chǔ)設(shè)施的容器化，標(biāo)準(zhǔn)化，讓已有應(yīng)用變?yōu)樵圃?Cloud Native)應(yīng)用，等等。

當(dāng)然，理想和現(xiàn)實(shí)之間是有鴻溝的。一波一波的技術(shù)變革，本質(zhì)上其實(shí)都是在試圖將開(kāi)發(fā)和運(yùn)維人員從瑣碎的，重復(fù)的，無(wú)聊的任務(wù)中解放出來(lái)，專(zhuān)注于有創(chuàng)意的領(lǐng)域。但變革最難變革的是人的思維方式和做事習(xí)慣，以及應(yīng)對(duì)來(lái)自組織的阻礙。你說(shuō)云應(yīng)該就是按需的，動(dòng)態(tài)的，自服務(wù)的，但用戶(hù)的運(yùn)維部門(mén)就喜歡審批開(kāi)發(fā)人員資源申請(qǐng)，于是云變成了一個(gè)虛擬機(jī)分配系統(tǒng)。你說(shuō)資源應(yīng)該動(dòng)態(tài)調(diào)度，應(yīng)用混合部署有利于提高資源利用率，但用戶(hù)的安全部門(mén)要求應(yīng)用的業(yè)務(wù)必須分層，每層必須需要部署到獨(dú)立的服務(wù)器上，跨層調(diào)用的端口還需要申請(qǐng)。所以技術(shù)變革最后要落地成商業(yè)模式，首先要通過(guò)技術(shù)理念的傳播去改變用戶(hù)的思維方式以及組織體系，當(dāng)然這肯定不可能是一蹴而就的，是一個(gè)長(zhǎng)期的，反復(fù)過(guò)程，其次要等待業(yè)務(wù)需求的驅(qū)動(dòng)，當(dāng)業(yè)務(wù)增長(zhǎng)導(dǎo)致軟件復(fù)雜度到一定規(guī)模的時(shí)候，自然會(huì)尋求新技術(shù)來(lái)解決復(fù)雜性。

結(jié)語(yǔ)

寫(xiě)了這么多，有人會(huì)問(wèn)，我還是沒(méi)能確定到底選擇哪一家合適啊?未來(lái)是不可預(yù)測(cè)的，但是可以創(chuàng)造的。當(dāng)你做出選擇的那一刻，你希望的未來(lái)就向你靠近了一步。

本文由作者首發(fā)[高可用架構(gòu)]

【本文是51CTO專(zhuān)欄作者“王淵命”的原創(chuàng)文章，轉(zhuǎn)載請(qǐng)聯(lián)系作者本人獲取授權(quán)】

戳這里，看該作者更多好文