為什麼我們要開源自己研發的高性能容器編排系統 Eru2

作為自己 30 歲之前的一個「小目標」，白天我提交完最後一個大特質修正後，Eru2（https://projecteru2.gitbooks.io/white-paper/content/）的開源計劃就走入了倒計時階段。2007-2017 眨眼 10 年。啟蒙於 hongqn（https://www.douban.com/people/hongqn/）的豆瓣後端體系介紹而步入了系統工程師的深坑，受教於金山快盤的工程化實踐，又有幸與啟蒙自己的豆瓣平台組共事兩年一起做 Douban App Engine，在 (*)aaS 的道路上越走越遠。14年洲際旅行回國，從芒果TV 到 ENJOY ，從最初的 DAE Copy on Docker 到理論上國內首批大規模使用 Redis Cluster 並提供了 Cerberus 和容器化解決方案，這後面驅動的都是我一直想做的大一統平台。

幸運的是，有 Docker，DAE 當年隔離的問題再也不是問題 。不幸的是，有 Docker，容器的不穩定在大集群下面對管理提出了更高的要求。Docker 就像一把雙刃劍，關鍵是你怎麼去用它。Borg 提供了一個視角，而它的親兒子 Kubernetes 以壓倒性的優勢成為了平台層面的事實標準。在它的身後，角落裡 Docker 的親兒子 Swarm 還在負隅頑抗，而它的身邊，是一個叫 Mesos 的屍體。

那麼問題來了，為什麼我們要做這個東西呢？

讓我們把眼光放回 2014 年，就以當時的業界視角來看，其實你是沒多少選擇的。當年的 Kubernetes 江湖傳聞就一個人全職開發，除了 Google 爹的光環以外複雜的概念和尚不穩定的特性，沒有全知全能的視野當時的你會知道終有一天它終將為王？甚至 Mesos 上的 Marathon 在先發優勢上都能把 Kubernetes 按在地上摩擦，但一想到以 Apache 之名下 Mesos 那「笨重」的結構你會輕易去嘗試？至於 Docker 的親兒子，它的爹還在忙於 1.0 的 stable，它的媽還不知道是在世界的哪個角落，所以造輪子並非一個不可理解的選擇。我們再把時間撥到2015年，半個前豆瓣平台組還能有機會在宜信大數據給我們帶來基於特定工程的最優解 Lain（https://www.gitbook.com/@laincloud）。即便到了 2017 年，從我的個人角度來看，雖然 Kubernetes 幾乎一統江湖，但自建平台也還是有一定土壤的。

如 Kubernetes 吧，Google 二兒子，Borg 血統最為純凈的繼承者，萬千資源於一身的編排調度平台集大成者，早期用戶也不得不面對其架構複雜部署困難的問題。對於小公司而言，上 Kubernetes 帶來的成本遠高於其帶來 DevOps 效率提升而降低的成本。對於中大型公司而言，Kubernetes 本身相對而言的排他性對於已有基礎設施重建以及業務適配又是一個需要額外成本的地方。至於超大公司以他們的人力物力財力，就我某幾位不願意透露姓名的P8/P9基友所言，早就脫離社區自己玩自己的去了，畢竟業務才是來錢的大爺。你不能說它不行，樂觀鎖的分配能力完全能滿足一家豆瓣類似規模的中大型公司，Pod Service 的概念抽象使得所謂的微服務化變得前所未有的簡單直觀。但一個東西不能說它好就要去上對吧，自己的業務模式 Workflow 要不要改造，如何改造，對於 Kubernetes 本身的運維經驗有沒有積累，現有的基礎設施怎麼辦，這都是需要考慮的問題。況且線上用了 Kubernetes 了，離線任務要不要用，怎麼用，如何和 Apache 全家桶攪一起，都要摸索。

其他的幾種選擇來說，Lain 對於特定工程來說是最優解，沒有比一個能自舉的平台更加迷人了。然而就我對他們的了解，如果你的團隊沒有豆瓣那種我要打10個的素質，學習成本還是蠻高的，需要嚴格的遵從 Workflow 和開發範式，需要有相當高的 DevOps 能力。已經死掉的 Mesos 系而言，光是 Apache 之名就足以嚇跑很多人，已經到 2017 的今天，Hadoop 的部署使用還能出書出課程收費教人，讓人不得不對其同門 Mesos 的易用性打上一個問號。況且就以資源分配來說，悲觀鎖資源邀約的設計在大集群下的性能還是比較堪憂的，就不說這也是一套強侵入式的架構。至於 Docker 親兒子，在 Engine 尚未表現出足以服眾的穩定性前提下，把編排直接結合進其中作為一個 Mode，作為一個平台特性的東西來講，這是大忌。同樣的，Swarm 除了原生這一個「吸引人」的地方以外，無論是資源分配，Workflow 的集成和服務抽象均不如 Kubernetes。

還有一個就是，就以上幾個平台而言，離線服務均都沒考慮在內。當然 Mesos 會好些，但需要額外的框架支持，這種二元結構是它的優勢也是它的劣勢。如 Yarn 的離線計算如何結合容器平台，如怎樣結合各類不同的 Fault tolerant job scheduler，這都需要使用者自行摸索。

那麼我們又做了什麼？

Eru2 本質上不是一攬子解決方案，結合在芒果TV 時期的經驗，我們並不想做成特定工程類的最優解，而是一個儘可能減少對現有基礎設施侵入的基礎組件，因為這不是一個技術問題，這是政治問題。它的設計目標有：

高效而精確並且多維度的資源分配和實時再分配

儘可能的復用現有基礎設施，儘可能減少對現有基礎設施的排他性和侵入性

不提供全家桶

滿足離線需求，提供介面滿足離線計算，做大一統平台

無論多大規模，儘可能的易維護

對業務而言改動小，易接入

使用者心智負擔低

在芒果 TV 的時候，我們全自動化無人管理過上千容器的單一 Redis 集群，而這種集群還有另外幾個。在 ENJOY 的時候整個公司的看得到的看不到的甚至開發機都由我們驅動。不能說我們做得多好吧，畢竟這幾年在互聯網荒漠的長沙全職在做的除我和不願意透露姓名的 tonicbupt 以外只有在 ENJOY 期間的 timfeirg，dante 和 wrfly 了。再能1個打10個，多少資源干多少活，我們只是想給這個浮躁的技術圈增加那麼一點新的可能性。

燒腦式Kubernetes實戰訓練營

本次培訓理論結合實踐，主要包括：Kubernetes架構和資源調度原理、Kubernetes DNS與服務發現、基於Kubernetes和Jenkins的持續部署方案 、Kubernetes網路部署實踐、監控、日誌、Kubernetes與雲原生應用、在CentOS中部署Kubernetes集群、Kubernetes中的容器設計模式、開發Kubernetes原生應用步驟介紹等，點擊識別下方二維碼加微信好友了解具體培訓內容。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！