摘要：此文已由作者劉超授權(quán)網(wǎng)易云社區(qū)發(fā)布。所以當我們評估大數(shù)據(jù)平臺牛不牛的時候，往往以單位時間內(nèi)跑的任務(wù)數(shù)目以及能夠處理的數(shù)據(jù)量來衡量。的問題調(diào)度在大數(shù)據(jù)領(lǐng)域是核心中的核心，在容器平臺中是重要的，但不是全部。

此文已由作者劉超授權(quán)網(wǎng)易云社區(qū)發(fā)布。

歡迎訪問網(wǎng)易云社區(qū)，了解更多網(wǎng)易技術(shù)產(chǎn)品運營經(jīng)驗

最近總在思考，為什么在支撐容器平臺和微服務(wù)的競爭中，Kubernetes 會取得最終的勝出，事實上從很多角度出發(fā)三大容器平臺從功能方面來看，最后簡直是一摸一樣。

參考

Docker, Kubernetes, DCOS 不談信仰談技術(shù)

容器平臺選型的十大模式：Docker、DC/OS、K8S誰與當先？

經(jīng)過一段時間的思索，以及采訪了從早期就開始實踐 Kubernetes 的網(wǎng)易云架構(gòu)師們后，我把反思所得總結(jié)為今天的這篇文章。

一、從企業(yè)上云的三大架構(gòu)看容器平臺的三種視角

一切都從企業(yè)上云的三大架構(gòu)開始看起

如圖所示，企業(yè)上云的三大架構(gòu)為 IT 架構(gòu)、應(yīng)用架構(gòu)和數(shù)據(jù)架構(gòu)，在不同的公司，不同的人、不同的角色，關(guān)注的重點不同。

對大部分的企業(yè)來講，上云的訴求是從 IT 部門發(fā)起的，發(fā)起人往往是運維部門，他們關(guān)注計算、網(wǎng)絡(luò)、存儲，試圖通過云計算服務(wù)來減輕 CAPEX 和 OPEX。

有的公司有 ToC 的業(yè)務(wù)，因而累積了大量的用戶數(shù)據(jù)，公司的運營需要通過這部分數(shù)據(jù)進行大數(shù)據(jù)分析和數(shù)字化運營，因而在這些企業(yè)里面往往還需要關(guān)注數(shù)據(jù)架構(gòu)。

從事互聯(lián)網(wǎng)應(yīng)用的企業(yè)，往往首先關(guān)注的是應(yīng)用架構(gòu)，是否能夠滿足終端客戶的需求，帶給客戶良好的用戶體驗。業(yè)務(wù)量上往往會有短期內(nèi)出現(xiàn)爆炸式增長的現(xiàn)象，因而關(guān)注高并發(fā)應(yīng)用架構(gòu)，并希望這個架構(gòu)可以快速迭代，從而搶占風(fēng)口。

在容器出現(xiàn)之前，這三種架構(gòu)往往通過虛擬機云平臺的方式解決。當容器出現(xiàn)之后，容器的各種良好的特性讓人眼前一亮，它的輕量級、封裝、標準、易遷移、易交付的特性，使得容器技術(shù)迅速被廣泛使用。

然而一千個人心中有一千個哈姆雷特，由于原來工作的關(guān)系，三類角色分別從自身的角度看到了容器的優(yōu)勢給自己帶來的便捷。

對于原來在機房里管計算、網(wǎng)絡(luò)、存儲的 IT 運維工程師來講，容器更像是一種輕量級的運維模式，在他們看來，容器和虛擬機的最大的區(qū)別就是輕量級，啟動速度快，他們往往更愿意推出虛擬機模式的容器。

對于數(shù)據(jù)架構(gòu)來講，他們每天都在執(zhí)行各種各樣的數(shù)據(jù)計算任務(wù)，容器相對于原來的 JVM，是一種隔離性較好，資源利用率高的任務(wù)執(zhí)行模式。

從應(yīng)用架構(gòu)的角度出發(fā)，容器是微服務(wù)的交付形式，容器不僅僅是做部署的，而且是做交付的，CI/CD 中的 D 的。

所以這三種視角的人，在使用容器和選擇容器平臺時方法會不一樣。

二、Kubernetes 才是微服務(wù)和 DevOps 的橋梁

Swarm：IT 運維工程師

從 IT 運維工程師的角度來看：容器主要是輕量級、啟動快，并且自動重啟，自動關(guān)聯(lián)，彈性伸縮的技術(shù)，使得 IT 運維工程師似乎不用再加班。

Swarm 的設(shè)計顯然更加符合傳統(tǒng) IT 工程師的管理模式。

他們希望能夠清晰地看到容器在不同機器的分布和狀態(tài)，可以根據(jù)需要很方便地 SSH 到一個容器里面去查看情況。

容器最好能夠原地重啟，而非隨機調(diào)度一個新的容器，這樣原來在容器里面安裝的一切都是有的。

可以很方便地將某個運行的容器打一個鏡像，而非從 Dockerfile 開始，這樣以后啟動就可以復(fù)用在這個容器里面手動做的 100 項工作。

容器平臺的集成性要好，用這個平臺本來是為了簡化運維的，如果容器平臺本身就很復(fù)雜，像 Kubernetes 這種本身就這么多進程，還需要考慮它的高可用和運維成本，這個不劃算，一點都沒有比原來省事，而且成本還提高了。

最好薄薄的一層，像一個云管理平臺一樣，只不過更加方便做跨云管理，畢竟容器鏡像很容易跨云遷移。

Swarm 的使用方式比較讓 IT 工程師有熟悉的味道，其實 OpenStack 所做的事情它都能做，速度還快。

Swarm 的問題

然而容器作為輕量級虛擬機，暴露出去給客戶使用，無論是外部客戶，還是公司內(nèi)的開發(fā)，而非 IT 人員自己使用的時候，他們以為和虛擬機一樣，但是發(fā)現(xiàn)了不一樣的部分，就會有很多的抱怨。

例如自修復(fù)功能，重啟之后，原來 SSH 進去手動安裝的軟件不見了，甚至放在硬盤上的文件也不見了，而且應(yīng)用沒有放在 Entrypoint 里面自動啟動，自修復(fù)之后進程沒有跑起來，還需要手動進去啟動進程，客戶會抱怨你這個自修復(fù)功能有啥用？

例如有的用戶會 ps 一下，發(fā)現(xiàn)有個進程他不認識，于是直接 kill 掉了，結(jié)果是 Entrypoint 的進程，整個容器直接就掛了，客戶抱怨你們的容器太不穩(wěn)定，老是掛。

容器自動調(diào)度的時候，IP 是不保持的，所以往往重啟后原來的 IP 就沒了，很多用戶會提需求，這個能不能保持啊，原來配置文件里面都配置的這個 IP ，掛了重啟就變了，這個怎么用啊，還不如用虛擬機，至少沒那么容易掛。

容器的系統(tǒng)盤，也即操作系統(tǒng)的那個盤往往大小是固定的，雖然前期可以配置，后期很難改變，而且沒辦法每個用戶可以選擇系統(tǒng)盤的大小。有的用戶會抱怨，我們原來本來就很多東西直接放在系統(tǒng)盤的，這個都不能調(diào)整，叫什么云計算的彈性啊。

如果給客戶說容器掛載數(shù)據(jù)盤，容器都啟動起來了，有的客戶想像云主機一樣，再掛載一個盤，容器比較難做到，也會被客戶罵。

如果容器的使用者不知道他們在用容器，當虛擬機來用，他們會覺得很難用，這個平臺一點都不好。

Swarm 上手雖然相對比較容易，但是當出現(xiàn)問題的時候，作為運維容器平臺的人，會發(fā)現(xiàn)問題比較難解決。

Swarm 內(nèi)置的功能太多，都耦合在了一起，一旦出現(xiàn)錯誤，不容易 debug。如果當前的功能不能滿足需求，很難定制化。很多功能都是耦合在 Manager 里面的，對 Manager 的操作和重啟影響面太大。

Mesos：數(shù)據(jù)運維工程師

從大數(shù)據(jù)平臺運維的角度來講，如何更快地調(diào)度大數(shù)據(jù)處理任務(wù)，在有限的時間和空間里面，更快地跑更多的任務(wù)，是一個非常重要的要素。

所以當我們評估大數(shù)據(jù)平臺牛不牛的時候，往往以單位時間內(nèi)跑的任務(wù)數(shù)目以及能夠處理的數(shù)據(jù)量來衡量。

從數(shù)據(jù)運維的角度來講，Mesos 是一個很好的調(diào)度器。既然能夠跑任務(wù)，也就能夠跑容器，Spark 和 Mesos 天然的集成，有了容器之后，可以用更加細粒度的任務(wù)執(zhí)行方式。

在沒有細粒度的任務(wù)調(diào)度之前，任務(wù)的執(zhí)行過程是這樣的。任務(wù)的執(zhí)行需要 Master 的節(jié)點來管理整個任務(wù)的執(zhí)行過程，需要 Worker 節(jié)點來執(zhí)行一個個子任務(wù)。在整個總?cè)蝿?wù)的一開始，就分配好 Master 和所有的 Work 所占用的資源，將環(huán)境配置好，等在那里執(zhí)行子任務(wù)，沒有子任務(wù)執(zhí)行的時候，這個環(huán)境的資源都是預(yù)留在那里的，顯然不是每個 Work 總是全部跑滿的，存在很多的資源浪費。

在細粒度的模式下，在整個總?cè)蝿?wù)開始的時候，只會為 Master 分配好資源，不給 Worker 分配任何的資源，當需要執(zhí)行一個子任務(wù)的時候，Master 才臨時向 Mesos 申請資源，環(huán)境沒有準備好怎么辦？好在有 Docker，啟動一個 Docker，環(huán)境就都有了，在里面跑子任務(wù)。在沒有任務(wù)的時候，所有節(jié)點上的資源都是可被其他任務(wù)使用的，大大提升了資源利用效率。

這就是 Mesos 最大的優(yōu)勢，在 Mesos 的論文中，最重要闡述的就是資源利用率的提升，而 Mesos 的雙層調(diào)度算法是核心。

號稱了解mesos雙層調(diào)度的你，先來回答下面這五個問題！

原來大數(shù)據(jù)運維工程師出身的，會比較容易選擇 Mesos 作為容器管理平臺。不過原來是跑短任務(wù)，加上 marathon 就能跑長任務(wù)。但是后來 Spark 將細粒度的模式 deprecated 掉了，因為效率還是比較差。

Mesos 的問題

調(diào)度在大數(shù)據(jù)領(lǐng)域是核心中的核心，在容器平臺中是重要的，但不是全部。所以容器還需要編排，需要各種外圍組件，讓容器跑起來運行長任務(wù)，并且相互訪問。Marathon 只是萬里長征的第一步。

所以早期用 Marathon + Mesos 的廠商，多是裸用 Marathon 和 Mesos 的，由于周邊不全，因而要做各種的封裝，各家不同。大家有興趣可以到社區(qū)上去看裸用 Marathon 和 Mesos 的廠商，各有各的負載均衡方案，各有各的服務(wù)發(fā)現(xiàn)方案。

所以后來有了 DCOS，也就是在 Marathon 和 Mesos 之外，加了大量的周邊組件，補充一個容器平臺應(yīng)有的功能，但是很可惜，很多廠商都自己定制過了，還是裸用 Marathon 和 Mesos 的比較多。

而且 Mesos 雖然調(diào)度牛，但是只解決一部分調(diào)度，另一部分靠用戶自己寫 framework 以及里面的調(diào)度，有時候還需要開發(fā) Executor，這個開發(fā)起來還是很復(fù)雜的，學(xué)習(xí)成本也比較高。

雖說后來的 DCOS 功能也比較全了，但是感覺沒有如 Kubernetes 一樣使用統(tǒng)一的語言，而是采取大雜燴的方式。在 DCOS 的整個生態(tài)中，Marathon 是 Scala 寫的，Mesos 是 C++ 寫的，Admin Router 是 Nginx+lua，Mesos-DNS 是Go，Marathon-lb 是 Python，Minuteman 是 Erlang，這樣太復(fù)雜了吧，林林總總，出現(xiàn)了 Bug 的話，比較難自己修復(fù)。

Kubernetes

而 Kubernetes 不同，初看 Kubernetes 的人覺得他是個奇葩所在，容器還沒創(chuàng)建出來，概念先來一大堆，文檔先讀一大把，編排文件也復(fù)雜，組件也多，讓很多人望而卻步。我就想創(chuàng)建一個容器，怎么這么多的前置條件。如果你將 Kubernetes 的概念放在界面上，讓客戶去創(chuàng)建容器，一定會被客戶罵。

在開發(fā)人員角度，使用 Kubernetes 絕對不是像使用虛擬機一樣，開發(fā)除了寫代碼，做構(gòu)建，做測試，還需要知道自己的應(yīng)用是跑在容器上的，而不是當甩手掌柜。開發(fā)人員需要知道，容器是和原來的部署方式不一樣的存在，你需要區(qū)分有狀態(tài)和無狀態(tài)，容器掛了起來，就會按照鏡像還原了。開發(fā)人員需要寫 Dockerfile，需要關(guān)心環(huán)境的交付，需要了解太多原來不了解的東西。實話實說，一點都不方便。

在運維人員角度，使用 Kubernetes 也絕對不是像運維虛擬機一樣，我交付出來了環(huán)境，應(yīng)用之間互相怎么調(diào)用，我才不管，我就管網(wǎng)絡(luò)通不通。在運維眼中他做了過多不該關(guān)心的事情，例如服務(wù)的發(fā)現(xiàn)，配置中心，熔斷降級，這都應(yīng)該是代碼層面關(guān)心的事情，應(yīng)該是 SpringCloud 和 Dubbo 關(guān)心的事情，為什么要到容器平臺層來關(guān)心這個。

Kubernetes + Docker，卻是 Dev 和 Ops 融合的一個橋梁。

Docker 是微服務(wù)的交付工具，微服務(wù)之后，服務(wù)太多了，單靠運維根本管不過來，而且很容易出錯，這就需要研發(fā)開始關(guān)心環(huán)境交付這件事情。例如配置改了什么，創(chuàng)建了哪些目錄，如何配置權(quán)限，只有開發(fā)最清楚，這些信息很難通過文檔的方式又及時又準確地同步到運維部門來，就算是同步過來了，運維部門的維護量也非常的大。

所以，有了容器，最大的改變是環(huán)境交付的提前，是每個開發(fā)多花 5% 的時間，去換取運維 200% 的勞動，并且提高穩(wěn)定性。

而另一方面，本來運維只管交付資源，給你個虛擬機，虛擬機里面的應(yīng)用如何相互訪問我不管，你們愛咋地咋地，有了 Kubernetes 以后，運維層要關(guān)注服務(wù)發(fā)現(xiàn)，配置中心，熔斷降級。

兩者融合在了一起。在微服務(wù)化的研發(fā)的角度來講，Kubernetes 雖然復(fù)雜，但是設(shè)計的都是有道理的，符合微服務(wù)的思想。

網(wǎng)易云輕舟微服務(wù)是圍繞應(yīng)用和微服務(wù)打造的一站式 PaaS 平臺，幫助用戶快速實現(xiàn)易接入、易運維的微服務(wù)解決方案。

相關(guān)閱讀：為什么 kubernetes 天然適合微服務(wù) (1)

為什么 kubernetes 天然適合微服務(wù) （2）

為什么 kubernetes 天然適合微服務(wù) （3）

文章來源： 網(wǎng)易云社區(qū)