OpenStack Liberty 版本对容器支持的详解

OpenStack 是目前全球云服务市场上使用最为广泛的开源平台之一，无论是公有云还是私有云，OpenStack 已经成为云服务框架的事实标准。2015 年 10 月 15 日，OpenStack 发布了其第 12 个版本 Liberty，为全球的云服务提供商和云用户带来了 53 个主要的改进点。

Liberty 版本增强了生产级云平台所需要的核心服务，提供了基于角色的访问控制（RBAC），允许运营者更加精细地调整网络安全设置，提升对 OpenStack 大规模部署的支持力度。其中最引人注目的变化是，将以 Docker 为代表的容器技术纳入到 OpenStack 体系中，借助目前 OpenStack 成熟的模型，对生产环境中的容器部署与管理给予强有力的支持。

容器技术无疑是近两年最炙手可热的虚拟化技术之一，其开源、开放、弹性易部署、高性价比等诸多优势基因，使其备受业界关注，尤其是 Docker 公司对容器进行了诸多改进与大力推广，形成了围绕容器技术的一个巨大生态系统，彻底改变了软件的开发、部署到运行的整个生命周期。OpenStack 很早就感知到了容器所带来的变革，在早期 Havana 版本就已经开始尝试对容器进行扩展。作为虚拟化技术，容器比传统虚拟机更轻量化，所以最初自然会想到使用容器全面替代虚拟机，并且想当然地认为所有东西都能够正常工作，所以产生了 nova-docker-driver，heat-docker-driver 等项目。但不幸的是，虚拟化应用的现实情况非常复杂，最终 OpenStack 认识到，容器完全不同于虚拟机，也不应该把容器当成虚拟机来使用，容器需要一套完全不同的管理工具，以便在大型企业、超大规模数据中心和云环境中被使用。

经过从 H 版本到 K 版本的摸索，OpenStack 对于整合容器的思路逐步清晰与成熟，温哥华 OpenStack Summit 上， Container/Docker 成为一大关注焦点，随后发表的白皮书《Exploring Opportunities: Containers and OpenStack》阐明了 OpenStack 今后深度整合容器的方式与方向。基于这份白皮书，Liberty 版本发布时，包含了许多容器相关的重要新特性：

• Magnum - 提供容器环境的编排、部署与管理，即：COE(Container Orchestration Engines) as a service，目前支持 Kubernetes、Mesos 和 Docker Swarm；
• Kuryr - 集成 libnetwork 等原生的容器网络组件，打通容器网络与 Neutron 网络；
• Murano - 提供应用目录服务，实现服务与应用程序的一键发布、快速部署和生命周期管理；
• Solum - 简化云应用程序从研发到交付的生命周期管理，为云应用开发者提供持续集成的能力；
• Manila - 文件共享服务，可以为容器应用的 Replication 和多读多写提供持久化存储方案 。

Magnum

Magnum 项目由 OpenStack 联合创始成员 Rackspace 主导开发，在 OpenStack 整合容器方面扮演了一个重要角色。Magnum 解决什么问题？正如项目团队主管 Otto 所说：“在容器上运行应用时出现的大多数问题都是基础设施问题，包括‘我如何与我们的网络连接在一起？我利用自己的存储能够做哪些工作？我的地址来自哪里？我如何编排它们？如何扩展它们？’，而这些正是 Magnum 要解决的核心问题。“

(点击放大图像)

在Liberty 版本发布了首个Magnum 生产级的完整版，支持Kubernetes、Apache Mesos 和Docker Swarm 等COE(Container Orchestration Engines) backends，支持基于TLS 的Master/Minion/Worker 间的安全连接，支持Neutron LBaaS 以及弹性伸缩，以及支持Master 节点的HA 部署方案。

Magnum 本身并不直接负责容器的生命周期管理，而是把这部分控制权交给 COE backends，但这并不是说 Magnum 仅仅是负责 COE 集群的部署，用户利用 Magnum 提供的 API 可以对容器进行间接的精细控制，比如在 Kubernetes 上创建一个端口等，根据 COE backends 的不同，可以获得不同的原生 API 体验。

除了可以选择不同的 COE backends，由于 Magnum 集成在 Nova、Ironic 等 OpenStack 的现有服务之中，因此通过 Magnum 可以将集群部署在不同的计算资源上，即：可以部署在虚拟机 (VM) 上，也可以部署在裸机 (BareMetal) 上，这样更利于使用者采用容器技术。

Magnum 支持也并不仅仅局限于 Linux，微软正在将 Windows Server 容器和 Hyper-V 容器这两个不同类型的容器整合至 Windows Server 2016 之中，这两种容器都可以由 Docker Engine 管理，自然 Magnum 最终将能够覆盖 Docker 或微软自己的容器管理工具，以管理 OpenStack 云中的微软容器与虚拟层技术。

Kuryr

Kuryr 是 OpenStack 的一个新项目，通过直接集成 libnetwork 等原生的容器网络组件，把容器和 Docker 网络加入到 Neutron 解决方案和网络服务的使用中，从而弥补其中现存的差距 。

(点击放大图像)

目前Neutron 已经成熟，并且有着非常丰富的插件与驱动生态系统，可以提供网络解决方案和服务（例如，负载平衡即服务LBaaS、虚拟私有网络即服务VPNaaS，以及防火墙即服务FWaaS），而相比较而言目前的容器网络还不够完善，Kuryr 的使命就是向Docker 传递Neutron 网络和服务，在容器网络和容器与OpenStack 混合的环境中，能够零成本地使用现有Neutron 网络的一切成果。

Kuryr 还有一个重要的任务是解决虚拟环境之上容器网络的性能问题。我们知道，通用的虚拟机 Neutron 网络是使用 Overlay 技术实现的，容器网络一般也会使用 Flannel 等 Overlay 技术，如果容器环境建立在虚拟机之上 (VM nested containers )，那么容器网络就是 Overlay over Overlay 的架构。两层封包解包对网络传输性能的影响非常大，Kuryr 尝试将这种低效的架构进行扁平化，从而提高网络性能。而对于容器来说，并不用关心是建立在虚拟机 (VM nested containers ) 之上， 还是建立在物理主机 (Bare Metal) 之上。这一特性非常适用于 Magnum 进行容器部署，所以未来 Magnum 也计划把 Kuryr 作为 COE 网络的默认选项。

Murano

容器的出现解决了服务与应用的快速部署与弹性扩展的问题，使得这些年不温不火的 PaaS 平台重新得到了关注。如何将第三方开发者的服务与应用方便地发布出来是 PaaS 平台的一个重要功能点，即 PaaS 平台的应用目录 (Application Catalog) 服务。各主流的 PaaS 平台，比如 OpenShift、CloudFundry、GAE 都有相应的方案，但发布接口与应用打包方式并不统一。OpenStack 的 Murano 致力于通过标准化以及一套新的编程语言（YAQL）来解决这一问题。

Murano 是 OpenStack 的应用目录服务，在 Murano 的世界里，一切皆服务 (Anything as a Service)，不管是虚拟机镜像、容器镜像、服务应用模板，甚至是一个编排模板 (HOT)，都可以在 Murano 中发布。第三方开发者与管理员可以通过标准的接口、标准的应用打包规范 、标准的应用发布流程，标准的生命周期管理流程，来实现服务与应用程序的一键发布、快速部署和管理，降低服务与应用程序对底层基础架构的依赖。

在 Liberty 版本中，开发者的控制得到加强，支持应用版本升级。 应用程序的使用者可以自由选择应用将要被部署的网络。另外，在基础设施控制方面，Murano 能够使用 Glance Artifact Repository 作为它的存储后端，通过 Glance Artifact API 即可读取或存储服务镜像。

(点击放大图像)

Solum

Solum 项目实现了 PaaS 平台中的持续集成 / 持续交付的功能，使云服务能更简单的应用和集成到用户的应用开发过程中。基于 OpenStack 架构 的 DRY（“不重复自己”）原则，Solum 高度利用现有的 OpenStack 已经存在的组件，例如 Heat、Nova、Glance、Keystone、Neutron 等，还可以与 Murano 配合建立应用目录索引为其他应用提供服务。

不管源代码的语言是什么，通过 Solum 提供的模块化 Language Pack 机制，可以做到跨开发者、跨测试、跨生产环境地将源代码打包到一个 Docker 镜像，并发布到一个 OpenStack 云上。Solum 集成多个开发环境，如 Eclipse、IntelliJ、Komodo 等，从应用开发的源头上简化了整个应用程序的持续集成过程。

(点击放大图像)

Manila

Docker 对于容器的网络与存储都给出了合理的解决方案，这在单个容器上也的确是有效的，但是把容器放到集群中运行时，情况就变得复杂了。在集群环境中，为了实现容器的高可用，相同的容器会被启动多份，并且集群调度器还会在某个时机根据某种策略将容器迁移到另外一个 worker 节点，这就要求容器的存储需要提供多读多写以及随容器迁移的特性，坦白来说，目前还没有同时解决这两个问题的完美、高效的原生容器存储方案，NFS 等传统的共享文件系统是现阶段相对可以接受的方案之一。

Manila 作为共享文件系统服务，自然提供多读多写与容器位置无关的特性，满足容器集群的基本要求。除此之外，在 Liberty 版本中 Manila 还提供很多扩展以提高共享文件系统的可用性。

Manila 超额申请的功能能够自动精简配置存储，让 Manila 管理后台超额申请的程度。用户可超额申请 2 倍、10 倍，或是他们认为可能需要的倍数。
因为共享存储用户不会从一开始就精确知道自己需要多少空间，Manila 允许用户对共享存储大小进行扩展 / 收缩。

自动化增加共享可以让用户能够监控如创建共享，或是批准对共享的访问等操作，触发脚本自动增加共享。

共享迁移允许共享从一个存储控制器迁移至另一个上面，从而用户能够方便地对共享存储的内容进行维护而不用停止服务。

在下一个版本 Mitaka 中，Manila 计划对大规模升级和高可用性的进一步支持、共享复制等。共享复制将允许 Manila 配置共享，以便将其复制到具有不同可用性的区域中。一旦数据中心遭遇停电、火灾或水灾，用户可以切换至数据的副本上，从而维持应用的运行。共享复制支持各种执行情况，例如，双主动复制，或是主动 - 被动复制，同步或异步都将被支持。

总结

OpenStack 与容器的深度整合，能让 IaaS 层的资源使用更加充分，管理粒度细化，资源利用率提高，因为容器相对虚拟机来说更轻量，对资源的利用率会更加充分，同时容器也可以充分利用现有 OpenStack 中众多的成熟项目，省去了重新发明轮子的无用功。

目前 Liberty 版本对于容器的支持与整合只是一个开端，未来 OpenStack 对于容器的支持将会是持续的。OpenStack 的容器白皮书中所描述的用户所期待的容器和容器管理细节，都将在 Mitaka 以及后续版本中逐步实现。

作者介绍

郑阳是创业团队轻元科技的技术负责人。轻元科技基于 OpenStack Liberty 版本，集成了 Kubernetes 容器编排系统，开发了一个容器和虚拟机统一管理、组合服务的云平台，并部署实施了多个私有云客户。加入轻元科技之前，郑阳是 NEC 中国的高级技术经理，在 SDN、OpenStack 领域有着多年的研发和部署经验。

感谢陈兴璐对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。