转载

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要解决的核心问题。“

(点击放大图像)

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

在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解决方案和网络服务的使用中，从而弥补其中现存的差距。

(点击放大图像)

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

目前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即可读取或存储服务镜像。

(点击放大图像)

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

Solum

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

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

(点击放大图像)

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

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 ）关注我们。

原文 http://www.infoq.com/cn/articles/openstack-liberty-container-support

正文到此结束