以Docker为代表的传统容器已到生死存亡之际

发表于 4年以前 | 总阅读数：699 次

云原生是一座由精妙理论所构筑的摩天大厦，但其中的砖石还需加固。

当云原生将容器技术作为下一代云计算的基础之一时，并不意味着容器本身停止了演化。事实上，以Docker为代表的传统容器在遇到多租户场景时，它的安全问题立刻暴露了出来，这时，人们才怀念起虚拟化的好处。

于是，采用虚拟化技术的“安全容器”这一概念应运而生，而开启这一变革的，正是Kata Containers，前不久，它刚刚度过两周年。

新的Kata Containers为我们带来虚拟机的安全性和隔离性、与容器兼容的API接口，同时还有与容器同一级别的性能，这意味着采用安全容器的时机已经成熟。

与此相对的是，上个月，Docker的企业级业务被打包出售，据称出售价格甚至不及几轮下来的融资总额。

所有在生产环境使用容器的公司，从现在开始都有必要审视自己的安全策略，并制定从容器到安全容器的迁移计划。

这一切是怎么发生的呢？听我为你一一道来。

Docker的溃败

2019年11月13日，私有云基础设施公司Mirantis在其官方博客宣布，收购Docker公司企业级业务，包括接管它的700多个客户，这标志着Docker公司从2013年开始的商业化探索彻底失败。

在不了解容器发展历史的人看来，这种结果很难理解，Docker是容器热潮的开创者，容器则是这一轮云计算技术演进的开启者，为什么明明站在风口上了，却仍然飞不起来？

这与Docker创始人的一系列迷之操作固然脱不了干系，但其实，Docker今天的命运，在4年前就决定了。

在2013年以前，业界其实一直都没有找到云计算原生的打开方式，GAE以及Cloud Foundry早期版本为代表的PaaS将大家都带到坑里，只留下一地鸡毛。直到Docker开源，大家才如梦方醒，原来不是方向不对，而是应用分发和交付的手段不行。

然而，Docker公司将其核心代码开源的初心并不只是造福业界，它是想用这种方式吸引商业客户。Docker公司将Docker注册为商标，引起了社区的警觉，各种自创容器项目层出不穷。

为了结束这种乱象，2015年6月，容器开放推进组织OCI成立，旨在围绕容器格式和运行时制定一个开放的标准，Docker作为创始成员，意图将这个标准制定权抓在手里。

然而，大家实在是被Docker在商业化和社区两边左右摇摆的态度吓怕了，2014年Kubernetes发布后，迅速吸引了包括红帽在内的一批成员，并在短短一年之后的2015年7月，Kubernetes发布了1.0版本，随之而来的还有CNCF云原生计算基金会。

CNCF的诞生宣告云计算技术演进的重心从容器转移到容器编排，随后的2016年，Kubernetes发布了容器运行时接口CRI，只要符合这个接口，Kubernetes就可以通过它来运行容器，是不是Docker已经无关紧要了。

就这样，容器从Docker变成了一种标准接口实现，只要符合这个标准，不用管背后运行的是什么。

结合容器和Kubernetes，大家在自己的集群上用得很愉快，但当云厂商试图向大众提供容器服务时，多租户安全问题出现了。

AWS的选择

要理解这个问题，我们首先要了解容器的原理。

Linux容器的本质是一种进程隔离技术，通过cgroup和namespace，容器里的应用只使用给定的资源，不同容器之间互不侵犯。

从容器里应用的角度来看，它只能看到给定的计算存储资源和为其定制的系统，但从容器外面的系统来看，它运行的是一个一个的进程。

如果这些容器都属于同一个用户那还没什么，但如果是云服务，一台机器里面运行着不同用户的一个个进程，光是想一想就有一种四处漏风的感觉！

从技术角度讲，AWS在它的官方博客中是这么描述这个安全隐患的：

由于操作系统内核漏洞，Docker组件设计缺陷，以及不当的配置都会导致Docker容器发生逃逸，从而获取宿主机权限。由于频发的安全及逃逸漏洞，在公有云环境容器应用不得不也运行在虚拟机中，从而满足多租户安全隔离要求。而分配、管理、运维这些传统虚拟机与容器轻量、灵活、弹性的初衷背道而驰，同时在资源利用率、运行效率上也存浪费。

这就是云原生里面的多租户问题，其本质是容器安全问题。前几年，云厂商在推出Kubernetes集群服务方面进展神速，但在提供单一容器托管方面却步伐迟缓，就是因为这个问题迟迟没有解决。

并且，多租户问题不仅仅在公有云上存在，在公司内部的私有云上同样存在，不同部门、团队的应用，理应进行强隔离，以免一个业务出现问题影响整个公司。但过去，大家应用容器的势头很强，装作看不到这个问题罢了。

对于多租户问题，虽然社区逐渐有了一些解决方案，但因为还不太成熟，也缺乏一个标志性事件把它们推到前台。终于，2018年12月，AWS出手了。

众所周知，AWS是云计算行业的领头羊，但在容器到云原生这波浪潮里，AWS却变成了跟随者的角色，它肯定是不甘心的，最终，它在容器安全给出了自己的答案，重新走在了所有云厂商的前面。

AWS的答案是Firecracker，一种轻量级虚拟机（MicroVM），这个轻量级是相对于全功能虚拟机来说的，后者的代表是QEMU，号称能模拟所有硬件设备。Firecracker将能省的地方都省了，最终留下一个极其精巧的运行时，只保护该保护的地方。

从性能上来讲，Firecracker和容器已经很接近了，它最初的意图就是为AWS的Serverless服务Lambda提供保护，性能必须要跟上；从安全上来讲，在该保护的地方，它提供的是虚拟机级别的保护，无论是来自内部和外部的漏洞和攻击都能防护。

AWS还推出了Firecracker的containerd实现，这意味着可以用标准容器的方法来驱动Firecracker，说明用虚拟机来解决容器安全这条道路是可行的。

但是，AWS有自己的一套完整生态，Firecracker也是这个生态的一部分，虽然它开源了，社区并不能做到开箱即用，与Kubernetes有一些不兼容的地方。

这时，就轮到Kata Containers出场了。

面向云原生的虚拟化

Kata Containers的前身是Hyper runV和Intel Clear Container，这两者都试图用虚拟化的技术来解决容器安全问题。

两者都是2015年5月布的，后来发现彼此技术路径差不多，两边的创始人聚到一起一合计，要不合并吧，于是Kata Containers就诞生了。

当时，正遭遇Kubernetes和CNCF强劲攻势的OpenStack基金会，一眼看出了Kata Containers的应用潜力，于是在将战略改为面向开放基础设施的同时，将Kata Containers接纳为第二个顶级开放基础设施项目，与OpenStack同级。

但是，Kata Containers在诞生后一段时间里，却并不受社区的开发人员看好。

其重要原因有二，第一个是，Kata虽然从第一天就将与Kubernetes集成作为最优先目标，但Kubernetes早期版本只考虑了如何运行容器，要让Kubernetes支持非容器技术需要额外做一些功夫，当时runC容器还如日中天，让Kubernetes管理虚拟机是一个比较另类的做法。

第二，Kata虽然成功地让虚拟机兼容了容器的大部分接口，但是性能太差，其中一个主要原因在于，它在底层采用了上面提到的QEMU作为对接系统接口层，而QEMU是一个包含数百万行代码、数万个文件的项目，虽然Kata努力对其进行了精简，但带来额外的性能损耗，还是让对安全不太敏感的应用难以接受。

事情的转机就在于AWS Firecracker的发布，当时，Firecracker只支持AWS自己的Serverless服务，但是明眼人都看得出来，Serverless都支持了，容器还远吗？Firecracker也让大家更加关注容器安全问题，Kata Containers开始受到更多的关注。

同时，Kata也在利用包括Firecracker在内的最新开源社区进展，进一步降低开销：比如，支持Firecracker作为部分适用场景的VMM，以及研发自己的rust-VMM cloud-hypervisor，又将沙箱agent替换为轻量的rust-agent，让内存占用从十多MB降低到1.1MB，提升肉眼可见，并且，这个开销已经可以接受。

另一方面，在Kata Containers和社区的推动下，Kubernetes开始接受安全容器了，在Kubernetes里运行Kata不再需要做额外处理。

在Kata Containers的两周年之际，它给自己的定义是面向云原生的虚拟化。

之所以要强调虚拟化，是因为它的本质是用的虚拟化技术，但与传统虚拟化相比，Kata Containers走的是一个完全不同的发展方向，是适合云原生场景下的虚拟化。

但是为什么又叫它安全容器呢？现在回到我们开头介绍的多租户问题，使用Kata Containers后，当你启动一个容器，实际上是启动了一个虚拟机，但这个虚拟机的功能、生命周期、性能表现都和容器一模一样。

鸭子测试说，如果一个动物走路像鸭子、说话像鸭子、长得像鸭子、啄食也像鸭子，那么我们就认为它是一只鸭子。放到Kata Containers也一样。

Docker自身的技术路线，无法很好地解决安全问题，所以当CRI和安全容器出现之后，它的商业化探索已经注定不会有太好结局。

Kata Containers与安全容器的未来

软件世界里有很多不确定性，但我们可以确定的是，安全问题一定会发生。

那么，如何应对安全问题呢？Linus说过这样一句话：