如果你想知道Kubernetes容器管理系统的未来会是什么样子，那么Facebook一直在使用和开发封闭的源代码，自行开发的Tupperware容器控制系统（在Docker容器和Kubernetes出现之前）可能是一个非常好的一个很好的灵感来源。
Kubernetes五年前由谷歌开源。谷歌的内部Borg和Omega集群以及集装箱控制系统并不是对Kubernetes的鼓舞。事实上，谷歌没有直接提取Borg代码，清理其关键信息，并将其转储到GitHub上。相反，它使用Go编程语言（谷歌也创建了）从零开始创建了Kubernetes。围绕它建立了一个社区，并取得了巨大的成功。此时，选择Kubernetes作为为应用程序构建的下一代容器编排平台，将不会被解雇。
但这并不意味着其他非常大的公司如Facebook没有遇到大规模的问题，也没有以Kubernetes努力解决或解决的方式解决这些问题，即使Google面临类似的内部问题博格和欧米茄。不幸的是，Facebook不会创建Tupperware容器集群和控制器的开源版本，或者新的Delos存储服务将支持当前的迭代控制平面Tupperware，这两个版本都是上周晚些时候Facebook的系统规模活动。讨论。Tupperware系统构建得非常准确，运行Facebook应用程序和数据服务，因此很难创建控制器的通用版本来集成和支持企业中运行的各种服务。谷歌的Borg和Omega也是如此，它花了相当大的精力重写Borg和Omega的核心部分，使其成为通用集群和容器控制器。说实话，Kubernetes平台还没有完成，即使已经五年了。取得了很大进展。如果你想与更多Kubernetes技术专家沟通，你可以加我WeChat liyingjiese，注意“添加组”。每周都有来自世界各地主要公司的最佳实践和行业更新。
简单地说，Chunqiang Tang是负责Tupperware在Facebook工作的工程经理。他负责IBM TJ Watson研究中心的云自动化研究。他告诉“下一个平台”，Facebook没有计划向特百惠学习，然后将它们用于收集。去Kubernetes，就像谷歌可能有一天做的那样。 （Google云平台上的Kubernetes上已经有很多Google服务，而不是Borg/Omega裸机上。）
虽然Facebook目前没有计划用Tupperware打开Delos的低延迟，可插拔的应用程序编程接口数据存储，但密歇根大学计算机科学与工程教授Jason Flinn参与了Facebook的Delos项目。他暗示该项目仅在一年前启动，仅用了大约四个月的生产时间，因此现在开启它还为时尚早。即便如此，从长远来看也是可能的。
关键是在“系统规模”会议上披露的有关特百惠和Delos的信息可用于通知和激励其他集群和容器管理和存储子系统，包括开源和封闭源。毕竟，谷歌在2005年发布的MapReduce论文直接导致雅虎创建了Hadoop。
我们对Facebook对运行基础设施规模的见解很感兴趣，就像我们对这两组代码的技术细节感兴趣一样。这些见解适用于许多人，即使代码可能仅适用于一个人。
在规模方面，Tang透露Kubernetes无法与Borg/Omega相提并论，当然也无法与Tupperware相提并论。当它首次推出时，Kubernetes很难在数百台服务器上运行，一年后它突破了1000个节点。根据Tang的说法，Kubernetes现在管理着约5,000个节点。这与Borg或Tupperware的可扩展性相去甚远。 Google和Facebook数据中心的物理集群跨越大约100,000台机器，并且多个数据中心构成一个区域。在谷歌，这些物理集群被博格拆分为单位。在过去，这些单元平均有10,000个节点，但有些节点缩小到数千个节点，有些节点扩展到多达50,000个节点。当最初构思Tupperware时，Facebook与大多数数据中心一样，从机架，集群和数据中心的角度组织了特百惠，这些结构通常具有难以触及的物理配置。同样在2010年初，当Docker容器甚至不存在（并且多年不会投入生产）时，Facebook首先使用chroot来运行沙盒应用程序，以便它们可以在物理Linux服务器上同时运行。就像Google已经做了很长时间一样，随着命名空间的成熟，Facebook也使用这些来提供工作负载之间的隔离。
众所周知，Google创建并向Linux社区捐赠的Cgroups和Namespaces是Docker和Linux容器的基础，而Facebook则部署Linux容器并在一个方向内部扩展。 Docker抓取Linux容器并以稍微不同的方式处理它们。进化已经发生（我们意识到这太简单了）。我们认为，就集装箱化而言，Facebook几年来一直落后于谷歌，最终它面临着同样的问题，并以稍微不同的方式解决了这些问题。问题是您无法通过集群级别的管理来提高效率。最终，您仍需要跨越数据中心和区域。
如今，特百惠不再考虑机架，集群和数据中心。相反，它为单个区域的多个数据中心提供了一个抽象层，可以拥有数十万个物理服务器，有时甚至跨越世界的多个区域。特百惠已经从管理集群管理工具发展成为一个有意识的工具，对于在Facebook上部署应用程序的程序员来说很简单，例如部署应用程序以在普林斯维尔地区的不同数据中心运行。或者在Princeville和Lula数据中心部署此应用程序，并根据可用性计算Tupperware。这不是无服务器计算——对于我们来说，这是一个愚蠢的术语——，但系统没有管理计算，这是所有数据中心的最终目标，如果你想说实话（系统管理员不会这样做，除非他们计划到是该公司唯一聘用的现场可靠性工程师）。
对于Facebook来说，集群管理是一个很大的障碍。它使用一个名为Resource Broker的工具来解决这个问题。此工具允许Facebook通过将工作从一个群集移动到另一个群集来松散地耦合群集。转到调度程序以维护群集。 Resource Broker还监控所有Facebook服务器的容量和可用性。一旦特百惠调度程序和物理集群之间的链接中断，事情就会变得更容易。现在，在每个区域或跨区域，调度程序工作被拆分，每个拆分管理在Tupperware上运行的作业的子集，但关键是所有这些剪切都被聚合以显示所有服务器，容器的托管单个视图和工作量。有趣的是，Tang表示，Tupperware调度程序的分配器负责将容器分配给它管理的服务器，其强大到足以处理整个Facebook区域而不会出现碎片（这并不意味着Facebook不会出于其他原因）。特百惠是碎片化的。在每台服务器上都有一个Tupperware守护程序，它将打开并删除在BTRFS文件系统中使用自定义格式创建并由systemd管理的容器。
未来的Kubernetes将遵循Facebook的方法
有趣的是，Facebook一直处于单插槽服务器的最前沿，特别是Yosemite微服务器，它们被广泛部署在Facebook上以运行基础设施软件。这是效果，每个Facebook数据中心现在有更多的物理服务器，如果没有更多的标准双插槽机器，可能会有更多的物理服务器，这将为特百惠负载带来更多，而摩尔定律正在增加核心数量每个节点都可以支持，从而增加了容器的数量。因此，您需要拆分Tupperware的工作，但希望通过Tupperware的界面保持透明性。
但这里还有另一个使命。最终，Facebook希望通过单一面板管理其整个车队，这将需要更多的Tupperware工作分片和与Facebook网络上的工作负载相关的类似存储分片。到目前为止，Facebook已安装的服务器中只有20％包含在这个庞大的共享资源池中，但最终Facebook希望能够随时随地使用其全球资源，而无需考虑数据中心和地区。
这是另一个有趣的观察。 Borg考虑工作量的方式是在线工作和批处理工作。调度程序的主要工作是通过批处理工作（例如MapReduce数据分析工作）填充空闲容量，直到在线工作（需要更多容量，例如填充搜索引擎请求。因此，这两种类型的工作交错进行系统，按比例扩大和减少使用，以提高利用率。Facebook采用了不同的方法，并考虑了原始服务器级别。首先，当使用微服务器时，每个服务器节点具有较少量的原始计算，因此与使用双插槽机器相比，分割更少（这是由于AMD罗马Epyc处理器的核心数量很大）。更改）。在Facebook上，程序员被教导以他们使用他们可以在服务器上使用的所有容量的方式编码。在每个区域的夜晚，当新闻源，Messenger，Web前端和应用程序的其他层未被大量使用时，该区域中的服务器节点执行各种批处理作业，例如MapReduce分析和统计机器学习（毕竟，并非所有东西都需要GPU来进行深度学习。因此，不要担心在线或批处理工作在每个物理服务器上使用Resource Broker提供不同容器的数量，Facebook会为每个服务器分配批处理或在线工作，确保它完好无损地运行以获得最有价值的消耗。这是Google和Facebook之间的一个有趣的区别。在Facebook中，容器实际上是一种部署机制，而不是工作负载隔离工具。
除了规模之外，还有另一个领域，Facebook声称有权吹嘘Kubernetes，即管理有状态的应用程序，如Facebook，Instagram，Messenger和WhatsApp背后的数据库和数据存储，包括ZippyDB，ODS Gorilla和Skuba——而不是无状态应用程序——，例如构成Facebook应用程序前端的网络和PHP服务器。

• 上一篇: 蓝盟IT外包，元宇宙：四梁八柱是什么
  下一篇: 选择基于云的文件共享服务

• 分享到：