OpenStack白皮书 新机遇：容器与OpenStack（一）

概述：

“重要的是，作为一个社区，我们应将OpenStack看为不可知论的整合引擎，”Collier说，“这可将用户置于获取商业成功的最佳位置。就像面对计算、存储和网络技术时，OpenStack并未重造轮子一样，对于容器技术，我们亦该如此。”

–Mark Collier, COO, OpenStack 基金会

就目前看，容器无疑是个热门的话题。OpenStack用户调查显示，超过半数的受访者均对将容器与OpenStack云结合使用在生产环境中兴趣盎然。受益于Docker为首的新兴开源项目，容器技术倍受开发和运维人员欢迎。

Linux kernel已支持容器数年；而现在Microsoft Windows也已经入列。然而，由于标准尚未成形、工具集生态系统相对初成、投入产出比的不确定性等原因，容器技术在企业级市场仍有不断涌现的机遇。

容器是在快速发展的技术，正如在过去支持那些新兴技术一样，OpenStack也在快速拥抱容器。相比与在数据中心构建一套全新的、独立的平台去管理容器，OpenStack提供的可同时管理虚拟机、容器及裸机的跨平台统一API对IT组织更有价值。

Trevor Pott 在写于The Register的文章中阐述了自己的观点：“OpenStack不是仅是云、项目或产品，更不是个虚拟化系统、API、用户界面，亦非某种标准。OpenStack是上述全部的整合甚至更多；是所有IT基础架构的框架，其互换性与互操作性甚至已经达到IT技术所知的极限。”

对容器技术的支持仅是OpenStack价值体现的诸多例子之一。以OpenStack作为云策略的基础，用户可通过统一的云基础架构添加全新、甚至尚处实验阶段的技术，之后适时部署于生产环境，而不必妥协于多租户安全与隔离、管理及监控、存储和网络等问题。

此白皮书将基于OpenStack细究容器技术及管理，描述其相关服务正如何被开发为未来OpenStack发行版中的首要资源。

编者按：容器技术快速发展并倍受欢迎，同时，由于标准尚未成形、生态系统相对初成，容器技术在企业级市场不断有大展拳脚的机遇涌现。作为各种成熟和将来各种不可知技术的整合引擎，OpenStack并未重造轮子，而是在自身的快速演进和不断成熟过程中，积极拥抱容器技术。加入对容器的支持，意味着OpenStack可同时以统一API去管理虚拟机、容器及裸机，这也是OpenStack能成为数据中心统一控制平台的坚实基础。

– EasyStack创始工程师、存储专家 王后明

何为容器？

容器是相互隔离的、可移植的应用执行空间，可在容器内运行程序并包含所有基础库和依赖包。但容器并非虚拟机，二者间差异远多于似处。同于虚拟机，不同的容器共享接入计算、网络与存储的系统资源，但异处在于，同一主机上的容器共享同一OS内核，但应用、运行时状态及其他不同服务被Namespaces 和cgroup内核功能分别分离。Docker添加了“容器镜像（Container Image）”的概念，让容器可被使用于任何装有较新Linux内核的主机。很快，Windows应用也可将Windows主机享受相同可移植性。相比将之封装进虚拟机镜像，容器镜像让应用部署速度大幅提升。

图例1: 容器 vs. 虚拟机

当下，容器被使用的主要目的有二种：

实现完整系统 – 操作系统、应用、服务等均可存在于容器内，其名做系统或OS容器。 系统容器的使用案例与虚拟机相近

而应用容器则全然不同。容器是个更便捷、便携的捆绑、运行应用的方式，可用于分解、隔离应用的不同组成部分，也就是微服务（Microservices），以便实现更颗粒化的扩展、更便捷的管理、更佳的安全、配置，并高效处理之前被配置管理工具（Configuration Management Tools, CM Tools）的系列问题，但不是虚拟化技术或配置管理工具的替代品。

开发者可将单一应用或服务及与其必要的运行时依赖及服务放置容器内，而无须完整的操作系统。这让容器镜像体积较小，仅约几兆。相比，虚拟机镜像往往会大出几个数量级。

容器技术已经存在数年，但它的兴起始于众多厂商对容器镜像的定义。容器镜像可以从概念上理解为一个可存储于磁盘上的容器文件系统快照。容器的文件系统被按层排列，类似OpenStack项目代码以一系列commits的方式排列于Git库的排列，使容器镜像可辨识其来源、其体积更小，因为必要的仅是不同于上层镜像的那部分。容器镜像让Docker 及类似工具大幅简化容器的创建及部署，以单一命令发布应用及其必要组件。此概念及其层化的特点是容器成为主流技术的关键点。

管理员与开发者关注容器技术的两个主要原因如下：

1.应用容器相比虚拟机，更为轻便，可将计算、存储及带宽需求减到最少。因多个容器可利用同一内核（当下的Linux;未来的Windows）， 容器的体积可更小， 需要更少的CPU、内存及存储资源，因其使用不需任何硬件虚拟化。相比虚拟机，它们可承受更动态的系统，因为容器的使用过程中需移动的数据体积相对虚拟机镜像小了许多。

2.另一优势在于，容器是可移植的，可运行于任何装有必要操作系统的硬件设备。开发者可在 工作站中运行容器并于其中创建应用，再将该应用存进容器镜像并部署于任何运行在同一操作系统的虚拟或物理服务器。该应用将可正常运行。

相比虚拟机，容器的部署速度优势显着，因其体积小，仅为几兆，而非数千兆。通常应用容器可于几秒内启动，虚拟机则需数分钟。容器还可通过内核直接接入设备驱动器，使 I/O运行速度快于需将这些操作虚拟化的虚拟机管理模式。即使是拥有数十万个容器的环境，此速度优势仍很重要，可影响整体响应能力 – 新工作负载可迅速上线，让启动风暴成为过去式。

容器形成了大量计算单元，而监控、管理、编排等功能缺失时，IT管理员将面临容器的“无序蔓延”,即容器被弃置或遗忘，进而一些第三方生态系统管理工具被越来越多的理解为与“容器” 同意。于此，细究所涉工具成为必要，且该以OpenStack为背景。

最常见的三个工具分别是Docker Swarm、Kubernetes和Mesos

Docker让容器镜像的概念备受欢迎。开发者因此可将应用及其从属部件封装进可运行于当下任何Linux（及未来的Windows）服务器的容器镜像。Docker还可为容器的部署提供附加工具，包括Docker Machine, Docker Compose及Docker Swarm.简言之，Machine可让Docker主机便于启动；Compose可让复杂的分布式应用易于部署在Docker上；Swarm则实现了Docker原生的集群编排功能。

Kubernetes（源自Google,现向原生云计算基金会CNCF贡献）为Docker容器的开源编排系统，负责调度计算群中的节点的任务并积极管理工作负载以确保其状态与用户明确的意图相符。

Apache Mesos可用于应用容器于大规模集群环境中的部署和管理。它可让开发者以作业、任务的思维模式构想其应用。与作业系统，例如Marathon相结合，Mesos将可完成工作与任务的调度及运行。

OpenStack将上述三个选择称作Container Orchestration Engine （COE（容器编排引擎））， OpenStack容器服务Magnum支持这三种COE,并可在一系列的计算实例集合内自动部署和管控用户所选的COE ,作为容器运行平台。

需指出，容器生态系统尚需完善，即便对于Docker这样的公司。例如，2015年6月，21家公司发起了Open Container Initiative6以促进容器镜像基础标准的形成。作为该项目的核心发起人，Docker贡献了自己的容器格式、运行时环境及RunC.随之容器技术逐渐成熟，确保 Docker、 Kubernetes及Mesos等工具可于OpenStack流畅运行已成为OpenStack之持续发展的基础目标。作为IT基础架构的基础框架，OpenStack仍需保持其于软件及硬件的不知论性。

编者按：容器并不是全新技术，其在Unix时代早已存在。随着chroot机制的广泛应用、group以及namespace进入Linux内核等标志事件，容器技术逐渐火热并进入大众视野。在生态圈方面，围绕容器的编排工具如Docker Swarm,Google Kubernetes, Apache Mesos等也可作为容器编排引擎，被OpenStack容器即服务项目Magnum所管理。

– EasyStack创始工程师、存储专家 王后明