未来的Kubernetes将效仿Facebook的做法

【编者的话】如今，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平台尚未完成，即使五年来它已经取得了长足的进步。如果你想和更多Kubernetes技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。

简单地说，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管理。

（编辑：济南站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!