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

　　云原生是一座由精妙理论所构筑的摩天大厦，但其中的砖石还需加固。
　　当云原生将容器技术做为下一代云计算的基础之一时，并不意味着容器自己中止了演化。事实上，以 Docker 为表明的传统容器在遇到多租户场景时，它的安全问题马上暴露了出来，这时，人们才怀念起虚拟化的好处。
　　因而，采用虚拟化技术的“安全容器”这一律念应运而生，而开启这一变革的，正是 Kata Containers，前不久，它刚刚度过两周年。
　　新的 Kata Containers 为咱们带来虚拟机的安全性和隔离性、与容器兼容的 API 接口，同时还有与容器同一级别的性能，这意味着采用安全容器的时机已经成熟。
　　与此相对的是，上个月，Docker 的企业级业务被打包出售，据称出售价格甚至不及几轮下来的融资总额。
　　全部在生产环境使用容器的公司，从如今开始都有必要审视本身的安全策略，并制定从容器到安全容器的迁移计划。
　　这一切是怎么发生的呢？听我为你一一道来。
　　<strong>Docker 的溃败</strong>
　　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，你们在本身的集群上用得很愉快，但当云厂商试图向大众提供容器服务时，多租户安全问题出现了。
　　<strong>AWS 的选择</strong>
　　要理解这个问题，咱们首先要了解容器的原理。
　　Linux 容器的本质是一种进程隔离技术，经过 cgroup 和 namespace，容器里的应用只使用给定的资源，不一样容器之间互不侵犯。
　　从容器里应用的角度来看，它只能看到给定的计算存储资源和为其定制的系统，但从容器外面的系统来看，它运行的是一个一个的进程。
　　若是这些容器都属于同一个用户那还没什么，但若是是云服务，一台机器里面运行着不一样用户的一个个进程，光是想想就有一种四处漏风的感受！
　　从技术角度讲，AWS 在它的官方博客中是这么描述这个安全隐患的：
　　因为操做系统内核漏洞，Docker 组件设计缺陷，以及不当的配置都会致使 Docker 容器发生逃逸，从而获取宿主机权限。因为频发的安全及逃逸漏洞，在公有云环境容器应用不得不也运行在虚拟机中，从而知足多租户安全隔离要求。而分配、管理、运维这些传统虚拟机与容器轻量、灵活、弹性的初衷背道而驰，同时在资源利用率、运行效率上也存浪费。
　　这就是云原生里面的多租户问题，其本质是容器安全问题。前几年，云厂商在推出 Kubernetes 集群服务方面进展神速，但在提供单一容器托管方面却步伐迟缓，就是由于这个问题迟迟没有解决。
　　而且，多租户问题不只仅在公有云上存在，在公司内部的私有云上一样存在，不一样部门、团队的应用，理应进行强隔离，以避免一个业务出现问题影响整个公司。但过去，你们应用容器的势头很强，装做看不到这个问题罢了。
　　对于多租户问题，虽然社区逐渐有了一些解决方案，但由于还不太成熟，也缺少一个标志性事件把它们推到前台。终于，2018 年 12 月，AWS 出手了。
　　众所周知，AWS 是云计算行业的领头羊，但在容器到云原生这波浪潮里，AWS 却变成了跟随者的角色，它确定是不甘心的，最终，它在容器安全给出了本身的答案，从新走在了全部云厂商的前面。
　　AWS 的答案是<strong>Firecracker</strong>，一种轻量级虚拟机（MicroVM），这个轻量级是相对于全功能虚拟机来讲的，后者的表明是 QEMU，号称能模拟全部硬件设备。Firecracker 将能省的地方都省了，最终留下一个极其精巧的运行时，只保护该保护的地方。
　　从性能上来说，Firecracker 和容器已经很接近了，它最初的意图就是为 AWS 的 Serverless 服务 Lambda 提供保护，性能必需要跟上；从安全上来说，在该保护的地方，它提供的是虚拟机级别的保护，不管是来自内部和外部的漏洞和***都能防御。
　　AWS 还推出了 Firecracker 的 containerd 实现，这意味着能够用标准容器的方法来驱动 Firecracker，说明用虚拟机来解决容器安全这条道路是可行的。
　　可是，AWS 有本身的一套完整生态，Firecracker 也是这个生态的一部分，虽然它开源了，社区并不能作到开箱即用，与 Kubernetes 有一些不兼容的地方。
　　这时，就轮到 Kata Containers 出场了。
　　<strong>面向云原生的虚拟化</strong>
　　Kata Containers 的前身是 Hyper runV 和 Intel Clear Container，这二者都试图用虚拟化的技术来解决容器安全问题。
　　二者都是 2015 年 5 月布的，后来发现彼此技术路径差很少，两边的创始人聚到一块儿一合计，要不合并吧，因而 Kata Containers 就诞生了。
　　当时，正遭遇 Kubernetes 和 CNCF 强劲攻势的 OpenStack 基金会，一眼看出了 Kata Containers 的应用潜力，因而在将战略改成面向开放基础设施的同时，将 Kata Containers 接纳为第二个顶级开放基础设施项目，与 OpenStack 同级。
　　可是，Kata Containers 在诞生后一段时间里，却<strong>并不受社区的开发人员看好</strong>。
　　其重要缘由有二，第一个是，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 的两周年之际，它给本身的定义是<strong>面向云原生的虚拟化</strong>。
　　之因此要强调虚拟化，是由于它的本质是用的虚拟化技术，但与传统虚拟化相比，Kata Containers 走的是一个彻底不一样的发展方向，是适合云原生场景下的虚拟化。
　　可是为何又叫它安全容器呢？如今回到咱们开头介绍的多租户问题，使用 Kata Containers 后，当你启动一个容器，其实是启动了一个虚拟机，但这个虚拟机的功能、生命周期、性能表现都和容器如出一辙。
　　<strong>鸭子测试</strong>说，若是一个动物走路像鸭子、说话像鸭子、长得像鸭子、啄食也像鸭子，那么咱们就认为它是一只鸭子。放到 Kata Containers 也同样。
　　Docker 自身的技术路线，没法很好地解决安全问题，因此当 CRI 和安全容器出现以后，它的商业化探索已经注定不会有太好结局。
　　<strong>Kata Containers 与安全容器的将来</strong>
　　软件世界里有不少不肯定性，但咱们能够肯定的是，安全问题必定会发生。
　　那么，如何应对安全问题呢？Linus 说过这样一句话：
　　安全问题的惟一正解在于容许那些（致使安全问题的）Bug 发生，但经过额外的隔离层来阻挡住它们。
　　—— LinuxCon NA 2015, Linus Torvalds
　　要一劳永逸地解决容器安全问题，可能惟有为其添加额外的隔离层，这也是 Kata Containers 的思路。
　　值得一提的是，安全容器<strong>并非只有 Kata Containers 和 Firecracker</strong>这一条路线，Google 推出的 gVisor 是另外一条路线，它是一个更纯粹的隔离层，上层应用对系统的全部访问都通过隔离层处理后，再将其中少数请求交给宿主机响应。
　　Kata Containers 通过两年耕耘，业界开始逐渐跟进，好比百度智能云，在函数计算、容器服务、边缘计算等方面开始尝试。
　　2019 年，Kata Containers 创始人加入蚂蚁金服，蚂蚁并未干涉 Kata Containers 的发展路线，Kata 还是社区主导的开源项目，Kata Containers 也开始在蚂蚁和阿里内部逐渐落地。
　　Kata Containers 将来仍会继续优化其性能，固然，更重要的是，容器和虚拟机就像是一座天平的两端，Kata Containers 须要不断地摸索，去找到那个平衡点。
　　AWS 已经证实了安全容器是公有云落地 Serverless 的关键技术之一，与之相似，边缘计算也将成为安全容器的典型应用场景。
　　随着 AWS 以及各家云厂商的跟进，能够预见，2020 年将迎来安全容器落地的爆发。
　　<strong>Kata Containers 项目地址：</strong>
　　<a href="https://github.com/kata-containers" target="_blank">https://github.com/kata-containers</a>;