我的应用程序需要运行许多容器作为工作节点（以执行各种批处理作业），而我对保持 Web 服务器或数据库并不真正感兴趣 - 只是可能需要 1 秒到 1 小时之间任何时间的短作业。我的想法是针对节点云工作，而不必担心这些节点中的哪些机器有可用资源来处理我的工作（mesos 在这方面非常擅长 - 正如所宣传的那样）。
我现在正在使用 DC/OS，我想知道是否有任何其他集群技术提供此功能：given I need 1CPU, 2GB RAM and 2GB of disk - run X docker container against my nodes.
我喜欢 swarm 的想法，因为我非常熟悉 docker 本身，并且我相信它是最容易设置和自动化的（放大或缩小）。我喜欢 kubernetes（不过没有经验），因为它是免费的，而且我很确定它会长期保持这种状态。我喜欢 DC/OS，因为它捆绑了很多东西，但我不确定他们未来的计划，而且我习惯于项目切断功能以将它们包含在一个计划中，该计划会为你的 x 个节点收费。
你觉得呢？你有没有什么想法？
Kubernetes、Swarm 和 Mesos 都可以在技术上为您安排作业并为您处理受限资源。
与其他两个不同，Mesos 主要设计用于处理较低级别的分发、任务和资源管理。专注于这些位会带来更大的功能和灵活性，但也会在较低级别上带来更多的复杂性。这就是 DC/OS 存在的原因，它为您提供一系列微服务工具，可以作为更高级别的平台运行。
Mesos 还被设计为允许您使用自己的调度程序来处理任务生命周期需求，这往往是有状态任务所需要的。Kubernetes 和 Swarm 主要设计用于处理无状态服务用例，然后通过包含的调度程序进行调整以处理有状态服务和作业。
DC/OS 建立在 Mesos 之上，并带有用于作业和服务的内置调度程序，同时仍允许您在需要时构建自己的自定义调度程序。
Kubernetes 最近也增加了对自定义调度程序的支持，但它远不如 Mesos 实现和生态系统成熟，并且仍然围绕使用核心 pod 和副本集原语，这可能是授权或限制，具体取决于您的需求。
Mesosphere 最近构建了一个新的 dcos-commons 框架，以简化构建基于 JVM 的 Mesos 调度程序。因此，这可能会提高您在 DC/OS 上的工作效率。https://github.com/mesosphere/dcos-commons
Mesos & DC/OS 还为您提供了更多关于容器化的选择。如果您愿意，可以使用 Docker 映像和 Docker 容器。或者，您可以使用带有或不带有 Docker 镜像的 Mesos 容器运行时，这在工作负载和打包方面为您提供了更大的灵活性。
DC/OS 和 Kubernetes 都具有包管理器，这对于安装 Spark、Kafka 或 Cassandra 等依赖项很有用。但是 DC/OS 往往拥有更强大的数据服务，因为它们是使用自己的自定义调度程序构建的，而 Kubernetes 生态系统倾向于在其系统周围进行复杂的生命周期管理 Docker 容器包装器，因为自定义调度程序的到来较晚。如果您考虑 docker 图像“包”，Docker 还包括包管理。不同之处在于 DC/OS 和 Kubernetes 封装了可能包含多个容器的更高级别的抽象（应用程序和 Pod）。最近，Docker 添加了更高级别的抽象“堆栈”，但我认为没有任何外部存储库机制或围绕它们的大量包管理。
Swarm 绝对是最简单的，但它的原始 API 被设计为与节点 API 相同，这对于熟悉和入职非常有用，但作为更高级别的抽象而受到限制。从那以后，他们有效地重写了 swarm API 并将其作为“swarm-mode”捆绑到 docker-engine 中。这种编排引擎和容器运行时的捆绑使用户更容易安装和管理，而且还结合了以前的两个不同的抽象级别。因此，Docker 引擎不再只是编排引擎的依赖项，而是与它们竞争，这违背了 Unix 的哲学，即做好一件事并在各自的开源社区中造成一些政治混乱。Twitter、黑客新闻和聊天对话升级为关于分叉 docker的讨论这导致K8s 尝试替代方案，DC/OS 支持 Docker 镜像而不使用 Docker 引擎，以及Docker 提取容器。
他们都工作正常。选择一种取决于您的需要。我通常推荐 DC/OS，因为它解决了更多的问题，并且由许多不同的微服务工具和层组成，允许您通过针对层进行编程来支持多个用例，而不是最有意义的。披露，我确实为 Mesosphere 工作！;)