我是來自于華為PaaS部門的鐘成，目前正在做相關的一些產品研發。我想分享的主題是從Borg到Kubernetes，其實Borg就是 Kubernetes的前身。我今天主要會談三個方面，第一個是Borg的介紹，第二是Kubernetes基于Borg做了哪些改變，以及它的發展方向，第三個話題想談一下未來的云可能需要一個怎么樣的產品或者是怎么樣的形態。

Borg是什么?它解決了什么問題?

我們先看第一個話題，就是Borg是什么?它解決了什么問題?

我們看一下這張圖，這張圖來自于一部電影叫做《星際迷航》相信大家大部分人都看過。Borg是里面的一種外星人，反派，他做什么事情呢?他和其他的文明接觸，把你這個文明搶占下來，然后它會和你同化，會把你進行改造，把你改造成一個半人半機器的怪物，你就變成他們這個文明當中的一部分，然后他在這個宇宙當中不斷的擴張下去。我覺得這是一個非常酷的種族。而Borg就以這個名字來命名其大規模分布式的集成管理系統。他希望他們的系統也可以把不同的機器同化掉，變成他們自己的機器，然后運行他們自己的程序。

對谷歌來說，Borg是一個比較頂層的集成管理系統。在它上面跑了谷歌大部分的應用程序和框架包括Gmail、Google Docs、Web Search這樣直接面對客戶的一些應用程序。它同時也包括一些底層的框架，(MR)，包括它的一些GFS這些分布式的存儲系統。也就是說你可以認為所有的應用程序都需要通過它來管理底層的這些物理機。Borg在谷歌已經成功的應用的十多年。

大家可以看一下Borg的整體的架構。它也是一個典型的分布式平臺的架構，就是一個邏輯上的master，然后下面有很多的節點，每一個節點上有一些它的代理程序。這里就可以看一下，作為谷歌內部的一個工程師怎么樣用這個系統呢?他們使用Borgcfg(命令行)或者Web UI提交需要跑的應用(Task) 到系統，Task可以是任何一種東西，比如說他是一個應用程序，或者是一個批處理任務，或者是一個(MR)的任務。他把這個任務通過Borgcfg提交到 BorgMaster，然后BorgMaster會接受這個請求，把請求放到隊列里面去，并由Scheduler來掃描這個隊列，查看這個應用的資源需求，并在集群中尋找匹配的機器。你其實提交的這個任務，它需要多少的資源，你需要怎么樣的機器，大概要跑多少時候，他會做一個匹配，就會看到底層有哪些機器是空閑的。然后就把這個任務發配到這個機器上面去，然后開始運行。

這個就是總體的一個Borg的框架。一個典型的啟動時間，從用戶提交應用到應用啟動是25秒。其中80%的時間是每個節點上下載這個應用包的時間。大家可以看到這個時間是很快的，它的調度時間還不到5秒，其中20秒是耗在傳輸這一層上。

關于BorgMaster的調度原理

我后面主要想探討一下，我今天想說的一個重點就是關于BorgMaster，它這里有很多應用，它怎么樣調動這個應用的優先級呢?或者說到底哪臺機器應該跑什么應用呢?Borg的做法就是對單個Task做了一個資源上的估量，大家可以看到這里有好幾條線，其中一個機器上面最外面的那條虛線就是用戶提交的一個資源的一個配額，就是Task再怎么運行也不能超過它的限制，這是一個硬性的限制，如果說超過這個限制，就會限制它，不讓它跑。這只是用戶提交的數字，大家知道用戶提交的數字很多時候是不準確的，你無法預估到底你的程序在你的系統上需要耗多少 CPU，占多少內存。Borg是怎么去評估這個資源呢?他在Task啟動300秒之后，就進行一個資源回收的工作。大家可以看到中間有一個黃色的區域，黃色的區域就是這個應用程序實際上所消耗的資源。然后它會從外面，慢慢把它推進去，推到綠區的地方，推到綠區的地方劃一條線，這條線就是所謂的保留資源，就是Borg這個系統認為你這個應用是長期穩定運行的所需要的資源。

這里就有一個問題，為什么Borg要這么做呢?原因是為了把剩下的區域的資源給空出來，如果說我知道這個應用實際上就用了這么多的資源。然后我給它劃了一定的安全線之后，剩下的這些資源我就可以調度出來，也就是說可以給到其它的應用程序用。

綠色的這一塊是黃色的塊加上一些安全區組成的，每過幾秒重新計算一遍應用程序耗費了多少資源。這實際上是一個動態的過程，它并不是說劃走了之后就再也不能變了。綠色的方塊是可以一直拓展到外面的虛線的范圍之內。這就是對單個Task做的一個策略。然后通過他對系統上跑的應用做了一個區分。就是說，他先想了一下，到底有哪些應用，這些應用有什么樣的特性。其中有一類應用就是所謂的生產型的應用，就是prod task，其特征就是永遠都是不停止的，他是一個長進程，它永遠是面向用戶的，比如說Gmail或者是Web Search，它中間不可能斷的，它的響應時間是幾微秒到幾百毫秒。然后這種任務就是說，你必須要優先保證它的運行，它的短期性能波動是比較敏感的。

還有一類任務就是所謂的non-prod task，他是一個批處理任務，類似像Map Reduce，它不是直接面向用戶的，對性能不是非常的敏感，跑完了就完了，下一個再跑就是下一個任務了，不是一個長進程。

為什么要區分任務?

當prod task的資源任務消耗比較大的時候，比如說很多人突然都來上一個網站，這個網站的服務器內存CPU就會非常高。這個時候，在這臺機器上應用資源不足的時候，他就會把Non-prod task殺掉，殺掉之后讓它去其他的機器上去運行。但是在空閑的時候，就可以讓任務繼續回來。這樣的話，我就可以充分利用這臺機器上的所有時間點上的資源，可以把這些東西塞的比較滿。最后谷歌的測試結果是，大概20%的工作負載可以跑在回收資源上。這個數據其實是非常大的。對谷歌有那么多臺的機器，你可以省下20%的資源，對它來說就是非常非常多的錢。

Borg的價值

我這里稍微總結一下，Borg這套系統給谷歌提供了什么樣的價值。它主要是提供了三個方面。第一個是隱藏的資源管理和故障處理的細節，讓用戶可以專注于應用開發。用戶不用操心底層的系統是怎么操作的，就算我掛了他也會幫我啟起來。第二個是本身提供高可靠性和高可用性的操作，并支持應用程序做到高可靠高可用。第三個是在數以萬計的機器上高資源利用率運行。

對于Borg具體怎么做到這三個方面，google有一篇很長的論文《在Google使用Borg進行大規模集群的管理》，里面有很多細節，今天就不展開說了。

#p#

Kubernetes架構

自從谷歌把Borg這個系統推出之后，對內部來說是非常成功，但是在外面的社區，其實大家都不知道這個東西到底是怎么做的，也不知道他內部是怎么實現的。后來做Borg的那批人他們就做了另外一個軟件，這個軟件就是Kubernetes，Kubernetes總體而言你可以認為是Borg的一個開源的版本，但是Kubernetes和Borg有一些不一樣，我后面會大致的講一下。這是Kubernetes的架構，大家其實可以看到，它的這個架構和Borg的架構基本上是類似的，包括用戶怎么用的也是類似的。用戶通過用kubectl這么一個命令行工具，把任務提交上來。

Kubernetes與Borg的區別

Borg在谷歌已經運行了十年，而且機器的規模量非常大，他一個集群就是一萬臺，甚至更多。而 Kubernetes是2014年才出來的，我個人認為這是針對亞馬遜，亞馬遜的公有云非常的成功，谷歌也想進入這個領域，他的方式就是把 Kubernetes這個系統開源推出來，在業界產生一定的影響力，讓大家都去用。這樣的話，后面就可以和亞馬遜競爭一下，這是我個人推測他們的一個想法。

Borg底層用的是lxc的容器，而Kubernetes是用的Docker容器。Borg是用C++編寫的，Kubernetes是用Go語言編寫的。Borg在集群調度的性能上做了很多的優化，Kubernetes還沒有做非常多的優化，目前他在這方面還是比較土的，后面還有很多工作需要做。 Borg的單集群能夠調度的機器有上萬臺，而按Kubernetes目前只能支持幾百臺，這是目前的數據。

然后我們再看一下，對于這兩個系統的用戶來說它們有什么區別。Borg的用戶其實就是谷歌的一批工程師，大家也知道谷歌工程師都是世界比較頂尖的工程師，他們在寫這個程序的時候就考慮過程序會跑在云上，他知道這個程序是分布式的。他在寫這個應用的時候，就會針對這個系統做非常多的優化，在設計的時候就知道我應該做一個分布式的系統。但是Kubernetes他想做的事情更多一些，就是除了運行這些分布式的系統之外，他還想就是說能夠支持一些，他首先是支持Docker的這些容器，但是他還希望支持一些比較傳統的，比較菜的，技術水平一般的人寫的這些應用程序。他在這方面做了一些工作。一個是用了 Docker容器，這樣的話就支持很多東西了。還有內他還可以掛載外部的持久層，就是你可以把一些分布層面的系統掛在那個系統上面。我的容器就去讀取外部的分布式的存儲。這樣的話，我這個容器就算是掛了，我這個數據也可以比較安全的保存。另外他就提供了一些監控還有一些日志的功能。但是這些功能是不是夠呢，這還是有一定的疑問的。后期如果說我想用Kubernetes來跑一些傳統的應用，那我肯定還會對這些應用和系統做一定程度的改造，但至少沒有困難到無法完成。

這個是它Kubernetes設計上的一些特色，Kubernetes的網絡架構是每一個Pod都有一個單獨的IP，這樣的應用更加友好一些。寫應用程序的人就不用考慮沖突這種情況。還有就是它分組的模式，就是我這些容器如何分組。Borg是一個比較專家的系統，他有230多個參數，但是 Kubernetes是非常簡單的大概就是三四個描述文件就完了。

Borg和Kubernetes的形象化總結

這里就是我對Borg和Kubernetes的一個形象化的總結。Borg就是一個噴氣式飛機的駕駛系統，非常的專業和高大上，他適用于谷歌這樣的大公司，它有幾百萬的機器。Kubernetes是一個它的簡化版，它是一輛設計優良的轎車，它適合中小型公司，用它來對自己的集群進行調度。

未來Kubernetes這邊也會做一些相應的工作，包括多租戶支持，包括容器持久化、集群規模的提升、利用率和網絡方面的等等。

[[154548]]

未來的云需要什么?

最后可以說是我個人的一些思考。我們未來的云到底需要什么樣的東西。大家可以看到，自從計算機風靡以來，有很多的系統，很多的軟件，一波又一波的起來，有一部分的系統或者說軟件是比較成功的，可以長久存在下去，比如說像Java、或者是C，或者是像Windows這樣，還有一些系統非常不幸，像Cobol或者是DOS或者是Minix這些系統，它們慢慢的被人所遺棄，慢慢被人所遺忘，最后變成廢棄的停車場。

我這里想考慮一下，如果說再過十年，我們現在在用的一些技術，像Kubernetes或者是Borg這樣的技術，是會進入到左邊這個行列還是右邊這個行列呢?我個人是希望進入左邊的行列，畢竟我們還是希望他可以成為一款經典的產品。至少對這些系統來說，我們會非常自豪，我們做了一款比較經典的產品，可以長久的被人們所使用下去。

如果說想做到這一點，就得面對我們現在這個時代，整個計算機系統所面臨的一個困境，或者說我們集群管理系統所面對的一個困境。這個困境是什么呢?就是這里所展示的Babel塔的困境。在以色列那個地方，這是一個圣經的故事，人們想造成一般座通天之塔，他們想挑戰上帝的權威。上帝一看你們這批凡人，就覺得你們這批鳥人居然敢挑戰我的權威，他就發明了各種語言，一起做巴別塔工作的人就各自使用不同的語言，他們就無法交流，最后這個塔就造不下去了。

其實在計算機的世界也是如此，大家使用各自的語言，各自的框架，最后使我們合作起來非常的復雜。包括我們的集群管理系統也好，包括其他的系統也好，其實都是幫助我們跨越這個鴻溝，幫助我們大家可以比較好的進行合作。但是目前來說，還沒有一個非常好的方案可以讓大家非常好的進行合作，我覺得這個是我們做這個系統需要做的一個事情。我這里引一句老子的話，大家可以看一下。

我在想，是什么因素決定了一個系統或者是一個軟件，它是否可以長期生存下去呢?我覺得非常重要的一點，他要明確自己要做什么。其實就是前面講的端水的端水，掃地的掃地，就是說你不但要明確自己這個軟件要做什么，還得明確自己不要做什么。你什么東西是無以之為用，就是這個領域我是不進去的，我是不去做的。如果說你什么東西都做，最后就會比較弱，很容易就會顛覆，或者是被人取代。如果說你單單把一件事情做好，那你今后在這個領域，至少你是無可替代的，可以長期生存下去。我記得前一段時間有人問Linus，怎么看Docker容器。然后他說我才不關心這什么狗屁容器，我就關心我的內核，你不要來問我這個問題。我覺得他這個就是一個非常好的一個態度，他把他自己內核這一個模塊做好，他把他系統這一塊做好，那么對他而言，他這個工作就可以長期延續下去。

那么對于我們來說，比較詳細一點，就是說在我們軟件開發當中碰到的情況是這樣的。從我們的軟件設計到開發到測試、生產都經過非常多，非常反復的過程。同時在大部分的集群系統當中，我們也非常難以調度它。那么我覺得對于我們來說，就是后面要解決幾個方面的問題。我覺得這是我們一個大的方向。

我們以后的產品是不是可以減少語言、程序、框架不同帶來的復雜性，能不能把流程進行簡化，把語言進行簡化，把網絡和服務依賴進行簡化，這是我提的另一個問題。

原文鏈接：http://www.dockone.io/article/784