爲何 kubernetes 自然適合微服務 (1)

此文已由做者劉超受權網易雲社區發佈。

歡迎訪問網易雲社區，瞭解更多網易技術產品運營經驗

最近總在思考，爲何在支撐容器平臺和微服務的競爭中，Kubernetes 會取得最終的勝出，事實上從不少角度出發三大容器平臺從功能方面來看，最後簡直是一摸同樣。

參考

Docker, Kubernetes, DCOS 不談信仰談技術

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

通過一段時間的思索，以及採訪了從早期就開始實踐 Kubernetes 的網易雲架構師們後，我把反思所得總結爲今天的這篇文章。

1、從企業上雲的三大架構看容器平臺的三種視角

一切都從企業上雲的三大架構開始看起

如圖所示，企業上雲的三大架構爲 IT 架構、應用架構和數據架構，在不一樣的公司，不一樣的人、不一樣的角色，關注的重點不一樣。

對大部分的企業來說，上雲的訴求是從 IT 部門發起的，發起人每每是運維部門，他們關注計算、網絡、存儲，試圖經過雲計算服務來減輕 CAPEX 和 OPEX。

有的公司有 ToC 的業務，於是累積了大量的用戶數據，公司的運營須要經過這部分數據進行大數據分析和數字化運營，於是在這些企業裏面每每還須要關注數據架構。

從事互聯網應用的企業，每每首先關注的是應用架構，是否可以知足終端客戶的需求，帶給客戶良好的用戶體驗。業務量上每每會有短時間內出現爆炸式增加的現象，於是關注高併發應用架構，並但願這個架構能夠快速迭代，從而搶佔風口。

在容器出現以前，這三種架構每每經過虛擬機雲平臺的方式解決。當容器出現以後，容器的各類良好的特性讓人眼前一亮，它的輕量級、封裝、標準、易遷移、易交付的特性，使得容器技術迅速被普遍使用。

然而一千我的心中有一千個哈姆雷特，因爲原來工做的關係，三類角色分別從自身的角度看到了容器的優點給本身帶來的便捷。

對於原來在機房裏管計算、網絡、存儲的 IT 運維工程師來說，容器更像是一種輕量級的運維模式，在他們看來，容器和虛擬機的最大的區別就是輕量級，啓動速度快，他們每每更願意推出虛擬機模式的容器。

對於數據架構來說，他們天天都在執行各類各樣的數據計算任務，容器相對於原來的 JVM，是一種隔離性較好，資源利用率高的任務執行模式。

從應用架構的角度出發，容器是微服務的交付形式，容器不只僅是作部署的，並且是作交付的，CI/CD 中的 D 的。

因此這三種視角的人，在使用容器和選擇容器平臺時方法會不同。

2、Kubernetes 纔是微服務和 DevOps 的橋樑

Swarm：IT 運維工程師

從 IT 運維工程師的角度來看：容器主要是輕量級、啓動快，而且自動重啓，自動關聯，彈性伸縮的技術，使得 IT 運維工程師彷佛不用再加班。

Swarm 的設計顯然更加符合傳統 IT 工程師的管理模式。

他們但願可以清晰地看到容器在不一樣機器的分佈和狀態，能夠根據須要很方便地 SSH 到一個容器裏面去查看狀況。

容器最好可以原地重啓，而非隨機調度一個新的容器，這樣原來在容器裏面安裝的一切都是有的。

能夠很方便地將某個運行的容器打一個鏡像，而非從 Dockerfile 開始，這樣之後啓動就能夠複用在這個容器裏面手動作的 100 項工做。

容器平臺的集成性要好，用這個平臺原本是爲了簡化運維的，若是容器平臺自己就很複雜，像 Kubernetes 這種自己就這麼多進程，還須要考慮它的高可用和運維成本，這個不划算，一點都沒有比原來省事，並且成本還提升了。

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

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

Swarm 的問題

然而容器做爲輕量級虛擬機，暴露出去給客戶使用，不管是外部客戶，仍是公司內的開發，而非 IT 人員本身使用的時候，他們覺得和虛擬機同樣，可是發現了不同的部分，就會有不少的抱怨。

例如自修復功能，重啓以後，原來 SSH 進去手動安裝的軟件不見了，甚至放在硬盤上的文件也不見了，並且應用沒有放在 Entrypoint 裏面自動啓動，自修復以後進程沒有跑起來，還須要手動進去啓動進程，客戶會抱怨你這個自修復功能有啥用？

例若有的用戶會 ps 一下，發現有個進程他不認識，因而直接 kill 掉了，結果是 Entrypoint 的進程，整個容器直接就掛了，客戶抱怨大家的容器太不穩定，總是掛。

容器自動調度的時候，IP 是不保持的，因此每每重啓後原來的 IP 就沒了，不少用戶會提需求，這個能不能保持啊，原來配置文件裏面都配置的這個 IP ，掛了重啓就變了，這個怎麼用啊，還不如用虛擬機，至少沒那麼容易掛。

容器的系統盤，也即操做系統的那個盤每每大小是固定的，雖然前期能夠配置，後期很難改變，並且沒辦法每一個用戶能夠選擇系統盤的大小。有的用戶會抱怨，咱們原來原本就不少東西直接放在系統盤的，這個都不能調整，叫什麼雲計算的彈性啊。

若是給客戶說容器掛載數據盤，容器都啓動起來了，有的客戶想像雲主機同樣，再掛載一個盤，容器比較難作到，也會被客戶罵。

若是容器的使用者不知道他們在用容器，當虛擬機來用，他們會以爲很難用，這個平臺一點都很差。

Swarm 上手雖然相對比較容易，可是當出現問題的時候，做爲運維容器平臺的人，會發現問題比較難解決。

Swarm 內置的功能太多，都耦合在了一塊兒，一旦出現錯誤，不容易 debug。若是當前的功能不能知足需求，很難定製化。不少功能都是耦合在 Manager 裏面的，對 Manager 的操做和重啓影響面太大。

Mesos：數據運維工程師

從大數據平臺運維的角度來說，如何更快地調度大數據處理任務，在有限的時間和空間裏面，更快地跑更多的任務，是一個很是重要的要素。

因此當咱們評估大數據平臺牛不牛的時候，每每以單位時間內跑的任務數目以及可以處理的數據量來衡量。

從數據運維的角度來說，Mesos 是一個很好的調度器。既然可以跑任務，也就可以跑容器，Spark 和 Mesos 自然的集成，有了容器以後，能夠用更加細粒度的任務執行方式。

在沒有細粒度的任務調度以前，任務的執行過程是這樣的。任務的執行須要 Master 的節點來管理整個任務的執行過程，須要 Worker 節點來執行一個個子任務。在整個總任務的一開始，就分配好 Master 和全部的 Work 所佔用的資源，將環境配置好，等在那裏執行子任務，沒有子任務執行的時候，這個環境的資源都是預留在那裏的，顯然不是每一個 Work 老是所有跑滿的，存在不少的資源浪費。

在細粒度的模式下，在整個總任務開始的時候，只會爲 Master 分配好資源，不給 Worker 分配任何的資源，當須要執行一個子任務的時候，Master 才臨時向 Mesos 申請資源，環境沒有準備好怎麼辦？好在有 Docker，啓動一個 Docker，環境就都有了，在裏面跑子任務。在沒有任務的時候，全部節點上的資源都是可被其餘任務使用的，大大提高了資源利用效率。

這就是 Mesos 最大的優點，在 Mesos 的論文中，最重要闡述的就是資源利用率的提高，而 Mesos 的雙層調度算法是核心。

號稱瞭解mesos雙層調度的你，先來回答下面這五個問題！

原來大數據運維工程師出身的，會比較容易選擇 Mesos 做爲容器管理平臺。不過原來是跑短任務，加上 marathon 就能跑長任務。可是後來 Spark 將細粒度的模式 deprecated 掉了，由於效率仍是比較差。

Mesos 的問題

調度在大數據領域是核心中的核心，在容器平臺中是重要的，但不是所有。因此容器還須要編排，須要各類外圍組件，讓容器跑起來運行長任務，而且相互訪問。Marathon 只是萬里長征的第一步。

因此早期用 Marathon + Mesos 的廠商，可能是裸用 Marathon 和 Mesos 的，因爲周邊不全，於是要作各類的封裝，各家不一樣。你們有興趣能夠到社區上去看裸用 Marathon 和 Mesos 的廠商，各有各的負載均衡方案，各有各的服務發現方案。

因此後來有了 DCOS，也就是在 Marathon 和 Mesos 以外，加了大量的周邊組件，補充一個容器平臺應有的功能，可是很惋惜，不少廠商都本身定製過了，仍是裸用 Marathon 和 Mesos 的比較多。

並且 Mesos 雖然調度牛，可是隻解決一部分調度，另外一部分靠用戶本身寫 framework 以及裏面的調度，有時候還須要開發 Executor，這個開發起來仍是很複雜的，學習成本也比較高。

雖然說後來的 DCOS 功能也比較全了，可是感受沒有如 Kubernetes 同樣使用統一的語言，而是採起大雜燴的方式。在 DCOS 的整個生態中，Marathon 是 Scala 寫的，Mesos 是 C++ 寫的，Admin Router 是 Nginx+lua，Mesos-DNS 是Go，Marathon-lb 是 Python，Minuteman 是 Erlang，這樣太複雜了吧，林林總總，出現了 Bug 的話，比較難本身修復。

Kubernetes

而 Kubernetes 不一樣，初看 Kubernetes 的人以爲他是個奇葩所在，容器還沒建立出來，概念先來一大堆，文檔先讀一大把，編排文件也複雜，組件也多，讓不少人望而卻步。我就想建立一個容器，怎麼這麼多的前置條件。若是你將 Kubernetes 的概念放在界面上，讓客戶去建立容器，必定會被客戶罵。

在開發人員角度，使用 Kubernetes 絕對不是像使用虛擬機同樣，開發除了寫代碼，作構建，作測試，還須要知道本身的應用是跑在容器上的，而不是當甩手掌櫃。開發人員須要知道，容器是和原來的部署方式不同的存在，你須要區分有狀態和無狀態，容器掛了起來，就會按照鏡像還原了。開發人員須要寫 Dockerfile，須要關心環境的交付，須要瞭解太多原來不瞭解的東西。實話實說，一點都不方便。

在運維人員角度，使用 Kubernetes 也絕對不是像運維虛擬機同樣，我交付出來了環境，應用之間互相怎麼調用，我才無論，我就管網絡通不通。在運維眼中他作了過多不應關心的事情，例如服務的發現，配置中心，熔斷降級，這都應該是代碼層面關心的事情，應該是 SpringCloud 和 Dubbo 關心的事情，爲何要到容器平臺層來關心這個。

Kubernetes + Docker，倒是 Dev 和 Ops 融合的一個橋樑。

Docker 是微服務的交付工具，微服務以後，服務太多了，單靠運維根本管不過來，並且很容易出錯，這就須要研發開始關心環境交付這件事情。例如配置改了什麼，建立了哪些目錄，如何配置權限，只有開發最清楚，這些信息很難經過文檔的方式又及時又準確地同步到運維部門來，就算是同步過來了，運維部門的維護量也很是的大。

因此，有了容器，最大的改變是環境交付的提早，是每一個開發多花 5% 的時間，去換取運維 200% 的勞動，而且提升穩定性。

而另外一方面，原本運維只管交付資源，給你個虛擬機，虛擬機裏面的應用如何相互訪問我無論，大家愛咋地咋地，有了 Kubernetes 之後，運維層要關注服務發現，配置中心，熔斷降級。

二者融合在了一塊兒。在微服務化的研發的角度來說，Kubernetes 雖然複雜，可是設計的都是有道理的，符合微服務的思想。

網易雲輕舟微服務是圍繞應用和微服務打造的一站式 PaaS 平臺，幫助用戶快速實現易接入、易運維的微服務解決方案。

相關閱讀：爲何 kubernetes 自然適合微服務 (1)

爲何 kubernetes 自然適合微服務 （2）

爲何 kubernetes 自然適合微服務 （3）

文章來源： 網易雲社區