如何在 OpenStack 中编排容器

容器是当前计算领域的热门话题。它们是部署应用程序的有效且高效的方法。然而，当复杂的应用程序拆分到多个容器之间时，事情可能会变得有些复杂。当这种情况发生时，容器需要能够有效地协同工作，而这正是容器编排的用武之地。编排器有助于管理容器，并确保它们能够以正常运行所需的方式连接和协作。

云环境中有很多不同的容器编排工具，那么管理员如何选择最适合他们的解决方案呢？ Gigaspaces 的创始人兼首席技术官 Nati Shalom 和他的几位同事将在温哥华 OpenStack 峰会上通过他们的演讲帮助管理员解答这个问题。他们的演讲将探讨几种不同容器编排工具之间的差异：Kubernetes、Heat、Fleet、MaestroNG 和 TOSCA，并为针对不同用例选择理想解决方案提供最佳实践。

我们采访了 Nati，以了解更多关于他在温哥华 OpenStack 峰会上将要进行的演讲以及他对容器、编排和 OpenStack 的未来发展的看法。

在不过多剧透的情况下，您在 OpenStack 峰会上的演讲能让与会者期待获得什么？

本次演讲将侧重于流行的编排方法，概述一般差异和潜在的协同作用，然后深入探讨关于如何为正确的工作选择正确的工具的最佳实践。由于我们最终有时间限制，我们可能无法展示每个工具的现场示例或比较整体用户体验，但将主要关注各种编排方法之间的差异，这些差异通常会导致语义差异。

为了回答这个问题，云管理员首先需要问自己一些关键的限定问题。而这些问题中的每一个都会带来最适合这项工作的工具/解决方案。我首先会根据您的环境来划分这些问题，然后询问您使用哪些工具来管理这些环境，最后询问您正在寻找什么级别的编排——针对一个项目的临时编排，还是更长期或全局的编排，以及应用程序堆栈的考虑因素。

因此，首先也是最重要的，您需要考虑您的环境是仅限 OpenStack、仅限容器，还是混合模型，例如遗留基础设施（即 vSphere 或物理硬件）。

如果您处于仅限 OpenStack 的环境中，您的首选将是 Heat 以及其他用于处理软件配置、监控、工作流程、策略等的补充堆栈的集成。其中一些可能来自 OpenStack 的项目，在某些情况下，最好选择相关的开源项目。如果您计划迁移到仅限容器的环境，您的首选可能是 Docker。就目前而言，您需要集成大量用于处理日志记录、监控、工作流程的补充堆栈——例如，Kubernetes 提供了更高级的编排，专门针对微服务。如果您的世界更像是容器和配置管理工具（Puppet、Chef、SaltStack）的混合，以及私有云（OpenStack、VMware）或公共云（Amazon、Google）的混合，那么您的最佳选择将是基于 TOSCA 的编排——它也是基础设施和工具链无关的。显然，不用说，如果您已经大量投资于 Chef 或 Puppet，那么您的最佳选择将是带有对此类框架的内置支持的编排工具。

接下来，问题是您是为特定产品/项目寻找编排，还是作为许多应用程序的通用解决方案，而这变得更加棘手。

许多产品都带有自己的编排，这些编排是为该应用程序的特定用例量身定制的——一个很好的例子是 Cloud Foundry/Bosh 或 Hadoop/Yarn。其他编排工具带有通用解决方案，以及针对特定应用程序的内置模板，并且这些工具各有其优势。例如，有些编排工具更适合网络应用程序，例如 NFV，或者那些更适合大数据应用程序的工具，因此即使在这种情况下我也会选择通用编排工具，我也会寻找最适合我的目标工作负载的工具。

另一个重要的标准是可嵌入性，将编排工具作为另一个产品的一部分与选择编排工具来运行您的数据中心操作是截然不同的。在这种情况下，我会寻找一种轻量级解决方案，可以以最小的运行时开销使用，可能仅作为库使用。您还需要决定您是需要也包括部署后方面（监控、自我修复和自动扩展）的完整生命周期编排，还是主要需要安装或配置。

一些编排工具将自身限制为主要处理安装阶段，但是一些编排工具提供了部署后管理任务的更广泛方面，涵盖应用程序的完整生命周期——包括监控、更新策略、扩展和自我修复。

最后，重要的是要了解您的堆栈在网络、DevOps 工具链、监控和语言方面的外观。许多 DevOps 环境由一系列用于处理日志记录、监控和生命周期其他方面的开源项目组成。这组工具往往变化很快。一些编排工具带有对此类工具的内置集成，但在将新工具添加到组合中时，最终会受到相当大的限制。在工具恰好是它们自己的集群的情况下尤其如此，因此需要在应用程序编排和工具特定编排之间建立更高级的关系。在这种情况下，我们最终会得到编排的编排——一个很好的例子是应用程序编排和网络编排，或应用程序编排和大数据编排，其中应用程序编排需要与工具编排交互并委托责任给工具编排。

您是否看到格式之间会趋于融合？或者是否会有一两个格式在其他云之上胜出？

从我所看到的，我敢说可能会最终形成三个主要的阵营

• 仅限 Docker（或大部分）——将用 Go 编写的工具，并将成为当前 Docker 项目的扩展。最主要的框架可能来自 Docker 本身（Swarm、Compose 或 Machine）。
• 特定于基础设施——这些工具将主要提供映射到特定基础设施的核心功能，该组主要针对那些有兴趣仅在特定环境中部署应用程序的人。 Amazon Cloud Formation 或 OpenStack Heat 是这一类别的很好的例子。
• 混合——用于本质上是混合的环境的编排，并且包括 Docker 以外的其他技术堆栈，例如 Chef、Puppet 或 Ansible，或 VMware、OpenStack、AWS 等云。我认为 TOSCA 将成为该组的主要编排规范选择是有道理的，因为它具有内置的中立性。

展望更广泛的 OpenStack 峰会，您对温哥华峰会最兴奋的是什么？您认为我们将看到哪些重大主题出现？

NFV（网络功能虚拟化）和客户用例非常令人兴奋，在这些用例中，我们了解客户实际上是如何使用 OpenStack 的。我也希望听到更多关于 OpenStack 路线图的信息——深入了解计划塑造下一个版本的事项，并参与这些讨论。最后，是网络：峰会始终是结识开发人员和决策者的独特场所，并了解人们参与和贡献这个项目的所有激动人心的方式。

对于 OpenStack 作为一个项目，下一个版本需要关注什么？ Liberty 版本可能带来什么，尤其是在编排方面？

我个人认为，如果 OpenStack 能够找到一种方法，让更多的云提供商能够添加对 OpenStack 的支持，包括那些被认为是 OpenStack 竞争对手的云提供商，例如 AWS、Google 和 Azure，那么 OpenStack 将会更加成功。 同样，如果它能够找到一种方法来鼓励其他流行的开源项目对 OpenStack 的原生支持，它将会更加成功。

我认为到目前为止，人们已经非常关注将 OpenStack 打造成 Amazon 的替代品。在我看来，这种策略导致 OpenStack 项目过于分散到许多项目中。我认为 VMware 对 OpenStack 的支持是潜在的竞争基础设施如何与 OpenStack 兼容的一个很好的例子。 如果我们能够让其他基础设施提供商更容易地将 OpenStack 兼容性添加到 OpenStack API 中，我们将获得比仅仅专注于将 OpenStack 打造成可行的竞争替代品更多的收益。基本上，我想说包容性至关重要，而不是排他性：开源之道。

在编排的背景下，我认为最好是 Heat 可以成为其他编排框架与 OpenStack 的集成点，例如我在演讲中提到的那些框架。 在这种情况下，通过 Heat 翻译器项目将 TOSCA 支持添加到 Heat 听起来像是朝着正确方向迈出的一步。

我认为 OpenStack Kilo 和 Liberty 带来的令人兴奋的功能是那些增加了独特性能的功能，这些功能最适合私有云环境或 NFV。 这包括对裸机 (Ironic) 和即将推出的共享文件系统 (Manila) 的支持，以及高级调度规则，这些规则将更好地控制资源利用率。 我个人认为，Ironic 与容器结合使用将带来数量级更高的性能和利用率，因此，将使选择 OpenStack 背后的 ROI 论据更加有力。

话虽如此，我认为 Kilo 公告中的主要新闻是没有那么多新闻！ 显然，这强烈表明 OpenStack 项目最终正朝着现有核心服务的稳定性和完整性迈进，而不是不断扩展到新的领域。

您还想补充什么吗？

由于本次演讲的主题可能相当广泛，我欢迎任何有兴趣看到我们涵盖特定兴趣领域的评论或建议。 我也感谢那些已经获得任何这些工具使用经验的人的指点，您可以在 Twitter 上找到我，我很高兴根据观众想看的内容来调整我的演讲。

此外，这是一个很好的机会来提及世界各地还有其他 OpenStack 活动，这些活动为所有无法前往温哥华的人提供了精彩的演讲，我鼓励所有无法参加的人查看这里，例如，几乎紧随峰会之后就有一个优秀的 OpenStack Days EMEA 巡回活动。 我特别参与了 OpenStack Israel 的组织，这是其中之一，在那里我们将有一系列来自世界各地的优秀演讲者——主要的一位是来自 Deutsche Telekom 的 Axel Clauberg，在我看来，他正在领导迄今为止最雄心勃勃的 OpenStack 项目之一。

本文是 OpenStack 峰会温哥华 2015 年演讲者访谈系列的一部分，OpenStack 峰会温哥华是一个为期五天的会议，面向 OpenStack 云软件的开发人员、用户和管理员.