Borg 到 Kubernetes,未來的云需要什么
我是來自于華為PaaS部門的鐘成,目前正在做相關(guān)的一些產(chǎn)品研發(fā)。我想分享的主題是從Borg到Kubernetes,其實Borg就是 Kubernetes的前身。我今天主要會談三個方面,第一個是Borg的介紹,第二是Kubernetes基于Borg做了哪些改變,以及它的發(fā)展方向,第三個話題想談一下未來的云可能需要一個怎么樣的產(chǎn)品或者是怎么樣的形態(tài)。
Borg是什么?它解決了什么問題?
我們先看第一個話題,就是Borg是什么?它解決了什么問題?
我們看一下這張圖,這張圖來自于一部電影叫做《星際迷航》相信大家大部分人都看過。Borg是里面的一種外星人,反派,他做什么事情呢?他和其他的文明接觸,把你這個文明搶占下來,然后它會和你同化,會把你進(jìn)行改造,把你改造成一個半人半機(jī)器的怪物,你就變成他們這個文明當(dāng)中的一部分,然后他在這個宇宙當(dāng)中不斷的擴(kuò)張下去。我覺得這是一個非??岬姆N族。而Borg就以這個名字來命名其大規(guī)模分布式的集成管理系統(tǒng)。他希望他們的系統(tǒng)也可以把不同的機(jī)器同化掉,變成他們自己的機(jī)器,然后運(yùn)行他們自己的程序。
對谷歌來說,Borg是一個比較頂層的集成管理系統(tǒng)。在它上面跑了谷歌大部分的應(yīng)用程序和框架包括Gmail、Google Docs、Web Search這樣直接面對客戶的一些應(yīng)用程序。它同時也包括一些底層的框架,(MR),包括它的一些GFS這些分布式的存儲系統(tǒng)。也就是說你可以認(rèn)為所有的應(yīng)用程序都需要通過它來管理底層的這些物理機(jī)。Borg在谷歌已經(jīng)成功的應(yīng)用的十多年。
大家可以看一下Borg的整體的架構(gòu)。它也是一個典型的分布式平臺的架構(gòu),就是一個邏輯上的master,然后下面有很多的節(jié)點,每一個節(jié)點上有一些它的代理程序。這里就可以看一下,作為谷歌內(nèi)部的一個工程師怎么樣用這個系統(tǒng)呢?他們使用Borgcfg(命令行)或者Web UI提交需要跑的應(yīng)用(Task) 到系統(tǒng),Task可以是任何一種東西,比如說他是一個應(yīng)用程序,或者是一個批處理任務(wù),或者是一個(MR)的任務(wù)。他把這個任務(wù)通過Borgcfg提交到 BorgMaster,然后BorgMaster會接受這個請求,把請求放到隊列里面去,并由Scheduler來掃描這個隊列,查看這個應(yīng)用的資源需求,并在集群中尋找匹配的機(jī)器。你其實提交的這個任務(wù),它需要多少的資源,你需要怎么樣的機(jī)器,大概要跑多少時候,他會做一個匹配,就會看到底層有哪些機(jī)器是空閑的。然后就把這個任務(wù)發(fā)配到這個機(jī)器上面去,然后開始運(yùn)行。
這個就是總體的一個Borg的框架。一個典型的啟動時間,從用戶提交應(yīng)用到應(yīng)用啟動是25秒。其中80%的時間是每個節(jié)點上下載這個應(yīng)用包的時間。大家可以看到這個時間是很快的,它的調(diào)度時間還不到5秒,其中20秒是耗在傳輸這一層上。
關(guān)于BorgMaster的調(diào)度原理
我后面主要想探討一下,我今天想說的一個重點就是關(guān)于BorgMaster,它這里有很多應(yīng)用,它怎么樣調(diào)動這個應(yīng)用的優(yōu)先級呢?或者說到底哪臺機(jī)器應(yīng)該跑什么應(yīng)用呢?Borg的做法就是對單個Task做了一個資源上的估量,大家可以看到這里有好幾條線,其中一個機(jī)器上面最外面的那條虛線就是用戶提交的一個資源的一個配額,就是Task再怎么運(yùn)行也不能超過它的限制,這是一個硬性的限制,如果說超過這個限制,就會限制它,不讓它跑。這只是用戶提交的數(shù)字,大家知道用戶提交的數(shù)字很多時候是不準(zhǔn)確的,你無法預(yù)估到底你的程序在你的系統(tǒng)上需要耗多少 CPU,占多少內(nèi)存。Borg是怎么去評估這個資源呢?他在Task啟動300秒之后,就進(jìn)行一個資源回收的工作。大家可以看到中間有一個黃色的區(qū)域,黃色的區(qū)域就是這個應(yīng)用程序?qū)嶋H上所消耗的資源。然后它會從外面,慢慢把它推進(jìn)去,推到綠區(qū)的地方,推到綠區(qū)的地方劃一條線,這條線就是所謂的保留資源,就是Borg這個系統(tǒng)認(rèn)為你這個應(yīng)用是長期穩(wěn)定運(yùn)行的所需要的資源。
這里就有一個問題,為什么Borg要這么做呢?原因是為了把剩下的區(qū)域的資源給空出來,如果說我知道這個應(yīng)用實際上就用了這么多的資源。然后我給它劃了一定的安全線之后,剩下的這些資源我就可以調(diào)度出來,也就是說可以給到其它的應(yīng)用程序用。
綠色的這一塊是黃色的塊加上一些安全區(qū)組成的,每過幾秒重新計算一遍應(yīng)用程序耗費(fèi)了多少資源。這實際上是一個動態(tài)的過程,它并不是說劃走了之后就再也不能變了。綠色的方塊是可以一直拓展到外面的虛線的范圍之內(nèi)。這就是對單個Task做的一個策略。然后通過他對系統(tǒng)上跑的應(yīng)用做了一個區(qū)分。就是說,他先想了一下,到底有哪些應(yīng)用,這些應(yīng)用有什么樣的特性。其中有一類應(yīng)用就是所謂的生產(chǎn)型的應(yīng)用,就是prod task,其特征就是永遠(yuǎn)都是不停止的,他是一個長進(jìn)程,它永遠(yuǎn)是面向用戶的,比如說Gmail或者是Web Search,它中間不可能斷的,它的響應(yīng)時間是幾微秒到幾百毫秒。然后這種任務(wù)就是說,你必須要優(yōu)先保證它的運(yùn)行,它的短期性能波動是比較敏感的。
還有一類任務(wù)就是所謂的non-prod task,他是一個批處理任務(wù),類似像Map Reduce,它不是直接面向用戶的,對性能不是非常的敏感,跑完了就完了,下一個再跑就是下一個任務(wù)了,不是一個長進(jìn)程。
為什么要區(qū)分任務(wù)?
當(dāng)prod task的資源任務(wù)消耗比較大的時候,比如說很多人突然都來上一個網(wǎng)站,這個網(wǎng)站的服務(wù)器內(nèi)存CPU就會非常高。這個時候,在這臺機(jī)器上應(yīng)用資源不足的時候,他就會把Non-prod task殺掉,殺掉之后讓它去其他的機(jī)器上去運(yùn)行。但是在空閑的時候,就可以讓任務(wù)繼續(xù)回來。這樣的話,我就可以充分利用這臺機(jī)器上的所有時間點上的資源,可以把這些東西塞的比較滿。最后谷歌的測試結(jié)果是,大概20%的工作負(fù)載可以跑在回收資源上。這個數(shù)據(jù)其實是非常大的。對谷歌有那么多臺的機(jī)器,你可以省下20%的資源,對它來說就是非常非常多的錢。
Borg的價值
我這里稍微總結(jié)一下,Borg這套系統(tǒng)給谷歌提供了什么樣的價值。它主要是提供了三個方面。第一個是隱藏的資源管理和故障處理的細(xì)節(jié),讓用戶可以專注于應(yīng)用開發(fā)。用戶不用操心底層的系統(tǒng)是怎么操作的,就算我掛了他也會幫我啟起來。第二個是本身提供高可靠性和高可用性的操作,并支持應(yīng)用程序做到高可靠高可用。第三個是在數(shù)以萬計的機(jī)器上高資源利用率運(yùn)行。
對于Borg具體怎么做到這三個方面,google有一篇很長的論文《在Google使用Borg進(jìn)行大規(guī)模集群的管理》,里面有很多細(xì)節(jié),今天就不展開說了。
#p#
Kubernetes架構(gòu)
自從谷歌把Borg這個系統(tǒng)推出之后,對內(nèi)部來說是非常成功,但是在外面的社區(qū),其實大家都不知道這個東西到底是怎么做的,也不知道他內(nèi)部是怎么實現(xiàn)的。后來做Borg的那批人他們就做了另外一個軟件,這個軟件就是Kubernetes,Kubernetes總體而言你可以認(rèn)為是Borg的一個開源的版本,但是Kubernetes和Borg有一些不一樣,我后面會大致的講一下。這是Kubernetes的架構(gòu),大家其實可以看到,它的這個架構(gòu)和Borg的架構(gòu)基本上是類似的,包括用戶怎么用的也是類似的。用戶通過用kubectl這么一個命令行工具,把任務(wù)提交上來。
Kubernetes與Borg的區(qū)別
Borg在谷歌已經(jīng)運(yùn)行了十年,而且機(jī)器的規(guī)模量非常大,他一個集群就是一萬臺,甚至更多。而 Kubernetes是2014年才出來的,我個人認(rèn)為這是針對亞馬遜,亞馬遜的公有云非常的成功,谷歌也想進(jìn)入這個領(lǐng)域,他的方式就是把 Kubernetes這個系統(tǒng)開源推出來,在業(yè)界產(chǎn)生一定的影響力,讓大家都去用。這樣的話,后面就可以和亞馬遜競爭一下,這是我個人推測他們的一個想法。
Borg底層用的是lxc的容器,而Kubernetes是用的Docker容器。Borg是用C++編寫的,Kubernetes是用Go語言編寫的。Borg在集群調(diào)度的性能上做了很多的優(yōu)化,Kubernetes還沒有做非常多的優(yōu)化,目前他在這方面還是比較土的,后面還有很多工作需要做。 Borg的單集群能夠調(diào)度的機(jī)器有上萬臺,而按Kubernetes目前只能支持幾百臺,這是目前的數(shù)據(jù)。
然后我們再看一下,對于這兩個系統(tǒng)的用戶來說它們有什么區(qū)別。Borg的用戶其實就是谷歌的一批工程師,大家也知道谷歌工程師都是世界比較頂尖的工程師,他們在寫這個程序的時候就考慮過程序會跑在云上,他知道這個程序是分布式的。他在寫這個應(yīng)用的時候,就會針對這個系統(tǒng)做非常多的優(yōu)化,在設(shè)計的時候就知道我應(yīng)該做一個分布式的系統(tǒng)。但是Kubernetes他想做的事情更多一些,就是除了運(yùn)行這些分布式的系統(tǒng)之外,他還想就是說能夠支持一些,他首先是支持Docker的這些容器,但是他還希望支持一些比較傳統(tǒng)的,比較菜的,技術(shù)水平一般的人寫的這些應(yīng)用程序。他在這方面做了一些工作。一個是用了 Docker容器,這樣的話就支持很多東西了。還有內(nèi)他還可以掛載外部的持久層,就是你可以把一些分布層面的系統(tǒng)掛在那個系統(tǒng)上面。我的容器就去讀取外部的分布式的存儲。這樣的話,我這個容器就算是掛了,我這個數(shù)據(jù)也可以比較安全的保存。另外他就提供了一些監(jiān)控還有一些日志的功能。但是這些功能是不是夠呢,這還是有一定的疑問的。后期如果說我想用Kubernetes來跑一些傳統(tǒng)的應(yīng)用,那我肯定還會對這些應(yīng)用和系統(tǒng)做一定程度的改造,但至少沒有困難到無法完成。
這個是它Kubernetes設(shè)計上的一些特色,Kubernetes的網(wǎng)絡(luò)架構(gòu)是每一個Pod都有一個單獨(dú)的IP,這樣的應(yīng)用更加友好一些。寫應(yīng)用程序的人就不用考慮沖突這種情況。還有就是它分組的模式,就是我這些容器如何分組。Borg是一個比較專家的系統(tǒng),他有230多個參數(shù),但是 Kubernetes是非常簡單的大概就是三四個描述文件就完了。
Borg和Kubernetes的形象化總結(jié)
這里就是我對Borg和Kubernetes的一個形象化的總結(jié)。Borg就是一個噴氣式飛機(jī)的駕駛系統(tǒng),非常的專業(yè)和高大上,他適用于谷歌這樣的大公司,它有幾百萬的機(jī)器。Kubernetes是一個它的簡化版,它是一輛設(shè)計優(yōu)良的轎車,它適合中小型公司,用它來對自己的集群進(jìn)行調(diào)度。
未來Kubernetes這邊也會做一些相應(yīng)的工作,包括多租戶支持,包括容器持久化、集群規(guī)模的提升、利用率和網(wǎng)絡(luò)方面的等等。
未來的云需要什么?
最后可以說是我個人的一些思考。我們未來的云到底需要什么樣的東西。大家可以看到,自從計算機(jī)風(fēng)靡以來,有很多的系統(tǒng),很多的軟件,一波又一波的起來,有一部分的系統(tǒng)或者說軟件是比較成功的,可以長久存在下去,比如說像Java、或者是C,或者是像Windows這樣,還有一些系統(tǒng)非常不幸,像Cobol或者是DOS或者是Minix這些系統(tǒng),它們慢慢的被人所遺棄,慢慢被人所遺忘,最后變成廢棄的停車場。
我這里想考慮一下,如果說再過十年,我們現(xiàn)在在用的一些技術(shù),像Kubernetes或者是Borg這樣的技術(shù),是會進(jìn)入到左邊這個行列還是右邊這個行列呢?我個人是希望進(jìn)入左邊的行列,畢竟我們還是希望他可以成為一款經(jīng)典的產(chǎn)品。至少對這些系統(tǒng)來說,我們會非常自豪,我們做了一款比較經(jīng)典的產(chǎn)品,可以長久的被人們所使用下去。
如果說想做到這一點,就得面對我們現(xiàn)在這個時代,整個計算機(jī)系統(tǒng)所面臨的一個困境,或者說我們集群管理系統(tǒng)所面對的一個困境。這個困境是什么呢?就是這里所展示的Babel塔的困境。在以色列那個地方,這是一個圣經(jīng)的故事,人們想造成一般座通天之塔,他們想挑戰(zhàn)上帝的權(quán)威。上帝一看你們這批凡人,就覺得你們這批鳥人居然敢挑戰(zhàn)我的權(quán)威,他就發(fā)明了各種語言,一起做巴別塔工作的人就各自使用不同的語言,他們就無法交流,最后這個塔就造不下去了。
其實在計算機(jī)的世界也是如此,大家使用各自的語言,各自的框架,最后使我們合作起來非常的復(fù)雜。包括我們的集群管理系統(tǒng)也好,包括其他的系統(tǒng)也好,其實都是幫助我們跨越這個鴻溝,幫助我們大家可以比較好的進(jìn)行合作。但是目前來說,還沒有一個非常好的方案可以讓大家非常好的進(jìn)行合作,我覺得這個是我們做這個系統(tǒng)需要做的一個事情。我這里引一句老子的話,大家可以看一下。
"三十幅共一轂,當(dāng)其無,有車之用。
埏埴以為器,當(dāng)其無,有器之用。 鑿戶牖以為室,當(dāng)其無,有室之用。 故有之以為利,無之以為用。" |
我在想,是什么因素決定了一個系統(tǒng)或者是一個軟件,它是否可以長期生存下去呢?我覺得非常重要的一點,他要明確自己要做什么。其實就是前面講的端水的端水,掃地的掃地,就是說你不但要明確自己這個軟件要做什么,還得明確自己不要做什么。你什么東西是無以之為用,就是這個領(lǐng)域我是不進(jìn)去的,我是不去做的。如果說你什么東西都做,最后就會比較弱,很容易就會顛覆,或者是被人取代。如果說你單單把一件事情做好,那你今后在這個領(lǐng)域,至少你是無可替代的,可以長期生存下去。我記得前一段時間有人問Linus,怎么看Docker容器。然后他說我才不關(guān)心這什么狗屁容器,我就關(guān)心我的內(nèi)核,你不要來問我這個問題。我覺得他這個就是一個非常好的一個態(tài)度,他把他自己內(nèi)核這一個模塊做好,他把他系統(tǒng)這一塊做好,那么對他而言,他這個工作就可以長期延續(xù)下去。
那么對于我們來說,比較詳細(xì)一點,就是說在我們軟件開發(fā)當(dāng)中碰到的情況是這樣的。從我們的軟件設(shè)計到開發(fā)到測試、生產(chǎn)都經(jīng)過非常多,非常反復(fù)的過程。同時在大部分的集群系統(tǒng)當(dāng)中,我們也非常難以調(diào)度它。那么我覺得對于我們來說,就是后面要解決幾個方面的問題。我覺得這是我們一個大的方向。
我們以后的產(chǎn)品是不是可以減少語言、程序、框架不同帶來的復(fù)雜性,能不能把流程進(jìn)行簡化,把語言進(jìn)行簡化,把網(wǎng)絡(luò)和服務(wù)依賴進(jìn)行簡化,這是我提的另一個問題。