Borg和Kubernetes有什麼不一樣？將來的雲鬚要什麼？

你們好，我是來自於華爲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進行大規模集羣的管理》，裏面有不少細節，今天就不展開說了。

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這邊也會作一些相應的工做，包括多租戶支持，包括容器持久化、集羣規模的提高、利用率和網絡方面的等等。

將來的雲鬚要什麼？

最後能夠說是我我的的一些思考。咱們將來的雲到底須要什麼樣的東西。你們能夠看到，自從計算機風靡以來，有不少的系統，不少的軟件，一波又一波的起來，有一部分的系統或者說軟件是比較成功的，能夠長久存在下去，好比說像Java、或者是C，或者是像Windows這樣，還有一些系統很是不幸，像Cobol或者是DOS或者是Minix這些系統，它們慢慢的被人所遺棄，慢慢被人所遺忘，最後變成廢棄的停車場。

我這裏想考慮一下，若是說再過十年，咱們如今在用的一些技術，像Kubernetes或者是Borg這樣的技術，是會進入到左邊這個行列仍是右邊這個行列呢？我我的是但願進入左邊的行列，畢竟咱們仍是但願他能夠成爲一款經典的產品。至少對這些系統來講，咱們會很是自豪，咱們作了一款比較經典的產品，能夠長久的被人們所使用下去。

若是說想作到這一點，就得面對咱們如今這個時代，整個計算機系統所面臨的一個困境，或者說咱們集羣管理系統所面對的一個困境。這個困境是什麼呢？就是這裏所展現的Babel塔的困境。在以色列那個地方，這是一個聖經的故事，人們想形成通常座通天之塔，他們想挑戰上帝的權威。上帝一看大家這批凡人，就以爲大家這批鳥人竟然敢挑戰個人權威，他就發明了各類語言，一塊兒作巴別塔工做的人就各自使用不一樣的語言，他們就沒法交流，最後這個塔就造不下去了。

其實在計算機的世界也是如此，你們使用各自的語言，各自的框架，最後使咱們合做起來很是的複雜。包括咱們的集羣管理系統也好，包括其餘的系統也好，其實都是幫助咱們跨越這個鴻溝，幫助咱們你們能夠比較好的進行合做。可是目前來講，尚未一個很是好的方案可讓你們很是好的進行合做，我以爲這個是咱們作這個系統須要作的一個事情。我這裏引一句老子的話，你們能夠看一下。

三十幅共一轂，當其無，有車之用。
埏埴覺得器，當其無，有器之用。
鑿戶牖覺得室，當其無，有室之用。
故有之覺得利，無之覺得用。

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

那麼對於咱們來講，比較詳細一點，就是說在咱們軟件開發當中碰到的狀況是這樣的。從咱們的軟件設計到開發到測試、生產都通過很是多，很是反覆的過程。同時在大部分的集羣系統當中，咱們也很是難以調度它。那麼我以爲對於咱們來講，就是後面要解決幾個方面的問題。我以爲這是咱們一個大的方向。

咱們之後的產品是否是能夠減小語言、程序、框架不一樣帶來的複雜性，能不能把流程進行簡化，把語言進行簡化，把網絡和服務依賴進行簡化，這是我提的另外一個問題。