拥抱容器，你选好管理方式了吗？

根据 451 Research，2016年，容器技术市场产生了7.62亿美元的收入。到2020年，分析公司预测，容器的年度收入将达到27亿美元，复合年增长率为40％。

容器市场大好，但是我们面临两个问题：如何确保这些容器的安全性？以及如何部署管理它们？

想要解决问题。首先，我们需要建立——

容器策略：您希望在哪里运用容器？每个 CPU 应分配多少个？ 所有这些问题，都可以通过设置正确的容器策略进行回答。

互操作性：当然，他们应该与您现有的 IT 管理工具协同运作。

OK，在有了明确的需求之后，我们就可以对目前主流的容器编排工具——Kubernetes、Mesosphere Marathon 和 Docker Swarm 进行进一步筛选，他们都可以在不改变原有架构的情况下对容器进行编排管理。

Docker Swarm

如果你刚开始接触容器，最初了解到的应该是 Docker，作为很多人的入门级容器，它吸引了大量的用户。 而 Swarm 是 Docker 本地的编排工具，算得上是 Docker 本地的集群管理器。

Docker Swarm 在2016年6月（1.12）版本中将其功能整合到完整的 Docker 应用程序中，并花了大量的精力来解决启动和运行。虽然几个新产品有启动问题，比如服务发现程序（例如 Consul 或 CoreOSetcd）是在 Docker Swarm 启动之前运行。Sysadmins 发现这个问题很难解决，即使解决这些启动问题，也还是需要花费大量的精力部署 Swarm。

所以，即便新的 Docker Swarm 努力获取用户，但目前它仍然落后于 Mesosphere 的中央操作系统（DC / OS）和 Kubernetes，但是谁能保证以后不发生变化呢？ 毕竟新改进的 Docker Swarm 确实在部署的便利性上有了提升。 我之前跟几个 DevOps 谈过，他们认为，与 Kubernetes 或 Mesos 集群相比，Docker Swarm 是一个快进版本。

所以，如果你已经是一个有经验的 Docker 用户，Swarm 的学习曲线对你来说就很容易。 Docker Native Orchestration 使用单节点 Docker 概念，并将它们扩展到 Swarm。 但一旦你有在运行的 Docker 节点，Swarm 的设置就十分繁琐。 例如，您可以使用单个 shell 命令将 Docker 实例添加到 Swarm 集群。 更新的 Swarm 还支持滚动更新，包括节点之间的传输层安全加密，以及简单的负载平衡和相对容易的服务抽象。

目前，Swarm 还有改进的余地。 例如，它当前不支持运行状况检查和自动回滚。 Swarm 用户也抱怨很多实现问题。例如， Swarm 不能正确支持多主机容器网络等。

Docker Swarm 是内置在 Docker 中的，这应该是它最大的吸引力。 不过，潜在用户应该注意的是，它就是一个运行的工作，而不是一个立马能解决您容器部署和管理问题的解决方案。

Mesosphere Marathon

Marathon 是一个用于 Mesosphere DC / OS 和 Apache Mesos 的容器编排平台。 DC / OS 是基于 Mesos 分布式系统内核的分布式操作系统。 Mesos 也是一个开源集群管理系统。 Marathon（通过其合作伙伴计划，Chronos，容错作业调度程序）提供有状态应用程序和基于容器的无状态应用程序之间的管理集成。

Marathon 的出现实际上早于容器。 Mesosphere 联合创始人和首席技术官 Tobias Knaup 在最近的一次采访中解释说，“Marathon 从一开始就被设计为一个通用的工作负载管理器，甚至在 Docker 出名之前。 他们的目标是建立一个桥梁，连通旧世界到新世界，使现有的应用程序可以部署和扩展，不需要进行太大的变化。“在 Knaup 看来，无论它是不是一个现代应用程序架构（如微服务或更传统的三层企业应用程序），至少它非常适合长时间运行。

Marathon 有一个用户界面，您可以将其视为一个应用程序，它可以看作一个框架来管理容器。这涉及DevOps 的开发人员方面，因为容器通过 REST API 与 Marathon 一起工作。

Marathon 具有许多功能，包括高可用性，服务发现和负载平衡。 如果在 DC / OS 上运行它，您的应用程序也会获得虚拟 IP 路由。

作为一个更成熟的项目，Marathon 没有 Docker Swarm 的初期问题。 另一方面，Marathon 有一个更陡峭的学习曲线。 由于 Marathon 只能在带有 Mesos 的软件堆栈上运行，这增加了另一层的复杂性。最后，一些功能（例如身份验证）仅适用于 DC / OS 上的Marathon。 这为你的堆栈又增加了一个抽象层。

Kubernetes

Kubernetes（也就是 K8S），起源于 Borg。（开源之前，Kubernetes 的名字叫做“项目7”，是 Borg 的友好版本）。

Google 在创建 Kubernetes 中的作用并不令人感到惊异。很久以前 Docker 使得容器流行起来，Google 的很多项目——搜索、Gmail、Google 文档都使用了容器技术。 Borg，以及和它的开源的继承者 Kubernetes，管理着数十亿个容器。

Kubernetes 自推出以来，就被移植到 Azure，DC / OS 以及几乎所有叫得出名字的云平台。 唯一的例外是 Amazon WebServices（AWS）。 即使在那里，CoreOS 也让用户在 AWS 上部署 Kubernetes 集群。

Kubernetes 有巨大的供应商支持。 今天，Kubernetes 由 Linux 基金会托管。 此外，还有来自众多公司的 Kubernetes 发行版，包括Red Hat OpenShift，Canonical 公司的 Kubernetes 发行版，CoreOS Tectonic 以及英特尔和 Mirantis。

为什么？ 除了证明自身在 Google 的大型数据中心，Kubernetes 拥有自我修复，自动化推出和回滚和存储编排。功能列表还在继续更新。 简而言之，无论你想用你的容器做什么，Kubernetes 都可以对它进行管理。

互操作性也是 Kubernetes 一个巨大的亮点。 Sam Ghods 是基础架构即服务（IaaS）云提供商 Box 的联合创始人，他称赞 Kubernetes，他说：“我可以编写一个 JSON 规范，并将其提交给任何地方运行的任何 Kubernetes 集群，还能够重新创建正确的拓扑和完全正确的我需要的基础设施。”

Kubernetes 的另一个优点是“对每朵云的友好性，”软件工程师 Erez Rabih 说，“你可以在 AWS，GoogleCloud，Microsoft 的 Azure、Rackspace 上运行你的集群。”事实上，Kubernetes 开发人员的短期目标是使你能够运行 Docker 容器，由 Kubernetes 管理，同时在多个云架构上使用群集联盟。

当然，Kubernetes 并不是完美的。 首先，它有两个问题。 第一，负载平衡很困难。 到最后，Kubernetes 的进入将使得 Kubernetes 从内部运行到外部的负载均衡器变得容易，但这还是一个在逐步改进的工作。 第二，Kubernetes 擅长自动修复问题。 但它运行非常好，并且可以快速地对容器进行重启，以至于你不会注意到你的容器崩溃。 当然，为了解决这个问题，您需要添加一个集中式日志系统。

最后，这三种容器管理工具都与多个云平台配合使用，包括 OpenStack、Magnum 和 Azure 容器服务。

好了！在这么多分析之后，问题来了，哪一个平台最适合你呢？

Kubernetes 的首席工程师 Brendan Burns 显然坚持自己的偏爱，但他总结了这些容器管理系统之间的差异：“Mesos 和 Kubernetes 主要旨在解决运行集群应用程序的类似问题; 他们有不同的发展历史和不同的方法来解决这个问题。Mesos 的集中力量在通用调度，插入多个不同的调度器。“

相比之下，Burns 说，”Kubernetes 的设计理念是，构建分布式应用程序的环境。它包括用于复制和服务发现作为核心原理，而这是通过 Mesos 中的框架添加的。Swarm 是 Docker 努力扩展现有的 Docker API，使一群机器看起来像一个单一的 Docker API。

从支持视图和功能列表比较来看，赢家显然是 Kubernetes。 在 AWS 和 Docker 之外，所有人都支持它。

幸运的是，您可以混合和匹配这些程序，满足您公司需求。三者之间可以很好地进行协同工作。这不容易，但它是可行的 ——也许这也是探索三者之间哪个更适合你的最佳方式。

但是，和往常一样，最佳选择取决于您的具体需求。例如，如果你的公司有工作人员精通 Docker，可以选择运行在 Docker Swarm 上。因为假如它运行得很好，那为什么还要切换到另一个系统？ 况且 Docker 一直都会被使用。 Marathon 有它的优势，为你提供一种方式（虽然是多层次的方式）来处理你的容器和你的旧应用程序。

我无法给你一容易的“这才是真正的方式”的答案。你要逐一检查它们，来找出哪个容器管理工具或工具满足自己的需要。

我可以告诉你，如果你搬到容器，你肯定会需要这些程序。你也不想浪费你的时间来构建自己的容器管理工具的吧。

所以，选择哪个呢？ Good luck！