容器和虚拟机水火不容？不存在的！

​最近一两年来，以容器为代表的云原生技术一直是 IT 行业最为热门的话题。随着云原生技术的崛起，有企业甚至跳过了 IaaS 层直接在物理机上部署容器。容器的风头几乎盖过云计算，虚拟化技术甚至由此被认为是传统方法。容器的普及对虚拟机形成了冲击，也就有了容器与虚拟机之争。

1

容器和虚拟机各有千秋

从操作系统诞生，虚拟化技术就一直伴随着它发展。因为硬件的限制，人们从一开始就希望使用软件来模拟硬件，而这也是虚拟机的核心思想。

虚拟机就是在本机的操作系统之下，虚拟出来的一个操作系统，在虚拟机中对硬件的操作，都会经过转换来对应到实体机的变化。你可以把虚拟机想象成一个真实的计算机，因为对于使用者来说，它提供的功能就相当于一个实体计算机。

和虚拟机一样，容器的发展也离不开操作系统的支持。正是因为操作系统实现了 namespace 和 cgroups 的资源分离技术，才使得容器技术得以实现。

（图片来源于网络）

相比于虚拟机，容器显得更加轻量，与虚拟机不同的是，它不对外提供一个完整的计算机功能，而是提供一些必备的基础功能。你可以把它想象成一个精简的 linux 内核，它需要更多的镜像才能对外提供相应的服务。

因为轻量级，我们的普通计算机就可以启动成百上千的容器，它们彼此通过命名空间相互独立，看上去我们一下子拥有了成百上千台服务器。

容器的出现改变了开发人员和运维人员的业务开发。因为容器在启动、定制和维护等方面的便利性，越来越多的企业愿意采用容器化技术，k8s 等容器集群管理技术则使得容器的市场接受度变得更高。

虚拟机和容器之间是水火不相容的吗？在 k8s 中对虚拟机和容器进行统一管理是否可行？

尽管现在大多数软件工程师对容器都有了一定的了解，容器技术也因为广泛普及而发展迅速，但企业仍然会在选择容器还是虚拟机的问题上犯难。其实，从特性上分析，容器和虚拟机各有千秋：

1、容器和虚拟机都可以提高应用的可移植性，提高组织在软件开发过程中的效率

2、容器将操作系统和应用解耦，使得业务开发人员更专注于上层应用，底层技术团队更专注于基础架构

3、虚拟机通过虚拟机管理程序复制底层硬件为业务应用提供基础资源

企业可以根据自身的业务应用特性和应用场景需求，在虚拟机和容器之间作出选择。本文基于现有的容器编排标准(k8s)之上讨论将虚拟机与容器进行统一管理的必要性及可行性。

2

容器和虚拟机对比差异性

首先是一个老生常谈的话题，将容器和虚拟机放在一起对比，我们知道虚拟机和容器最主要的区别在于操作系统内核和隔离性两个方面。

（图片来源于网络）

从操作系统内核看：虚拟机使用自定义操作系统，容器使用与宿主机相同的操作系统内核

从隔离性方面看：虚拟机与所有虚拟机之间完全隔离，容器采用 linux namespace 与其他容器进行隔离

就这两方面的差异而言，我们能够很容易的评估出虚拟机和容器之间的主要差异：

从以上虚拟机容器对比表可以看出，虚拟机与容器之间并没有绝对的高低之分，同样的，在软件设计过程中，一个优秀的软件架构通常也不是绝对的和可复用的，我们能够做的是通过需求分析、成本分析选择最合适的方法实现软件。这也是本文的主旨，即在不同场景下，技术人员或软件架构师会较虚拟机和容器的特性、业务软件的特性、当下的成本三方面分析业务软件到底是适合在虚拟机环境还是容器环境中运行。

3

哪些应用适合虚拟机场景？

现在我们来列举一下在哪些场景下，企业可能会优先选择使用虚拟机，而不是容器：

1、半永久资源分配解决方案 - 某些应用作为企业的半永久资源分配应用，不经常发生扩容、缩容、更新等场景，这些应用最初就是部署在虚拟机上的不会变更的应用，迁移到容器中可能增加企业额外的成本。

2、旧版应用程序不适合容器化 - 某些应用对于容器环境会有水土不服的现象，例如它适配的内核版本与宿主机的内核版本不同，需要对该应用进行重构或者改造，而这些应用最初可能是由第三方提供的应用，迁移到容器中同样会增加企业额外的成本。

3、传统 IT 软件部门舒适度及惯性 - 容器和虚拟机的运维场景不完全一致，这会对运维部门造成额外的学习成本，为了使得整个运维部门的变更过程更加平滑，企业在做云原生改造过程的前期更倾向于保留目前运维角色的运维惯性。

4、隔离有风险的环境 - 容器的隔离是使用内核模块完成的，于宿主机而言，它拥有整个机器中所有进程的可见性，一旦宿主机发生安全漏洞可能殃及到运行在其上的所有容器。

根据以上的几种场景，在当下的容器环境中，企业还是倾向于将这些应用部署在虚拟机上：

1、网络功能虚拟机化软件(NFV) - 该类软件在部署之后几乎不会对其分配的资源发生变更，且需要保留传统网络运维部门的惯性，否则将增加网络运维部门额外的成本和风险。

2、Windows 应用 - 由于当前的容器环境对于旧版本的 Windows 内核支持并不良好，许多企业(常出现在医疗行业)老旧的.NET 框架应用无法完美迁移到容器环境中。

3、Unikernel 应用 - 无核化本就是一类不同于容器技术和虚拟机技术的产物，处于技术潮流的某些大企业中的无核化应用没有迁移到容器环境的必要，但与本系列的主旨不矛盾的是，我们依然可以在现流行的编排标准中找出兼容三者之间的方案。

4、需要高度隔离的应用 - 上文我们提到过，在容器环境下，宿主机被攻破后可能会殃及容器应用程序的安全，某些安全要求极高的软件为了降低安全风险，更倾向于部署在虚拟机当中。

4

哪些应用适合容器场景？

列举完虚拟机适合的场景之后，我们再一起来看看哪些应用适合容器场景：

1、快速迁移解决方案 - 当企业的应用需要在故障、卡顿等不健康场景下进行快速的迁移、资源变更时，容器的启动效率对比与虚拟机具有更大的优势，能够提升业务的连续性。

2、在同一操作系统场景下的自动化伸缩方案 - 当无状态应用承载流量出现瓶颈时，可能需要进行实例数量的变更负载流量，同上文，启动效率和业务连续性方面容器更具有优势。

就场景而言或许阅读文章的你会觉得容器覆盖的场景并没有虚拟机广，实际上并非如此，在容器场景中快速迁移解决方案和自动化伸缩方案是企业面向最终用户的业务应用最基本的需求，而虚拟机大多数的场景都在于企业未下决心进行改造的老旧系统或是一些内部使用的软件。在以上应用场景下，企业会从效率方面考虑，倾向于将这些应用部署在容器中：

1、敏捷 devops 应用 - 企业内部进行敏捷 devops 流程所产出的应用，这些应用具有快速变更、快速迁移的特性。

2、微服务应用 - 微服务应用大多数也是敏捷 devops 下的产物，并且微服务应用大多都将状态下沉到一些中间件当中，业务应用大多都是无状态的需要快速变更、快速迁移、快速扩容的应用。

5

虚拟机和 K8s 相互融合

可以看到，容器和虚拟机根本就不存在谁取代谁，而是相互融合、共存的状态。但这也带来新的问题，企业的虚拟机和容器管理平台是各司其职互不干扰地运行呢？还是对其二者进行统一管理？统一管理又会带来什么好处呢？

事实上，在企业统一虚拟机运维和容器运维团队技术栈之后，可以享受现有容器编排系统(k8s)带来的价值：

1、使得容器环境与虚拟机环境不再割裂，统一网络方案：统一网络方案带来的好处不言而喻，一方面可以减少网络运维的成本，一方面不会在“虚拟机容器之间网络互访”的问题上来带网络选型的局限性。

2、促进虚拟机应用向声明式配置和自动化运维方向发展：使用 k8s 对虚拟机容器进行统一管理后，可以让虚拟机及虚拟机应用享受到 k8s 的红利，降低虚拟机及虚拟机应用的运维成本，使运维面向一套统一的模型，即声明式模型。

3、虚拟机容器混合部署，提升机器资源利用率：虚拟机和容器可以统一部署在同一套硬件环境下，在某些统一管理实现中，甚至可以达到在一台主机上虚拟机和容器的共存，达到企业降本增效的目的。

在软件工程中，任何一种技术都具备成为某一种场景下的最优选择，这些选择是企业根据自身条件作出的决策。

谐云，拥有国内最先进行云原生底层技术研究和 K8s 应用的团队，是国内为数不多掌握底层核心技术的容器云产品及解决方案提供商，谐云产品以建好容器云—管好容器云—用好容器云为矩阵，为企业的虚拟机管理带来 k8s 的红利，提供云原生全栈服务，助力企业降本增效，携手拥抱云原生！