【編者的話】如今，Kubernetes***管理大約5000個(gè)節(jié)點(diǎn)，這不但與Borg或Tupperware的可擴(kuò)展性相去甚遠(yuǎn)，而且做不到無(wú)感知地調(diào)度不同區(qū)域的節(jié)點(diǎn)。本文通過(guò)介紹Tupperware與Delos背后的一些思想以及完成的一些工作，最終Facebook能夠隨時(shí)隨地使用其全球資源，而不再考慮數(shù)據(jù)中心和區(qū)域。

如果你想知道Kubernetes容器管理系統(tǒng)的未來(lái)會(huì)是什么樣子，那么Facebook自2011年以來(lái)一直在使用和發(fā)展的封閉源代碼、自主研發(fā)的Tupperware容器控制系統(tǒng)(Docker容器以及Kubernetes出現(xiàn)之前)可能是一個(gè)很好的靈感來(lái)源。

Kubernetes是5年前由谷歌開(kāi)源的，并不是說(shuō)谷歌內(nèi)部Borg和Omega集群以及容器控制系統(tǒng)對(duì)Kubernetes沒(méi)有很好的啟發(fā)。實(shí)際上，谷歌并沒(méi)有直接拉取Borg代碼，將其關(guān)鍵信息清理干凈，然后將其轉(zhuǎn)儲(chǔ)到GitHub上，而是用Go編程語(yǔ)言(谷歌也創(chuàng)建了這種語(yǔ)言)從零開(kāi)始創(chuàng)建了Kubernetes，并在周圍建立了一個(gè)社區(qū)，取得了巨大的成功。在這一點(diǎn)上，沒(méi)有人會(huì)因?yàn)檫x擇Kubernetes作為應(yīng)用程序構(gòu)建的下一代容器編排平臺(tái)而被解雇。

但這并不意味著Facebook等其他超大規(guī)模公司沒(méi)有遇到大規(guī)模的問(wèn)題，也沒(méi)有以Kubernetes沒(méi)有努力解決或解決的方式來(lái)解決這些問(wèn)題，即使谷歌在內(nèi)部也面臨著與Borg和Omega類似的問(wèn)題。遺憾的是，F(xiàn)acebook不會(huì)創(chuàng)建一個(gè)開(kāi)源版本的Tupperware容器集群和控制器，或新的Delos存儲(chǔ)服務(wù)支撐當(dāng)前迭代控制平面的Tupperware，這兩者都是在上周晚些時(shí)候Facebook的系統(tǒng)規(guī)模活動(dòng)上討論的。

Tupperware系統(tǒng)的構(gòu)建非常精確，能夠運(yùn)行Facebook的應(yīng)用程序和數(shù)據(jù)服務(wù)，很難創(chuàng)建一個(gè)通用版本的控制器來(lái)整合和支持企業(yè)中運(yùn)行的各種服務(wù)。谷歌的Borg和Omega也是如此，它花了相當(dāng)大的努力重寫(xiě)了Borg和Omega的核心部分，使其成為一個(gè)通用的集群和容器控制器，老實(shí)說(shuō)，Kubernetes平臺(tái)尚未完成，即使五年來(lái)它已經(jīng)取得了長(zhǎng)足的進(jìn)步。

簡(jiǎn)單地說(shuō)，Chunqiang Tang是臉書(shū)負(fù)責(zé)Tupperware工作的工程經(jīng)理，之前曾在IBM的TJ沃森研究中心負(fù)責(zé)云自動(dòng)化研究，他向“next平臺(tái)”講述Facebook沒(méi)有計(jì)劃從Tupperware學(xué)習(xí)，然后應(yīng)用它們，匯聚到Kubernetes，就像谷歌有一天可能做的那樣。(已經(jīng)有很多谷歌服務(wù)在谷歌云平臺(tái)上運(yùn)行在Kubernetes之上，而不是在Borg/Omega裸機(jī)上運(yùn)行。)

雖然Facebook目前還沒(méi)有計(jì)劃開(kāi)放與Tupperware一起使用的Delos低延遲、可插拔的應(yīng)用編程接口數(shù)據(jù)存儲(chǔ)，但密歇根大學(xué)計(jì)算機(jī)科學(xué)與工程教授杰森·弗林(Jason Flinn)曾與Facebook一起參與Delos項(xiàng)目，他暗示說(shuō)，這個(gè)項(xiàng)目?jī)H在一年前開(kāi)始，在生產(chǎn)中僅使用了大約四個(gè)月，所以開(kāi)放它還為時(shí)尚早，即使這樣但從長(zhǎng)遠(yuǎn)來(lái)看是有可能的。

關(guān)鍵是，在“系統(tǒng)規(guī)模”會(huì)議上披露的Tupperware和Delos的信息可以用來(lái)通知和激勵(lì)其他集群和容器管理及存儲(chǔ)子系統(tǒng)的工作，包括開(kāi)源和閉源。畢竟，谷歌在2005年發(fā)布的MapReduce論文直接導(dǎo)致雅虎創(chuàng)建了Hadoop。

我們對(duì)Facebook在大規(guī)模運(yùn)行基礎(chǔ)設(shè)施方面提供的洞見(jiàn)感興趣，正如對(duì)兩組代碼的技術(shù)細(xì)節(jié)感興趣一樣。這些見(jiàn)解適用于許多人，即使代碼可能只適用于一個(gè)人。

就規(guī)模而言，Tang透露Kubernetes不能與Borg/Omega相提并論，當(dāng)然也不能與Tupperware相提并論。當(dāng)它***推出時(shí)，Kubernetes艱難的在數(shù)百臺(tái)服務(wù)器上運(yùn)行，一年后它突破了1000個(gè)節(jié)點(diǎn)。根據(jù)Tang的說(shuō)法，現(xiàn)在Kubernetes***管理大約5000個(gè)節(jié)點(diǎn)。這與Borg或Tupperware的可擴(kuò)展性相去甚遠(yuǎn)。谷歌和Facebook數(shù)據(jù)中心的物理集群跨越大約10萬(wàn)臺(tái)機(jī)器，多個(gè)數(shù)據(jù)中心組成一個(gè)區(qū)域。在谷歌，這些物理集群被Borg分割成單元，在過(guò)去，這些單元平均有10000個(gè)節(jié)點(diǎn)，但有些被縮小到幾千個(gè)節(jié)點(diǎn)，有些被擴(kuò)大到高達(dá)50000個(gè)節(jié)點(diǎn)。

在Tupperware最初構(gòu)思的時(shí)候，F(xiàn)acebook就像大多數(shù)數(shù)據(jù)中心一樣，從機(jī)架、集群和數(shù)據(jù)中心的角度來(lái)組織Tupperware，而這些結(jié)構(gòu)通常具有難以超越的物理配置。同樣在2010年代早期，當(dāng)時(shí)Docker容器甚至不存在(并且在很多年內(nèi)不會(huì)投入到生產(chǎn))，所以Facebook起初使用chroot運(yùn)行沙箱應(yīng)用程序，這樣它們就可以在一個(gè)物理的Linux服務(wù)器上同時(shí)運(yùn)行，就像谷歌已經(jīng)做了很長(zhǎng)一段時(shí)間一樣，隨著命名空間的成熟，F(xiàn)acebook也采用這些來(lái)提供工作負(fù)載之間的隔離。

眾所周知，由谷歌創(chuàng)建并捐贈(zèng)給Linux社區(qū)的Cgroups和Namespaces是Docker和Linux容器的基礎(chǔ)，而Facebook部署了Linux容器并在內(nèi)部向一個(gè)方向擴(kuò)展，Docker抓取了Linux容器并以稍微不同的方式對(duì)它們進(jìn)行了進(jìn)化(我們意識(shí)到，這過(guò)于簡(jiǎn)單化了)。我們的觀點(diǎn)是，在容器化方面，F(xiàn)acebook比谷歌落后了幾年，最終它也面臨同樣的問(wèn)題，并以稍微不同的方式解決了這些問(wèn)題。問(wèn)題是，你不能通過(guò)集群級(jí)別的管理來(lái)提高效率，最終，你還是需要跨數(shù)據(jù)中心和區(qū)域。

如今，Tupperware不再考慮機(jī)架、集群和數(shù)據(jù)中心，而是提供了一個(gè)跨越一個(gè)區(qū)域的多個(gè)數(shù)據(jù)中心的抽象層，該區(qū)域可能有幾十萬(wàn)臺(tái)物理服務(wù)器，或者有時(shí)跨越全球多個(gè)區(qū)域。Tupperware已經(jīng)從一個(gè)管理集群的操作工具發(fā)展成為一個(gè)有意識(shí)的工具，對(duì)于在Facebook上部署應(yīng)用程序的程序員來(lái)說(shuō)是件簡(jiǎn)單的事情，比如部署這個(gè)應(yīng)用程序在普林維爾地區(qū)的不同數(shù)據(jù)中心運(yùn)行，或者在普林維爾和盧拉數(shù)據(jù)中心部署這個(gè)應(yīng)用程序，Tupperware根據(jù)可用性來(lái)計(jì)算。這不是無(wú)服務(wù)器計(jì)算——對(duì)我們來(lái)說(shuō)這是一個(gè)愚蠢的術(shù)語(yǔ)——而是系統(tǒng)無(wú)管理計(jì)算，這是所有數(shù)據(jù)中心的最終目標(biāo)，如果你想說(shuō)實(shí)話的話(系統(tǒng)管理員不會(huì)這樣做，除非他們計(jì)劃成為公司雇傭的唯一剩余的現(xiàn)場(chǎng)可靠性工程師)。

對(duì)于Facebook來(lái)說(shuō)，集群管理是一個(gè)很大的障礙，它使用了一個(gè)名為Resource Broker的工具來(lái)解決這個(gè)問(wèn)題，該工具允許Facebook通過(guò)將工作從一個(gè)集群轉(zhuǎn)移到另一個(gè)集群，并將集群松散耦合到調(diào)度程序，從而對(duì)集群進(jìn)行維護(hù)。Resource Broker還監(jiān)視Facebook所有服務(wù)器的容量和可用性。

一旦Tupperware調(diào)度程序和物理集群之間的鏈接斷開(kāi)，事情就開(kāi)始變得輕松一些?，F(xiàn)在，在每個(gè)區(qū)域或跨區(qū)域內(nèi)，調(diào)度程序工作被切分，每個(gè)切分管理運(yùn)行在Tupperware上的作業(yè)的子集，但關(guān)鍵是所有這些切分都被聚合起來(lái)，以顯示所管理的所有服務(wù)器、容器和工作負(fù)載的單一視圖。有趣的是，Tang說(shuō)Tupperware調(diào)度程序中負(fù)責(zé)將容器分配到其管理下的服務(wù)器的分配器功能強(qiáng)大，足以在不分片的情況下處理整個(gè)Facebook區(qū)域(這并不意味著Facebook不會(huì)因?yàn)槠渌蚨鴮upperware碎片化)。在每臺(tái)服務(wù)器上都有一個(gè)Tupperware守護(hù)進(jìn)程，它將打開(kāi)和刪除容器，這些容器是使用BTRFS文件系統(tǒng)中的自定義格式創(chuàng)建的，并由systemd管理。

有趣的是，F(xiàn)acebook一直站在單套接字服務(wù)器的前沿，尤其是Yosemite微服務(wù)器，它們被廣泛部署在Facebook上運(yùn)行基礎(chǔ)設(shè)施軟件。這里是這樣的效果，每個(gè)Facebook數(shù)據(jù)中心現(xiàn)在都有更多的物理服務(wù)器，如果沒(méi)有更多的標(biāo)準(zhǔn)雙套接字機(jī)器，可能會(huì)有更多的物理服務(wù)器，這會(huì)給Tupperware帶來(lái)更多的負(fù)載，而摩爾定律(Moore’s Law)正在增加每個(gè)節(jié)點(diǎn)能夠支持的核心，因此也就增加了容器的數(shù)量。因此，需要分割Tupperware的工作，但希望與Tupperware的界面保持透明。

但這里還有另外一個(gè)使命，最終，F(xiàn)acebook希望能夠通過(guò)一個(gè)面板管理其整個(gè)機(jī)群，這將需要更多的Tupperware工作分片，以及與Facebook網(wǎng)絡(luò)上的工作負(fù)載相關(guān)的類似存儲(chǔ)分片。到目前為止，F(xiàn)acebook已經(jīng)安裝的服務(wù)器中只有20%包含在這個(gè)巨大的共享資源池中，但最終Facebook希望能夠隨時(shí)隨地使用其全球資源，而不再考慮數(shù)據(jù)中心和區(qū)域。

這是另一個(gè)有趣的觀察，Borg考慮工作負(fù)載的方式是，有在線工作和批處理工作，調(diào)度程序的主要工作是用批處理工作(如MapReduce數(shù)據(jù)分析工作)填充空閑的容量，直到在線工作(如填充搜索引擎請(qǐng)求)需要更多的容量。因此，這兩種類型的工作在系統(tǒng)上交錯(cuò)進(jìn)行，按需要按比例增加和減少它們的使用，以提高利用率。

Facebook采取了一種不同的方法，并在原始服務(wù)器級(jí)別進(jìn)行思考。首先，使用微服務(wù)器時(shí)，每個(gè)服務(wù)器節(jié)點(diǎn)的原始計(jì)算量更小，因此與使用雙套接字機(jī)器相比，可以分割的部分更少(這一點(diǎn)隨著AMD Rome Epyc處理器的高內(nèi)核數(shù)量而發(fā)生變化)。在Facebook，程序員被教導(dǎo)以這樣一種方式編碼，即使用他們?cè)诜?wù)器上所能使用的所有容量。在每個(gè)區(qū)域的夜間，當(dāng)新聞提要、Messenger、Web前端和應(yīng)用程序的其他層沒(méi)有被大量使用時(shí)，該區(qū)域的服務(wù)器節(jié)點(diǎn)將執(zhí)行各種批處理工作，如MapReduce分析和統(tǒng)計(jì)機(jī)器學(xué)習(xí)(畢竟，并不是所有的東西都需要GPU才能進(jìn)行深度學(xué)習(xí))。因此，不必?fù)?dān)心多少在線或批處理工作提供每個(gè)物理服務(wù)器上不同的容器與Resource Broker，F(xiàn)acebook將批處理或在線工作分配給每個(gè)服務(wù)器，確保它運(yùn)行完整得到最有價(jià)值的消費(fèi)。這是谷歌和Facebook之間一個(gè)有趣的區(qū)別，在Facebook中，容器實(shí)際上更像是一種部署機(jī)制，而不是工作負(fù)載隔離工具。

除了規(guī)模之外，還有一個(gè)領(lǐng)域是Facebook聲稱對(duì)Kubernetes有吹噓的權(quán)利，那就是管理有狀態(tài)的應(yīng)用程序——比如Facebook網(wǎng)站、Instagram、Messenger和WhatsApp背后的數(shù)據(jù)庫(kù)和數(shù)據(jù)存儲(chǔ)，包括ZippyDB、ODS Gorilla和Skuba——而不是無(wú)狀態(tài)的應(yīng)用程序——比如構(gòu)成Facebook應(yīng)用程序前端的網(wǎng)絡(luò)和PHP服務(wù)器。

Tupperware控制器上增加了一項(xiàng)名為T(mén)askControl的服務(wù)，該服務(wù)查看應(yīng)用程序?qū)S護(hù)與其存儲(chǔ)的有狀態(tài)鏈接的依賴性，然后根據(jù)這些需求決定如何部署運(yùn)行這些應(yīng)用程序的容器，并根據(jù)需要更新和移動(dòng)它們，而不會(huì)破壞該有狀態(tài)鏈接，從而損壞或崩潰應(yīng)用程序。TaskControl與一個(gè)名為ShardManager的數(shù)據(jù)服務(wù)協(xié)同工作，該服務(wù)決定數(shù)據(jù)在Facebook網(wǎng)絡(luò)中的放置和復(fù)制。這一切都是自動(dòng)完成的，程序員不必為此大驚小怪。

按比例控制按比例存儲(chǔ)

正如你可能想象的那樣，管理Tupperware和其他Facebook服務(wù)中的控制平面的數(shù)據(jù)是一項(xiàng)很大的工作，為此，F(xiàn)acebook正在談?wù)撘环N新的復(fù)制存儲(chǔ)系統(tǒng)Delos，部署在Facebook堆棧的控制平面中，最終可能成為文件和對(duì)象存儲(chǔ)的架構(gòu)。

在Delos創(chuàng)建之前，F(xiàn)acebook軟件的各種控制平面中使用的數(shù)據(jù)以各種不同的方式存儲(chǔ)，有些使用MySQL，有些使用ZooKeeper，有些使用其他鍵值存儲(chǔ)或數(shù)據(jù)庫(kù)。與大多數(shù)公司一樣，每個(gè)獨(dú)特的應(yīng)用程序似乎都需要一個(gè)獨(dú)特的數(shù)據(jù)存儲(chǔ)或數(shù)據(jù)庫(kù)，具有自己的API、性能、容錯(cuò)和部署方法?？刂破矫娴倪@些存儲(chǔ)系統(tǒng)通常必須從頭開(kāi)始設(shè)計(jì)，并在每次向這些控制平面添加一組新特性時(shí)重寫(xiě)。這真是件麻煩事。

因此，F(xiàn)linn告訴“Next平臺(tái)”，F(xiàn)acebook放棄了使用Delos的單片存儲(chǔ)系統(tǒng)設(shè)計(jì)。

Flinn解釋說(shuō)，Delos背后的想法是圍繞可重構(gòu)、虛擬、分布式共享塊的新抽象構(gòu)建一個(gè)存儲(chǔ)系統(tǒng)，這允許我們滿足控制平面的許多獨(dú)特目標(biāo)。所以你有了高可靠存儲(chǔ)的標(biāo)準(zhǔn)：它必須是高可用的，它必須是強(qiáng)一致的。它還必須有一個(gè)相當(dāng)豐富的API，其中包含一些類似于帶有輔助索引的關(guān)系查詢的內(nèi)容，以及一些查詢規(guī)劃和復(fù)雜謂詞。它還必須運(yùn)行在各種各樣的硬件上，我們***的和***的機(jī)器上，它們的存儲(chǔ)空間肯定是***的，但是它也應(yīng)該運(yùn)行在舊的機(jī)器上，這些機(jī)器可能與它提供元數(shù)據(jù)的服務(wù)位于同一位置。***，在我看來(lái)，這方面***的要求，也是Delos所提供的獨(dú)特之處之一，就是它必須沒(méi)有依賴關(guān)系，而且它的設(shè)計(jì)目標(biāo)是在堆棧的底部。這簡(jiǎn)化了一些事情，比如打開(kāi)一個(gè)新的數(shù)據(jù)中心、恢復(fù)工作等等。

Delos背后的關(guān)鍵思想是，所謂物化的數(shù)據(jù)狀態(tài)與存儲(chǔ)的順序和持久性方面是分離的，并且可以從相對(duì)簡(jiǎn)單的日志構(gòu)建具有不同級(jí)別容錯(cuò)或復(fù)制的更復(fù)雜的日志。像下圖這樣：

VirtualLog可以切換模式，以一種SimpleLog格式操作另一種SimpleLog格式，同時(shí)仍然在更高的具體化級(jí)別上維護(hù)狀態(tài)，這就是關(guān)系、鍵值、文件系統(tǒng)和其他API對(duì)外公開(kāi)的方式。這樣做的好處是，可以在不破壞上層API層的情況下完全更改存儲(chǔ)系統(tǒng)的底層，這意味著兩件事：存儲(chǔ)系統(tǒng)可以具有多個(gè)并發(fā)的特性，并且可以根據(jù)需要獨(dú)立地更新不同的層。

Delos的***個(gè)用例是創(chuàng)建一個(gè)名為DelosTable的關(guān)系系統(tǒng)，它位于Tupperware資源代理下面，取代了Facebook從Hadoop堆棧的開(kāi)源ZooKeeper項(xiàng)目創(chuàng)建的定制ZKLog系統(tǒng)。起初，F(xiàn)acebook將DelosTable放在ZKLog之上運(yùn)行，四個(gè)月后，它能夠使用原生的SimpleLog格式替換掉ZKLog層，該格式基于LogDevice系統(tǒng)，F(xiàn)acebook在Tupperware生產(chǎn)軟件環(huán)境中開(kāi)放了一段時(shí)間。下面是運(yùn)行Tupperware資源代理的每種不同日志格式的性能概要：

Flinn在Delos的帖子中解釋說(shuō)，我們根據(jù)延遲SLA在分解的日志設(shè)備排序?qū)雍途酆系谋镜厝罩九判驅(qū)又g動(dòng)態(tài)切換。當(dāng)滿足延遲SLA時(shí)，我們選擇聚合實(shí)現(xiàn)(它使用更少的資源，并且沒(méi)有關(guān)鍵路徑依賴關(guān)系)，當(dāng)違反延遲SLA時(shí)，我們切換到分解實(shí)現(xiàn)。

顯然，與使用ZKLog相比，使用LogDevice格式甚至NativeLog格式在減少延遲和提高整體性能方面有巨大的好處，這有利于Tupperware控制平面。當(dāng)下一個(gè)想法出現(xiàn)時(shí)，將它整合到Delos并進(jìn)一步提高性能或可伸縮性將相對(duì)容易。

譯者：Mr.lzc，軟件工程師、DevOpsDays深圳核心組織者&志愿者，目前供職于華為，從事云存儲(chǔ)工作，以Cloud Native方式構(gòu)建云文件系統(tǒng)服務(wù)，專注于Kubernetes、微服務(wù)、Serverless領(lǐng)域。