将来的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打点。

（编辑：河北网）

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