Java ApacheMesos实际上做什么？

我正在努力想办法，需要澄清一些问题

我对Mesos的理解是，它是一个可执行文件，安装在集群中的每个物理/VM服务器（“节点”）上，然后（以某种方式）提供一个javaapi，将每个节点视为计算资源（CPU/RAM/等）的集合。因此，对于使用JavaAPI编码的程序，它们只看到一组资源，不必担心代码如何/在何处部署

首先，我的理解可能是根本错误的（在这种情况下，请纠正我！）。但如果我的目标是，那么JavaAPI（由Mesos提供）如何允许Java客户机利用这些资源？！？有人能举一个具体的例子吗

---

更新 看看我下面那张糟糕的画。如果我正确理解Mesos架构，我们有一个由3台物理服务器组成的集群（

phys01

、

phys02

和

phys03

）。这些物理卡中的每一个都运行一个Ubuntu主机（或者其他什么）。通过hypervisor，比如Xen，我们可以运行1+vm

我对Docker&CoreOS感兴趣，所以我将在本例中使用它们，但我猜这同样适用于其他非容器设置

所以在每个虚拟机上我们都有CoreOS。在每个CoreOS实例上运行的是一个Mesos可执行文件/服务器。集群中的所有Mesos节点都将它们下面的所有内容视为单个资源池，工件可以任意部署到Mesos集群，Mesos将确定实际将它们部署到哪个CoreOS实例

在Mesos上跑步是一种“Mesos框架”，如马拉松或Kubernetes。Kubernetes内部运行着各种Docker容器（

C1

-

C4

）

---

这种对Mesos的理解或多或少是正确的吗？

你的总结几乎是正确的，但它没有反映Mesos所代表的本质。项目背后的公司mesosphere的愿景是创建一个“数据中心操作系统”，mesos是它的内核，类似于普通操作系统的内核。 API不限于java，可以使用C++、C++、java／Scala或Python。 如果您已经设置了mesos集群，正如您在问题中所描述的，并且希望使用您的资源，那么您通常通过一个框架来完成这项工作，而不是直接在框架上运行您的工作负载。这并不意味着这是复杂的，这证明了这一点。框架适用于多种流行的分布式数据处理系统，如。还有其他框架，比如数据中心级别的cron，或者允许您运行基于Docker的应用程序

更新：

是的，mesos将关注集群中的位置，因为内核就是这样做的——调度和管理有限的资源。然而，您所绘制的设置提出了几个明显的问题

介观层以下的层： 这是可能的，但我认为很麻烦。这不是运行mesos的典型场景——通常情况下，它会移动到尽可能低的层（在您的例子中，位于Ubuntu之上）。因此，我希望您有足够的理由运行CoreOS和虚拟机监控程序

介观层之上的层： Kubernetes是可用的框架，而中间层似乎在其中投入了很多精力。然而，毫无疑问，在功能方面存在部分重叠——特别是在调度方面。如果您想根据容器安排基本的工作负载，您最好使用容器，或者在将来使用容器。所以我也希望你们有充分的理由做出这样的安排。

---

旁注：Kubernetes与马拉松相似，其方法更为广泛，而且相当固执己见。

非常感谢@vanthome（+1）-请查看我的更新和绘图。我的要点正确吗？如果是这样的话，我仍然不理解Mesos节点和运行在它们上面的“框架”（如Marathon或Kubernetes）之间的不同角色，您有没有机会详细说明一下？再次感谢！那么，与虚拟服务器相比，mesos在物理服务器上工作得最好，这公平吗？如果是或不是，原因是什么？@CharlesPrakashDasari一般来说，所有分布式资源管理系统都应该在裸机上运行，因为根据经验，如果将虚拟化系统层层叠加，每一层将消耗约10%的IO性能。CPU和内存开销通常可以忽略不计，但在许多地方，我看到框架（Marathon/Aurora/Kubernetes的框架组件）执行“调度”，因此它是调度器。但是你说Mesos做调度，因为它是内核在一个地方的工作，而框架在另一个地方做调度。正如你所说的，Mesos和FW的日程安排似乎重叠。在我看来，查找资源似乎是调度器的核心工作，但这项工作是由Mesos完成的，Mesos是框架/调度器下面的一层。那么框架（应该是调度器）的工作是什么呢？在粒度级别上，“调度”的各个子工作是什么？调度的哪些部分是由Mesos完成的，调度的哪些部分是由框架完成的？我认为Mesos节点并不将底层的所有内容视为单个资源池，而是将其上的层视为框架。我说得对吗？