云原生是一座由精妙理论所构筑的摩天大厦，但其中的砖石还需加固。
当云原生将容器技术作为下一代云计算的基础之一时，并不意味着容器本身停止了演化。事实上，以 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 说过这样一句话：
安全问题的唯一正解在于允许那些（导致安全问题的）Bug 发生，但通过额外的隔离层来阻挡住它们。
—— LinuxCon NA 2015, Linus Torvalds
要一劳永逸地解决容器安全问题，可能唯有为其添加额外的隔离层，这也是 Kata Containers 的思路。
值得一提的是，安全容器 并不是只有 Kata Containers 和 Firecracker 这一条路线，Google 推出的 gVisor 是另一条路线，它是一个更纯粹的隔离层，上层应用对系统的所有访问都经过隔离层处理后，再将其中少数请求交给宿主机响应。
Kata Containers 经过两年耕耘，业界开始逐渐跟进，比如百度智能云，在函数计算、容器服务、边缘计算等方面开始尝试。
2019 年，Kata Containers 创始人加入蚂蚁金服，蚂蚁并未干涉 Kata Containers 的发展路线，Kata 仍是社区主导的开源项目，Kata Containers 也开始在蚂蚁和阿里内部逐渐落地。
Kata Containers 未来仍会继续优化其性能，当然，更重要的是，容器和虚拟机就像是一座天平的两端，Kata Containers 需要不断地摸索，去找到那个平衡点。
AWS 已经证明了安全容器是公有云落地 Serverless 的关键技术之一，与之类似，边缘计算也将成为安全容器的典型应用场景。
随着 AWS 以及各家云厂商的跟进，可以预见，2020 年将迎来安全容器落地的爆发。
Kata Containers 项目地址：