IBM 研究部门发表了一篇关于容器和虚拟机环境性能比较的论文。这篇论文使用了Docker 和KVM 作为研究对象,阐述了Docker 使用NAT 或AUFS 时的开销,并且质疑了在虚拟机上运行容器的实践方法。
论文作者在原生、容器和虚拟化环境中运行了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 上的方法,由于虚拟机的性能开销,这种实践方法不会得到任何额外的好处。
参考英文原文: Comparing Virtual Machines and Linux Containers Performance
感谢张龙对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。
活动推荐:
2023年9月3-5日,「QCon全球软件开发大会·北京站」 将在北京•富力万丽酒店举办。此次大会以「启航·AIGC软件工程变革」为主题,策划了大前端融合提效、大模型应用落地、面向 AI 的存储、AIGC 浪潮下的研发效能提升、LLMOps、异构算力、微服务架构治理、业务安全技术、构建未来软件的编程语言、FinOps 等近30个精彩专题。咨询购票可联系票务经理 18514549229(微信同手机号)。
评论