容器技术的最大意义在于其不需要同时使用多个操作系统，而在hypervisor虚拟化环境当中每台虚拟机都需要使用独立的操作系统。显而易见，这种方式能够大幅度降低系统开销所占用的内存，能够为应用及其数据预留更多的空间。

使用容器技术能够节约大量操作系统所占用的内存空间。通常相比于hypervisor，使用容器能够在同一台服务器当中创建三倍的实例数量。在某些情况当中，比如完全一样的虚拟桌面，实例数量能够达到之前的十倍。从另外一个角度来说，特定负载所需的服务器数量也就大幅降低了。授权部分也会受到影响，企业只需要为每台服务器购买一个授权。由于应用成为共享镜像的一部分，因此也能够从中获益。

容器提升性能和安全性

容器技术还能够带来其他好处。相比于hypervisor，其启动速度更快，主要是因为镜像不需要从头进行加载。镜像具有更好的可移植性并且更加易于部署，因此能够在运营过程中为部署和敏捷性带来很大帮助。此外，测试报告显示相比于传统hypervisor，容器在完成某些特定任务方面具有很大的性能优势，最多只需要使用原有时间的15%。

容器技术拥有如此多的优势，以至于很多人不太理解除了行业内的保守派之外，容器技术为什么还没有完全取代原有hypervisor。毕竟，Docker在这个行业当中拥有很强的领导能力，并且容器技术也已经基本成熟。

容器是一种全新技术，并且正在快速发展。而与之对比的hypervisor则更加成熟，并且已经通过市场的证明。其在安全性方面不断加固，并且x86 VTx架构为其提供了硬件辅助，因此想要实现跨租户间的袭击几乎是不可能的。相对来说有人质疑容器更加脆弱，攻击者可能袭击底层操作系统，进而控制服务器当中的所有实例。

由此产生的结果是容器通常被运行在hypervisor之上。每个租户的容器实例都被隔离在单独的虚拟机当中，这样就能够实现硬件保护，防止遭遇跨租户袭击。这种方式的缺点也十分明显。不仅更加复杂，而且还会涉及hypervisor代码以及操作系统拷贝等授权问题，并且影响性能，甚至是失去敏捷性——但是至少实例是安全的。

但是现在容器生态系统已经能够应付这种局面。一些Thin hypervisor，比如英特尔的Clear Container，就是被设计用来保护容器并且合理利用硬件——不会占用大量空间或者过度影响系统性能表现。其他一些安全改进——特别是在镜像证明和认证方面——意味着容器已经能够弥补和hypervisor在安全性方面的差距了。

Hypervisor如何回应

Hypervisor开发者也并不清闲。尽管最初他们否认容器会对其带来威胁，但是最终还是开始应对容器技术所带来的各种威胁可能性。比如，VMware使用内存页面去重复化技术来降低内存使用量，这种技术能够替换整个内存页面，将所有重复内容都指向同一个内存地址。这种方式能够有效降低负载，但是hypervisor的运行速度依然无法和容器相提并论。在运营过程中还可以通过其他方式来实现平衡。内存页面去重复化技术能够进一步演变，比如针对已经加载的镜像创建索引，针对已经在系统当中的文件进行检查。这种方式不会带来任何额外负载，能够大幅度提升去重复化速度。我们想要将现在的hypervisor和未来的容器进行对比，表明hypervisor虚拟化并没有停滞不前。

除了内存和性能问题之外，两种解决方案的应用领域也各不相同。对于那些需要进行大规模扩展、但是几乎不会相互影响——至少不会直接相互影响——的任务来说，使用容器更加合适。比如，容器技术能够很好地满足Web服务以及微服务的需求，如果能够对容器进行恰当配置，那么其还能够在云中发挥重要作用。

相比于容器，hypervisor更加适用于那些规模庞大的独立应用，管理员能够更好地控制和应用相关的网络和存储架构，由于这些大型应用通常都被用来执行一些关键任务，因此节约资源和启动时间并不是其主要考虑因素——特别是和潜在的故障时间或者安全隐患相比。

科学计算，几年之前刚刚进入虚拟化领域，已经在很大程度上提升了生产力。这些工具通常都会根据当前环境进行调整，因此更加适合于复杂任务。

至于成本因素，应用和操作系统授权方式还需要进行不断调整，这样才能使得所有用户都能够负担的起虚拟化的价格，不论选择使用哪种虚拟化方式。每个实例每分钟的收费方式也许将会成为最终标准。

凭借现有的强大生态系统以及庞大的用户群体，hypervisor还将会在IT领域发挥重要作用。在容器和hypervisor的竞争当中，只有当hypervisor设计者不再进行回应的的时候，容器才有可能成为最终的胜利者，但是这几乎是不可能的。事实上，未来最有可能的发展方向就是hypervisor和容器技术相互融合，至少在特性和优势方面。那些现在已经非常依赖于hypervisor基础架构的IT部门也许希望继续使用这种方式，比如使用简化的hypervisor实例或者在hypervisor实例当中使用容器。另一方面，全新安装的企业最有可能会直接使用Docker或者其他方案。对应用进行分类也是一种可行方案，hypervisor虚拟化更加适用于庞大的单一应用。

首先容器更小（M），虚拟机比较大，同时需要对硬件仿真。

其次容器性能比虚拟机好，容器可以在几秒钟内启动并重新启动。虚拟机一般要几分钟。

此外虚拟机管理程序和客户机操作系统不需要额外的开销，使容器消耗更少的CPU和内存。

最后管理成本上，每台虚拟机需要一个完整的功能操作系统，然后进行额外的管理；而容器和母系统共用才做系统，因此额外开销少。

缺点上：

容器隔离性不如虚拟机，比较底层是共用的

其次，无法对硬件仿真，一些和硬件有耦合的产品不能用

虚拟化技术通过Hypervisor(虚拟机管理系统)为每个app启动一个Guest OS(客户机操作系统),也就是为每个app启动一个虚拟机。比较直观地说,vm通过Hypervisor对硬件资源进行虚拟化,而docker直接使用硬件资源,利用率上来看docker明显更具有优势。

使用虚拟机运行多个相互隔离的应用时
基础设施(Infrastructure)。它可以是你的个人电脑，数据中心的服务器，或者是云主机。
主操作系统(Host Operating System)。你的个人电脑之上，运行的可能是MacOS，Windows或者某个Linux发行版。
虚拟机管理系统(Hypervisor)。利用Hypervisor，可以在主操作系统之上运行多个不同的从操作系统。类型1的Hypervisor有支持MacOS的HyperKit，支持Windows的Hyper-V以及支持Linux的KVM。类型2的Hypervisor有VirtualBox和VMWare。
从操作系统(Guest Operating System)。假设你需要运行3个相互隔离的应用，则需要使用Hypervisor启动3个从操作系统，也就是3个虚拟机。这些虚拟机都非常大，也许有700MB，这就意味着它们将占用2.1GB的磁盘空间。更糟糕的是，它们还会消耗很多CPU和内存。
各种依赖。每一个从操作系统都需要安装许多依赖。如果你的的应用需要连接PostgreSQL的话，则需要安装libpq-dev；如果你使用Ruby的话，应该需要安装gems；如果使用其他编程语言，比如Python或者Node.js，都会需要安装对应的依赖库。
应用。安装依赖之后，就可以在各个从操作系统分别运行应用了，这样各个应用就是相互隔离的。
使用Docker容器运行多个相互隔离的应用时，

基础设施(Infrastructure)。
主操作系统(Host Operating System)。所有主流的Linux发行版都可以运行Docker。对于MacOS和Windows，也有一些办法”运行”Docker。
Docker守护进程(Docker Daemon)。Docker守护进程取代了Hypervisor，它是运行在操作系统之上的后台进程，负责管理Docker容器。
各种依赖。对于Docker，应用的所有依赖都打包在Docker镜像中，Docker容器是基于Docker镜像创建的。
应用。应用的源代码与它的依赖都打包在Docker镜像中，不同的应用需要不同的Docker镜像。不同的应用运行在不同的Docker容器中，它们是相互隔离的。
对比虚拟机与Docker
Docker守护进程可以直接与主操作系统进行通信，为各个Docker容器分配资源；它还可以将容器与主操作系统隔离，并将各个容器互相隔离。虚拟机启动需要数分钟，而Docker容器可以在数毫秒内启动。由于没有臃肿的从操作系统，Docker可以节省大量的磁盘空间以及其他系统资源。

LXC（LinuX容器）提供独立的操作系统环境，具有自己的文件系统，网络，进程和块I / O空间。描述容器的一种最喜欢的方式是它们就像“类固醇上的chroot”，因为它们提供chroot jails提供的文件系统隔离，但它们通过提供IP地址，单独的进程域，用户ID和专用访问来超越它chroot jails不提供的主机的物理资源（即内存，CPU）

主要用意是提供比chroot更完整的process的isolation，但是范畴都还是寄生在同一个Host OS上面，所以他很轻量，也很快(因为不像Hypervisor每开一个Guest OS都要跑完整的开机流程)

一开始Docker也是架设在LXC之上，不过从Docker 0.9版以后，LXC已经不再是Docker唯一且预设的执行环境

Docker现在支援更多种的”isolation tools”包含：
DOpenVZ
systemd-nspawn
libvirt的，LXC
libvirt的沙箱
QEMU / KVM
BSD Jails
Solaris Zones
chroot环境