Kubernetes的前世Borg系統(二)

Kubernetes前世Borg③

1.Kubernetes的前世此生

2.Kubernetes的前世Borg系統(一)

5 高效利用

Borg的主要目標之一是高效利用Google的機器，這意味着巨大的財務投資：將利用率提升幾個百分點能夠節省數百萬美圓。本節討論和評估Borg使用的一些策略和技術。

圖5：將prod和non-prod工做分離到不一樣的單元將須要更多的機器。

這兩個圖表顯示若是prod和non-prod工做負載發送到單獨的單元，須要多少額外的機器，使用百分比表示在一個單元中運行工做負載所需的最小機器數量。在當前和隨後的CDF圖中，每一個單元顯示的值推導自咱們的實驗嘗試產生的不一樣cell大小的90％，偏差條顯示了嘗試值的完整範圍。

5.1 評估方法

咱們的工做存在佈局限制，須要處理稀少的工做負載峯值，機器是異構的，在從服務做業中回收的資源中運行批處理做業。因此，爲了評估策略選擇，須要一個比「平均利用率」更復雜的度量標準。通過屢次實驗，咱們選擇了cell compaction：給定一個工做負載，經過刪除cell中的機器直到再也不適應，能夠發現它能適應的cell有多小，，從頭開始從新包裝工做負載以確保沒有掛在一個糟糕的配置。這提供了乾淨的最終條件，促進了自動化比較（沒有合成工做生成和建模的陷阱 [31]）。評價技術的定量比較能夠在[78]中找到：細節是使人驚訝的微妙。

不可能對真實生產單元進行實驗，但可使用Fauxmaster得到高保真的模擬結果，使用來自實際生產單元和工做負載的數據，包括其全部約束、實際限制、保留和使用數據（§5.5 ）。這些數據來自2014-10-01 14：00 PDT的Borg檢查點。（其餘檢查點產生了相似結果）。選擇15個Borgcell進行報告，首先消除特殊用途、測試和小（<5000臺機器）cell，而後對剩餘的cell進行取樣，以得到大小均勻的範圍。

爲了在壓縮的cell中維持機器異構性，隨機選擇機器進行刪除。爲了保持工做負載的異構性，保留除了與特定機器（例如，Borglets）綁定的服務器和存儲任務外的一切。爲大於原cell大小一半的做業更改硬約束爲軟約束，並容許多達0.2％的任務等待，若是他們很是「挑剔」並只能放置在少數幾臺機器上; 普遍的實驗代表，這產生了低方差的可重複結果。若是咱們須要比原cell更大的cell，能夠在壓縮以前克隆原始cell幾回; 若是咱們須要更多cell，只須要克隆原來的cell便可。

圖6：分離用戶將須要更多的機器。

若是用戶多於所示的閾值，針對5個不一樣的cell，給出了各私有單元的 Cell總數和須要的額外機器。對於具備不一樣隨機數種子的每一個cell，每一個實驗重複11次。在圖表中，咱們使用錯誤欄顯示所需機器數量的最小值和最大值，並選擇90％ile值做爲「結果」-平均值或中位數並不反映系統管理員若是但願合理地確保工做負載適合時將作什麼。咱們認爲cell壓縮提供了一種公平、一致的方法來比較調度策略，它直接轉化爲成本/效益結果：更好的策略須要更少的機器來運行相同的工做負載。

咱們的實驗集中在從一個時間點調度（打包）工做負載，而不是重放長期工做負載跟蹤。這部分是爲了不應對開放和封閉排隊模型的困難[71,79]，部分緣由是傳統的完成時間指標不適用於長期運行服務的環境，部分是爲了提供清晰的信號進行比較，部分是由於咱們不相信結果會有明顯的不一樣，部分是一個實際問題：咱們發現本身消耗了200000個Borg CPU核用於實驗 - 即便按谷歌的規模，這也是一個非平凡的投資。

在產品中，針對工做負載的增加留出有效的空間，偶然的「black swan」事件，負載高峯，機器故障，硬件更新，以及大規模局部故障（e.g., a power supply bus duct）。圖4顯示了若是應用了cell壓縮，真實的cell有多小。圖中跟隨的基線使用了壓縮的大小。

圖7：將cell細分紅更小的cell將須要更多的機器。

若是將這些特定cell劃分爲不一樣數量的較小cell，則須要額外的機器（做爲單個cell狀況的百分比）。

5.2 cell共享

幾乎全部機器同時運行着prod 和 non-prod任務：在共享的Borg cell中98%的機器，有83%跨越Borg管理的整個的機器集合。（有一些特殊用途的專用cell）。

因爲不少其它組織在單獨的集羣中運行面向用戶或批量做業，咱們對若是咱們也這樣作會發生什麼作了調查。圖5顯示了分離開proc和non-proc工做，在中值的cell中將須要20-30%的更多的機器來運行工做負載。這是由於proc做業老是會預留資源來處理稀有的負載高峯，但大部分時間並不使用這些資源。Borg回收利用這些未使用的資源來運行大部分non-proc工做，這樣整體上就須要更少的機器了。

大部分Borg cell被數以千計的用戶共享。圖6顯示了緣由。對這個測試，若是用戶的工做負載消耗了至少10TiB（或者100 TiB）的內存，就分離用戶的工做負載到一個新的cell。現存的策略看起來是好的：即便是更大的極限，將須要2–16×做爲一些cell，以及20–150%的額外的機器。再次，合併資源顯著減小了成本。

可是可能將不相關的用戶和做業類型打包到同一臺機器上會致使CPU干擾，所以須要更多的機器來彌補？爲了評估這一點，咱們研究了在具備相同時鐘速度的相同機器類型上運行的不一樣環境中的任務的CPI（每一個指令的週期數）如何改變。在這些條件下，CPI值是可比的，而且能夠用做針對性能干擾的代理，由於CPI的翻倍加倍了CPU綁定程序的運行時間。在一個星期內從約12000個隨機選擇的prod任務收集數據，使用[83]中描述的硬件配置架構，在5分鐘的間隔內對週期和指令進行計數，並對樣本進行加權，使得每秒鐘的CPU時間被公平計數。結果並不清晰。

（1）咱們發現CPI與在相同時間間隔內的兩個測量結果正相關：機器上的整體CPU使用率，（很大程度上獨立地）機器上的任務數量; 向機器添加任務使得其餘任務的CPI提升0.3％（使用適合這些數據的線性模型）; 將機器CPU使用率提升10％使得CPI提升小於2％。可是即便相關性在統計上是重要的，也只顯示了在CPI測量中看到的方差的5％; 其餘因素占主導地位，例如應用的固有差別和特定的干擾模式[24,83]。

（2）將咱們從共享cell中採樣的CPI與來自具備較少不一樣應用的幾個專用cell的CPI進行比較，咱們看到共享cell的平均CPI爲1.58（σ= 0.35），專用cell的平均CPI爲1.53（σ= 0.32）- 即，CPU在共享cell中性能下降約3％。

（3）爲了解決不一樣cell中的應用可能具備不一樣工做負載或還遇到選擇誤差（可能將干擾更敏感的程序已經移動到專用cell）的擔心，考察了Borglet的CPI，它在兩種類型的全部機器上運行。它在專用cell中的CPI爲1.20（σ= 0.29），在共享cell中的CPI爲1.43（σ= 0.45），代表它在專用cell中的運行速度爲1.19倍，與在共享單元中同樣快，雖然這加劇了輕負載機器的影響，但輕微誤差結果有利於專用cell。

圖8：沒有適合大多數任務的桶大小。

請求的CPU和內存的CDF要求跨越樣本單元。沒有一個值突出，雖然幾個整數CPU核大小有點更受歡迎。

圖9：「Bucketing」資源需求將須要更多的機器。

將15個單元中的CPU和存儲器請求四捨五入爲下一個最接近2的冪所產生的額外開銷的CDF。下限和上限跨越實際值（見文本）。

這些實驗證明，倉庫規模的性能比較是棘手的，在[51]中增強了觀察，而且還代表共享不會大大增長運行程序的成本。

但即便假設最不利的結果，共享仍然是一個勝利：CPU減速超過了幾種不一樣劃分方案所需機器的減小，共享優勢適用於全部資源，包括內存和磁盤，而不只僅是CPU 。

5.3 大細胞

Google構建了大cell，以容許運行大型計算，並減小資源碎片。經過將cell的工做負載分到多個較小的cell來測試後者的效果 - 首先隨機排列做業，而後在分區之間以循環方式分配做業。圖7證明使用較小cell將明顯須要更多的機器。

圖10：資源回收是至關有效的。

若是禁用15個表明性cell，則須要額外機器的CDF。

圖11：資源估計在識別未使用的資源方面是成功的。

虛線顯示了15個cell中的任務請求（極限）的CPU和內存使用率的CDF。大多數任務使用遠遠低於其極限，雖然少數比請求的使用了更多的CPU。實線顯示出了CPU和內存保留限制率的CDF; 這些都更接近100％。直線是資源估計處理的僞像。

5.4 細粒度資源請求

Borg用戶請求CPU以milli-cores爲單位，內存和磁盤空間以字節爲單位。（core是處理器超線程，針對機器類型的性能進行標準化）。圖8顯示了利用這種粒度：在所請求的內存或CPU核的數量上幾乎沒有明顯的「sweet spots」，而且這些資源之間幾乎沒有明顯的相關性。除了在90％及以上的內存請求稍大以外，這些分佈與[68]中提出的分佈很是類似。

提供一組固定大小的容器或虛擬機雖然在IaaS（基礎設施即服務）提供商[7,33]中很常見，但不能很好地知足咱們的需求。爲了說明這一點，經過在每一個資源維度上將它們四捨五入到下一個最接近的2的冪，從CPU的0.5內核和RAM的1GiB開始，對prod做業和分配（§2.4）「bucketed」CPU核和內存資源限制。圖9顯示這樣作將須要比平均狀況下多30-50％的資源。上限來自於將整個機器分配給大型任務（在壓縮前將原始細胞翻兩番後不適合）; 下限來自於容許這些任務進入待定狀態。（這小於[37]中報告的大約100％的開銷，由於咱們支持超過4個buckets，並容許CPU和RAM容量獨立擴展。）

圖12：更積極的資源估計能夠回收更多的資源，對內存不足事件（OOM）幾乎沒有影響。

一個生產cell使用的時間線（從2013-11-11開始），5分鐘窗口平均的預留和限制以及累積的內存不足事件; 後者的斜率是OOM的總速率。豎欄使用不一樣的資源估計設置按周分開。

5.5 資源回收

做業能夠指定資源限制 - 每一個任務應被授予的資源的上限。 Borg使用該限制來肯定用戶是否有足夠的配額來接受做業，並肯定特定機器是否有足夠的免費資源來安排任務。正若有用戶購買比所須要的更多的配額，有用戶請求比任務將使用的更多的資源，由於Borg一般會殺死一個試圖使用比它須要的更多的RAM或磁盤空間的任務，或節流CPU到任務所要求的。此外，某些任務偶爾須要使用其全部資源（例如，在一天的高峯時間或在應對拒絕服務***時），但大多數時間不會。

不是浪費當前未被消耗的已分配資源，而是估計任務將使用多少資源，並回收能夠容忍低質量資源（例如批處理做業）的工做的剩餘資源。這整個過程稱爲資源回收。該估計稱爲任務的預留，而且由Borgmaster每幾秒鐘使用由Borglet捕獲的細粒度使用（資源消耗）信息來計算。初始預留被設置爲等於資源請求（限制）;在300s後，爲了容許瞬間啓動，緩慢向實際使用加上安全餘量衰減。若是使用超過，預訂會迅速增長。

Borg調度程序使用極限來計算prod任務的可行性（§3.2），所以調度程序從不依賴於已回收的資源，也沒有暴露給資源超額訂閱; 對於non-proc任務，使用現有任務的預留，以便將新任務安排到已回收的資源中。

機器在運行時可能會耗盡資源，若是這個保留（預測）是錯誤的 - 即便全部任務使用的資源小於其極限。若是發生這種狀況，殺死或限制non-proc任務（永不處理proc任務）。

圖13：調度延遲做爲負載的函數。

描繪了一個可運行的線程必須等待多於1ms的時間來訪問CPU的頻率，並做爲機器有多忙的函數。在每對豎欄中，延遲敏感的任務在左側，批處理任務在右側。僅在幾個時間的百分比中，線程必須等待超過5ms才能訪問CPU（白色欄）;其它幾乎沒必要等待更長的時間（更黑的欄）。來自從 2013年12月以來表明性單元格的數據；錯誤欄顯示每日差別。

圖10顯示了更多的機器無需資源回收。大約20％的工做負載（§6.2）在中值cell的回收資源中運行。

能夠在圖11中看到更多細節，其中顯示了預留和使用限制的比率。若是須要資源，超過其內存限制的任務將首先被搶佔，而無論其優先級如何，所以任務超過其內存限制是不多見的。另外一方面，CPU能夠容易地被節流，所以短時間峯值能夠至關無害地推進使用高於預留（push usage above reservation fairlyharmlessly）。

圖11代表資源回收多是無必要保守的：在預留和使用線之間存在明顯的區域。爲了測試這一點，選擇了一個活的生產cell，並經過減小安全邊界，在第一週調整資源估計算法的參數到一個積極的設置，而後在下一週調整到基線和積極設置之間的中間設置，而後恢復到基線。圖12顯示發生了什麼。在第二週保留明顯更接近使用，第三週稍差，基準周（第一和第四周）顯示了最大差距。如預期的那樣，內存（OOM）事件的發生率在第2周和第3周輕微增長。在評估結果後，咱們決定淨收益超過了消極面，並將中等資源回收參數部署到其餘 cell。

6 隔離

50％的機器運行9個或更多的任務; 一個90%ile的機器大約有25個任務，將運行大約4500個線程[83]。雖然在應用之間共享機器增長了利用率，但還須要良好的機制來防止任務彼此干擾。這都適用於安全性和性能。

6.1 安全隔離

使用Linux chroot jail做爲同一臺機器上多個任務之間的主要安全隔離機制。爲了容許遠程調試，經過使用自動分發（和撤銷）ssh密鑰，使得用戶只有當機器在爲該用戶運行任務時才能訪問該機器。對於大多數用戶，這已被替換爲borgssh命令，它與Borglet協做構建一個ssh鏈接到一個shell，該shell在與任務相同的chroot和cgroup中運行，從而更緊密地鎖定訪問。

VM和安全沙盒技術用於經過Google的AppEngine（GAE）[38]和Google Compute Engine（GCE）運行外部軟件。在做爲Borg任務運行的KVM進程[54]中運行每一個託管的VM。

6.2 性能隔離

Borglet的早期版本具備相對原始的資源隔離實施：內存，磁盤空間和CPU週期的過後使用檢查，結合使用過多內存或磁盤的任務，以及積極應用Linux的CPU優先級來控制使用太多CPU的任務。可是欺騙任務對機器上其餘任務的性能影響仍然太容易，所以一些用戶膨脹了他們的資源請求，以減小Borg能夠與他們共同調度的任務數量，這下降了利用率。資源回收能夠收回一些剩餘的，但不是全部，由於涉及安全邊際。在最極端的狀況下，用戶請求使用專用機器或cell。

如今，全部Borg任務都在基於Linux cgroup的資源容器中運行[17,58,62]，Borglet操做容器設置，提供更好的控制(由於操做系統內核在循環中)。即便如此，偶爾的低級資源干擾（例如，存儲器帶寬或L3高速緩存污染）仍然發生，如在[60,83]中。

爲了幫助過載和過量使用，Borg任務有一個應用類或appclass。最重要的區別存在於延遲敏感（LS）應用類和其他的應用類（在本文中稱爲批處理）中。LS任務用於面向用戶的應用程序和須要快速響應請求的共享基礎結構服務。高優先級LS任務獲得最佳處理，而且可以一次暫時使批量任務捱餓幾秒鐘。

二次分割存在於可壓縮資源（例如，CPU週期，磁盤I / O帶寬）和不可壓縮資源（例如，存儲器，磁盤空間）中，可壓縮資源是基於速率的而且能夠經過在不殺死它的狀況降低低其服務質量而從任務中回收；不可壓縮資源一般不能在不殺死任務的狀況下被回收。若是機器耗盡了不可壓縮資源，則Borglet當即終止任務，從最低優先級到最高優先級，直到能夠知足剩餘保留爲止。若是機器耗盡了可壓縮資源，Borglet會限制使用（有利於LS任務），使得能夠處理短負載高峯而不殺死任何任務。若是狀況沒有改善，Borgmaster將從機器中刪除一個或多個任務。

Borglet中的用戶空間控制循環基於預測的將來使用狀況（針對prod任務）或內存壓力（針對非prod的狀況）給容器分配內存；處理來自內核的Out-of-Memory（OOM）事件; 而且當嘗試分配超出其內存限制時，或者當過分提交的機器實際上耗盡內存時，殺死任務。 Linux的渴望文件緩存因爲須要準確的內存覈算，顯着地使實現複雜化。

爲了提升性能隔離，LS任務能夠保留整個物理CPU核，從而阻止其餘LS任務使用。批處理任務容許在任何核上運行，但被賦予相對於LS任務的小調度程序共享。Borglet動態調整貪婪LS任務的資源上限，以確保不會使批處理任務捱餓多分鐘，在須要時選擇性地應用CFS帶寬控制[75]；共享是不足的，由於咱們有多個優先級。

像Leverich [56]，咱們發現標準的Linux CPU調度器（CFS）須要大量調整，以支持低延遲和高利用率。爲了減小調度， CFS版本使用擴展的每一個羣組的負載歷史[16]，容許由LS任務搶佔批任務，而且當多個LS任務在一個CPU上是可運行時減小調度量。幸運的是，許多應用程序使用線程請求模型，這減輕了持續負載不平衡的影響。謹慎使用cpusets將CPU核分配給具備特別緊迫延遲要求的應用程序。這些努力的一些結果如圖13所示。這一領域的工做繼續，添加線程佈局和CPU管理，即NUMA-，超線程和功率感知（例如，[81]），並提升Borglet的控制保真度。

容許任務使用達到其限制的資源。大多數被容許超過用於諸如CPU的可壓縮資源，以利用未使用（鬆弛）資源。只有5％的LS任務禁用此功能，可能得到更好的可預測性; 少於1％的批量任務使用此功能。默認狀況下，禁止使用閒置內存，由於這增長了任務被終止的機會，但即便如此，10％的LS任務會覆蓋此功能，並且79％的批處理任務這樣作，由於這是MapReduce框架的默認設置。這補充了回收資源的結果（§5.5）。批處理任務會隨機利用未使用的以及回收的內存：大多數時間這是可行的，雖然偶爾當一個LS任務急需資源時，批處理任務會被犧牲。

7 相關工做

已經研究了幾十年的資源調度，在不一樣的上下文中，如廣域HPC超級計算網格，工做站網絡和大規模服務器集羣。在這裏只關注大型服務器集羣環境中最有意義的工做。

最近的一些研究分析了來自Yahoo!，Google和Facebook的集羣跟蹤[20,52,63,68,70,80,82]，並說明了這些現代數據中心和工做負載中固有的規模和異構性的挑戰。 [69]包含集羣管理器架構的分類。

Apache Mesos [45]使用基於供應的機制在中央資源管理器（有點像Borgmaster減去其調度程序）和多個「框架」（如Hadoop [41]和Spark [73]）之間劃分資源管理和放置功能。 Borg主要使用基於請求的機制來集中化這些功能，這種機制能夠很好地擴展。 DRF [29,35,36,66]最初是爲Mesos開發的; Borg使用優先級和許可配額來代替。Mesos開發商已經宣佈擴展Mesos以包括投機的資源分配和回收，並解決[69]中肯定的一些問題。

YARN [76]是一個以Hadoop爲中心的集羣管理器。每一個應用程序都有一個管理器，它與中央資源管理器協商所需的資源; 這與Google MapReduce做業自2008年以來用於從Borg獲取資源的方案大體相同.YARN的資源管理器最近才變得容錯。相關的開源工做是Hadoop容量調度器[42]，它爲容量保證，分層隊列，彈性共享和公平性提供多租戶支持。 
YARN最近已經擴展到支持多種資源類型，優先級，搶佔和高級准入控制[21]。俄羅斯方塊研究原型[40]支持工時感知的（makespan-aware）做業打包。

Facebook的Tupperware [64]是一個相似Borg的系統，用於在羣集上調度cgroup容器; 只有一些細節已經被公開，儘管它彷佛提供了一種資源回收的形式。 Twitter有開源的Aurora [5]，一個相似Borg的調度器，用於在Mesos之上運行的長時間運行的服務，配置語言和狀態機相似於Borg。 
Microsoft的Autopilot系統提供了「自動化軟件配置和部署; 系統監控; 執行修復動做來處理軟件和硬件故障「。Borg生態系統提供了相似的功能，但限於篇幅這裏不作討論； Isaard [48]概述了咱們堅持的許多最佳實踐。

Quincy [49]使用網絡流模型爲幾百個節點的集羣上的數據處理DAG提供公平性和數據位置感知調度。Borg使用配額和優先級在用戶之間共享資源，並擴展到數萬臺機器。Quincy直接處理執行圖，而這是單獨構建在Borg的頂部。

Cosmos [44]專一於批處理，重點是確保其用戶可以公平地訪問他們捐贈給集羣的資源。它使用每一個工做管理器（per-job manager）來獲取資源; 幾個細節是公開的。

微軟的Apollo系統[13]使用每一個做業調度器進行短時間批處理做業，以在看來與Borg cell大小相同的集羣上實現高吞吐量。 Apollo使用機會主義執行低優先級後臺工做，以多日排隊延遲爲代價（有時）來提升利用率。Apollo節點提供任務的開始時間的預測矩陣做爲兩個資源維度上大小的函數，其中調度器結合啓動成本的估計及遠程數據訪問以進行佈置決定，由隨機延遲調製以減小衝突。Borg使用中央調度器基於先前分配的狀態來佈置決定，能處理更多的資源維度，並專一於高可用性、長期運行的應用程序的需求; Apollo能夠處理更高的任務到達率。

阿里巴巴的Fuxi [84]支持數據分析工做負載；它從2009年開始運行。像Borgmaster同樣，中央FuxiMaster（複製用於容錯）從節點收集資源可用性信息，接受來自應用程序的請求，並將一個匹配到另外一個。Fuxi增量調度策略與Borg的等價類相反：Fuxi不是將每一個任務與一組合適的機器相匹配，而是將新可用資源與積壓的待處理工做進行匹配。像Mesos同樣，Fuxi容許定義「虛擬資源」類型。只有合成工做負載結果是公開的。

Omega [69]支持多個平行的，專門的「垂直」，每一個大體至關於Borgmaster減去其持久存儲和連接分片。 Omega調度器使用樂觀併發控制來操做存儲在中央持久存儲器中的指望和觀察到的cell狀態的共享表示，其經過單獨的鏈路組件被同步到Borglet。Omega架構旨在支持多個不一樣的工做負載，這些工做負載具備特定於應用程序的RPC接口，狀態機和調度策略（例如，長期運行的服務器，來自各類框架的批處理做業，基礎架構服務（如集羣存儲系統），虛擬機Google Cloud Platform）。另外一方面，Borg提供了「一個適合全部」的RPC接口，狀態機語義和調度器策略，隨着時間的推移，因爲須要支持許多不一樣的工做負載，它們的規模和複雜性都有所增加，可擴展性還沒有成爲問題（§3.4）。

Google的開源Kubernetes系統[53]將應用程序放置在Docker容器[28]中（在多個主機節點上）。它運行在裸機（如Borg）和各類雲託管提供者中，如Google Compute Engine。它是由許多創建Borg的工程師積極開發的。 Google提供了一個名爲Google Container Engine的託管版本[39]。將在下一節討論如何將Borg的教訓應用於Kubernetes。

高性能計算團體在這一領域有着悠久的工做傳統（例如，Maui，Moab，Platform LSF [2，47，50]）; 然而，規模、工做負載和容錯的要求不一樣於谷歌的cell。一般，這樣的系統經過具備等待工做的大積壓（隊列）來實現高利用率。

虛擬化提供商如VMware [77]和數據中心解決方案提供商（如HP和IBM [46]）提供集羣管理解決方案，一般擴展到O（1000）機器。此外，幾個研究團體具備以某些方式改進調度決策質量的原型系統（例如，[25,40,72,74]）。

最後，正如已經指出的，管理大規模集羣的另外一個重要部分是自動化和「運算符scaleout」。 [43]描述瞭如何計劃故障，多租戶，健康檢查，准入控制和可從新啓動性對於每一個操做者完成大量機器是必要的。Borg的設計理念是相似的，可以爲每一個操做員（SRE）支持數萬臺機器。

8 經驗教訓和將來工做

本節講述了十多年來在生產中操做Borg所學到的一些定性教訓，並描述了在設計Kubernetes時如何利用這些觀察結果[53]。

8.1經驗教訓：壞的方面

從Borg的一些特性開始，做爲告誡和在Kubernetes中知情的替代設計。 
做爲任務的惟一分組機制，做業是限制性的。 Borg沒有一流的方式來管理整個多做業服務做爲一個單一的實體，或指的是服務的相關實例（例如，canary和生產軌跡）。做爲一個***，用戶在做業名稱中編碼服務拓撲，並構建更高級別的管理工具來解析這些名稱。在範圍的另外一端，不可能引用做業的任意子集，這致使諸如滾動更新和做業調整大小的不靈活語義問題。 
爲了不這種困難，Kubernetes拒絕了做業概念，而是使用標籤組織調度單元（pods） - 用戶能夠附加到系統中任何對象的任意鍵/值對。同等的，能夠經過附加到一個做業上實現Borg做業：將做業名標籤附加到一組pod，可是也能夠表示任何其餘有用的分組，例如服務，層或發行類型（例如，生產、分段、測試）。 Kubernetes中的操做經過標籤查詢來識別其目標，該查詢選擇了將應用操做的對象。這種方法比做業的單個固定分組提供更多的靈活性。

每一個機器一個IP地址使事情複雜化。在Borg中，機器上的全部任務都使用其主機的單個IP地址，從而共享主機的端口空間。這致使了一些困難：Borg必須調度做爲資源的端口; 任務必須預先聲明須要多少個端口，而且願意在啓動時被告知使用哪些端口；Borglet必須強制端口隔離；而且命名和RPC系統必須處理端口和IP地址。

因爲Linux命名空間，虛擬機，IPv6和軟件定義網絡的出現，Kubernetes能夠採起對用戶更加友好的方法，消除這些複雜性：每一個pod和服務都有本身的IP地址，容許開發人員選擇端口，而不是要求軟件適應選擇，並消除了管理端口的基礎架構複雜性。

針對高級用戶進行優化，犧牲了休閒用戶。Borg提供了一大套針對「超級用戶」的功能，以便用戶能夠微調程序運行方式（BCL規範列出約230個參數）：最初的重點是支持谷歌上最大的資源消費者，他們的效率增益是相當重要的。不幸的是，這種API的豐富性使事情變得更難針對「休閒」用戶，而限制了其發展。解決方案是構建在Borg之上運行的自動化工具和服務，並經過實驗肯定合適的設置。這些都受益於容錯應用程序提供的實驗自由：若是自動化出現錯誤，這是一個麻煩事，而不是災難。

8.2經驗教訓：好的方面

另外一方面，一些Borg的設計特性已經很是優越，並經受住了時間的考驗。 
Allocs是有用的。 Borg alloc抽象概念產生了普遍使用的日誌存儲模式（§2.4），另外一個流行的模式是簡單的數據加載器任務按期更新Web服務器使用的數據。Allocs和包容許這種幫助服務由不一樣的團隊開發。

Kubernetes中同alloc等價的是pod，它是一個或多個容器的資源封裝，這些容器老是被調度到同一機器上而且能夠共享資源。Kubernetes在相同的pod中使用輔助容器代替alloc中的任務，可是想法是同樣的。

集羣管理不只僅是任務管理。儘管Borg的主要做用是管理任務和機器的生命週期，可是運行在Borg上的應用程序能夠從許多其餘集羣服務中受益，包括命名和負載平衡。 Kubernetes使用服務抽象支持命名和負載平衡：服務具備名稱和由標籤選擇器定義的動態pod集。羣集中的任何容器均可以使用服務名稱鏈接到服務。在封面下，Kubernetes自動負載平衡與標籤選擇器匹配的pod中的服務鏈接，而且跟蹤pod在因爲故障而隨着時間從新安排時運行的位置。

內省是相當重要的。雖然Borg幾乎老是「只是工做」，當出了問題，找到根本緣由多是挑戰性的。Borg中一個重要的設計決策是要向全部用戶顯示調試信息，而不是隱藏：Borg有成千上萬的用戶，因此「自助」必須是調試的第一步。雖然這使得更難以輕視特性和改變用戶依賴的內部策略，但它仍然是一個贏家，尚未找到任何現實的替代品。爲了處理大量數據，提供了多個級別的UI和調試工具，所以用戶能夠快速識別與其做業相關的異常事件，而後從其應用程序和基礎架構自己深刻查看詳細的事件和錯誤日誌。 
Kubernetes旨在複製Borg的許多內省技術。例如，它附帶了諸如cAdvisor [15]等用於資源監視和基於Elasticsearch / Kibana [30]和Fluentd [32]的日誌聚合的工具。能夠查詢主機的對象狀態的快照。Kubernetes具備統一的機制，全部組件均可以用來記錄事件（例如，被調度的pod，容器失敗），這些事件對客戶端也是可用的。

主機是分佈式系統的內核。Borgmaster最初設計爲一個單片系統，但隨着時間的推移，它變得更像一個內核，位於服務生態系統的核心，協做管理用戶做業。例如，將調度程序和主UI（Sigma）拆分爲單獨的進程，並增長了服務用於准入控制、垂直和水平自動縮放，從新打包任務，按期做業提交（cron），工做流管理以及用於離線查詢的歸檔系統操做。總之，這使得可以在不犧牲性能或可維護性的狀況下擴展工做負載和功能集。

Kubernetes架構更進一步：它的核心有一個API服務器，只負責處理請求和操做底層狀態對象。集羣管理邏輯被構建爲小的可組合的微服務（該API服務器的客戶端），例如複製控制器，用於在面對故障時保持pod的指望數量的副本，以及節點控制器，用於管理機器生命週期。

總結

在過去十年裏，幾乎全部的Google集羣工做負載都轉而使用Borg。咱們繼續發展它，並將從中學到的教訓應用到Kubernetes。

文章來源：http://javajgs.com/archives/6312