單個容器的局限性及多容器的必要性

　本文討論了單個容器所無法解決的問題和局限性，并介紹了容器編排的必要性和復(fù)雜性及常用工具的比較，提到了諸如Kubernetes、Mesos等容器管理工具。
　　就像之前已被證實(shí)的那樣，要在一個機(jī)器上創(chuàng)建成千上萬個容器還是相對容易的。但如何去部署這么多的容器呢？如何管理且追蹤它們？如何管理、如何來處理故障恢復(fù)？這些事情看似容易，但解決起來困難重重。讓我們來解析一下究竟難在何處。
　　用一個簡單的命令，就可以設(shè)立Docker環(huán)境，來跑一個Docker直到你將停其掉為止。但如果你需要在兩臺機(jī)器上跑Docker容器呢？如果50臺呢？或者如果1萬臺呢？現(xiàn)在，你可能會問為何要這么做。這里有一些好的理由：
　　1.為了服務(wù)更多的用戶，你可能會遇到你Nginx網(wǎng)絡(luò)服務(wù)器縱向擴(kuò)容的瓶頸，也就是說，在一個云供應(yīng)商那兒使用一個更大的實(shí)例類型或者在你的披薩盒子里塞下更多的內(nèi)存。如果你已經(jīng)碰到那堵墻，你就會需要這么一個選項(xiàng)，可以橫向的擴(kuò)容，典型性的就是采用代理服務(wù)器／冗余控制來作為服務(wù)穩(wěn)定的切入口。
　　2.另一個方面是容錯。如果你可愛的Redis容器停止存在了，該怎么辦？有可能是底下的機(jī)器死了？你會想要做故障轉(zhuǎn)移。在容器工作的情景下，這意味著你的編排器得在另一個健康的機(jī)器中重新啟動你需要運(yùn)行的容器。
　　所以，這都取決于你的目標(biāo)動機(jī)——容量、容錯或者兩者皆有——如果你有10個或者1千個機(jī)器，那挑戰(zhàn)就存在著：如何在這些不同的機(jī)器間有效率且有效果地進(jìn)行容器擴(kuò)容。
　　然而，在我們跨入這些挑戰(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)波動沒有那么敏感，然而可能存在例如像獨(dú)立管理等完成時間上的總體服務(wù)水平協(xié)議（SLA）。
　　除了以上這些工作任務(wù)的類別區(qū)分，還想要支持工作優(yōu)先度劃分：比如對業(yè)務(wù)尤為關(guān)鍵的、對頂層收入產(chǎn)生直接影響的生產(chǎn)性工作，以及非生產(chǎn)性工作比如質(zhì)量測試、測試和研發(fā)這類。
　　從一個到兩個
　　把術(shù)語理清之后，讓我們直接來面對在超過一臺服務(wù)器上跑容器需要克服的挑戰(zhàn)。
　　最為基本的問題是：在一臺服務(wù)器上能裝下多少容器？我們發(fā)現(xiàn)，在裸機(jī)上不同負(fù)載的測試表明每個機(jī)器容納250個容器是可能的，這是Docker Daemon的潛在極限。對一個平均跑20個Docker鏡像的簡單的微服務(wù)構(gòu)架的應(yīng)用而言，產(chǎn)生大約10倍的容量（scale factor）。顯而易見，當(dāng)你在一個機(jī)器上跑超過一個應(yīng)用，這將會非常容易的降低到2倍。另外，資源消耗會產(chǎn)生一個自然的極限：比如，假設(shè)一個單獨(dú)的容器可能消耗內(nèi)存的為100MB，對于一個32GB的內(nèi)存（除去操作系統(tǒng)需要的2GB），那就留給我們3萬MB或者相當(dāng)于300個容器。這比我們之前討論的極限要高的多。因此，即便在中等的負(fù)荷下，擴(kuò)容顯得不可避免。
　　一旦當(dāng)你跑了兩臺機(jī)器來服務(wù)你的容器，你需要關(guān)注以下事項(xiàng)：
　　1.任何一個容器的健康情況是怎樣的？它是否還在運(yùn)行、在服務(wù)，而且如果是這樣的話，它的核心健康數(shù)據(jù)（監(jiān)控）是怎樣的？
　　2.我到哪里能找到特定的那個容器？也就是說，在容器的邏輯ID和具體的（路由）IP之間能有一個匹配：端口匹配必須建立和保持，這也被稱為服務(wù)發(fā)現(xiàn)。
　　3.應(yīng)用版本和更新。不管何時當(dāng)應(yīng)用的一個新版本被部署時，Docker鏡像需要被傳遞到服務(wù)器上（即鏡像的實(shí)時性和信任）。
　　上述羅列的這些功能要求是在編排系統(tǒng)核心任務(wù)之外的，也就是如何來編排容器（或者，換句話說，來決定在哪臺機(jī)器上來跑容器）。盡管這個描述，是一個真實(shí)情況的簡略版，但它能幫助我們理解在多臺機(jī)器上跑容器的基本挑戰(zhàn)。對于兩臺機(jī)器來說，任何包括Docker Swarm、Kubernetes和Mesos的解決方案都適合；有了后兩個，盡管是可取的，但似乎也大材小用。直到你的應(yīng)用被使用的非常厲害，而且當(dāng)你添加到第三臺、第二十臺或者第487臺機(jī)器為止。那么，然后呢？
　　從兩個到多個
　　今年早些時候，谷歌發(fā)布了他們主要的生產(chǎn)集群管理的細(xì)節(jié)，Borg。
　　谷歌在10萬臺機(jī)器的區(qū)間內(nèi)，他們中位數(shù)集群尺寸大約在1萬臺機(jī)器，也有一些更大的。谷歌稱，一個單獨(dú)的BorgMaster（其專有的分配集群的首腦）在一個cell（谷歌對于集群的術(shù)語）內(nèi)能管理成千上萬臺機(jī)器。一個忙碌的BorgMaster使用10至14個CPU內(nèi)核以及高至50GB的內(nèi)存。另外，幾個cell有任務(wù)到達(dá)率在每分鐘1萬個任務(wù)以上。盡管不是每個人都是谷歌或者Twitter，在這個事情上，對于企業(yè)級別的需要應(yīng)對成千上萬用戶或者一個流行的移動端應(yīng)用即需要面對百萬數(shù)量級潛在的多進(jìn)程用戶而言的復(fù)雜應(yīng)用，還是非常容易會到達(dá)成百上千個機(jī)器的范疇。
　　在一個分布式系統(tǒng)內(nèi)，去追蹤成千上萬件事情（進(jìn)程、連接等）以及它們的狀態(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；有一件特別難的事，尤其當(dāng)要考慮到做兩種類型的任務(wù)（長時期跑的和批量的）和任務(wù)優(yōu)先級劃分。你當(dāng)然不想因?yàn)橐粋€以周為單位的Spark批量任務(wù)以為它需要你集群中的一大塊兒，然后把你企業(yè)的應(yīng)用給耗盡從而喪失每小時10萬美金的利潤。
　　總結(jié)一下，在集群層面上以最優(yōu)方式來安排容器意味著要這么做：
　　? 如果發(fā)生故障，你的服務(wù)要能繼續(xù)跑。
　　? 你的最大化利用要很嚴(yán)格、很動態(tài)。
　　另外，故障處理，意味著確保發(fā)生故障后能重新安排，要潛在地把其他工作事先清空也是很難且動態(tài)的。我說“很難”和“動態(tài)”的意思是，這些需要很多計劃安排，而且我們在討論的是一個迅速且一直在變化的環(huán)境，這本身是計算機(jī)相對于人類而言擅長之初的完美例子。
　　現(xiàn)在，既然我們已經(jīng)探索過了存在問題的空間，讓我們再來看一下解決辦法的空間。
　　Mesos滿足了以上列表的要求，很成熟，而且得益于它的兩層安排體系，也使得它極度靈活。和“一種尺寸適應(yīng)所有情況”的單一安排體系不同的是，Mesos把實(shí)際工作分配決定委派給所謂專門的框架安排體系，而它自己則通過應(yīng)用“專用資源公平算法”（Domain Resource Fairness algorithm，簡稱DRF算法）來關(guān)注資源抽象和管理。DRF算法本質(zhì)上讓不同的工作得以公平地分享不同類型的資源（CPU、RAM等等）。
　　或許，對這個討論更為重要的是，Mesos可以線性擴(kuò)容。早在2010年，在Mesos原始的技術(shù)報告中（精確的說，在6.5部分），在AWS上的一個有99個EC2實(shí)例的集群進(jìn)行了一個實(shí)驗(yàn)，每個集群都有八個CPU內(nèi)核和6GB的內(nèi)存。在集群上跑有5萬個slave daemons，結(jié)果是一個線性的向上的增加（總在1秒以內(nèi)），說明在主從daemon之間存在線性擴(kuò)容的關(guān)系。
　　線性擴(kuò)容是Mesos一個非常關(guān)鍵的特征，用來跑容器化的工作負(fù)載，不管是在某一個云環(huán)境中還是在一個混合的云設(shè)置中（比如：混合了在終端的云或者不同云提供商之間的云）。迄今為止，Mesos在這方面是唯一一個被證明有追蹤記錄的開源的社區(qū)項(xiàng)目（Twitter、Airbnb、Apple和50多個公司），我們未來也看看它會朝何處發(fā)展。
　　從谷歌10多年前在跑容器擴(kuò)容方面學(xué)到的經(jīng)驗(yàn)（不管是Kubernetes中的pod概念還是基于谷歌Omega的優(yōu)化方案），都已經(jīng)引入了Mesos核心。從另外一方面來說，人們可以得益于使用Data Center Operating System，是Apache Mesos的商業(yè)版本，和Kubernetes和Swarm包一起使用。
　　原文鏈接：What Makes Containers At Scale So Difficult
?