虚拟机容器和Docker的区别

在原生、容器和虚拟化环境中运行了cPu、内存、网络和i/o的benchmark。

其中，分别使用KVm和docker作为虚拟化和容器技术的代表。

benchmark也包含了对不同环境下Redis和mysQL负载的采样。

通过小数据包和多客户端，Redis侧重于网络栈的性能。

而mysQL侧重于内存，网络和文件系统的性能。

结果显示，在每一项测试中，docker的性能等同于或超出KVm的性能。

在cPu和内存性能方面，KVm和docker都引入了明显的，但可略不计的开销。

但是，对于i/o密集型的应用，两者都需要进行调整以减少开销带来的影响。

当使用auFs存储文件时，docker的性能会降低。

而相比之下，使用卷（volume）能够获得更好的性能。

卷是一种专门设计的目录，存在于一个或多个容器内。

通过这种目录能够绕过联合文件系统（union file system）。

这样它就没有了存储后端可能带来的开销。

默认的auFs后端会引起显著的i/o开销，特别是当有多层目录深度嵌套的时候。

docker的默认网络选项，--net=bridge，由于nat会重写数据包，也引入了性能开销。

当数据包收发率变高时，这种开销会变得很明显。

可以通过使用--net=host改善网络的性能。

这个选项告诉docker不要为容器创建一个独立的网络栈，并允许容器拥有宿主机网络接口的完全访问权限。

但是，使用这个选项时要小心。

因为它允许容器内的进程像其他根进程一样，使用数值较小的端口；并允许容器内的进程访问本地网络服务，如d-bus。

这使得容器内的进程可以做一些预料之外的事情，如重启宿主机。

尽管自诞生以来，KVm性能有了相当大的提升，但它仍然不适用于对延时敏感或高i/o访问率的工作负载。

因为每次i/o操作，它都会增加一些开销。

这个开销对于耗时较少的i/o操作是有意义的，但对于耗时较长的i/o操作是可以忽略的。

根据这些测试结果，论文对使用虚拟机实现iaas的方法提出了质疑： 传统观点（在某种程度上，这种观点存在于年轻的云生态圈中）认为使用虚拟机实现iaas，使用容器实现Paas。

我们没有找到技术方面的理由来证明必须这么做，尤其是证明容器基于iaas能提供更好的性能或者更容易部署。

由于容器提供了控制手段，并在不使用虚拟机的情况下能达到物理机的性能，所以它能够消除iaas和非虚拟化的服务器间的差异。

尽管在虚拟环境中运行容器是一种常见的实践方法，但是论文建议直接在物理的Linux服务器上运行它们。

否则，相比于直接运行在非虚拟化的Linux上的方法，由于虚拟机的性能开销，这种实践方法不会得到任何额外的好处。

来源：https://www.weidianyuedu.com