在Google使用Borg進行大規模集羣的管理

pdf:  http://vdisk.weibo.com/s/z2pdgMOY-UA4C/1445988517

-----

在Google使用Borg進行大規模集羣的管理

<Large-scale cluster management at Google with Borg>

原做:
Abhishek Vermay, Luis Pedrosaz, Madhukar Korupolu,
David Oppenheimer, Eric Tune, John Wilkes

譯者:
難易  http://my.oschina.net/HardySimpson

Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored.For all other uses, contact the owner/author(s).
EuroSys’15, April 21–24, 2015, Bordeaux, France.
Copyright is held by the owner/author(s).
ACM 978-1-4503-3238-5/15/04.
http://dx.doi.org/10.1145/2741948.2741964

摘要

谷歌的Borg系統羣集管理器運行幾十萬個以上的jobs，來自幾千個不一樣的應用，橫跨了多個集羣，這些每一個集羣有上萬臺機器。

它經過權限控制、高效的任務包裝、超售、和進程級別性能隔離實現了高利用率。它支持高可用性應用程序，它擁有最大限度地減小故障恢復時間的運行特性，它擁有減小相關故障機率的調度策略。Borg是這樣簡化用戶生活的：提供聲明性的工做規範語言，名稱服務集成，實時做業監控，和分析和模擬系統行爲的工具。

咱們將會展示Borg系統架構和特色，重要的設計決策，定量分析它的一些策略，和十年以來的運維經驗和學到的東西。

1. 簡介

集羣管理系統咱們內部叫Borg，它管理、調度、開始、重啓和監控谷歌運行的應用程序的生命週期。本文介紹它是怎麼作到這些的。

Borg提供了三個主要的好處：它（1）隱藏資源管理和故障處理細節，使其用戶能夠專一於應用開發；（2）高可靠性和高可用性的操做，並支持應用程序作到高可靠高可用；（3）讓咱們在數以萬計的機器上有效運行。Borg不是第一個來解決這些問題的系統，但它是在這個規模，這種程度的彈性和完整性下運行的爲數很少的幾個系統之一。

本文圍繞這些主題來編寫，包括了咱們在生產環境運行十年的一些經驗。

2.用戶視角

Borg的用戶是谷歌開發人員和系統管理員(網站可靠性工程師 SRE)，他們運行谷歌應用與服務。用戶以job的方式提交他們的工做給Borg，job由一個或多個task組成，每一個task含有一樣的二進制程序。一個job只能在一個Borg的Cell裏面跑，Cell是包括了多臺機器的單元。這一節主要講用戶視角下的Borg系統。

2.1 工做負載

Borg Cell主要運行兩種異構的工做負載。第一種是長期的服務，應該「永遠」運行下去，並處理短期的敏感請求（幾微秒到幾百毫秒）。這種服務是面向終端用戶的產品如Gmail、Google Docs、網頁搜索，內部基礎設施服務（例如，Bigtable）。第二種是批處理任務，須要幾秒到幾天來完成，對短時間性能波動不敏感。在一個Cell上混合運行了這兩種負載，取決於他們的主要租戶（好比說，有些Cell就是專門用來跑密集的批處理任務的）。工做負載也隨着時間會產生變化：批處理任務作完就會終止退出，終端用戶服務的負載是以天爲週期而波動運行的。Borg須要把這兩種狀況都處理好。

Borg有一個2011年5月的負載數據[80]，已經被普遍的分析了[68,26，27，57，1]。

最近幾年，不少應用框架是搭建在Borg上的，包括咱們內部的MapReduce[23]、flumejava[18]、Millwheel[3]、Pregel[59]。這中間的大部分都是有一個控制器，能夠提交job。前2個框架相似於YARN的應用管理器[76]。咱們的分佈式存儲系統，例如GFS[34]和他的後繼者CFS、Bigtable[19]、Megastore[8]都是跑在Borg上的。

在這篇文章裏面，咱們把高優先級的Borg的jobs定義爲生產(prod)，剩下的是非生產的(non-prod)。大多數長期服務是prod的，大部分批處理任務是non-prod的。在一個典型的Cell裏面，prod job分配了70%的CPU資源而後實際用了60%；分配了55%的內存資源而後實際用了85%。在$5.5會展現分配和實際值的差是很重要的。

2.2 集羣和Cell

一個Cell裏面的全部機器都屬於單個集羣，集羣是由高性能的數據中心級別的光纖網絡鏈接起來的。一個集羣安裝在數據中心的一座樓裏面，n座樓合在一塊兒成爲一個site。一個集羣一般包括一個大的Cell還有一些小的或測試性質的Cell。咱們儘可能避免任何單點故障。

在測試的Cell以外，咱們中等大小的Cell大概包括10000臺機器；一些Cell還要大不少。一個Cell中的機器在不少方面都是異構的：大小(CPU,RAM,disk,network)、處理器類型、性能以及外部IP地址或flash存儲。Borg隔離了這些差別，讓用戶單純的選擇用哪一個Cell來跑任務，分配資源、安裝程序和其它依賴、監控系統的健康並在故障時重啓。

(譯者：Cell其實就是邏輯上的集羣)

2.3 job和task

一個Borg的job的屬性有：名字、擁有者和有多少個task。job能夠有一些約束，來指定這個job跑在什麼架構的處理器、操做系統版本、是否有外部IP。約束能夠是硬的或者軟的。一個job能夠指定在另外一個job跑完後再開始。一個job只在一個Cell裏面跑。

每一個task包括了一組linux進程，跑在一臺機器的一個容器內[62]。大部分Borg的工做負載沒有跑在虛擬機(VM)裏面，由於咱們不想付出虛擬化的代價。並且，Borg在設計的時候還沒硬件虛擬化什麼事兒呢。

task也有一些屬性，包括資源用量，在job中的排序。大多task的屬性和job的通用task屬性是同樣的，也能夠被覆蓋 —— 例如，提供task專用的命令行參數，包括CPU核、內存、磁盤空間、磁盤訪問速度、TCP端口等等，這些都是能夠分別設置並按照一個好的粒度提供。咱們不提供固定的資源的單元。Borg程序都是靜態編譯的，這樣在跑的環境下就沒有依賴，這些程序都被打成一個包，包括二進制和數據文件，能被Borg安裝起來。

用戶經過RPC來操做Borg的job，大可能是從命令行工具，或者從咱們的監控系統($2.6)。大多job描述文件是用一種申明式配置文件BCL -- GCL[12]的一個變種，會產生一個protobuf文件[67]。BCL有一些本身的關鍵字。GCL提供了lambda表達式來容許計算，這樣就能讓應用在環境裏面調整本身的配置。上萬個BCL配置文件超過一千行長，系統中累計跑了了千萬行BCL。Borg的job配置很相似於Aurora配置文件[6]。

圖2展示了job的和task的狀態機和生命週期。

用戶能夠在運行時改變一個job中的task的屬性，經過推送一個新的job配置給Borg。這個新的配置命令Borg更新task的規格。這就像是跑一個輕量級的，非原子性的事務，並且能夠在提交後輕易再改回來。更新是滾動式的，在更新中能夠限制task重啓的數量，若是有太多task停掉，操做能夠終止。

一些task更新，例如更新二進制程序，須要task重啓；另一些例如修改資源需求和限制會致使這個機器不適合跑現有的task，須要中止task再從新調度到別的機器上；還有一些例如修改優先級是能夠不用重啓或者移動task。

task須要可以接受Unix的SIGTERM信號，在他們被強制發送SIGKILL以前，這樣就有時間去作清理、保存狀態、結束現有請求執行、拒絕新請求。實際的notice的delay bound。實踐中，80%的task能正常處理終止信號。

2.4 Allocs

Borg的 alloc (allocation的縮寫)是在單臺機器上的一組保留的資源配額，用來讓一個或更多的task跑；這些資源一直分配在那邊，不管有沒有被用。allocs能夠被分配出來給將來的task，用來保持資源在中止一個task和重啓這個task之間，用來彙集不一樣jobs的tasks到同一臺機器上——例如一個web server實例和附加的，用於把serverURL日誌發送到一個分佈式文件系統的日誌蒐集實例。一個alloc的資源管理方式和一臺機器上的資源管理方式是相似的；多個tasks在一個alloc上跑並共享資源。若是一個alloc必須被從新定位到其餘的機器上，那麼它的task也要跟着從新調度。

一個alloc set就像一個job：它是一組allocs保留了多臺機器上的資源。一旦alloc set被建立，一個或多個jobs就能夠被提交進去跑。簡而言之，咱們會用task來表示一個alloc或者一個top-level task(一個alloc以外的)，用job來表示一個job或者alloc set。

2.5 優先級、配額和管理控制

當有工做負載在運行時超載會發生什麼事情？咱們的解決方案是優先級和配額。

全部job都有優先級，一個小的正整數。高優先級的task能夠優先獲取資源，即便後面被殺掉。Borg定義了不重疊的優先級段給不一樣任務用，包括(優先級降序)：監控、生產、批任務、高性能(測試或免費)。在這篇文章裏面，prod的jobs是在監控和生產段。

雖然一個降級的task總會在cell的其餘地方找到一席之地。連鎖降級反應也有可能會發生，就是一個task降下來以後，把下面運行的task再擠到別的機器上，如此往復。爲了不這種狀況，咱們禁止了prod級task互相排擠。合理粒度的優先級在其餘場景下也頗有用——MapReduce的master跑的優先級比worker高一點，來保證他們的可用性。

優先級是jobs的相對重要性，決定了jobs在一個cell裏面是跑仍是等(pending)。配額則是用來決定jobs是否運行被調度。配額就是一組資源(CPU, RAM, disk)的數量在一個指定的優先級、一個指定的時間段(月這個量級)。數量決定了這個用戶的job能夠用的最多資源(例子：20TB內存和prod優先級從如今到7月在xx cell內)。配額檢查是管理控制的一部分，不是調度層的：配額不足的任務在提交的時候就會被拒絕。

高優先級的配額老是消費的比低優先級要多。prod級的配額是被限制爲一個cell裏面實際的資源量，因此用戶提交了prod級的job的配額時，在不計資源碎片和限制以外，能夠期待這個job必定會跑。即便這樣，咱們鼓勵用戶多買一點比本身須要多一點的配額，不少用戶超買是由於他們的應用程序的用戶數量增加後須要的配額就大了。對於超買，咱們的應對方案是低優先級資源的超售：全部用戶在0優先級均可以用無限的配額，雖然在實際運行中這種狀況很難跑起來。一個低優先級的job在資源不足時會保持等(pending)狀態。

配額分配在Borg系統以外，和咱們的物理資源計劃有關。這些資源計劃在不一樣的數據中心產生不一樣的價格和配額。用戶jobs只在有足夠配額和足夠優先級以後才能啓動。配額的使用讓Dominant Resource Fairness(DRF)[29, 35, 36, 66]不是那麼必要了。

Borg有一個容量系統給一些特殊權限給某些用戶，例如，容許管理員刪除或修改cell裏面的job，或者容許用戶區訪問特定的內核特性或者讓Borg對本身的job不作資源估算($5.5)。

2.6 命名和監控

光是建立和部署task是不夠的：一個服務的客戶端和其餘系統須要能找到它們，即便它換了個地方。爲了搞定這一點，Borg創造了一個穩定的「Borg name Service」(BNS)名字給每一個task，這個名字包括了cell名字，job名字，和task編號。Borg把task的主機名和端口寫入到一個持久化高可用文件裏，以BNS名爲文件名，放在Chubby[14]上。這個文件被咱們的RPC系統使用，用來發現task的終端地址。BNS名稱也是task的DNS名的基礎構成部分，因此，cc cell的ubar用戶的jfoo job的第50個task的DNS名稱會是50.jfoo.ubar.cc.borg.google.com。Borg同時還會把job的大小和task的健康信息寫入到Chubby在任何狀況改變時，這樣負載均衡就能知道怎麼去路由請求了。

幾乎全部的Borg的task都會包含一個內置的HTTP服務，用來發布健康信息和幾千個性能指標(例如RPC延時)。Borg監控這些健康檢查URL，把其中響應超時的和error的task重啓。其餘數據也被監控工具追蹤並在Dashboards上展現，當服務級別對象(SLO)出問題時就會報警。

用戶能夠使用一個名叫Sigma的web UI，用來檢查他們全部的job狀態，一個特殊的cell，或者深刻到某個job的某個task的資源用率，詳細日誌，操做歷史，和最終命運。咱們的應用產生大量的日誌，都會被自動的滾動來避免塞滿硬盤，會在一個task結束後保留一小段時間用來debug。若是一個job沒有被跑起來，Borg會提供一個爲何掛起的解釋，指導用戶怎麼修改這個job的資源需求來符合目前這個cell的狀況。咱們發佈資源的使用方針，按照這個方針來作就容易被調度起來。

Borg記錄全部的job提交和task時間，以及每task的資源使用細節在基礎存儲服務裏面。這個存儲服務有一個分佈式的只讀的SQL-like的交互式接口，經過Dremel[61]提供出來。這些數據在實時使用、debug、系統查錯和長期容量規劃上都頗有用。這些數據也是Google集羣負載追蹤的數據來源之一[80].

全部這些特性幫助用戶理解和debug Borg的行爲和管理他們的job，而且幫助咱們的SRE每一個人管理超過上萬臺機器。

3. Borg架構

一個Borg的Cell包括一堆機器，一個邏輯的中心控制服務叫作Borgmaster，和在每臺機器上跑的Borglet的agent進程(見圖1)。全部Borg的組件都是用C++寫的。

3.1 Borgmaster

Cell的Borgmaster由2個進程組成，主的Borgmaster進程和一個單獨的scheduler($3.2)。主的Borgmaster處理全部客戶端的RPC請求，例如修改狀態(建立job)，提供數據讀取服務(查找job)。它同時管理系統中全部組件(機器、task、allocs等等)的狀態機，和Borglet通訊，而且提供一個Sigma的備份Web UI。

Borgmaster在邏輯上是一個單進程，但實際上開了5個副本。每一個副本維護了一個內存級別的cell狀態拷貝，這些狀態同時被記錄在一個高可用、分佈式、Paxos-based存儲[55]放在這些副本的本地硬盤上。在一個cell裏面，一個單獨的被選舉出來的master同時用於Paxos leader和狀態修改器，用來處理全部改變cell狀態的請求，例如提交一個job或者在一個機器上終止一個task。當cell啓動或前一個master掛了時，Paxos算法會選舉出一個master；這須要一個Chubby鎖而後其餘系統能夠找到master。選舉一個master或者換一個新的須要的典型事件是10s，但須要大概1分鐘才能讓一個大的cell內生效，由於一些內存狀態要重構。當一個副本從網絡隔離中恢復時，須要動態的從其餘Paxos副本中從新同步本身的狀態。

某個時刻的Borgmaster的狀態被稱爲checkpoint，會被以快照形式+change log形式保存在Paxos存儲裏面。checkpoints有不少用途，包括把Borgmaster的狀態恢復到之前的任意時刻(例如在處理一個請求以前，用來解決軟件缺陷)；極端狀況下手動修改checkpoints，造成一個持續的事件日誌供從此用；或用於線下的在線仿真。

一個高仿真的Borgmaster叫Fauxmaster，能夠用來讀取checkpoint文件，包括一份完整的Borgmaster的代碼，和Borglet的存根接口。它接受RPC來改變狀態機和執行操做，例如調度全部阻塞的tasks，咱們用它來debug錯誤，和它交互就和Borgmaster交互是同樣的，一樣咱們也有一個仿真的Borglet能夠用checkpoint重放真實的交互。用戶能夠單步調試看到系統中的全部過去的改變。Fauxmaster在這種狀況下也頗有用：多個這個類型的job比較合適？以及在改變cell配置前作一個安全檢查(這個操做會把任何關鍵jobs給踢掉嗎？)

3.2 調度 schedule

當一個job被提交的時候，Borgmaster會把它持久化的存儲在Paxos存儲上，而後把這個job的task放到等待(pending)的隊列裏面去。這個隊列會被scheduler異步的掃描，而後分發task到有充足資源的機器上。scheduler主要是處理task的，不是job。掃描從高優先級到低優先級，在同個優先級上用round-robin的方式處理，以保證用戶之間的公平性和避免頭上的大job阻塞住。調度算法有2個部分：可行性檢查(feasibility checking)，找到一臺能跑task的機器，和打分(scoring)，找個一個最合適的機器。

在可行性檢查這個階段，scheduler會找到一組機器，都知足task的約束並且有足夠可用的資源 —— 包括了一些已經分配給低優先級任務的能夠被騰出來的資源。在打分階段，scheduler會找到其中「最好」的機器。這個分數包括了用戶的偏好，但主要是被內置的標準：例如最小化的倒騰其餘task，找到已經有這個task安裝包的，在電力和出錯的可用域之間儘量分散的，在單臺機器上混合高低優先級的task以保證高峯期擴容的。

Borg原來用E-PVM[4]的變種算法來打分，在異構的資源上生成一個單一的分數，在調度一個task時最小化系統的改變。但在實踐中，E-PVM最後把負載平均分配到全部機器，把擴展空間留給高峯期 —— 但這麼作的代價是增長了碎片，尤爲是對於大的task須要大部分機器的時候；咱們有時候給這種分配取綽號叫「最差匹配」。

分配策略光譜的另外一端是「最佳匹配」，把機器塞任務塞的越緊越好。這樣就能留下一些空的機器給用戶jobs(他們也跑存儲服務)，因此處理大task就比較直接了，不過，緊分配會懲罰那些對本身所需資源預估不足的用戶。這種策略會傷害爆發負載的應用，並且對須要低CPU的批處理任務特別不友好，這些任務能夠被輕易調度到不用的資源上：20%的non-prod task須要小於0.1核的CPU。

咱們目前的打分模型是一個混合的，試圖減小碎片資源 —— 一些由於這臺機器上資源沒被所有用掉而剩下的。比起「最佳匹配」，這個模型提供了3%-5%的打包效率提高(在[78]裏面定義的)

若是一臺機器在打分後沒有足夠的資源運行新的task，Borg會驅逐(preempts)低優先級的任務，從最低優先級往上踢，直到資源夠用。咱們把被踢掉的task放到scheduler的等待(pending)隊列裏面去，而不是遷移或冬眠這些task。

task啓動延遲(從job提交到task運行之間的時間段)是被咱們持續關注的。這個時間差異很大，通常來講是25s。包安裝耗費了這裏面80%的時間：一個已知的瓶頸就是對本地硬盤的爭搶。爲了減小task啓動時間，scheduler但願機器上已經有足夠的包(程序和數據)：大部分包是隻讀的因此能夠被分享和緩存。這是惟一一種Borg scheduler支持的數據本地化方式。順便說一下，Borg分發包到機器的辦法是樹形的和BT類型的協議。

另外，scheduler用了某些技術來擴散到幾萬臺機器的cell裏面。($3.4)

3.3 Borglet

Borglet是部署在cell的每臺機器上的本地Borg代理程序。它啓動中止task；若是task失敗就重啓；經過修改OS內核設置來管理本地資源；滾動debug日誌；把本機的狀態上報給Borgmaster和其餘監控系統。

Borgmaster每過幾秒就會輪詢全部的Borglet來獲取機器當前的狀態還有發送任何請求。這讓Borgmaster能控制交流頻率，避免一個顯式的流控機制，並且防止了恢復風暴[9].

選舉出來的master負責發送消息給Borglet而且根據響應更新cell的狀態。爲了性能可擴展，每一個Borgmaster副本會運行一個無狀態的鏈接分配(link shard)來處理和特定幾個Borglet的交流；這個分配會在Borgmaster選舉的時候從新計算。爲了保證彈性，Borglet把全部狀態都報上來，可是link shard會聚合和壓縮這些信息到狀態機，來減小選舉出來的master的負載。

若是Borglet幾回沒有響應輪詢請求，將會被標記爲掛了(down)，而後上面跑的task會被從新分配到其餘機器。若是通信恢復，Borgmaster會讓這個Borglet殺掉已經被分配出去的task，來避免重複。Borglet會繼續常規的操做即便和Borgmaster恢復聯繫，因此目前跑的task和service保持運行以防全部的Borgmaster掛了。

3.4 可擴展性

咱們還不知道Borg的可擴展性極限在哪裏，每次咱們碰到一個極限，咱們就越過去。一個單獨的Borgmaster能夠管理一個cell裏面幾千臺機器，若干個cell能夠處理10000個任務每分鐘。一個繁忙的Borgmaster使用10-14個CPU核以及50GB內存。咱們用了幾項技術來得到這種擴展性。

早期的Borgmaster有一個簡單的，同步的循環來處理請求、調度tasks，和Borglet通訊。爲了處理大的cell，咱們把scheduler分出來做爲一個單獨的進程，而後就能夠和別的Borgmaster功能並行的跑，別的Borgmaster能夠開副原本容錯。一個scheduler副本操做一份cell的狀態拷貝。它重複地：從選舉出來的master獲取狀態改變(包括全部的分配的和pending的工做)；更新本身的本地拷貝，作調度工做來分配task；告訴選舉出來的master這些分配。master會接受這些信息而後應用之，除非這些信息不適合(例如，過期了)，這些會在scheduler的下一個循環裏面處理。這一切都符合Omega[69]的樂觀並行策略精神，並且咱們最近真的給Borg添加這種功能，對不一樣的工做負載用不一樣的scheduler來調度。

爲了改進響應時間，咱們增長了一些獨立線程和Borglet通訊、響應只讀RPC。爲了更高的性能，咱們分享(分區)這些請求給5個Borgmaster副本$3.3。最後，這讓99%的UI響應在1s之內，而95%的Borglet輪詢在10s之內。

一些讓Borg scheduler更加可擴展的東西：

分數緩存：評估一臺機器的可用性和分數是比較昂貴的，因此Borg會一直緩存分數直到這個機器或者task變化了——例如，這臺機器上的task結束了，一些屬性修改了，或者task的需求改變了。忽略小的資源變化讓緩存保質期變長。

同級別均化處理：同一個Borg job的task通常來講有相同的需求和資源，因此不用一個個等待的task每次都去找可用機器，這會把全部可用的機器打n次分。Borg會對相同級別的task找一遍可用機器打一次分。

適度隨機：把一個大的Cell裏面的全部機器都去衡量一遍可用性和打分是比較浪費的。因此scheduler會隨機的檢查機器，找到足夠多的可用機器去打分，而後挑出最好的一個。這會減小task進入和離開系統時的打分次數和緩存失效。適度隨機有點像Sparrow [65]的批處理採樣技術，一樣要面對優先級、驅逐、非同構系統和包安裝的耗費。

在咱們的實驗中($5)，調度整個cell的工做負載要花幾百秒，但不用上面幾項技術的話會花3天以上的時間。通常來講，一個在線的調度從等待隊列裏面花半秒就能搞定。

4. 可用性

在大型分佈式系統裏面故障是很常見的[10,11,12]。圖3展現了在15個cell裏面task驅逐的緣由。在Borg上跑的應用須要能處理這種事件，應用要支持開副本、存儲數據到分佈式存儲這些技術，並能按期的作快照。即便這樣，咱們也儘量的緩和這些事件形成的影響。例如，Borg：

• 自動的從新調度被驅逐的task，若是須要放到新機器上運行
• 經過把一個job分散到不一樣的可用域裏面去，例如機器、機架、供電域
• 在機器、OS升級這些維護性工做時，下降在同一時刻的一個job中的task的關閉率
• 使用聲明式的目標狀態表示和冪等的狀態改變作操做，這樣故障的客戶端能夠無損的從新啓動或安全的遺忘請求
• 對於失聯的機器上的task，限制必定的比率去從新調度，由於很難去區分大規模的機器故障和網絡分區
• 避免特定的會形成崩潰的task:機器的匹配
• critical級別的中間數據寫到本地硬盤的日誌保存task很重要，就算這個task所屬的alloc被終止或調度到其餘機器上，也要恢復出來作。用戶能夠設置系統保持重複嘗試多久：若干天是比較合理的作法。

一個關鍵的Borg設計特性是：就算Borgmaster或者Borglet掛了，task也會繼續運行下去。不過，保持master運行也很重要，由於在它掛的時候新的jobs不能提交，或者結束的沒法更新狀態，故障的機器上的task也不能從新調度。

Borgmaster使用組合的技術在實踐中保證99.99%的可用性：副本技術應對機器故障；管理控制應對超載；部署實例時用簡單、底層的工具去減小外部依賴(譯者：我猜想是rsync或者scp這種工具)。每一個cell和其餘cell都是獨立的，這樣減小了誤操做關聯和故障傳染。爲了達到這個目的，因此咱們不搞大cell。

5. 使用效率

Borg的一個主要目的就是有效的利用Google的機器艦隊，這但是一大筆財務投資：讓效率提高几個百分點就能省下幾百萬美圓。這一節討論了和計算了一些Borg使用的技術和策略。

5.1 測度方法論

咱們的job部署是有資源約束的，並且不多碰到負載高峯，咱們的機器是異構的，咱們從service job回收利用的資源跑batch job。因此，爲了測量咱們須要一個比「平均利用率」更抽象的標準。在作了一些實驗後咱們選擇了cell壓縮率(cell compaction)：給定一個負載，咱們不斷的從零開始(這樣能夠避免被一個倒黴的配置卡住)，部署到儘量小的Cell裏面去，直到不再能從這個cell裏面抽機器出來。這提供了一個清晰的終止條件，並促進了無陷阱的自動化比較，這裏的陷阱指的是綜合化的工做負載和建模[31]。一個定量的比較和估算技術能夠看[78]，有很多微妙的細節。

咱們不可能在線上的cell作性能實驗，因此咱們用了Fauxmaster來達到高保真的模擬效果，使用了真的在線cell的負載數據包括全部的約束、實際限制、保留和經常使用數據($5.5)。這些數據從2014-10-1 14:00 PDT的Borg快照(checkpoints)裏面提取出來。(其餘快照也產生相似的結論)。咱們選取了15個Borg cell來出報告，先排除了特殊目的的、測試的、小的(<5000機器)的cell，而後從剩下的各類量級大小的cell中平均取樣。

在壓縮cell實驗中爲了保持機器異構性，咱們隨機選擇去掉的機器。爲了保持工做負載的異構性，咱們保留了全部負載，除了那些對服務和存儲須要有特定需求的。咱們把那些須要超過一半cell的job的硬限制改爲軟的，容許不超過0.2%的task持續的pending若是它們過於挑剔機器；普遍的測試代表這些結果是可重複的。若是咱們須要一個大的cell，就把原cell複製擴大；若是咱們須要更多的cell，就複製幾份cell。

全部的實驗都每一個cell重複11次，用不一樣的隨機數發生器。在圖上，咱們用一個橫線來表示最少和最多須要的機器，而後選擇90%這個位置做爲結果，平均或者居中的結論不會表明一個系統管理員會作的最優選擇。咱們相信cell壓縮提供了一個公平一致的方式去比較調度策略：好的策略只須要更少的機器來跑相同的負載。

咱們的實驗聚焦在調度(打包)某個時間點的一個負載，而不是重放一段長期的工做蹤影。這部分是由於複製一個開放和關閉的隊列模型比較困難，部分是由於傳統的一段時間內跑完的指標和咱們環境的長期跑服務不同，部分是由於這樣比較起來比較明確，部分是由於咱們相信怎麼整都差很少，部分是由於咱們在消費20萬個Borg CPU來作測試——即便在Google的量級，這也不是一個小數目(譯者：就你丫理由多！)

在生產環境下，咱們謹慎的留下了一些頂部空間給負載的增長，好比一些「黑天鵝」時間，負載高峯，機器故障，硬件升級，以及大範圍故障(供電進灰)。圖4顯示了咱們在現實世界中能夠把cell壓縮到多小。上面的基線是用來表示壓縮大小的。

5.2 Cell的共享使用

幾乎咱們全部的機器都同時跑prod和non-prod的task：在共享Borg cell裏有98%的機器同時跑這2種task，在全部Borg管理的機器裏面有83%同時跑這2種task(咱們有一些專用的Cell跑特定任務)。

鑑於不少其餘的組織把面向用戶應用和批處理應用在不一樣的集羣上運行，咱們設想一下若是咱們也這麼幹會發生什麼狀況。圖5展示了在一箇中等大小的Cell上分開跑咱們prod和non-prod的工做負載將須要20-30%多的機器。這是由於prod的job一般會保留一些資源來應對極少發生的負載高峯，但實際上在大多狀況下不會用這些資源。Borg把這批資源回收利用了($5.5)來跑不少non-prod的工做，因此最終咱們只須要更少的機器。

大部分Borg cell被幾千個用戶共享使用。圖6展示了爲何。對這個測試，若是一個用戶消費超過了10TiB內存(或100TiB)，咱們就把這個用戶的工做負載分離到一個單獨的Cell裏面去。咱們目前的策略展示了它的威力：即便咱們設置了這麼高的閾值(來分離)，也須要2-16倍多的Cell，和20-150%多的機器。資源池的方案再次有效地節省了開銷。

可是，或許把不少不相關的用戶和job類型打包放到一臺機器上，會形成CPU衝突，而後就須要更多的機器進行補償？爲了驗證這一點，咱們看一下在同一臺機器，鎖定時鐘週期，每指令循環數CPI(cycles per instruction)在不一樣環境的task下是怎麼變化的。在這種狀況下，CPI是一個可比較的指標並且能夠表明衝突度量，由於2倍的CPI意味着CPU密集型程序要跑2倍的時間。這些數據是從一週內12000個隨機的prod的task中獲取的，用硬件測量工具[83]取的，而且對採樣作了權重，這樣每秒CPU都是平等的。測試結果不是很是明顯。

1. 咱們發現CPI在同一個時間段內和下面兩個量正相關：這臺機器上總的CPU使用量，以及(強相關)這個機器上同時跑的task數量；每往一臺機器上增長1個task，就會增長0.3%的CPI(線性模型過濾數據)；增長一臺10%的CPU使用率，就會增長小於2%的CPI。即便這已是一個統計意義顯著的正相關性，也只是解釋了咱們在CPI度量上看到的5%的變化，還有其餘的因素支配着這個變化，例如應用程序固有的差異和特殊的干涉圖案[24,83]。
2. 比較咱們從共享Cell和少數只跑幾種應用的專用Cell獲取的CPI採樣，咱們看到共享Cell裏面的CPI平均值爲1.58(σ=0.35,方差)，專用Cell的CPI平均值是1.53(σ=0.32,方差).也就是說，共享Cell的性能差3%。
3. 爲了搞定不一樣Cell的應用會有不一樣的工做負載，或者會有幸存者誤差(或許對衝突更敏感的程序會被挪到專用Cell裏面去)，咱們觀察了Borglet的CPI，在全部Cell的全部機器上都會被運行。咱們發現專用Cell的CPI平均值是1.20(σ=0.29,方差)，而共享Cell裏面的CPI平均值爲1.43(σ=0.45,方差)，暗示了在專用Cell上運行程序會比在共享Cell上快1.19倍，這就超過了CPU使用量輕負載的這個因素，輕微的有利於專用Cell。

這些實驗肯定了倉庫級別的性能測試是比較微妙的，增強了[51]中的觀察，而且得出了共享並無顯著的增長程序運行的開銷。

不過，就算咱們假設用了咱們結果中最很差的數據，共享仍是有益的：比起CPU的降速，在各個方案裏面減小機器更重要，這會帶來減小全部資源的開銷，包括內存和硬盤，不只僅是CPU。

5.3 大Cell

Google創建了大Cell，爲了容許大的任務運行，也是爲了下降資源碎片。咱們經過把負載從一個cell分到多個小cell上來測試後面那個效應(下降碎片效應)，隨機的把job用round-robin方式分配出去。圖7展現了用不少小cell會明顯的須要更多機器。

5.4 資源請求粒度

Borg用戶請求的CPU單位是千分之一核，內存和硬盤單位是byte。(1核是一個CPU的超線程，在不一樣機器類型中的一個通用單位)。圖8展示了這個粒度的好處：CPU核和內存只有少數的「最佳擊球點」，以及這些資源不多的相關性。這個分佈和[68]裏面的基本差很少，除了咱們看到大內存的請求在90%這個線上。

提供一個固定尺寸的容器和虛擬機，在IaaS(infrastructure-as-a-service)提供商裏面或許是比較流行的，但不符合咱們的需求。爲了展示這一點，咱們把CPU核和內存限制作成一個個尺寸，而後把prod的job按照大一點最近的尺寸去跑(取這2個維度的平方之和最近，也就是2維圖上的直線)，0.5核的CPU,1G的內存爲差值。圖9顯示了通常狀況下咱們須要30-50%多的資源來運行。上限來自於把大的task跑在一整臺機器上，這些task即便擴大四倍也沒辦法在原有Cell上壓縮跑。下限是容許這些task等待(pending)。(這比[37]裏面的數據要大100%，由於咱們支持超過4中尺寸並且容許CPU和內存無限擴張)。

5.5 資源再利用

一個job能夠聲明一個 限制資源 ，是每一個task能強制保證的資源上限。Borg會先檢查這個限制是否是在用戶的配額內，而後檢查具體的機器是否有那麼多資源來調度這個task。有的用戶會買超過他們須要的配額，也有用戶會的task實際須要更多的資源去跑，由於Borg會殺掉那些須要更多的內存和硬盤空間的task，或者卡住CPU使用率不上去。另外，一些task偶爾須要使用他們的全部資源(例如，在一天的高峯期或者受到了一個拒絕服務攻擊)，大多時候用不上那麼多資源。

比起把那些分出來但不用的資源浪費掉，咱們估計了一個task會用多少資源，而後把其餘的資源回收再利用給那些能夠忍受低質量資源的工做，例如批處理job。這整個過程被叫作資源再利用(resource reclamation)。這個估值叫作task自留地資源(reservation)，被Borgmaster每過幾秒就計算一次，是Borglet抓取的、細粒度資源消費用率。最初的自留地資源被設置的和 限制資源 同樣大；在300s以後，也就過了是啓動那個階段，自留地資源會緩慢的降低到實際用量加上一個安全值。自留地資源在實際用量超過它的時候會迅速上升。

Borg調度器(scheduler)使用 限制資源 來計算prod task的可用性($3.2)，因此這些task歷來不依賴於回收的資源，也不提供超售的資源；對於non-prod的task，使用了目前運行task的自留地資源，這麼新的task能夠被調度到回收資源。

一臺機器有可能由於自留地預估錯度而致使運行時資源不足 —— 即便全部的task都在 限制資源 以內跑。若是這種狀況發生了，咱們殺掉或者限制non-prod task，歷來不對prod task下手。

圖10展現了若是沒有資源再利用會須要更多的機器。在一箇中等大小的Cell上大概有20%的工做負載跑在回收資源上。

圖11能夠看到更多的細節，包括回收資源、實際使用資源和 限制資源 的比例。一個超內存限制的task首先會被從新調度，無論優先級有多高，因此這樣就不多有task會超過內存限制。另外一方面，CPU使用率是能夠輕易被卡住的，因此短時間的超過自留地資源的高峯時沒什麼損害的。

圖11暗示了資源再利用多是不必的保守：在自留地和實際使用中間有一大片差距。爲了測試這一點，咱們選擇了一個生產cell而後調試它的預估參數到一個激進策略上，把安全區劃小點，而後作了一個介於激進和基本之間的中庸策略跑，而後恢復到基本策略。

圖12展示告終果。第二週自留地資源和實際資源的差值是最小的，比第三週要小，最大的是第一和第四周。和預期的同樣，周2和周3的OOM率有一個輕微的提高。在複查了這個結果後，咱們以爲利大於弊，因而把中庸策略的參數放到其餘cell上部署運行。

6. 隔離性

50%的機器跑9個以上的task；最忙的10%的機器大概跑25個task，4500個線程[83]。雖然在應用間共享機器會增長使用率，也須要一個比較好的機制來保證task之間不互相沖突。包括安全和性能都不能互相沖突。

6.1 安全隔離

咱們使用Linux chroot監獄做爲同一臺機器不一樣task之間主要的安全隔離機制。爲了容許遠程debug，咱們之前會分發ssh key來自動給用戶權限去訪問跑他們task的機器，如今不這麼幹了。對大多數用戶來講，如今提供的是borgssh命令，這個程序和Borglet協同，來構建一個ssh shell，這個shell和task運行在一樣的chroot和cgroup下，這樣限制就更加嚴格了。

VM和安全沙箱技術被使用在外部的軟件上，在Google’s AppEngine (GAE) [38]和Google Compute Engine (GCE)環境下。咱們把KVM進程中的每一個hosted VM按照一個Borg task運行。

6.2 性能隔離

早期的Borglet使用了一種相對原始粗暴的資源隔離措施：過後檢查內存、硬盤、CPU使用率，而後終止使用過多內存和硬盤的task，或者把用太多CPU的激進task經過Linux CPU優先級降下來。不過，不少粗暴的task仍是很輕易的能影響同臺機器上其餘task的性能，而後不少用戶就會多申請資源來讓Borg減小調度的task數量，而後會致使系統資源利用率下降。資源回收能夠彌補一些損失，但不是所有，由於要保證資源安全紅線。在極端狀況下，用戶請求使用專用的機器或者cell。

目前，全部Borg task都跑在Linux cgroup-based資源容器[17,58,62]裏面，Borglet操做這些容器的設置，這樣就加強了控制由於操做系統內核在起做用。即便這樣，偶爾仍是有低級別的資源衝突(例如內存帶寬和L3緩存污染)仍是會發生，見[60,83]

爲了搞定超負荷和超請求，Borg task有一個應用階級(appclass)。最主要的區分在於延遲敏感latency-sensitive (LS)的應用和其餘應用的區別，其餘應用咱們在文章裏面叫batch。LS task是包括面向用戶的應用和須要快速響應的共享基礎設施。高優先級的LS task獲得最高有待，能夠爲了這個把batch task一次餓個幾秒種。

第二個區分在於可壓縮資源(例如CPU循環，disk I/O帶寬)都是速率性的能夠被回收的，對於一個task能夠下降這些資源的量而不去殺掉task；和不可壓縮資源(例如內存、硬盤空間)這些通常來講不殺掉task就無法回收的。若是一個機器用光了不可壓縮資源，Borglet立刻就會殺掉task，從低優先級開始殺，直到剩下的自留地資源夠用。若是機器用完了可壓縮資源，Borglet會卡住使用率這樣當短時間高峯來到時不用殺掉任何task。若是狀況沒有改善，Borgmaster會從這個機器上去除一個或多個task。

Borglet的用戶空間控制循環在將來預期的基礎上給prod task分配內存，在內存壓力基礎上給non-prod task分配內存；從內核事件來處理Out-of-Memory (OOM)；殺掉那些想獲取超過自身限制內存的task，或者在一個超負載的機器上實際超過負載時。Linux的積極文件緩存策略讓咱們的實現更負載一點，由於精確計算內存用量會麻煩不少。

爲了加強性能隔離，LS task能夠獨佔整個物理CPU核，不讓別的LS task來用他們。batch task能夠在任何核上面跑，不過他們只被分配了不多的和LS task共享的資源。Borglet動態的調整貪婪LS task的資源限制來保證他們不會把batch task餓上幾分鐘，有選擇的在須要時使用CFS帶寬控制[75]；光有共享是不行的，咱們有多個優先級。

就像Leverich [56]，咱們發現標準的Linux CPU調度(CFS)須要大幅調整來支持低延遲和高使用率。爲了減小調度延遲，咱們版本的CFS使用了額外的每cgroup歷史[16]，容許LS task驅逐batch task，而且避免多個LS task跑在一個CPU上的調度量子效應(scheduling quantum，譯者：或許指的是互相沖突？)。幸運的是，大多咱們的應用使用的每一個線程處理一個請求模型，這樣就緩和了持久負載不均衡。咱們節儉地使用cpusets來分配CPU核給有特殊延遲需求的應用。這些措施的一部分結果展示在圖13裏面。咱們持續在這方面投入，增長了線程部署和CPU管理包括NUMA超線程、能源覺察(例如[81])，增長Borglet的控制精確度。

Task被容許在他們的限制範圍內消費資源。其中大部分task甚至被容許去使用更多的可壓縮資源例如CPU，充分利用沒有被使用的資源。大概5%的LS task禁止這麼作，主要是爲了增長可預測性；小於1%的batch task也禁止。使用超量內存默認是被禁止的，由於這會增長task被殺的機率，不過即便這樣，10%的LS task打開了這個限制，79%的batch task也開了由於這事MapReduce框架默認的。這事對資源再回收($5.5)的一個補償。Batch task很樂意使用沒有被用起來的內存，也樂意不時的釋放一些可回收的內存：大多狀況下這跑的很好，即便有時候batch task會被急需資源的LS task殺掉。

7. 相關工做

資源調度在各個領域已經被研究了數十年了，包括在廣域HPC超算集羣中，在工做站網絡中，在大規模服務器集羣中。咱們主要聚焦在最相關的大規模服務器集羣這個領域。

最近的一些研究分析了集羣趨勢，來自於Yahoo、Google、和Facebook[20, 52, 63, 68, 70, 80, 82]，展示了這些現代的數據中心和工做負載在規模和異構化方面碰到的挑戰。[69]包含了這些集羣管理架構的分類。

Apache Mesos [45]把資源管理和應用部署作了分離，資源管理由中心管理器(相似於Bormaster+scheduler)和多種類的「框架」好比Hadoop [41]和Spark [73]，使用offer-based的機制。Borg則主要把這些幾種在一塊兒，使用request-based的機制，能夠大規模擴展。DRF [29, 35, 36, 66]策略是內賦在Mesos裏的；Borg則使用優先級和配額認證來替代。Mesos開發者已經宣佈了他們的雄心壯志：推測性資源分配和回收，而後把[69]裏面的問題都解決。

YARN [76]是一個Hadoop中心集羣管理。每一個應用都有一個管理器和中央資源管理器談判；這和2008年開始Google MapReduce從Borg獲取資源一模一樣。YARN的資源管理器最近才能容錯。一個相關的開源項目是Hadoop Capacity Scheduler [42]，提供了多租戶下的容量保證、多層隊列、彈性共享和公平調度。YARN最近被擴展成支持多種資源類型、優先級、驅逐、和高級權限控制[21]。俄羅斯方塊原型[40]支持了最大完工時間覺察的job打包。

Facebook的Tupperware [64]，是一個類Borg系統來調度cgroup容器；雖然只有少許資料泄露，看起來他也提供資源回收利用功能。Twitter有一個開源的Aurora[5]，一個類Borg的長進程調度器，跑在Mesos智商，有一個相似於Borg的配置語言和狀態機。

來自於微軟的Autopilot[48]提供了「自動化的軟件部署和開通；系統監控，以及在軟硬件故障時的修復操做」給微軟集羣。Borg生態系統提供了相同的特性，不過還有沒說完的；Isaard [48]歸納和不少咱們想擁護的最佳實踐。

Quincy[49]使用了一個網絡流模型來提供公平性和數據局部性在幾百個節點的DAG數據處理上。Borg用的是配額和優先級在上萬臺機器上把資源分配給用戶。Quincy處理直接執行圖在Borg之上。

Cosmos [44]聚焦在批處理上，重點在於用戶得到對集羣捐獻的資源進行公平獲取。它使用一個每job的管理器來獲取資源；沒有更多公開的細節。

微軟的Apollo系統[13]使用了一個每job的調度器給短時間存活的batch job使用，在和Borg差很少量級的集羣下獲取高流量輸出。Apollo使用了一個低優先級後臺任務隨機執行策略來增長資源利用率，代價是有多天的延遲。Apollo幾點提供一個預測矩陣，關於啓動時間爲兩個資源維度的函數。而後調度器會綜合計算啓動開銷、遠程數據獲取開銷來決定部署到哪裏，而後用一個隨機延時來避免衝突。Borg用的是中央調度器來決定部署位置，給予優先級分配處理更多的資源維度，並且更關注高可用、長期跑的應用；Apollo也許能夠處理更多的task請求併發。

阿里巴巴的Fuxi(譯者：也就是伏羲啦) [84]支撐數據分析的負載，從2009年開始運行。就像Borgmaster，一箇中央的FuxiMaster(也是作了高可用多副本)從節點上獲取可用的資源信息、接受應用的資源請求，而後作匹配。伏羲增長了和Borg徹底相反的調度策略：伏羲把最新的可用資源分配給隊列裏面請求的任務。就像Mesos，伏羲容許定義「虛擬資源」類型。只有系統的工做負載輸出是公開的。

Omega [69]支持多並行，特別是「鉛垂線」策略，粗略至關於Borgmaster加上它的持久存儲和link shards(鏈接分配)。Omega調度器用的是樂觀並行的方式去控制一個共享的cell觀察和預期狀態，把這些狀態放在一箇中央的存儲裏面，和Borglet用獨立的鏈接器進行同步。Omega架構。Omage架構是被設計出來給多種不一樣的工做負載，這些工做負載都有本身的應用定義的RPC接口、狀態機和調度策略(例如長期跑的服務端程序、多個框架下的batch job、存儲基礎設施、GCE上的虛擬機)。造成對比的是，Borg提供了一種「萬靈藥」，一樣的RPC接口、狀態機語義、調度策略，隨着時間流逝規模和複雜度增長，須要支持更多的不一樣方式的負載，而可可擴展性目前來講還不算一個問題($3.4)

Google的開源Kubernetes系統[53]把應用放在Docker容器內[28]，分發到多機器上。它能夠跑在物理機(和Borg同樣)或跑在其餘雲好比GCE提供的主機上。Kubernetes的開發者和Borg是同一撥人並且正在狂開發中。Google提供了一個雲主機版本叫Google Container Engine [39]。咱們會在下一節裏面討論從Borg中學到了哪些東西用在了Kubernetes上。

在高性能計算社區有一些這個領域的長期傳統工做(e.g., Maui, Moab, Platform LSF [2, 47, 50])；可是這和Google Cell所須要的規模、工做負載、容錯性是徹底不同的。大概來講，這些系統經過讓不少任務等待在一個長隊列裏面來獲取極高的資源利用率。

虛擬化提供商例如VMware [77]和數據中心方案提供商例如HP and IBM [46]給了一個大概在1000臺機器量級的集羣解決方案。另外，一些研究小組用幾種方式提高了資源調度質量(e.g., [25, 40, 72, 74])。

最後，就像咱們所指出的，大規模集羣管理的另一個重要部分是自動化和無人化。[43]寫了如何作故障計劃、多租戶、健康檢查、權限控制、和重啓動性來得到更大的機器數/操做員比。Borg的設計哲學也是這樣的，讓咱們的一個SRE能支撐超過萬臺機器。

8. 經驗教訓和將來工做

在這一節中咱們會聊一些十年以來咱們在生產環境操做Borg獲得的定性經驗，而後描述下這些觀察結果是怎麼改善Kubernete[53]的設計。

8.1 教訓

咱們會從一些受到吐槽的Borg特性開始，而後說說Kubernetes是怎麼幹的。

Jobs是惟一的task分組的機制。 Borg沒有自然的方法去管理多個job組成單個實體，或者去指向相關的服務實例(例如，金絲雀和生產跟蹤)。做爲hack，用戶把他們的服務拓撲編碼寫在job名字裏面，而後用更高層的工具區解析這些名字。這個問題的另一面是，沒辦法去指向服務的任意子集，這就致使了僵硬的語義，以致於沒法滾動升級和改變job的實例數。

爲了不這些困難，Kubernetes不用job這個概念，而是用標籤(label)來管理它的調度單位(pods)，標籤是任意的鍵值對，用戶能夠把標籤打在系統的全部對象上。這樣，對於一個Borg job，就能夠在pod上打上job:jobname這樣的標籤，其餘的有用的分組也能夠用標籤來表示，例如服務、層級、發佈類型(生產、測試、階段)。Kubernetes用標籤選擇這種方式來選取對象，完成操做。這樣就比固定的job分組更加靈活好用。

一臺機器只有一個IP把事情弄複雜了。 在Borg裏面，全部一臺機器上的task都使用同一個IP地址，而後共享端口空間。這就帶來幾個麻煩：Borg必須把端口當作資源來調度；task必須先聲明他們須要多少端口，而後瞭解啓動的時候哪些能夠用；Borglet必須完成端口隔離；命名和RPC系統必須和IP同樣處理端口。

很是感謝Linux namespace，虛擬機，IPv6和軟件定義網絡SDN。Kubernetes能夠用一種更用戶友好的方式來消解這些複雜性：全部pod和service均可以有一個本身的IP地址，容許開發者選擇端口而不是委託基礎設施來幫他們選擇，這些就消除了基礎設置管理端口的複雜性。

給資深用戶優化而忽略了初級用戶。 Borg提供了一大堆針對「資深用戶」的特性這樣他們能夠仔細的調試怎麼跑他們的程序(BCL有230個參數的選項)：開始的目的是爲了支持Google的大資源用戶，提高他們的效率會帶來更大的效益。可是很不幸的是這麼複雜的API讓初級用戶用起來很複雜，約束了他們的進步。咱們的解決方案是在Borg上又作了一些自動化的工具和服務，從實驗中來決定合理的配置。這就讓皮實的應用從實驗中得到了自由：即便自動化出了麻煩的問題也不會致使災難。

8.2 經驗

另外一方面，有很多Borg的設計是很是有益的，並且經歷了時間考驗。

Allocs是有用的。 Borg alloc抽象導出了普遍使用的logsaver樣式($2.4)和另外一個流行樣式：按期數據載入更新的web server。Allocs和packages容許這些輔助服務能被一個獨立的小組開發。Kubernetes相對於alloc的設計是pod，是一個多個容器共享的資源封裝，老是被調度到同一臺機器上。Kubernetes用pod裏面的輔助容器來替代alloc裏面的task，不過思想是同樣的。

集羣管理比task管理要作更多的事。 雖然Borg的主要角色是管理tasks和機器的生命週期，但Borg上的應用仍是從其餘的集羣服務中收益良多，例如命名和負載均衡。Kubernetes用service抽象來支持命名和負載均衡：service有一個名字，用標籤選擇器來選擇多個pod。在底下，Kubernetes自動的在這個service所擁有的pod之間自動負載均衡，而後在pod掛掉後被從新調度到其餘機器上的時候也保持跟蹤來作負載均衡。

反觀自省是相當重要的。 雖然Borg基本上是「just works」的，但當有出了問題後，找到這個問題的根源是很是有挑戰性的。一個關鍵設計抉擇是Borg把全部的debug信息暴露給用戶而不是隱藏：Borg有幾千個用戶，因此「自助」是debug的第一步。雖然這會讓咱們很難拋棄一些用戶依賴的內部策略，但這仍是成功的，並且咱們沒有找到其餘現實的替代方式。爲了管理這麼巨量的資源，咱們提供了幾層UI和debug工具，這樣就能夠升入研究基礎設施自己和應用的錯誤日誌和事件細節。

Kubernetes也但願重現不少Borg的自探查技術。例如它和cAdvisor [15] 一切髮型用於資源監控，用Elasticsearch/Kibana [30] 和 Fluentd [32]來作日誌聚合。從master能夠獲取一個對象的狀態快照。Kubernetes有一個一致的全部組件都能用的事件記錄機制(例如pod被調度、容器掛了)，這樣客戶端就能訪問。

master是分佈式系統的核心. Borgmaster原來被設計成一個單一的系統，可是後來，它變成了服務生態和用戶job的核心。比方說，咱們把調度器和主UI(Sigma)分離出來成爲單獨的進程，而後增長了權限控制、縱向橫向擴展、重打包task、週期性job提交(cron)、工做流管理，系統操做存檔用於離線查詢。最後，這些讓咱們可以提高工做負載和特性集，而無需犧牲性能和可維護性。

Kubernetes的架構走的更遠一些：它有一個API服務在覈心，僅僅負責處理請求和維護底下的對象的狀態。集羣管理邏輯作成了一個小的、微服務類型的客戶端程序和API服務通訊，其中的副本管理器(replication controller)，維護在故障狀況下pod的服務數量，還有節點管理器(node controller)，管理機器生命週期。

8.3 總結

在過去十年間全部幾乎全部的Google集羣負載都移到了Borg上。咱們將會持續改進，並把學到的東西應用到Kubernetes上。

鳴謝

這篇文章的做者同時也評審了這篇文章。可是幾十個設計、實現、維護Borg組件和生態系統工程師纔是這個系統成功的關鍵。咱們在這裏列表設計、實現、操做Borgmaster和Borglet的主要人員。若有遺漏抱歉。

Borgmaster主設計師和實現者有Jeremy Dion和Mark Vandevoorde，還有Ben Smith, Ken Ashcraft, Maricia Scott, Ming-Yee Iu, Monika Henzinger。Borglet的主要設計實現者是Paul Menage。

其餘貢獻者包括Abhishek Rai, Abhishek Verma, Andy Zheng, Ashwin Kumar, Beng-Hong Lim, Bin Zhang, Bolu Szewczyk, Brian Budge, Brian Grant, Brian Wickman, Chengdu Huang, Cynthia Wong, Daniel Smith, Dave Bort, David Oppenheimer, David Wall, Dawn Chen, Eric Haugen, Eric Tune, Ethan Solomita, Gaurav Dhiman, Geeta Chaudhry, Greg Roelofs, Grzegorz Czajkowski, James Eady, Jarek Kusmierek, Jaroslaw Przybylowicz, Jason Hickey, Javier Kohen, Jeremy Lau, Jerzy Szczepkowski, John Wilkes, Jonathan Wilson, Joso Eterovic, Jutta Degener, Kai Backman, Kamil Yurtsever, Kenji Kaneda, Kevan Miller, Kurt Steinkraus, Leo Landa, Liza Fireman, Madhukar Korupolu, Mark Logan, Markus Gutschke, Matt Sparks, Maya Haridasan, Michael Abd-El-Malek, Michael Kenniston, Mukesh Kumar, Nate Calvin, OnufryWojtaszczyk, Patrick Johnson, Pedro Valenzuela, PiotrWitusowski, Praveen Kallakuri, Rafal Sokolowski, Richard Gooch, Rishi Gosalia, Rob Radez, Robert Hagmann, Robert Jardine, Robert Kennedy, Rohit Jnagal, Roy Bryant, Rune Dahl, Scott Garriss, Scott Johnson, Sean Howarth, Sheena Madan, Smeeta Jalan, Stan Chesnutt, Temo Arobelidze, Tim Hockin, Todd Wang, Tomasz Blaszczyk, TomaszWozniak, Tomek Zielonka, Victor Marmol, Vish Kannan, Vrigo Gokhale, Walfredo Cirne, Walt Drummond, Weiran Liu, Xiaopan Zhang, Xiao Zhang, Ye Zhao, Zohaib Maya. 

Borg SRE團隊也是很是重要的，包括Adam Rogoyski, Alex Milivojevic, Anil Das, Cody Smith, Cooper Bethea, Folke Behrens, Matt Liggett, James Sanford, John Millikin, Matt Brown, Miki Habryn, Peter Dahl, Robert van Gent, Seppi Wilhelmi, Seth Hettich, Torsten Marek, and Viraj Alankar。Borg配置語言(BCL)和borgcfg工具是Marcel van Lohuizen, Robert Griesemer製做的。 

謝謝咱們的審稿人(尤爲是Eric Brewer, Malte Schwarzkopf and Tom Rodeheffer)，以及咱們的牧師Christos Kozyrakis，對這篇論文的反饋。

參考文獻

[1] O. A. Abdul-Rahman and K. Aida. Towards understanding the usage behavior of Google cloud users: the mice and elephants phenomenon. In Proc. IEEE Int’l Conf. on Cloud Computing Technology and Science (CloudCom), pages 272–277, Singapore, Dec. 2014.

[2] Adaptive Computing Enterprises Inc., Provo, UT. MauiScheduler Administrator’s Guide, 3.2 edition, 2011.

[3] T. Akidau, A. Balikov, K. Bekiro˘glu, S. Chernyak, J. Haberman, R. Lax, S. McVeety, D. Mills, P. Nordstrom,and S. Whittle. MillWheel: fault-tolerant stream processing at internet scale. In Proc. Int’l Conf. on Very Large Data Bases (VLDB), pages 734–746, Riva del Garda, Italy, Aug.2013.

[4] Y. Amir, B. Awerbuch, A. Barak, R. S. Borgstrom, and A. Keren. An opportunity cost approach for job assignment in a scalable computing cluster. IEEE Trans. Parallel Distrib.Syst., 11(7):760–768, July 2000.

[5] Apache Aurora. http://aurora.incubator.apache.org/ , 2014.

[6] Aurora Configuration Tutorial.  https://aurora.incubator.apach ... rial/ ,2014.

[7] AWS. Amazon Web Services VM Instances.  http://aws.amazon.com/ec2/instance-types/ , 2014.

[8] J. Baker, C. Bond, J. Corbett, J. Furman, A. Khorlin, J. Larson, J.-M. Leon, Y. Li, A. Lloyd, and V. Yushprakh. Megastore: Providing scalable, highly available storage for interactive services. In Proc. Conference on Innovative Data Systems Research (CIDR), pages 223–234, Asilomar, CA, USA, Jan. 2011.

[9] M. Baker and J. Ousterhout. Availability in the Sprite distributed file system. Operating Systems Review,25(2):95–98, Apr. 1991.

[10] L. A. Barroso, J. Clidaras, and U. H¨olzle. The datacenter as a computer: an introduction to the design of warehouse-scale machines. Morgan Claypool Publishers, 2nd edition, 2013.

[11] L. A. Barroso, J. Dean, and U. Holzle. Web search for a planet: the Google cluster architecture. In IEEE Micro, pages 22–28, 2003.

[12] I. Bokharouss. GCL Viewer: a study in improving the understanding of GCL programs. Technical report, Eindhoven Univ. of Technology, 2008. MS thesis.

[13] E. Boutin, J. Ekanayake, W. Lin, B. Shi, J. Zhou, Z. Qian, M. Wu, and L. Zhou. Apollo: scalable and coordinated scheduling for cloud-scale computing. In Proc. USENIX Symp. on Operating Systems Design and Implementation (OSDI), Oct. 2014.

[14] M. Burrows. The Chubby lock service for loosely-coupled distributed systems. In Proc. USENIX Symp. on Operating Systems Design and Implementation (OSDI), pages 335–350,Seattle, WA, USA, 2006.

[15] cAdvisor.  https://github.com/google/cadvisor , 2014

[16] CFS per-entity load patches.  http://lwn.net/Articles/531853 , 2013.

[17] cgroups.  http://en.wikipedia.org/wiki/Cgroups , 2014.

[18] C. Chambers, A. Raniwala, F. Perry, S. Adams, R. R. Henry, R. Bradshaw, and N. Weizenbaum. FlumeJava: easy, efficient data-parallel pipelines. In Proc. ACM SIGPLAN Conf. on Programming Language Design and Implementation (PLDI), pages 363–375, Toronto, Ontario, Canada, 2010.

[19] F. Chang, J. Dean, S. Ghemawat, W. C. Hsieh, D. A. Wallach, M. Burrows, T. Chandra, A. Fikes, and R. E. Gruber. Bigtable: a distributed storage system for structured data. ACM Trans. on Computer Systems, 26(2):4:1–4:26, June 2008.

[20] Y. Chen, S. Alspaugh, and R. H. Katz. Design insights for MapReduce from diverse production workloads. Technical Report UCB/EECS–2012–17, UC Berkeley, Jan. 2012.

[21] C. Curino, D. E. Difallah, C. Douglas, S. Krishnan, R. Ramakrishnan, and S. Rao. Reservation-based scheduling: if you’re late don’t blame us! In Proc. ACM Symp. on Cloud Computing (SoCC), pages 2:1–2:14, Seattle, WA, USA, 2014.

[22] J. Dean and L. A. Barroso. The tail at scale. Communications of the ACM, 56(2):74–80, Feb. 2012.

[23] J. Dean and S. Ghemawat. MapReduce: simplified data processing on large clusters. Communications of the ACM, 51(1):107–113, 2008.

[24] C. Delimitrou and C. Kozyrakis. Paragon: QoS-aware scheduling for heterogeneous datacenters. In Proc. Int’l Conf. on Architectural Support for Programming Languages and Operating Systems (ASPLOS), Mar. 201.

[25] C. Delimitrou and C. Kozyrakis. Quasar: resource-efficient and QoS-aware cluster management. In Proc. Int’l Conf. on Architectural Support for Programming Languages and Operating Systems (ASPLOS), pages 127–144, Salt Lake City, UT, USA, 2014.

[26] S. Di, D. Kondo, and W. Cirne. Characterization and comparison of cloud versus Grid workloads. In International Conference on Cluster Computing (IEEE CLUSTER), pages 230–238, Beijing, China, Sept. 2012.

[27] S. Di, D. Kondo, and C. Franck. Characterizing cloud applications on a Google data center. In Proc. Int’l Conf. on Parallel Processing (ICPP), Lyon, France, Oct. 2013.

[28] Docker Project.  https://www.docker.io/ , 2014.

[29] D. Dolev, D. G. Feitelson, J. Y. Halpern, R. Kupferman, and N. Linial. No justified complaints: on fair sharing of multiple resources. In Proc. Innovations in Theoretical Computer Science (ITCS), pages 68–75, Cambridge, MA, USA, 2012.

[30] ElasticSearch.  http://www.elasticsearch.org , 2014.

[31] D. G. Feitelson. Workload Modeling for Computer Systems Performance Evaluation. Cambridge University Press, 2014.

[32] Fluentd.  http://www.fluentd.org/ , 2014.

[33] GCE. Google Compute Engine. http: //cloud.google.com/products/compute-engine/, 2014.

[34] S. Ghemawat, H. Gobioff, and S.-T. Leung. The Google File System. In Proc. ACM Symp. on Operating Systems Principles (SOSP), pages 29–43, Bolton Landing, NY, USA, 2003. ACM.

[35] A. Ghodsi, M. Zaharia, B. Hindman, A. Konwinski, S. Shenker, and I. Stoica. Dominant Resource Fairness: fair allocation of multiple resource types. In Proc. USENIX Symp. on Networked Systems Design and Implementation (NSDI), pages 323–326, 2011.

[36] A. Ghodsi, M. Zaharia, S. Shenker, and I. Stoica. Choosy: max-min fair sharing for datacenter jobs with constraints. In Proc. European Conf. on Computer Systems (EuroSys), pages 365–378, Prague, Czech Republic, 2013.

[37] D. Gmach, J. Rolia, and L. Cherkasova. Selling T-shirts and time shares in the cloud. In Proc. IEEE/ACM Int’l Symp. on Cluster, Cloud and Grid Computing (CCGrid), pages 539–546, Ottawa, Canada, 2012.

[38] Google App Engine.  http://cloud.google.com/AppEngine , 2014.

[39] Google Container Engine (GKE).  https://cloud.google.com/container-engine/ , 2015.

[40] R. Grandl, G. Ananthanarayanan, S. Kandula, S. Rao, and A. Akella. Multi-resource packing for cluster schedulers. In Proc. ACM SIGCOMM, Aug. 2014.

[41] Apache Hadoop Project.  http://hadoop.apache.org/ , 2009.

[42] Hadoop MapReduce Next Generation – Capacity Scheduler. http: //hadoop.apache.org/docs/r2.2.0/hadoop-yarn/ hadoop-yarn-site/CapacityScheduler.html, 2013.

[43] J. Hamilton. On designing and deploying internet-scale services. In Proc. Large Installation System Administration Conf. (LISA), pages 231–242, Dallas, TX, USA, Nov. 2007.

[44] P. Helland. Cosmos: big data and big challenges.  http://research.microsoft.com/en-us/events/ fs2011/helland_cosmos_big_data_and_big\ _challenges.pdf, 2011.

[45] B. Hindman, A. Konwinski, M. Zaharia, A. Ghodsi, A. Joseph, R. Katz, S. Shenker, and I. Stoica. Mesos: a platform for fine-grained resource sharing in the data center. In Proc. USENIX Symp. on Networked Systems Design and Implementation (NSDI), 2011.

[46] IBM Platform Computing.  http://www-03.ibm.com/ systems/technicalcomputing/platformcomputing/ products/clustermanager/index.html.

[47] S. Iqbal, R. Gupta, and Y.-C. Fang. Planning considerations for job scheduling in HPC clusters. Dell Power Solutions, Feb. 2005.

[48] M. Isaard. Autopilot: Automatic data center management. ACM SIGOPS Operating Systems Review, 41(2), 2007.

[49] M. Isard, V. Prabhakaran, J. Currey, U. Wieder, K. Talwar, and A. Goldberg. Quincy: fair scheduling for distributed computing clusters. In Proc. ACM Symp. on Operating Systems Principles (SOSP), 2009.

[50] D. B. Jackson, Q. Snell, and M. J. Clement. Core algorithms of the Maui scheduler. In Proc. Int’l Workshop on Job Scheduling Strategies for Parallel Processing, pages 87–102. Springer-Verlag, 2001.

[51] M. Kambadur, T. Moseley, R. Hank, and M. A. Kim. Measuring interference between live datacenter applications. In Proc. Int’l Conf. for High Performance Computing, Networking, Storage and Analysis (SC), Salt Lake City, UT, Nov. 2012.

[52] S. Kavulya, J. Tan, R. Gandhi, and P. Narasimhan. An analysis of traces from a production MapReduce cluster. In Proc. IEEE/ACM Int’l Symp. on Cluster, Cloud and Grid Computing (CCGrid), pages 94–103, 2010.

[53] Kubernetes.  http://kubernetes.io , Aug. 2014.

[54] Kernel Based Virtual Machine.  http://www.linux-kvm.org.

[55] L. Lamport. The part-time parliament. ACM