Docker-Swarm，Kubernetes，Mesos和Core-OS Fleet

作者: 我头上有犄角
发布时间: 2024-08-22 01:05:56 (24天前)
转自：

5 条回复

0#
回复此人
筱梨 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 我认为最简单的答案是没有简单的答案。容器的迅速崛起，特别是Docker为“容器调度和编排”留下了力量真空，无论这意味着什么。实际上，这意味着你有许多技术可以在某些层面上协调工作，但在竞争中具有某些方面。例如，Kubernetes可以用作在计算集群上部署和管理容器的一站式服务（如谷歌最初设计的那样），但也可以位于Fleet上面，利用Fleet在CoreOS上提供的弹性层。 <a href="https://www.youtube.com/watch?v=tsk0pWf4ipw"> 正如谷歌视频所述 </A> Kubernetes不是一个完整的开箱即用容器扩展解决方案，但是从一开始就是一个很好的声明。同样地，你会在某个阶段期望Apache Mesos能够与Kubernetes合作，但不能与Marathon合作，因为Marathon似乎与Kubernetes一样。在某些地方，我认为我读过这些可能会成为同样努力的一部分，但我可能错了 - 它确实是关于Mesosphere的战略方向和Kubernetes原则的相应采用。 在DockerCon主题演讲中，Solomon Hykes建议Swarm将是一个可以为许多编排和调度框架提供通用接口的层。从我所看到的，Swarm旨在提供一个流畅的Docker部署工作流，与一些现有的容器工作流框架（如Deis）一起工作，但足够灵活，可以实现“重量级”部署和资源管理，如Mesos。 希望这会有所帮助 - 这可能是一个巨大的职位。我认为关键在于这些是年轻的，不断发展的服务，可能会合并并变得可互操作，但我们需要在接下来的12个月中试一试，看看它是如何发挥作用的。这个问题上有一些非常聪明的人，所以未来看起来非常光明。 </DIV>

编辑
1#
回复此人
听风～ | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 对于2017年以后的任何人来说，舰队都被弃用了。不要再使用它了。 <a href="https://coreos.com/fleet/docs/latest/" rel="noreferrer"> 舰队文档 </A> 说“舰队不再由CoreOS积极开发或维护”并链接到 <a href="https://coreos.com/blog/migrating-from-fleet-to-kubernetes.html" rel="noreferrer"> 集装箱编排：从车队搬到Kubernetes </A> 。 Fleet从Container Linux中删除（ <a href="https://coreos.com/blog/tectonic-self-driving.html" rel="noreferrer"> 以前称为CoreOS Linux </A> ）并用Kubernetes kubelet（代理商）代替。这恰好是企业提供的支点 <a href="https://coreos.com/tectonic/" rel="noreferrer"> 构造 </A> （一个Kubernetes发行版）作为他们的主要产品。 </DIV>

编辑
2#
回复此人
v-star*위위 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 据我了解： Mesos，Kubernetes和Fleet都试图解决一个非常相似的问题。我们的想法是，您从开发人员那里抽象出所有硬件，并且“集群管理工具”会为您排序。然后你需要做的就是给集群一个容器，给它一些信息（保持它永久运行，如果X发生就扩展等），集群管理器将实现它。 使用Mesos，它可以为您完成所有集群管理，但不包括调度程序。调度程序是说，好的，这个过程需要2个proc和512MB RAM，我有一台机器那边有免费的，所以我将在那台机器上运行它。 Mesos有一些插件调度程序：Marathon和Chronos，你可以编写自己的。这为您提供了大量的资源分配和集群扩展等功能。 Fleet和Kubernetes似乎抽象出那些细节（所以你基本上不必编写自己的调度程序）。这意味着您必须定义您的任务并以Fleet或Kubernetes定义的格式/方式提交它们，然后他们接管并为您安排任务（容器）。 所以我猜：使用Mesos可能意味着在编写自己的调度程序方面会有更多工作，但如果需要，可能会提供更多灵活性。 我认为在Mesos上运行Kubernetes的想法是Kubernetes充当Mesos的调度程序。就个人而言，我不确定这会带来什么好处，而不是自己运行一个或另一个（希望有人会跳进去解释！） 正如MikeB所说......这是早期的事情，而且一切都在争夺（同时关注亚马逊的ECS）所以有许多竞争标准和很多重叠！ -edit-我没有提到Docker swarm，因为我对它没有多少经验。 </DIV>

编辑
3#
回复此人
敢嫁就敢娶 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 的 披露：我是Kubernetes的首席工程师 </强> 我认为Mesos和Kubernetes主要是为了解决运行集群应用程序的类似问题，他们有不同的历史和解决问题的不同方法。 Mesos将精力集中在非常通用的调度上，并插入多个不同的调度程序。这意味着它使Hadoop和Marathon等系统能够在同一个调度环境中共存。 Mesos不太关注运行容器。 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。你可以在这里看到一堆讨论： <a href="https://github.com/docker/docker/pull/8859"> https://github.com/docker/docker/pull/8859 </A> 和这里： <a href="https://github.com/docker/docker/issues/8781"> https://github.com/docker/docker/issues/8781 </A> 希望有所帮助！如果您想多谈一下，请加入我们的IRC @＃google-containers。 </DIV>

编辑

登录后才能参与评论