為什麼 kubernetes 天然適合微服務 (1)
此文已由作者劉超授權網易雲社群釋出。
歡迎訪問網易雲社群，瞭解更多網易技術產品運營經驗
最近總在思考，為什麼在支撐容器平臺和微服務的競爭中，Kubernetes 會取得最終的勝出，事實上從很多角度出發三大容器平臺從功能方面來看，最後簡直是一摸一樣。
參考
Docker, Kubernetes, DCOS 不談信仰談技術
容器平臺選型的十大模式：Docker、DC/OS、K8S誰與當先？
經過一段時間的思索，以及採訪了從早期就開始實踐 Kubernetes 的網易雲架構師們後，我把反思所得總結為今天的這篇文章。
一、從企業上雲的三大架構看容器平臺的三種視角
一切都從企業上雲的三大架構開始看起
如圖所示，企業上雲的三大架構為 IT 架構、應用架構和資料架構，在不同的公司，不同的人、不同的角色，關注的重點不同。
對大部分的企業來講，上雲的訴求是從 IT 部門發起的，發起人往往是運維部門，他們關注計算、網路、儲存，試圖通過雲端計算服務來減輕 CAPEX 和 OPEX。
有的公司有 ToC 的業務，因而累積了大量的使用者資料，公司的運營需要通過這部分資料進行大資料分析和數字化運營，因而在這些企業裡面往往還需要關注資料架構。
從事網際網路應用的企業，往往首先關注的是應用架構，是否能夠滿足終端客戶的需求，帶給客戶良好的使用者體驗。業務量上往往會有短期內出現爆炸式增長的現象，因而關注高併發應用架構，並希望這個架構可以快速迭代，從而搶佔風口。
在容器出現之前，這三種架構往往通過虛擬機器雲平臺的方式解決。當容器出現之後，容器的各種良好的特性讓人眼前一亮，它的輕量級、封裝、標準、易遷移、易交付的特性，使得容器技術迅速被廣泛使用。
然而一千個人心中有一千個哈姆雷特，由於原來工作的關係，三類角色分別從自身的角度看到了容器的優勢給自己帶來的便捷。
對於原來在機房裡管計算、網路、儲存的 IT 運維工程師來講，容器更像是一種輕量級的運維模式，在他們看來，容器和虛擬機器的最大的區別就是輕量級，啟動速度快，他們往往更願意推出虛擬機器模式的容器。
對於資料架構來講，他們每天都在執行各種各樣的資料計算任務，容器相對於原來的 JVM，是一種隔離性較好，資源利用率高的任務執行模式。
從應用架構的角度出發，容器是微服務的交付形式，容器不僅僅是做部署的，而且是做交付的，CI/CD 中的 D 的。
所以這三種視角的人，在使用容器和選擇容器平臺時方法會不一樣。
二、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 作為容器管理平臺。不過原來是跑短任務，加上 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)
相關文章：
【推薦】 NGUI可展開列表的實現
【推薦】 一文看盡 Raft 一致性協議的關鍵點
【推薦】 ApiDoc 一鍵生成註釋