Docker-群，Kubernetes，Mesos & core-OS 舰队

我对所有这些都是相对较新的，但我在清楚地了解所列出的技术方面遇到了困难。

虽然，所有这些都试图解决不同的问题，但也有共同点。我想知道什么是共同的，什么是不同的。如果是这样的话，那么几个人的组合很可能是非常合适的，他们是什么？

我列出了其中的一些问题，但是如果有人能够详细列出所有的问题并回答这些问题，那就太好了。

  1. 库伯内特斯 VS 梅索斯:

    这个链接

    Apache 的 Mesos 和 Google 的 Kubernetes 有什么不同

    能够很好地洞察这些差异，但我无法理解为什么库伯内特斯应该在 Mesos 之上竞选。它是否更多地与两个开源解决方案的结合有关？

  2. Kubernetes vs Core-OS Fleet:

    如果我使用库伯内特，是否需要舰队？

  3. Docker-Swarm 是如何融入上述所有情况的？

31872 次浏览
小开

我认为最简单的答案是没有简单的答案。集装箱(尤其是 Docker)迅速崛起，为“集装箱调度和编排”(不管这可能意味着什么)留下了权力真空。在现实中，这意味着你有许多技术可以在某些层面上协调工作，但在某些方面的竞争。例如，Kubernetes 可以作为在计算集群上部署和管理容器的一站式商店(正如 Google 最初设计的那样) ，但也可以位于 Fleet 之上，利用 Fleet 在 CoreOS 上提供的弹性层。

正如这个 Google vid 指出的那样，Kubernetes 并不是一个完整的盒子式容器缩放解决方案，但是它是一个很好的开始。同样，在某个阶段，您可能希望 Apache Mesos 能够与 Kubernetes 一起工作，但不能与 Marathon 一起工作，因为 Marathon 似乎履行了与 Kubernetes 同样的角色。在某些地方，我认为我已经阅读了这些可能成为同样的努力的一部分，但我可能是错误的-这真的是关于中间层的战略方向和相应的采用库伯内特原则。

在 DockerCon 的主题演讲中，Solomon Hykes 提出 Swarm 将是一个可以为许多编排和调度框架提供通用接口的层。据我所知，Swarm 的设计目的是提供一个平稳的 Docker 部署工作流，可以与一些现有的容器工作流框架(如 Deis)协同工作，但也足够灵活，可以屈服于“重量级”部署和资源管理(如 Mesos)。

希望这能有所帮助——这可能是一篇巨大的文章。我认为关键在于，这些都是年轻的、不断发展的服务，它们可能会合并，变得可互操作，但我们需要熬过接下来的12个月，看看它们会如何发展。在这个问题上有一些非常聪明的人，所以前景看起来非常光明。

小开

据我所知:

Mesos，Kubernetes 和 Fleet 都在试图解决一个非常相似的问题。这个想法是，你从开发人员那里抽象出所有的硬件，然后“集群管理工具”为你把它们全部分类。然后你所需要做的就是给集群一个容器，给它一些信息(让它永久运行，如果 X 发生了，扩展它等等) ，集群管理器就会让它发生。

在 Mesos 中，它为您完成所有的集群管理，但不包括调度程序。调度程序就是这样一个位，这个过程需要2个处理器和512MB 的内存，我有一台机器有这么多空闲时间，所以我要在那台机器上运行它。有一些插件调度程序可用于 Mesos: 马拉松和 Chronos，你可以编写自己的。这给了你很大的资源分配和集群扩展能力等等。

Fleet 和 Kubernetes 似乎抽象出了这些细节(所以基本上不需要编写自己的调度程序)。这意味着您必须定义您的任务，并以 Fleet 或 Kubernetes 定义的格式/方式提交它们，然后他们接管并为您安排任务(容器)。

所以我想: 使用 Mesos 可能意味着在编写您自己的调度程序方面需要做更多的工作，但是如果需要的话，可能会提供更大的灵活性。

我认为，在 Mesos 之上运行库伯内特斯的想法是，库伯内特斯充当 Mesos 的调度员。就我个人而言，我不知道这样做会给自己带来什么好处(希望有人能介入并解释一下!)

就像 MikeB 说的。.现在还处于早期阶段，所有的东西都可以抓住(也要关注亚马逊的 ECS) ，所以有很多竞争标准和很多重叠！

- 编辑-我没有提到 Docker 群因为我没有太多的经验。

小开
最佳答案

我是 Kubernetes 的首席工程师

我认为 Mesos 和 Kubernetes 主要是为了解决类似的运行集群应用程序的问题，他们有不同的历史和不同的方法来解决这个问题。

Mesos 将精力集中在非常通用的调度上，并插入多个不同的调度程序。这意味着它使得 Hadoop 和 Marathon 这样的系统能够在相同的调度环境中共存。Mesos 较少关注运行容器。在对集装箱广泛感兴趣之前，中间层就已经存在，而且为了支持集装箱，已经在一些部分进行了重构。

相比之下，Kubernetes 从头到尾被设计成一个从容器构建分布式应用程序的环境。它包括用于复制和服务发现的原语作为核心原语，这些东西是通过 Mesos 的框架添加的。Kubernetes 的主要目标是建立、运行和管理分布式系统的系统。

Fleet 是一个低级任务分配器。它对于引导集群系统非常有用，例如，CoreOS 使用它将 kubernetes 代理和二进制文件分发到集群中的机器，以便产生 kubernetes 集群。它实际上并不打算解决同样的分布式应用程序开发问题，对于您的集群来说，可以将它看作是 systemd/init.d/upstart。如果您运行 kubernetes，则不需要它，您可以使用其他工具(例如 Salt、 Puppet、 Ansible、 Chef，...)来完成相同的二进制分发。

Swarm 是 Docker 对现有 Docker API 的扩展，以使一个机器集群看起来像一个单独的 Docker API。从根本上说，我们在 Google 和其他地方的经验表明，节点 API 对于集群 API 来说是不够的。你可以在这里看到一些讨论: https://github.com/docker/docker/pull/8859和这里: https://github.com/docker/docker/issues/8781

希望这能有所帮助! 如果你想了解更多，请加入我们的 IRC@# google-Container。

小开

对于任何人来到这2017年以后的舰队是不建议的。不要再使用它。

舰队文档说“舰队不再由 CoreOS 积极开发或维护”并链接到 货柜编配: 由船队迁往 Kubernetes。舰队从容器 Linux (前身为 CoreOS Linux)删除，取而代之的是库伯内特斯库贝莱(代理)。这与公司转向提供 地质构造(一个 Kubernetes 发行版)作为他们的主要产品是一致的。


提交答案