Kubernetes vs. Mesos：选择容器编排工具

容器编排在今天风靡一时并不是什么大秘密。作为许多文章和会议的主题，它有时似乎是唯一值得讨论的话题。

在Logz.io，我们现在处于将所有容器迁移到Kubernetes的过程的最后阶段，我想告诉你我们在决定使用哪个编排平台以帮助他们时所经历的过程的故事。那些仍然不确定使用哪种工具或者是否需要编排开始的人。

什么是编排，我需要它吗？

在我看来，第一个基本规则是，如果你不知道为什么需要编排，你可能不会。容器编排（我故意避免使用Docker这个词）并不适合所有人，也不能满足所有需求。

那么编排是什么？

想象一下，你有10个容器用于不同的目的。使用一堆实例并运行这些容器非常简单。当您的应用程序开始增长并且您部署的容器数量达到100时，压力会增加，但它仍然可以承受。但当你发现自己管理着成千上万的容器时，每个容器都有不同的版本，关系和网络配置，事情开始变得有点疯狂。

对于使用严重依赖容器的现代开发技术的公司而言，扩展此类架构的挑战可能无法应对。

这就是编排进入画面的地方。

业务流程基础架构的整个要点是提供一种“调度”容器的简单方法，让底层基础架构完成剩下的工作。

这听起来很神奇，但是有很多复杂的软件运行它，而且由于极其复杂的软件趋向，所有工作都非常出色，除非它不能运行。

缩小容器编排工具

在容器编排的上下文中，您将一遍又一遍地听到五个大名：Kubernetes，Mesos（DC / OS），ECS，Swarm和Nomad。决定使用哪些工具的过程将根据所涉及的公司和个人而有所不同。有时它只会归结为个人偏好。

在Logz.io，我们在消除过程之后得到了本文标题中命名的两个平台。

• Swarm - 是的，这是一个意见问题 - 被描述为对我们的需求来说太基本和简单。适合测试但不是真正适合我们在生产中使用的工具。
• 亚马逊的ECS自首次发布以来已有很大改善，但它似乎仍落后于其他主要参与者。由于我们需要一种与云无关的工具，因此ECS并不是我们真正的选择。
• 我们认为Nomad是一个太年轻的项目而且还不够成熟，无法认真考虑 - 但如果公平应对，它可能在未来进行另一次评估。

这给我们带来了两个强大的参与者 - 不断增长的人气和使用Kubernetes，以及不断发展的DC / OS。

关于DC / OS和Kubernetes

为了确保我们都指的是相同的概念，这里有一个简短的历史背景和解释，以帮助澄清问题。

Mesos是Apache的一个项目，它使您能够以分布式方式运行容器化和非容器化工作负载。

它最初是作为Berkeley的一个研究项目编写的，后来被Twitter用作谷歌Borg（Kubernetes的前身）的答案。为了解决它的高度复杂性（Mesos非常复杂且难以管理！），Mesosphere进入了画面，试图让Mesos成为普通人类可以使用的东西。

Mesosphere为Mesos提供了极好的Marathon“插件”，为用户提供了一种简单的方法来管理Mesos上的容器编排。

2016年中期，推出了由Mesosphere支持的开源项目DC / OS（数据中心操作系统），它进一步简化了Mesos，并允许您在几分钟内部署自己的Mesos集群，使用Marathon。

在本文中提及Mesos时，我指的是DC / OS。

Kubernetes？好吧，为了防止你过去几年在月球上生活，Kubernetes是一个容器编排平台，由Google于2014年中期发布，此后一直为Cloud Native Computing Foundation做出贡献。

Mesos vs. Kubernetes

首先要指出的是，您实际上可以在DC / OS上运行Kubernetes并使用它来调度容器而不是使用Marathon。这意味着所有的最大区别 - 正如其名称所暗示的那样，DC / OS更类似于操作系统而不是编排框架。您可以在其上运行非容器化的有状态工作负载。集装箱调度由Marathon处理。

简单明了，与Kubernetes相比，Marathon对API的一般方法很简单。Marathon聚合API并提供相对少量的API资源，而Kubernetes提供更多种类的资源并基于标签选择器。

第三，两个平台享有的受欢迎程度有明显差异。为什么这很重要？出于显而易见的原因 - 社区规模推动开发和提供支持。Kubernetes几乎提交了10倍，而GitHub则是Marathon的明星。

DC / OS具有“高级”订阅，可以打开额外的功能，而Kubernetes是完全开源的。

这让我想到了下一点。

为什么Kubernetes更好

在Logz.io，我是DC / OS的拥护者。我喜欢它的简单性，以及运行有状态工作负载的能力。我完全准备好放弃Kubernetes的一些优势，转而选择DC / OS。

然后我发现，自动化部署过程所需的一个简单功能仅包含在企业版中。从那时起，在与Mesosphere交谈之后，我们意识到这可能不是一次性的事情，即使我们克服了这个特定的障碍，DC / OS也是由商业公司控制的，为了更好和更好更差。

所以我们开始了我们的Kubernetes项目。

经过漫长的过程，使我们的容器适应Kubernetes的心态，或许更重要的是 - 在克服组织和文化挑战（一个完全不同的帖子的主题）之后，我们现在用Kubernetes管理数百个容器。

通过帮助我们将所有部署职责转移到现在每天多次部署新代码的开发人员，这一变化也促进了更高效的持续部署。底线 - 与Kubernetes一起转向容器编排已将“Jira门票 - >生产”开发周期缩短为30分钟。

总结

因此，虽然编排平台是城里最热门的技术之一，但它并不意味着您真正需要它。但是如果你这样做，我希望我能说明我们选择Kubernetes而不是其他现有解决方案的原因。

在未来的博客文章中，我将深入探讨安全迁移到Kubernetes所需的技术难题，以及我们必须经历的文化变革，以使Logz.io不断部署。

原文标题《Kubernetes vs. Mesos: Choosing a Container Orchestration Tool》

作者：Roi Ravhon

译者：February

不代表云加社区观点，更多详情请查看原文链接