基于OpenStack的容器化方案探讨

摘要 OpenStack作为一个成熟的虚拟化管理系统，长久以来主要以虚拟机的管理为核心。然而，随着近年来容器虚拟化技术的迅猛发展，OpenStack面临着日益激烈的竞争。容器化技术以其轻量级、高效部署和灵活扩展等优势，正逐步成为虚拟化领域的新宠。对于OpenStack而言，要想在未来的竞争中立于不败之地，容器化支持必不可少。本文将深入探讨OpenStack与容器的关系，并分析OpenStack如何通过技术革新来支持容器化，以适应虚拟化技术发展的新趋势，决定其未来的发展方向。

关键词：OpenStack，虚机，容器化

随着虚拟化技术的发展，OpenStack作为云管平台，为虚拟化提供了优秀的管理能力，随着技术的发展，日渐流行，在CT领域，已经成为事实上的标准。但是OpenStack最开始是作为虚机的虚拟化管理平台，并且虚拟机有单独的操作系统，隔离性和安全性都比较好。但是对于资源的占用也比较高，目前出现了一种轻量级的虚拟化，容器虚拟化，容器虚拟化是一种更轻量级的虚拟化，不同于虚机的虚拟化，容器的虚拟化，基本算应用的虚拟化，仅仅使用这个应用所需要的资源，这个比虚机虚拟化，占用资源更低，启动、停止也更加快捷方便，目前也逐渐在业界流行起来，随之对应的容器虚拟化管理平台Kubernetes 也随之流行起来，对OpenStack 形成了有力的竞争，OpenStack如果想保持在虚拟化运管平台竞争力，对容器化的支持是非常有必要的，本文对OpenStack对容器化的支持做一些探讨。Kubernetes 平台完成容器的虚拟化管理并实现了容器的编排。

一、虚机和容器虚拟化方式对比

虚机和容器是当前最主要的两种虚拟化技术，虚机具有隔离性好、可靠性高的特性，但是和容器相比，没有容器轻量化，占用资源较多，启动速度不如容器等问题。虚机从使用者来看，就相当于一个主机，具有自己独立的操作系统，容器更类似于一个应用，更加轻量化，两者具体的对比如下：

如上图所示，虚机和容器在大小上有很大的区别，虚机有完整的操作系统，具有良好的隔离性，而容器就是在主机操作系统内执行，可以利用主机的各种资源，同时容器也可以运行在虚机内。另外从启动速度上，容器也大大快于虚机，容器都不需要做重生，因为重新拉起一个容器的速度已经足够快了。最后在集成上，虚机都是一个单独的机器，集成上就是各个服务器之间集成，比较困难，而容器通常都是几个容器一起提供服务，集成比较简单。

虚拟机是一个完整的虚拟化服务器，通过被称为虚拟机管理程序的软件分配磁盘空间、处理器周期和I/0资源。在虚拟机中可以找到真实服务器上的所有内容：操作系统、设备驱动程序、应用程序、配置文件和网络连接。换句话说，从底层起，是裸机、服务器的主机操作系统、管理程序，然后是一个或多个虚拟机，每个虚拟机都有自己的操作系统、驱动程序和应用程序。

相比之下，容器中的所有内容都共享底层主机操作系统、设备驱动程序和一些配置文件。例如Docker，它提供一个或多个容器，而不是管理程序。每个容器只保存应用程序。这些应用程序依赖于主机操作系统和驱动程序，它也与在同一台服务器上运行的其他容器共享。这样容器的就比较轻量级，但是容器也有自己的弱势，因为容器的资源需求低，和其它容器共享底层资源，所以隔离性就不如虚机，随之而来的就是安全性方面也比虚机方面差，当然本文不是探讨虚机和容器的优劣性，所以这里就一带而过，而且从安全性来说，现在也有安全性较强的容器虚机化。本文主要是探讨容器发展的必然，才会引出OpenStack容器化的必要性。

二、OpenStack为什么要支持容器化

OpenStack 容器化有两个方向，一个是OpenStack 自身的容器化，一个是支持容器化的能力。

首先谈谈OpenStack自身的容器化，基于容器的各种优点，开销低，轻量化， 启动快，易部署，OpenStack 自身的容器化，对于OpenStack 的升级有很大帮助， 可以把OpenStack的组件部署在容器内，这样升级时，新老版本都可以同时存在，等新的版本稳定了，再把原来老版本组件的容器杀掉，如果新版本升级失败，可以仍然使用原来老版本的容器提供服务，这样加快了版本的升级，同时实现了灰度升级，使得升级的效率以及可靠性大大提高。不光是升级，OpenStack 自身容器化以后，部署 OpenStack 的时间，因为容器化部署的时间也会大大加快，对于新业务、新功能的验证也会大大加快，可以快速的推动新业务的部署和验证。

其次，对于OpenStack支持容器化的能力，容器化是目前虚拟化的发展方向， 在弹性扩展和快速部署方面用途很广，对于国内的主流的IT厂商，都开始尝试做容器化部署，这样满足电商业务，瞬间的流量扩展，又瞬间的流量收缩，对于IT厂商这种能力是非常高效的。同时在CT领域，目前5G的发展正当其时，5G要求服务的切片，微服务化，这些都为容器的部署提供了土壤，虽说在5G中微服务是必须的，容器不是必须的，但是每一个微服务，对于容器来说，就是一个容器，这种部署上的对应关系，不得不把5G和容器拉上联想。当然5G中，对可靠性要求比较高，容器需要解决的问题也很多，但是也代表后面的一个方向。

所以无论从IT还是从CT来说，对于容器都是一个发展方向，所以OpenStack如果需要做好虚拟化的运管系统，对于容器的支持都必不可少，否则面临着被容器边缘化的风险。

三、OpenStack 容器化的发展

OpenStack是一个组件化的项目，每个功能都是由一个组件实现，这样使得组件之间相互解耦，可扩展性也大大增强，如负责计算的Nova组件，负责网络的Neutron组件，负责块存储的Cinder组件。对于容器也是同样，也存在各种组件。如负责OpenStack容器化部署的Kolla组件，负责容器管理的Zun组件，负责容器编排的Magnum组件，负责安全容器或者叫轻量级虚机的Kata组件，负责让容器使用Neutron网络能力的Kuryr组件，负责提供应用仓库的Murano组件，负责集群能力的 senlin组件等等。

从上面可以看出目前OpenStack关于容器的组件很多，但是最重要的几个容器相关的组件是Kolla组件，Kata组件，以及OpenStack 需要发展的容器编排组件，和容器相比一个虚机就能提供一个服务，但是容器因为轻量化的特性，通常需要几个或者更多个容器一起才能提供服务。所以在虚机管理中并不重要的编排工作，在容器管理中变得至关重要，缺少编排，容器就无法对外提供服务。因此OpenStack如果需要在容器化上有发展，在虚拟化大潮中不被拍在沙滩上，或者边缘化，就需要推出OpenStack的容器编排组件，并且得到广泛认可，这样OpenStack 就成为一个能够管理、部署裸金属、容器、虚机的云化管理系统，可以满足多样性的需求，这样优势一下就显示出来。同时，OpenStack本身的容器化改造，也使得OpenStack本身轻量化，易部署。可以适应大大小小的环境，更 具有扩展能力。

目前容器的部署方式，一种是直接在裸金属上部署，一种是在虚机上部署，一种是通过OpenStack 进行部署，最后一种方式使用的最少，第一种方式是彻底 抛开了OpenStack，第二种方式，相当于OpenStack就提供了基础设施，和容器没有太大关联，所以如果后期容器的发展成为潮流，OpenStack就边缘化。如果 OpenStack仅仅提供容器的管理（生命周期管理），而不提供容器的编排，或者容器的编排，依赖于别的系统。那用OpenStack 部署容器的会非常少，只有OpenStack对于容器就属于本身的一种能力，那OpenStack 才能在容器化的大潮中不被抛弃。OpenStack需要提供各种场景下对于容器的部署与编排，需要在裸金属、虚机中都具体容器的部署与编排，或者把容器的编排变成自身的一个组件，只有这样，才能如下图所示，成为一个虚拟化的首选云管。

结论

OpenStack的发展必须要加大容器化的步伐，而且必须有自己的容器编排组件，并大力度推进，只有自己的容器编排组件能大规模应用，OpenStack的容器才能得到较好的发展，容器化编排组件是不可或缺的，当然同时也要推动OpenStack自身的容器化，OpenStack自身以及各个组件都能以容器化的形式进行部署，这样OpenStack部署和应用才能得到较高的效率，有利于OpenStack本身的推广，在纯容器的环境部署中也获得优势。这样OpenStack才能成为一个横跨裸金属、虚机、容器的云管操作系统。

参考文献

[1]奥马尔。海德希尔等著，肖力等译。精通OpenStack.

[2]陈亚威，朱龙。基于容器技术的高可用OpenStack 云平台快速部署应用[J]电子测试，2018，18：61-63.

[3]沈雪晴，朱洪斌，邢宇恒。容器技术及其在OpenStack云平台的应用[J].电气应用，2015，s2：562-565 .