單個(gè)容器的局限性及多容器的必要性

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