容器和虚机

这一段时间,凡是提及容器技术的话题总会成为热门。外界的声音似乎一致认为容器技术,或者说docker.com推出的,通过简单的docker命令管理和使用的,从docker image部署出来的docker 容器(真绕!)将会成为下一个取代各式虚拟机的技术。事实真的如此吗?


我们不妨从container最大的优势——性能说起。下图通过一系列的workload工具,对KVM代表的虚拟机技术、docker 容器和host 原生的应用进行了性能测试。很显而易见的是,相比KVM超过10%的额外开销,容器方面只有不到2%的性能损耗,应该是具有巨大的性能优势了。而且从具体的数值上看,容器方面的损耗仅仅只出现在了对系统资源的访问上,对于计算密集型的应用这类的开销完全可以直接忽略掉。
container_vm_performance
由于容器技术本质上是通过系统原生的cgroup框定资源配额,通过namespace完成用户态的限制,而真正实现容器内部的虚拟文件系统的是aufs。都是比较偏向于内核态的技术。由于aufs文件系统相较原生的Linux文件系统如exf4,性能上会略差。可以这么说,这个测试结果事实上可以验证了一点:容器技术(这里特指docker container)的性能损耗仅仅是由于aufs的性能问题。

下图是虚机技术和docker 容器在架构上的不同。可以明显的看出,docker container省去了虚拟机的hypervisor层和另一个厚厚的Guest OS层。由于实现Docker container的3大主力技术cgroup, namespace, aufs都是通过Linux内核的原生支持,Docker仅仅只用了一个薄薄的类似于兼容层的接口打包封装,也就是图中天蓝色的“Docker Engine”就实现了“虚拟化”。更少的stack意味着更少的开销,less is more。

container_vs_vm

话说回来,容器可以替代VM吗?

挑战一:内核态的缺失

前面说过,即便我们可以通过docker image的模拟,实现了在ubuntu上兼容Centos或者其他Linux操作系统但我们无法从Linux上启动一个Windows或者FreeBSD的容器。同样的,Windows即便已经官方支持了docker命令,但事实上它仅仅只是跑在了windows下的一个虚机上。如果你的应用从底层牢牢地绑定了操作系统或者Kernel的版本,容器并不适合你。

同样的,由于内核态的缺失,我们无法在容器内部直接对硬件进行访问。你无法直接访问硬盘,无法直接设置CPU和各类电源状态等。你当然可以通过一定的技术手段从容器内部强行访问硬件,但这明显不属于“正常使用”的范畴。

最后的,由于内核态的缺失,你会发现在container内部并没有cgroup的映射。这也就是说:你无法简单的从一个容器里再次启动一个容器实现容器嵌套。这一点对于虚拟机来说,只要你能接受卡顿的感觉,理论上你可以实现无限制的虚拟机嵌套。

挑战二:用户态的直接暴露

对于这个问题,简单来说就是:在host上可以对容器内部的资源随意操作。

对于VM来说,系统中所有的进程都是在一个hypervisor进程内部的。也就是说对于host级别的用户,vm只是一个(或者几个)进程而已。vm在做什么,host不care,也无法直接获取。而对于容器来说,host只要简单的通过ps命令就可以得知容器的进程甚至各种系统资源的详情。
举个简答的例子,如果我是一个手比较闲的管理员,我的主机上有个java进程,同时有多个container都托管了java。我打算杀掉本机上的java进程,结果手一抖killall -9 java,系统中所有的java进程都被一扫而光,包括所有托管的java容器全都挂掉。

有一个更为极端的例子是:借助特定代码,container可以越权访问主机或者另外container的资源。虽然这是一个存在于Linux kernel内的一个bug,但无可否认的另一点就是container本身的安全性并不健全。这也就是当下很多服务商坚持只提供VM中嵌套的container服务。

用户态暴露的另一问题就是volume的文件权限混乱问题。对于与主机共享的volume也是container的优势之一,但由于用户态的不同,明显应该低于root权限的container内部可以简单的通过volume在host上创建root权限的文件;另一方面同样可以通过volume在host侧创建大量不明用户的文件。

挑战三:复杂网络结构

尽管用户可以通过使用openvswith之类的服务替代默认的bridge实现跨主机之间的网桥,但对于绑定多IP,多层转发等“高级应用”,容器还是略有不足的。

总之,对于容器来说,它们的优势在于快速部署,快速移植带来弹性和更低的耦合度。对于docker来说,重点在于它的易用性和社区支持。它并不适合所有的虚拟机场景。归根揭底的说,尽管Docker官方出于商业影响的考虑,时常将自己和VM相提并论,但对于两种技术实现方式而言,这样的对比是不恰当的。

 

推荐阅读:
自打从硬件方向研究性能优化起,
之前我们通过几个概念简单的介绍

发表评论

电子邮件地址不会被公开。 必填项已用*标注

请补全下列算式: *

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据