论文阅读 Hypervisor- vs. Container-based Virtualization

ABSTRACT

很长一段时间以来，虚拟化这个术语都是指基于虚拟机监控程序的虚拟化。然而，在过去的几年里，基于容器的虚拟化变得成熟起来，特别是Docker得到了很多关注。基于管理程序的虚拟化为完整的操作系统提供了强大的隔离，而基于容器的虚拟化则努力以很少的资源成本将进程与其他进程隔离开来。本文将区分hypervisor和基于容器的虚拟化，并描述Docker和LXC背后的机制。本文介绍了从容器框架上的简单chroot到准备就绪的容器管理解决方案的过程，并介绍了容器的安全性。本文概述了两种不同的虚拟化方法及其优缺点。

1 INTRODUCTION

本文比较了两种不同的虚拟化方法:hypervisor和基于容器的虚拟化。Docker[1]是一种创建、管理和分发容器的免费工具，它通过将不同的技术结合到一个强大的虚拟化软件中而得到了广泛的关注。相比之下，基于虚拟机监控程序的虚拟化是被广泛使用了几十年的虚拟化领域的领军人物。这两种技术都有各自的优点，在决定哪一种技术更适合自己的需要之前，都必须考虑到两者之间的权衡。本文在第2部分介绍了hypervisor和基于容器的虚拟化，在第3部分介绍了它的优缺点，并在第4部分深入介绍了基于容器的虚拟化及其背后的技术。已经有很多文献对基于管理程序的虚拟化,而基于容器的虚拟化开始流行在过去的几年里和报纸关于这个话题越来越少,所以本文的重点是基于容器的虚拟化。本文的另一个重点是Docker，在4.3节中介绍了Docker，因为Docker在过去的两年中发展迅速，受到了社会的广泛关注。为了使本文更加完整，第5部分详细介绍了基于容器的虚拟化和Docker的一般安全风险以及处理这些风险的可能方法。第6节简要概述了与本主题相关的工作。

2 DISTINCTION: HYPERVISOR VS. CONTAINER-BASED VIRTUALIZATION

在谈到虚拟化时，大多数人提到的技术是基于管理程序的虚拟化。hypervisor是一种允许从硬件进行抽象的软件。系统管理程序必须模拟运行软件所需的所有硬件。因为有一台计算机的完整硬件的仿真，所以谈论虚拟机或虚拟计算机是很常见的。通常能够通过hypervisor提供的接口访问实际硬件，例如访问CD或闪存等物理设备上的文件或与网络通信。在这台虚拟计算机中，可以像在任何普通计算机上一样安装和使用操作系统和软件。运行hypervisor的硬件称为主机(操作系统称为主机操作系统)，而在它们内部运行的所有模拟机器都称为来宾操作系统，它们的操作系统称为来宾操作系统。现在，通常还会将实用软件与管理程序结合在一起，以便方便地访问管理程序的所有功能。这提高了操作的易用性，并可能带来不属于系统管理程序工作的其他功能，例如快照功能和图形界面。可以区分两种类型的管理程序，类型1和类型2管理程序。类型1的虚拟机监控程序直接运行在硬件上(因此通常称为裸机监控程序)，不需要操作系统，并且有自己的驱动程序，而类型2的虚拟机监控程序需要主机操作系统，主机操作系统的功能用于执行它们的操作。著名的管理程序或虚拟化产品有:

• KVM[2]:一个用于Linux内核的内核模块，允许访问真实硬件的虚拟化功能和模拟器，通常与KVM，qemu[3]一起使用，它正在仿真其余的硬件(类型2)，
• Xen[4]:一个直接运行在硬件上的自由虚拟机监控程序(类型1)，
• Hyper-V[5]:从微软集成到各种Windows版本的管理程序(类型1)，
• VMware工作站[6]:VMware专有虚拟化软件(类型 2)
• Virtual Box[7]:来自Oracle的免费、独立于平台的虚拟化解决方案(类型 2)。
  从现在开始，在讨论管理程序时，本文假设讨论类型2管理程序。基于容器的虚拟化并不模拟整个计算机。操作系统为容器软件提供某些特性，以便将进程与其他进程和容器隔离开来。因为Linux内核提供了许多隔离进程的功能，所以本文所讨论的所有解决方案都需要它。其他操作系统可能提供类似的机制，例如FreeBSD的监狱[8]或Solaris区域。因为没有完全的硬件仿真，所以在容器中运行的软件必须与主机系统的内核和CPU架构兼容。对于基于容器的虚拟化来说，一个非常有描述性的描述是“容器就像进程之间的防火墙”。基于虚拟机监控程序的虚拟化的类似比喻是运行在不同机器上的进程，这些机器连接到一个中央实例hypervisor并由它进行监控。

3 USE CASES AND GOALS OF BOTH VIRTUALIZATION TECHNOLOGIES

Hypervisor和基于容器的虚拟化技术具有不同的权衡，因此每个技术都有不同的目标要实现。虚拟化通常也有不同的用例，因此虚拟机监控程序和基于容器的虚拟化都有与特定用例相关的特殊优势和弱点。由于从硬件中抽象出来，这两种虚拟化都很容易迁移，并且可以更好地利用资源，从而降低成本和节约能源

3.1 Hypervisor-based virtualization

基于管理程序的虚拟化允许完全模拟另一台计算机，因此可以模拟其他类型的设备(例如智能手机)、其他CPU架构或其他操作系统。这在为移动平台开发应用程序时很有用——开发人员可以在开发系统上测试他的应用程序，而不需要访问目标设备。另一个常见的用例是虚拟机与主机之外的其他客户操作系统。有些用户需要特殊的软件，但这些软件不能在他们喜欢的操作系统上运行，虚拟化允许在这个环境中独立于主机系统运行几乎所有需要的环境和软件。由于来自硬件的抽象，所以更容易创建、部署和维护系统映像。在发生硬件事故的情况下，只需很少的努力就可以将虚拟机转移到另一个系统，在最好的情况下，即使用户没有注意到有迁移。基于管理程序的虚拟化利用了现代CPU功能。这允许虚拟机及其应用程序以非特权模式[10]直接访问CPU，从而在不牺牲主机系统安全性的情况下提高性能。
管理程序可以直接在硬件上设置(类型1)，也可以在主机操作系统上设置(类型2)。假设有一个类型 1 Hypervisor，那么图1中的所有操作系统都是来宾操作系统，而type 2 Hypervisor与其他用户空间应用程序处于相同的级别，操作系统(图中没有显示)和真正的硬件位于它下面的层上。

3.2 Container-based virtualization

基于容器的虚拟化利用内核特性为进程创建一个隔离的环境。与基于管理程序的虚拟化不同，容器不会获得自己的虚拟化硬件，而是使用主机系统的硬件。因此，在容器中运行的软件可以直接与主机内核通信，并且必须能够在操作系统上运行(参见图2)，以及主机所运行的CPU架构。无需仿真硬件和引导完整的操作系统，容器就可以在几毫秒内启动，而且比传统的虚拟机更高效。容器映像通常比虚拟机映像小，因为容器映像不需要包含完整的工具链来运行操作系统，即设备驱动程序、内核或init系统。这就是为什么基于容器的虚拟化在过去几年变得越来越流行的原因之一。较小的资源指纹允许在较小和较大的范围内获得更好的性能，并且仍然具有相对强大的安全性优势。
在软件开发中，封装容器是一种非常有趣的方法:开发人员不需要手工设置他们的机器，取而代之的是，构建系统映像可能是分布式的，其中包含处理项目所需的所有工具和配置。如果需要更新，则只需重新生成和分发一个映像。这种方法简化了开发人员机器上不同项目的管理，因为可以避免依赖冲突，并以一种简单的方式分隔不同的项目。

4 FROM CHROOT OVER CONTAINERS TO DOCKER

基于容器的虚拟化使用内核提供的大量功能来隔离进程或实现其他有助于实现这一目的的目标。大多数解决方案都建立在Linux内核之上，由于本文的重点在于LXC和Docker，因此我们将仔细研究Linux内核提供的用于在容器中虚拟化应用程序的特性。因为内核提供了所需的大部分功能，所以容器工具包通常不需要再次实现它们，并且内核代码已经被其他软件使用，这些软件被认为是稳定的，并且已经在生产中使用了。如果内核提供的机制存在安全问题，则会随内核更新一起分发补丁，这意味着容器软件不需要打补丁，用户只需保持内核最新即可。

4.1 chroot

change root机制允许更改进程及其所有子进程的根目录。Chroot用于限制文件系统对单个文件夹的访问，目标进程及其子进程将该文件夹视为根文件夹(/)。在Linux上，这不是一个安全特性，因为用户可以转义chroot [11]。
除此之外，chroot还可以防止软件错误访问chroot之外的文件，而且—即使可以转义chroot—也会使攻击者更难访问完整的文件系统。Chroot通常用于在某种隔离的环境中测试软件并安装或修复系统。这意味着除了将进程的根目录更改为文件系统中某个位置的另一个目录外，chroot不提供任何进一步的进程隔离。
与正常的进程执行相比，将它们放到chroot中是一个相当弱的保证它不能访问它们不应该访问的文件系统的位置。

4.2 Linux containers

Linux containers [12] (LXC)是一个旨在构建一个将进程与其他进程隔离的工具包的项目。说,chroot并不发达的安全特性,可以逃避chroot——LXC试图创建环境(容器),应该是防泄漏的过程及其子进程和保护系统即使攻击者能够逃脱容器。除此之外，它还提供了一个用于细粒度限制容器资源消耗的接口。容器完全虚拟化了网络接口，并确保只能以安全的方式访问内核接口。下面的小节将更详细地介绍最重要的隔离机制。Linux容器(LXC)这个名称可能有点让人困惑:它是一个在Linux上创建容器的工具包，当然，除了LXC之外，还有其他方法可以实现与其他实用程序相同的目标，并在Linux下创建独立的进程或它们的组(容器)。因为LXC是一个受欢迎的工具包,本文的大多数语句指Linux容器适用于LXC,但是我们将使用术语LXC为了专门谈论流行的实现和Linux容器为了谈论的一般概念处理隔离在Linux上如本文所述。下面介绍的功能很难使用，这意味着正确的配置需要大量的阅读文档和大量的时间来设置一切。部署系统级工具的复杂配置是一项艰巨的任务。在不危及现有解决方案安全性的情况下，将配置轻松地采用到其他环境和不同的需求几乎是不可能的，因为工具箱提供了对这些特性的访问。LXC是一个试图满足这些需求的工具包。

4.2.1 Linux kernel namespaces

到目前为止，进程只是chrooted的，但仍然可以看到其他进程，并且能够看到用户和组id等信息，访问主机名并与其他进程通信。流程的目标是创造一个环境,让他进入一个特殊的复制这些信息,不需要其他进程看到是一样的,但是简单的方法防止进程访问这些信息可能会崩溃或导致错误的行为。为了实现这些需求，内核提供了一个称为namespaces 的特性(实际上，有几个不同的[13]namespaces)。内核名称空间是一个功能，它允许隔离进程、进程组甚至完整的子系统，如内核的进程间通信或网络子系统。它是一种灵活的机制，通过为需要分隔的进程创建不同的namespaces来分隔进程。内核允许将诸如网络设备或进程/用户/组id之类的全局资源传递到namespaces中，并管理这些资源的同步。可以创建包含进程ID (PID)的名称空间，该进程ID已经在主机系统或其他容器中使用。这简化了挂起容器的迁移，因为容器的pid独立于主机系统的pid。用户名称空间允许“隔离与安全相关的标识符和属性，特别是用户id和组id[…，root目录，keys …和能力”[14]。将所有这些特性组合在一起，就有可能以这样的方式隔离进程：

• 名称空间中的进程id与其他名称空间中的进程id是隔离的，并且每个名称空间都是唯一的，但是不同名称空间中的进程可能具有相同的进程id，
• 如果需要，可以通过内核提供的API访问全局资源，
• 主机系统和容器的用户、组和其他安全相关信息的抽象。
  实际上，kernel namespaces是进程分离的基础，因此也是实现基于容器的虚拟化的关键概念之一。它们提供了构建容器所需的许多特性，从2.6.26内核开始就可用，这意味着它们已经存在了好几年，并且已经在生产环境中使用了。

4.2.2 Control groups

为了将进程与其他进程隔离，控制组(进一步称为cgroups)是一个非强制性的特性。首先，cgroups是一种跟踪进程和进程组(包括分叉进程)的机制。[16]在第一种情况下,他们不解决问题与处理隔离或隔离更强,但钩子允许其他子系统提供扩展这些功能和实现细粒度的资源控制和限制其他工具相比更灵活试图实现类似的目标。将资源分配给流程和流程组并管理这些分配的能力允许计划和控制容器的使用，而不会无限制地浪费简单容器的物理资源。同样，可以保证资源不是不可用的，因为其他进程正在为自己声明资源。乍一看，这可能是一个主要针对服务于多个不同用户的主机的功能(例如共享网络主机)，但它也是一个避免拒绝服务(DoS)攻击的强大机制。DoS攻击不会危害系统，它们试图生成无用的工作负载，通过过度的压力阻止服务完成其任务。一个行为与被怀疑的容器不同的容器可能会有一个未知的bug，可能会被攻击者攻击甚至控制，并且会消耗大量的物理资源——从一开始就限制对这些资源的访问可以避免中断，并且可能会节省所有相关人员的时间、金钱和精力。如前所述，控制资源不是隔离所必需的特性，而是与基于管理程序的虚拟化竞争所必需的特性。在基于管理程序的虚拟化中，限制资源使用是很常见的，而能够对容器做同样的事情可以更好地利用给定的资源。

4.2.3 Mandatory Access Control

对这类系统的需求通常是为了提高安全性，在这种情况下，MAC用于加强Linux/Unix的访问控制机制。相反，如果请求资源，则检查授权规则(策略)，如果满足策略定义的需求，则授予访问权。如何实现这样一个系统有不同的方法，主要有三种:SELinux[17]、AppArmor[18]和grsecurity的RBAC[19]。MAC策略通常用于限制对敏感资源的访问，这些敏感资源在特定上下文中不需要访问。例如，Linux上的chsh1 namespace功能程序设置了setuid位。这意味着一个普通用户可以运行这个二进制文件，而这个二进制文件可以将其自身提升为使用root特权运行，从而完成所需的工作。如果在二进制文件中发现了一个bug，就可能以普通用户的身份使用root权限执行恶意代码。可以提供一个MAC策略，允许二进制文件提升其权限，以完成其合法的工作，但拒绝root可以做但库不需要做的所有事情。
在本例中，chsh二进制文件没有用于联网的用例，但是允许这样做，因为它可以执行root可以执行的任何操作。政策拒绝访问网络相关的系统组件不影响二进制但是如果它被攻击者利用,他无法用二进制来嗅嗅活跃的网络接口或更改默认网关流量捕获数据包,因为自己的盒子一个MAC政策是否认chsh工具访问网络子系统。有很多例子bug在软件让攻击者访问敏感信息或恶意的活动不需要的攻击过程,例如cve - 2007 - 33042这是一个错误的Apache web服务器允许攻击者发送信号到其他进程在执行模式被启用SELinux减轻已经[10]。特别是网络服务，如web或邮件服务器，以及连接的系统，如数据库服务器，正在接收不可信的数据，是潜在的攻击目标。将它们对资源的访问限制在最小需求范围内可以提高系统和所有连接系统的安全性。将这些安全改进应用于容器增加了另一层保护，以减少来自容器内部的对主机和其他容器的攻击。

4.3 Docker

LXC是一个处理容器的工具包，使用户不必使用低层机制。它创建了一个接口来访问Linux内核提供的所有特性，同时减少了用户的学习曲线。如果没有LXC，用户需要花费大量时间阅读内核文档，以便理解和使用提供的特性手动设置容器。LXC允许自动化容器管理，并允许用户构建自己的容器解决方案，该解决方案可定制，甚至可以满足特殊需求。对于那些只想在一个隔离的环境中简单地运行进程而不想花太多时间弄清楚工具包是如何工作的人来说，这仍然是不切实际的。这就是Docker[1]的作用:它是一个命令行工具，允许创建、管理和部署容器。与使用LXC完成相同的任务相比，它只需要很少的技术背景，并且提供了在生产环境中使用容器所必需的各种特性。Docker于2013年3月启动，受到广泛关注，项目发展迅速。通过将隔离进程的技术与其他有用工具相结合，Docker使得基于其他容器映像创建容器映像变得更加容易。它允许用户访问internet上一个名为Docker Hub[20]的公共存储库，该存储库包含数百个可用的镜像，可以通过一个命令下载并启动它们。用户有能力改变和扩展这些图像，并与他人分享他们的改进。还有一个API允许用户与Docker进行远程交互。与LXC的使用相比，Docker带来了很多改进，但也在一个不再那么技术性的层上引入了新的攻击向量，因为现在用户及其行为在整个系统的安全性中发挥了更大的作用。在更详细地讨论它之前，我们先概述一下LXC Docker的一些主要改进。

4.3.1 One tool to rule them all

LXC是一个强大的工具，支持广泛的设置，因此，如果不深入研究主题和工具，就很难获得它。Docker旨在简化工作流程。Docker命令行工具是用户与Docker守护进程交互的接口。它是一个具有可记忆的参数名称的命令，允许用户访问所有特性。根据环境的不同，从在线存储库(Docker Hub)提取(下载)图像并在系统上运行所需的配置很少，甚至不需要配置。除了不是必需的之外，当然还可以为Docker和特定的镜像创建配置文件，以便简化管理、设置特定的参数和自动化新映像的构建过程。

4.3.2 Filesystem layers generated and distributed independently

与经典的 hypervisor-based virtualization程序的相比，虚拟化Docker一个主要的改进是文件系统层的使用。文件系统层可以看作是文件系统的不同部分，即容器的root文件系统和包含应用程序特定文件的文件系统。可能有不同的文件系统层，例如一个基本的系统可能总是需要的和额外的层包含文件，例如一个网络服务器。这意味着可以将准备运行的web服务器作为独立的文件系统层分发。通过例证的方式组成的web服务是一个SQL数据库服务器像MySQL、Apache这样的网络服务器,一个编程语言和框架的web应用程序是建立在python使用Django和一个邮件传输代理像sendmail。当然，在一定程度上可以拆分这些工具并在不同的环境中运行它们(邮件、web和数据库可能在完全不同的机器上运行)，本例假设设置是开发人员设置，与生产使用中的部署不同。在安装Docker后,可以获取文件系统层的所有这些工具,并将其组合在一起,一个图像,上面提到的所有软件,现在可能为了开发web应用程序使用。现在的web应用程序本身可能是一个新的文件系统层的内容允许部署以后以同样的方式。如果发布了其中一个组件的新版本，而开发人员希望更新其本地层，则只需要获取更新后的层。用户的配置通常保持在一个单独的层中，不受更新的影响。因为不需要再次获取其他层的数据，所以节省了空间和带宽。如果另一个用户想要使用web应用程序开发人员推到码头工人中心,但他更喜欢PostgreSQL / MySQL和nginx / Apache web服务器和web应用程序可以使用这些替代的开发人员的设置中,他可能会使用各自的他想要使用的文件系统层软件。

4.3.3 Docker Hub

如前所述，Docker Hub[20]是引入虚拟化市场的新技术之一。这是没有人需要的东西，因为它根本不存在，每个人都很好地从头开始阅读文档，创建虚拟机和容器映像。Docker Hub是一个完全集成到Docker软件中的web服务，允许从Docker Hub获取准备运行的图像。用户创建或修改的图像也可以在Docker Hub上共享。结果是,Docker hub包含了很多不同的软件的图像在不同的配置和每个用户有能力获取图像和文档的图像,使用和提高并与其他用户联系评论图片和合作。Docker Hub也可以通过web浏览器访问。为了方便选择正确的图像经常使用的图像，如Wordpress, MongoDB和Node。Docker Hub允许这些项目将它们的图像标记为直接来自已声明的项目成员的官方图像。每个人都可以将自己的映像推送到Docker Hub，这带来了极大的多样性和大量可用的容器映像软件。甚至可以在那里找到一些更复杂或更具体的程序配置。Hub还引入了第5节中介绍的一些安全问题。用户不绑定到Docker Hub。可以设置私有注册中心，以同样的方式在本地使用，但是例如，只有在公司网络中通过身份验证的用户才能访问，或者为了构建独立于现有结构的公共结构。

4.4 Managing great numbers of containers

运行容器在资源消耗方面很便宜。依赖于容器结构构建大型服务可能涉及位于世界各地不同机器上的数千个容器。今天，这可能仍然是一个特例，但一些公司已经面临管理问题，因为他们有太多的容器，无法手工管理。谷歌引入了Kubernetes[21]，以便简化管理，对容器进行分组，并自动处理容器组。

5. SECURITY OF CONTAINER-BASED VS. HYPERVISOR-BASED VIRTUALIZATION

基于管理程序的虚拟机通常用于通过将暴露给攻击者的资源与需要保护的其他资源隔离来引入另一层安全。正确配置的容器有一个安全配置文件，它比一个服务器上的多个应用程序稍微安全一些，比KVM虚拟机稍微安全一些。与相邻的多个应用程序相比，[10]具有更好的安全性，这是因为前面提到的机制使得从隔离的环境中逃逸变得更加困难，但是所有容器中的所有进程仍然与主机内核下的其他进程一起运行。由于KVM是一个虚拟机监控程序，它模拟完整的硬件和内部的另一个操作系统，因此很难逃离这个环境，因此基于虚拟机监控程序的虚拟化的安全性稍微高一些。
可以将这两种技术结合在一起，由于资源少，而且引入了基于容器的虚拟化的安全层，这被认为是一个好主意。尽管如此，基于容器的虚拟化并没有被证明是安全的，容器突破在过去的[22]中已经发生了。
共享图像的精神产生了多种安全问题。Docker已经很长一段时间没有足够的机制来检查下载的图像的完整性和真实性,这意味着图像的作者确实是形象的人声称他们是谁,没有被修改而不被认可,相反他们的系统暴露的攻击表面,它可能被攻击者可以修改图像和经过Docker的验证机制[23]。Docker通过集成一个名为Content Trust的新机制解决了这个问题，该机制允许用户验证图像的发布者[24]。对于基于管理程序的虚拟化软件来说，Docker Hub是无与伦比的，这意味着通常从头开始构建虚拟机。在Linux中，一方面包被签名并且真实性和完整性可以被验证是很常见的，另一方面每个虚拟机都包含大量的软件，这些软件需要手工处理。
Docker最大的问题之一是很难处理大量包含安全漏洞的图像。这个问题的起因是Docker Hub上的图像不会自动更新，每次更新都需要手工构建。这是一个相当社会的问题，人们不更新他们的软件，也不更新他们过去推送到Docker Hub的容器。与虚拟机上软件不更新的现象相比，这是一个比较困难的问题:Docker Hub实际上没有可用的更新，最新的映像包含漏洞。在虚拟机上，当运行仍然需要维护的操作系统时，需要有人登录并安装安全更新，由于各种原因，这些更新可能会被遗忘或简单地忽略，但是作为用户构建固定的容器通常需要更多的工作。
一项研究发现[25]，“Docker Hub中超过30%的官方图片存在高优先级的安全漏洞”。这些数字是由扫描Docker Hub上列出的图像以查找已知漏洞的工具生成的。超过60%的官方图像(这意味着它们来自容器中包含的项目的官方开发人员)包含中等或高优先级的漏洞。对中心上所有图像的漏洞进行分析，发现75%的漏洞都是考虑中、高优先级的问题。克服这些问题需要对容器进行永久性的分析，这意味着定期扫描容器以发现安全问题，并将发现的问题通知容器的创建者和用户。这意味着可能更容易出现过时容器的问题，因为它们集中存储的事实允许静态扫描存储库中的所有图像。
海登指出，如何从头构建一个安全的LXC容器，它可以用作进一步修改[10]的基础。

6. RELATED WORK

虚拟机监控程序和基于容器的虚拟化的一个用例是通过隔离不受信任的进程或连接到其他系统的进程来提高安全性，并暴露攻击面，即连接到internet的机器上的web服务器。当然，还有其他方法可以提高虚拟化的安全性。
另一种分离应用程序的方法可以在Qubes OS[26]项目中找到。他们建立一个基于Linux的操作系统和X11窗口系统的XEN,允许创建AppVMs专用的虚拟机中运行的应用程序——在某种程度上类似于容器的方法,但由于基于管理程序的虚拟化,而不是建在一个标准的Linux内核机制。根据他们的主页，甚至可以运行基于Microsoft Windows的应用程序虚拟机。
MirageOS[27]也是在XEN上设置的操作系统，但是在MirageOS上部署应用程序意味着部署包含应用程序的专门内核。这些unikernel[28]只包含执行其唯一任务所需的内容。因为没有不是绝对必需的特性，所以通常情况下，unikerkernel非常小，而且性能非常好。MirageOS是一个库操作系统，可以用来创建这样的unikerkernel。这种方法可能最大的缺点是，应用程序需要专门编写来与unikerkernel一起使用。

7. CONCLUSION

对于那些不需要或不希望拥有独立的模拟硬件和操作系统内核(系统中的系统)的人来说，基于容器的虚拟化是基于管理程序的虚拟化的轻量级替代方案。在许多场景中，速度、简单性和只需要隔离进程是普遍存在的，而基于容器的虚拟化满足了这些需求。通过使用Linux内核中已经存在多年的大部分特性，基于容器的虚拟化构建在一个成熟的代码库之上，这个代码库已经在用户的机器上运行，并且由Linux社区保持最新。特别是Docker引入了一些与虚拟化无关的新概念。为用户提供协作、共享和重用其他用户的工作的社交方面无疑是Dockers成功的秘诀之一，也是虚拟化领域的一个全新理念。因为运行大量容器相对容易，所以已经有工具可以管理大量的容器。
当涉及到安全问题时，不需要“vs”。在这篇论文的标题中。通常，当然可以在已经虚拟化的计算机上运行容器，或者在容器中运行管理程序。hypervisor 层被认为是比上面描述的机制的应用程序更厚的安全层。然而，应用这些轻量级机制增加了额外的安全性，而且几乎不需要任何资源。