虚拟化技术——Container技术存在的问题

Posted 2022-12-06 雨钓Moowei

如果Container技术这么好那我们是不是可以完全抛弃虚拟机，所有虚拟机原有的使用场景全部改用Container呢？

答案是不行！因为Container也有他的局限性，这主要有两方面的原因:

1. 第一是Container技术本身;

2. 第二是使用Container的应用场景上。

一、Container技术本身的不足**

Container技术本身最大的问题就是安全性。

在之前文章中提到，Container是共用操作系统的，一个物理的服务器上会跑几百上千个Container，甚至在某些数据中心里面可能会跑几万个、几十万个Container。那如果操作系统出现漏洞怎么办（并不能排除这种情况）？只要利用操作系统的漏洞，黑客可以迅速的把所有Container全部搞掉。

还是跟虚拟化技术对比，为什么虚机要安全的多。

以KVM为例，KVM在内核里就是两个模块，所以它的安全性要比你整个操作系统的安全性要高的多。此外，在硬件辅助虚拟化技术中，指令在执行时各个虚拟机之间指令执行的路径也是相互隔离的，所以虚拟机的安全性比Container的安全性要高很多。

二、使用场景限制**

2.1、多租户环境下

回到之前的问题，Container的安全性问题会带来哪些使用限制呢？

答案是在多租户环境下，特别是在公有云环境下。因为公有云环境下不同的租户来自不同的公司，而业界存在一个有趣的现象，同一个公有云上的客户具有行业密集性，比如七牛云视频图片最多，Ucloud上的用户手游最多。同行都是半个仇家，如果我有这个机会在自己Container的操作系统中植入一些病毒就可以搞垮你，那为啥不试试呢。所以这时Container的安全性就是一个严重的缺陷。针对这种场景Container技术就不太适用了，也就是它的安全性是不足以应用到公有云上的。

当然，如果你非要在公有云上使用Container的话也是可以的。把用户提交的东西限制死，只允许提交指定的东西上来，那安全性也是可以保证的。但是你是通过限制用户操作来保证安全性，因此用户的很多以应用是提交不不上去的，体验很差。

2.2、不同的Container要求操作系统不一致

此外，还有一些别的问题，因为Container是共用操作系统的内核，如果我两个应用的操作系统内核不一样怎么办。

典型的情况就是运营商一些网络设备里面经常需要去改驱动，因为他需要用特殊的硬件，linux的外设驱动全部都在内核里面。如果你要改Linux的内核驱动的话，而Container又是共用操作系统内核的，这怎们解决！你改了内核其他Container怎么办，而且通常情况下你也是没有修改权限的。当然这样的情况也是有解决方法的。相较于虚拟机，我们之所以使用Container无非就是贪图Guest OS 的开销，那我们先启动少数几个虚拟机，同时在虚拟机里面我们再使用Container技术实现资源的隔离和动态管理。租户间的隔离和安全性通过虚机来保证。

有些人会说“在虚机里面跑Container引入了两层虚机化开销”。这完全是无稽之谈。前面介绍了虚拟化的开销是执行特权指令时带来的开销。通常特权指令开销的比例占多少？一个笼统的说法是10%-20%。实际上这是不一定的。之前曾做过实验，专门做浮点运算，算一个pi，开个根号等等，虚拟化的开销基本上是0，因为没有一行特权指令，不涉及到内核问题。但是如果涉及网络IO，涉及到特权指令的调用，那超过20%很正常，甚至超过一半都有可能。比如在物理服务器上1分钟就能做完，在虚机里面可能就2分钟都没做完。所以需要具体问题具体分析。因此对于虚机里面跑Container就是两级虚拟化严重降低性能这种说法就太片面了。Container技术本身就是利用操作系统的功能来实现的，根本就没有指令再虚拟化造成的性能损耗。

未完待续。。。。(谨以此系列文章缅怀逝去的学生时代)