我正试着绕着ApacheMesos转，需要澄清几个问题。
我对mesos的理解是，它是一个可执行文件，安装在集群中的每个物理/vm服务器（“节点”）上，然后（以某种方式）提供一个javaapi，将每个节点视为计算资源（cpu/ram/等）的集合。因此，对于使用javaapi编写代码的程序，它们只看到一组资源，不必担心代码是如何/在何处部署的。
因此，首先，我的理解可能是根本错误的（在这种情况下，请纠正我！）。但是如果我的目标是，那么javaapi（由mesos提供）如何允许java客户机访问这些资源呢？！？有人能举一个具体的例子吗？
更新
看看我下面糟糕的画。如果我正确理解mesos架构，我们有一个由3个物理服务器组成的集群( phys01 , phys02 以及 phys03 ). 每个物理层都运行一个ubuntu主机（或者别的什么）。通过hypervisor，比如xen，我们可以运行1+vms。
我对docker&coreos很感兴趣，所以我将在本例中使用它们，但我猜这同样适用于其他非容器设置。
所以在每个虚拟机上我们都有coreos。在每个coreos示例上运行的是一个mesos可执行文件/服务器。集群中的所有mesos节点都将它们下面的所有内容视为一个单一的资源池，工件可以任意部署到mesos集群，mesos将确定实际将它们部署到哪个coreos示例。
在mesos之上跑步是一个“mesos框架”，比如马拉松或kubernetes。kubernetes内部运行着各种docker容器( C1 - C4 ).
这种对Mesos的理解或多或少是正确的吗？
1条答案
按热度按时间isr3a4wc1#
你的总结几乎是对的，但它并没有反映mesos所代表的本质。项目背后的公司mesosphere的愿景是创建一个“数据中心操作系统”，mesos是它的内核，类似于普通操作系统的内核。api不限于java，您可以使用c、c++、java/scala或python。如果您已经设置了mesos集群，正如您在问题中所描述的，并且希望使用您的资源，那么您通常通过一个框架来完成这项工作，而不是直接在框架上运行您的工作负载。这并不意味着这是复杂的，这里是一个非常小的例子，在scala中演示了这一点。框架适用于多种流行的分布式数据处理系统，如apachespark、apachecassandra。还有其他一些框架，比如数据中心级的cron chronos或marathon，它们允许您运行基于docker的应用程序。
更新：
是的，mesos会关心集群中的位置，因为内核就是这样做的——调度和管理有限的资源。不过，您所绘制的设置引发了几个明显的问题。
mesos下面的层：在coreos上安装mesos是可能的，但我认为很麻烦。对于运行mesos来说，这不是一个典型的场景——通常情况下，它被移动到尽可能低的层（在您的例子中，在ubuntu之上）。所以我希望您有足够的理由运行coreos和hypervisor。
中层以上的层：Kubernetes是可用的框架和中层似乎投入了很大的努力。然而，毫无疑问，在功能方面存在部分重叠——特别是在调度方面。如果您想基于容器来安排基本的工作负载，那么最好使用marathon，或者将来使用aurora。所以我也希望你们有充分的理由做出这样的安排。旁注：kubernetes类似于马拉松，有更广泛的方法和相当固执己见的观点。