本文討論了單個容器所無法解決的問題和局限性，本文介紹了容器編排的必要性和復(fù)雜性及常用工具的比較，提到了諸如Kubernetes, Mesos等容器管理工具

就像之前已被證實的那樣，要在一個機器上生成成千上萬個容器還是相對容易的。但你如何去部署成千上萬個容器呢?如何管理并且追蹤它們?如何管理、如何去做故障恢復(fù)?這些事情看似容易，但解決起來困難重重。讓我們來解析一下究竟難在何處。

用一個簡單的命令，就可以設(shè)立Docker環(huán)境，來跑一個Docker直到你將停其掉為止。但如果你需要在兩臺機器上跑Docker容器呢?如果50臺呢?或者如果1萬臺呢?現(xiàn)在，你可能會問為何要這么做。這里有一些好的理由：

1) 為了服務(wù)更多的用戶，你可能會遇到你Nginx網(wǎng)絡(luò)服務(wù)器縱向擴容的瓶頸，也就是說，在一個云供應(yīng)商那兒使用一個更大的實例類型或者在你的披薩盒子里塞下更多的內(nèi)存。如果你已經(jīng)碰到那堵墻，你就會需要這么一個選項，可以橫向的擴容，典型性的就是采用代理服務(wù)器/冗余控制來作為服務(wù)穩(wěn)定的切入口。

2) 另一個方面是容錯。如果你可愛的Redis容器停止存在了，該怎么辦?有可能是底下的機器死了?你會想要做故障轉(zhuǎn)移。在容器工作的情景下，這意味著你的編排器得在另一個健康的機器中重新啟動你需要運行的容器。

所以，這都取決于你的目標動機——容量、容錯或者兩者皆有——如果你有10個或者1千個機器，那挑戰(zhàn)就存在著：如何在這些不同的機器間有效率且有效果地進行容器擴容。

然而，在我們跨入這些挑戰(zhàn)之前，讓我們來理清一些術(shù)語。來自微軟和谷歌關(guān)于集群的研究表明了如下的工作量的區(qū)分：

1) 有一些長期在跑的服務(wù)，那應(yīng)該一直在跑。那些通常是做交互、對延遲敏感的例如面向終端用戶的網(wǎng)絡(luò)應(yīng)用這樣的任務(wù);或者是底層的服務(wù)，類似于Cassandra, ArangoDB, HDFS, 或者 Quobyte。

2) 然后，就有一些批量任務(wù)，延續(xù)時間從幾秒到很多小時。他們通常對表現(xiàn)波動沒有那么敏感，然而可能存在例如像獨立管理等完成時間上的總體服務(wù)水平協(xié)議(SLAs)。

除了以上這些工作任務(wù)的類別區(qū)分，還想要支持工作優(yōu)先度劃分：比如對業(yè)務(wù)尤為關(guān)鍵的、對頂層收入產(chǎn)生直接影響的生產(chǎn)性工作，以及非生產(chǎn)性工作比如質(zhì)量測試、測試和研發(fā)這類。

從一個到兩個

把術(shù)語理清之后，讓我們直接來面對在超過一臺服務(wù)器上跑容器需要克服的挑戰(zhàn)。

最為基本的問題是：在一臺服務(wù)器上能裝下多少容器?我們發(fā)現(xiàn)，在bare metal上不同負載的測試表明每個機器容納250個容器是可能的，這是Docker daemon的潛在極限。對一個平均跑20個Docker鏡像的簡單的微服務(wù)構(gòu)架的應(yīng)用而言，產(chǎn)生大約10倍的容量(scale factor)。顯而易見，當你在一個機器上跑超過一個應(yīng)用，這將會非常容易的降低到2倍。另外，資源消耗會產(chǎn)生一個自然的極限：比如，假設(shè)一個單獨的容器可能消耗內(nèi)存的為100MB，對于一個32GB的內(nèi)存(除去操作系統(tǒng)需要的2GB)，那就留給我們3萬MB或者相當于300個容器。這比我們之前討論的極限要高的多。因此，即便在中等的負荷下，擴容顯得不可避免。

一旦當你跑了兩臺機器來服務(wù)你的容器，你需要關(guān)注以下事項：

1) 任何一個容器的健康情況是怎樣的?它是否還在運行、在服務(wù)，而且如果是這樣的話，它的核心健康數(shù)據(jù)(監(jiān)控)是怎樣的?

2) 我到哪里能找到特定的那個容器?也就是說，在容器的邏輯ID和具體的(路由)IP之間能有一個匹配：端口匹配必須建立和保持，這也被稱為服務(wù)發(fā)現(xiàn)。

3) 應(yīng)用版本和更新。不管何時當應(yīng)用的一個新版本被部署時，Docker鏡像需要被傳遞到服務(wù)器上(即鏡像的實時性和信任)。

上述羅列的這些功能要求是在編排系統(tǒng)核心任務(wù)之外的，也就是如何來編排容器(或者，換句話說，來決定在哪臺機器上來跑容器)。盡管這個描述，是一個真實情況的簡略版，但它能幫助我們理解在多臺機器上跑容器的基本挑戰(zhàn)。對于兩臺機器來說，任何包括Docker Swarm, Kubernetes和Mesos的解決方案都適合;有了后兩個，盡管是可取的，但似乎也大材小用。直到你的應(yīng)用被使用的非常厲害，而且當你添加到第三臺、第二十臺或者第487臺機器為止。那么，然后呢?

從兩個到多個

今年早些時候，谷歌發(fā)布了他們主要的生產(chǎn)集群管理的細節(jié)，Borg.

谷歌在10萬臺機器的區(qū)間內(nèi)，他們中位數(shù)集群尺寸大約在1萬臺機器，也有一些更大的。谷歌稱，一個單獨的Borgmaster(其專有的分配集群的首腦)在一個cell(谷歌對于集群的術(shù)語)內(nèi)能管理成千上萬臺機器。一個忙碌的Borgmaster使用10至14個CPU內(nèi)核以及高至50GB的內(nèi)存。另外，幾個cell有任務(wù)到達率在每分鐘1萬個任務(wù)以上。盡管不是每個人都是谷歌或者Twitter，在這個事情上，對于企業(yè)級別的需要應(yīng)對成千上萬用戶或者一個流行的移動端應(yīng)用即需要面對百萬數(shù)量級潛在的多進程用戶而言的復(fù)雜應(yīng)用，還是非常容易會到達成百上千個機器的范疇。

在一個分布式系統(tǒng)內(nèi)，去追蹤成千上萬件事情(進程、連接等)以及她們的狀態(tài)是一件很難的事情。真相的來源是什么呢?你是從中心的位置每隔一段時間去檢查一下嗎?你去跑代理來推送狀態(tài)到上游嗎?這些都是一些已經(jīng)被討論了一陣的相關(guān)問題，比如從1990年代晚期以C10K問題的形式。

另外，跑成千上萬個容器(我們已經(jīng)從上面描述知道了這需要成百上千的服務(wù)器)會給你一個分布式的系統(tǒng)，存在許多復(fù)雜的失敗模式：從超時引起的問題，到網(wǎng)絡(luò)劃分的問題，到CPU垃圾清理的問題或者是內(nèi)存耗盡問題。最后的但不僅僅限于此的問題是，為了有效利用服務(wù)器，容器需要被以最有效的方式bin- packed;有一件特別難的事，尤其當要考慮到做兩種類型的任務(wù)(長時期跑的和批量的)和任務(wù)優(yōu)先級劃分。你當然不想因為一個以周為單位的Spark批量任務(wù)以為它需要你集群中的一大塊兒，然后把你企業(yè)的應(yīng)用給耗盡從而喪失每小時10萬美金的利潤。

總結(jié)一下，在集群層面上以最優(yōu)方式來安排容器意味著要這么做：

1) 如果發(fā)生故障，你的服務(wù)要能繼續(xù)跑

2) 你的最大化利用要很嚴格、很動態(tài)

另外，故障處理，意味著確保發(fā)生故障后能重新安排，要潛在地把其他工作事先清空也是很難且動態(tài)的。我說“很難”和“動態(tài)”的意思是，這些需要很多計劃安排，而且我們在討論的是一個迅速且一直在變化的環(huán)境，這本身是計算機相對于人類而言擅長之初的完美例子。

現(xiàn)在，既然我們已經(jīng)探索過了存在問題的空間，讓我們再來看一下解決辦法的空間。

Mesos滿足了以上列表的要求，很成熟，而且得益于它的兩層安排體系，也使得它極度靈活。和“一種尺寸適應(yīng)所有情況”的單一安排體系不同的是，Mesos把實際工作分配決定委派給所謂專門的框架安排體系，而它自己則通過應(yīng)用“專用資源公平算法”(Domain Resource Fairness algorithm，簡稱DRF算法)來關(guān)注資源抽象和管理。DRF算法本質(zhì)上讓不同的工作得以公平地分享不同類型的資源(CPU、RAM等等)。

或許，對這個討論更為重要的是，Mesos可以線性擴容。早在2010年，在Mesos原始的技術(shù)報告中(精確的說，在6.5部分)，在AWS上的一個有 99個EC2實例的集群進行了一個實驗，每個集群都有八個CPU內(nèi)核和6GB的內(nèi)存。在集群上跑有5萬個slave daemons，結(jié)果是一個線性的向上的增加(總在1秒以內(nèi))，說明在主從daemon之間存在線性擴容的關(guān)系。

線性擴容是Mesos一個非常關(guān)鍵的特征，用來跑容器化的工作負載，不管是在某一個云環(huán)境中還是在一個混合的云設(shè)置中(比如：混合了在終端的云或者不同云提供商之間的云)。迄今為止，Mesos在這方面是唯一一個被證明有追蹤記錄的開源的社區(qū)項目(Twitter,Airbnb, Apple和50多個公司)，我們未來也看看它會朝何處發(fā)展。

從谷歌10多年前在跑容器擴容方面學到的經(jīng)驗(不管是Kubernetes中的pod概念還是基于谷歌Omega的優(yōu)化方案)，都已經(jīng)引入了Mesos核心。從另外一方面來說，人們可以得益于使用Data Center Operating System，是Apache Mesos的商業(yè)版本，和Kubernetes和Swarm包一起使用。

我們會持續(xù)紀錄這方面的進展。要了解更多關(guān)于Mesos如何擴容，請繼續(xù)關(guān)注Next Platform。