【編者的話】如今，Kubernetes***管理大約5000個節點，這不但與Borg或Tupperware的可擴展性相去甚遠，而且做不到無感知地調度不同區域的節點。本文通過介紹Tupperware與Delos背后的一些思想以及完成的一些工作，最終Facebook能夠隨時隨地使用其全球資源，而不再考慮數據中心和區域。

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

Kubernetes是5年前由谷歌開源的，并不是說谷歌內部Borg和Omega集群以及容器控制系統對Kubernetes沒有很好的啟發。實際上，谷歌并沒有直接拉取Borg代碼，將其關鍵信息清理干凈，然后將其轉儲到GitHub上，而是用Go編程語言(谷歌也創建了這種語言)從零開始創建了Kubernetes，并在周圍建立了一個社區，取得了巨大的成功。在這一點上，沒有人會因為選擇Kubernetes作為應用程序構建的下一代容器編排平臺而被解雇。

但這并不意味著Facebook等其他超大規模公司沒有遇到大規模的問題，也沒有以Kubernetes沒有努力解決或解決的方式來解決這些問題，即使谷歌在內部也面臨著與Borg和Omega類似的問題。遺憾的是，Facebook不會創建一個開源版本的Tupperware容器集群和控制器，或新的Delos存儲服務支撐當前迭代控制平面的Tupperware，這兩者都是在上周晚些時候Facebook的系統規模活動上討論的。

Tupperware系統的構建非常精確，能夠運行Facebook的應用程序和數據服務，很難創建一個通用版本的控制器來整合和支持企業中運行的各種服務。谷歌的Borg和Omega也是如此，它花了相當大的努力重寫了Borg和Omega的核心部分，使其成為一個通用的集群和容器控制器，老實說，Kubernetes平臺尚未完成，即使五年來它已經取得了長足的進步。

簡單地說，Chunqiang Tang是臉書負責Tupperware工作的工程經理，之前曾在IBM的TJ沃森研究中心負責云自動化研究，他向“next平臺”講述Facebook沒有計劃從Tupperware學習，然后應用它們，匯聚到Kubernetes，就像谷歌有一天可能做的那樣。(已經有很多谷歌服務在谷歌云平臺上運行在Kubernetes之上，而不是在Borg/Omega裸機上運行。)

雖然Facebook目前還沒有計劃開放與Tupperware一起使用的Delos低延遲、可插拔的應用編程接口數據存儲，但密歇根大學計算機科學與工程教授杰森·弗林(Jason Flinn)曾與Facebook一起參與Delos項目，他暗示說，這個項目僅在一年前開始，在生產中僅使用了大約四個月，所以開放它還為時尚早，即使這樣但從長遠來看是有可能的。

關鍵是，在“系統規模”會議上披露的Tupperware和Delos的信息可以用來通知和激勵其他集群和容器管理及存儲子系統的工作，包括開源和閉源。畢竟，谷歌在2005年發布的MapReduce論文直接導致雅虎創建了Hadoop。

我們對Facebook在大規模運行基礎設施方面提供的洞見感興趣，正如對兩組代碼的技術細節感興趣一樣。這些見解適用于許多人，即使代碼可能只適用于一個人。

就規模而言，Tang透露Kubernetes不能與Borg/Omega相提并論，當然也不能與Tupperware相提并論。當它***推出時，Kubernetes艱難的在數百臺服務器上運行，一年后它突破了1000個節點。根據Tang的說法，現在Kubernetes***管理大約5000個節點。這與Borg或Tupperware的可擴展性相去甚遠。谷歌和Facebook數據中心的物理集群跨越大約10萬臺機器，多個數據中心組成一個區域。在谷歌，這些物理集群被Borg分割成單元，在過去，這些單元平均有10000個節點，但有些被縮小到幾千個節點，有些被擴大到高達50000個節點。

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

眾所周知，由谷歌創建并捐贈給Linux社區的Cgroups和Namespaces是Docker和Linux容器的基礎，而Facebook部署了Linux容器并在內部向一個方向擴展，Docker抓取了Linux容器并以稍微不同的方式對它們進行了進化(我們意識到，這過于簡單化了)。我們的觀點是，在容器化方面，Facebook比谷歌落后了幾年，最終它也面臨同樣的問題，并以稍微不同的方式解決了這些問題。問題是，你不能通過集群級別的管理來提高效率，最終，你還是需要跨數據中心和區域。

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

對于Facebook來說，集群管理是一個很大的障礙，它使用了一個名為Resource Broker的工具來解決這個問題，該工具允許Facebook通過將工作從一個集群轉移到另一個集群，并將集群松散耦合到調度程序，從而對集群進行維護。Resource Broker還監視Facebook所有服務器的容量和可用性。

一旦Tupperware調度程序和物理集群之間的鏈接斷開，事情就開始變得輕松一些。現在，在每個區域或跨區域內，調度程序工作被切分，每個切分管理運行在Tupperware上的作業的子集，但關鍵是所有這些切分都被聚合起來，以顯示所管理的所有服務器、容器和工作負載的單一視圖。有趣的是，Tang說Tupperware調度程序中負責將容器分配到其管理下的服務器的分配器功能強大，足以在不分片的情況下處理整個Facebook區域(這并不意味著Facebook不會因為其他原因而將Tupperware碎片化)。在每臺服務器上都有一個Tupperware守護進程，它將打開和刪除容器，這些容器是使用BTRFS文件系統中的自定義格式創建的，并由systemd管理。

有趣的是，Facebook一直站在單套接字服務器的前沿，尤其是Yosemite微服務器，它們被廣泛部署在Facebook上運行基礎設施軟件。這里是這樣的效果，每個Facebook數據中心現在都有更多的物理服務器，如果沒有更多的標準雙套接字機器，可能會有更多的物理服務器，這會給Tupperware帶來更多的負載，而摩爾定律(Moore’s Law)正在增加每個節點能夠支持的核心，因此也就增加了容器的數量。因此，需要分割Tupperware的工作，但希望與Tupperware的界面保持透明。

但這里還有另外一個使命，最終，Facebook希望能夠通過一個面板管理其整個機群，這將需要更多的Tupperware工作分片，以及與Facebook網絡上的工作負載相關的類似存儲分片。到目前為止，Facebook已經安裝的服務器中只有20%包含在這個巨大的共享資源池中，但最終Facebook希望能夠隨時隨地使用其全球資源，而不再考慮數據中心和區域。

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

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

除了規模之外，還有一個領域是Facebook聲稱對Kubernetes有吹噓的權利，那就是管理有狀態的應用程序——比如Facebook網站、Instagram、Messenger和WhatsApp背后的數據庫和數據存儲，包括ZippyDB、ODS Gorilla和Skuba——而不是無狀態的應用程序——比如構成Facebook應用程序前端的網絡和PHP服務器。

Tupperware控制器上增加了一項名為TaskControl的服務，該服務查看應用程序對維護與其存儲的有狀態鏈接的依賴性，然后根據這些需求決定如何部署運行這些應用程序的容器，并根據需要更新和移動它們，而不會破壞該有狀態鏈接，從而損壞或崩潰應用程序。TaskControl與一個名為ShardManager的數據服務協同工作，該服務決定數據在Facebook網絡中的放置和復制。這一切都是自動完成的，程序員不必為此大驚小怪。

按比例控制按比例存儲

正如你可能想象的那樣，管理Tupperware和其他Facebook服務中的控制平面的數據是一項很大的工作，為此，Facebook正在談論一種新的復制存儲系統Delos，部署在Facebook堆棧的控制平面中，最終可能成為文件和對象存儲的架構。

在Delos創建之前，Facebook軟件的各種控制平面中使用的數據以各種不同的方式存儲，有些使用MySQL，有些使用ZooKeeper，有些使用其他鍵值存儲或數據庫。與大多數公司一樣，每個獨特的應用程序似乎都需要一個獨特的數據存儲或數據庫，具有自己的API、性能、容錯和部署方法。控制平面的這些存儲系統通常必須從頭開始設計，并在每次向這些控制平面添加一組新特性時重寫。這真是件麻煩事。

因此，Flinn告訴“Next平臺”，Facebook放棄了使用Delos的單片存儲系統設計。

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

Delos背后的關鍵思想是，所謂物化的數據狀態與存儲的順序和持久性方面是分離的，并且可以從相對簡單的日志構建具有不同級別容錯或復制的更復雜的日志。像下圖這樣：

VirtualLog可以切換模式，以一種SimpleLog格式操作另一種SimpleLog格式，同時仍然在更高的具體化級別上維護狀態，這就是關系、鍵值、文件系統和其他API對外公開的方式。這樣做的好處是，可以在不破壞上層API層的情況下完全更改存儲系統的底層，這意味著兩件事：存儲系統可以具有多個并發的特性，并且可以根據需要獨立地更新不同的層。

Delos的***個用例是創建一個名為DelosTable的關系系統，它位于Tupperware資源代理下面，取代了Facebook從Hadoop堆棧的開源ZooKeeper項目創建的定制ZKLog系統。起初，Facebook將DelosTable放在ZKLog之上運行，四個月后，它能夠使用原生的SimpleLog格式替換掉ZKLog層，該格式基于LogDevice系統，Facebook在Tupperware生產軟件環境中開放了一段時間。下面是運行Tupperware資源代理的每種不同日志格式的性能概要：

Flinn在Delos的帖子中解釋說，我們根據延遲SLA在分解的日志設備排序層和聚合的本地日志排序層之間動態切換。當滿足延遲SLA時，我們選擇聚合實現(它使用更少的資源，并且沒有關鍵路徑依賴關系)，當違反延遲SLA時，我們切換到分解實現。

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

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