未来的Kubernetes将效仿Facebook的做法

有趣的是，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网络中的放置和复制。这一切都是自动完成的，程序员不必为此大惊小怪。

按比例控制按比例存储

（编辑：西安站长网）

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