容器与虚拟机之争？不存在的

Hypervisor技术从一开始就是云计算的基石之一。然而，近年来容器技术的爆发，让这种虚拟化技术开始被认为是传统方法。有不少人认为，容器的普及对虚拟机形成了冲击，于是就有了早些年的容器与虚拟机之争。

经过几年的技术发展和大规模实践，虽然许多企业正在将基于虚拟机的应用程序迁移到容器，但事实上虚拟机在数据中心和公有云中仍然普遍存在。一方面，容器并没有完全替代虚拟机，另一方面虚拟机也在积极支持容器，两者共存的情形反而越来越普遍。

今天就来聊聊虚拟机和容器到底有什么区别，为什么两者会走向共存，以及将来会走向何方?

虚拟机和容器各有优势

虚拟机和容器诞生的初衷，都是为了更好的提高资源利用率，但两者的区别在于：虚拟机是操作系统级别的资源隔离，而容器本质上是进程级的资源隔离。

虚拟机(Virtual Machine)，是指通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统。每个虚拟机都有独立的CMOS、硬盘和操作系统，可以像使用实体机一样对虚拟机进行操作。

虚拟机的运行离不开Hypervisor，Hypervisor是运行在基础物理服务器和操作系统之间的中间软件层，可允许多个操作系统和应用共享硬件。

简单来说，服务器硬件、Hypervisor、虚拟机之间的关系在于，每个虚拟机都有一个完整的操作系统，虚拟机内部署的应用可以使用整个操作系统的资源。

虚拟机的出现，解决了早期在物理服务器上部署应用但无法为其应用程序定义资源边界而导致的资源分配问题。

但是在使用虚拟化一段时间后，会发现它存在一些问题，例如：虚拟机的系统层会占用比较多物理机的资源，需要更进一步提高服务器的资源利用率;当需要迁移虚拟机服务程序时，需要迁移整个虚拟机，迁移流程复杂。

为了解决这些问题，容器就出现了。

容器技术，可以理解为操作系统虚拟化技术，它是一种轻量级的虚拟化技术。通过内核创建多个虚拟的操作系统实例(内核和库)，来隔离不同的进程(容器)，不同的实例相互隔离，相互之间完全无感知。可以简单地理解为容器就是一个进程沙盒，来提供进程级的隔离。

相比于虚拟机，容器没有自己的操作系统，而是通过容器引擎来实现共享宿主机操作系统内核，从而减少需要运行多个操作系统的开销。

作为一个标准的软件单元，容器将应用部署所需的代码和依赖项打包为镜像，可以快速可靠地从一个计算环境运行到另一个环境。

因此，容器很大的优势在于，它启动时间很快，可以达到秒级，而且对资源的利用率很高，如：一台主机可以同时运行几千个docker容器。此外，它占的空间很小，虚拟机一般要几GB到几十GB，而容器只需要MB级甚至KB级。

总的来说，容器和虚拟机具有相似的资源隔离和分配优势，但功能不同。容器虚拟化的是操作系统而不是硬件，因此容器更加轻便高效。但是如果用户需要使用在不同操作系统上运行的不同应用程序，虚拟机就能提供可靠的解决方案和更好的安全性。

因此，如今最有效和最常用的策略是，拥有一台具有多个虚拟机的物理机，每个虚拟机都有多个容器。容器和虚拟机一起使用，为部署和管理应用提供了极大的灵活性。

虚拟机和K8s相互融合

可以看到，容器和虚拟机根本就存在谁取代谁，而是相互融合的状态。这也带来了新的问题，即如何同时管理虚拟机和容器技术，成为企业的一个普遍的需求。

作为虚拟化技术的最主要推手，VMware很早就做出了反映。此前VMware通过在虚拟化平台上外挂PKS(Pivotal与VMware共同推出的一个K8s平台)，来实现虚机与容器的同时管理。但毕竟是外挂，其效率和管理方便性上都有不足。

去年的VMworld大会上，VMware发布Tanzu 品牌计划，宣布在虚拟化技术中原生地提供对容器技术的支持。VMware的Tanzu把虚拟机和K8s结合起来，对虚拟机和容器以及物理机统一进行管理，它能实现跨物理机、虚拟机以及内部数据中心、跨多个云来管理应用，从而为工作负载提供一个统一的支撑。

今年3月Tanzu正式亮相，VMware最新一代虚拟化平台vSphere 7对外发布，vSphere 7迎来了近10年比较大的变革。VMware对vSphere进行了重构，将K8s嵌入vSphere的控制平面，让它成为一个K8s原生平台，从而原生地支持K8s。

这样，那些VMware的传统用户无需在虚拟机和K8s容器环境之间做出选择，从而能自由在vSphere上进行现代应用程序开发和运营，同时继续利用现有的技术、工具和技能组合投资。

另一方面，容器厂商也认识到了虚拟化的客观存在，也在拥抱虚拟化技术，kubevirt 就是基于这个目的推出的。

kubevirt是 Red hat 开源的以容器方式运行虚拟机的项目，使用容器的Image Registry去创建虚拟机并提供虚机的生命周期管理。在红帽4月底举行的年度技术大会Red Hat Summit 2020大会上，红帽宣布推出OpenShift 虚拟化的技术预览，OpenShift 虚拟化就源自KubeVirt开源项目。企业可以通过这一功能，在整合了云原生与传统工作负载的OpenShift上开发、部署和管理由虚拟机、容器和无服务器构成的应用。

虽然VMware和红帽的从不同出发点出发，但目的是一样的，而这背后的推动力则是企业的现实需求。对用户而言，它们的行动无疑是受欢迎的，这能让企业少了后顾之忧，不再需要进行非此即彼的选择，不用纠结容器究竟应该部署在虚拟机还是裸机上，从而可以更灵活支持未来的各种应用。

虚拟机和K8s的未来

目前，虚拟机与容器技术的结合已经成为一个事实，不仅如此，虚拟机也正在成为云原生架构的一部分——这就是容器原生虚拟化。以K8s为代表的容器，运行在基于虚拟机的基础设施之上，而基于虚拟机的工作负载，仍然是IT组合的重要组成部分。

未来，虚拟机和K8s的融合会呈现哪些趋势呢?

K8s编排微型虚拟机(如Kata Containers、Firecracker或gVisor)

微型虚拟机不像传统虚拟化那样提供完整的“机器”，而是专注于提供足够的虚拟机，来成功执行应用程序容器或功能。因此，微型虚拟机旨在提供相对于标准Linux容器的硬隔离，同时很大限度地减少传统虚拟机在冷启动时间和性能方面的弱势。

对于某些用户而言，可能需要更强大的多租户隔离。因此，这种方式能够为不受信任的工作负载提供更严格的多租户隔离。

K8s编排标准虚拟机

以前，虚拟化堆栈是与K8s和云原生是完全独立的孤岛——独立的工作流程、独立的工具、独立的团队等。容器原生虚拟化的概念，使虚拟机能够遵循与K8s中基于容器的应用程序相同的工作流程。

现在有了像KubeVirt这样的开源项目，就可以实现容器原生虚拟化。K8s编排引擎可以应用于管理在云或虚拟化平台上运行的标准虚拟机，K8s开始使容器和虚拟机的混合运维成为可能。

裸机上的K8s(没有虚拟机)

虽然目前大多数K8s平台都部署在基于虚拟机的基础设施上，但容器并不依赖于虚拟机来运行，在裸机上运行K8s和容器的实践还在继续增长。

在裸机上运行K8s将使应用程序能够充分利用底层硬件，这对于为K8s带来更多机器和性能敏感应用程序的用户来说非常重要。在裸机上运行K8s和容器，还可以帮助用户减少虚拟机蔓延并简化操作。这对于虚拟机而言，不算是个好消息。

总体而言，虚拟机和容器有着各自的优势，虽然在应用场景上有一些重叠，但主要应用场景还是有区别的。比如，虚拟机更适合运行多个操作系统资源和功能的场景，而容器更适合在更少的服务器上运行更多的应用。

大部分情况下，多数企业会同时使用虚拟机和容器，特别是考虑到大多数企业在此前已经广泛部署了虚拟化技术。鉴于此，容器和虚拟化应当会在相当长时间内共存。

作者：科技云报道