（本文选自《Kata Containers在百度智能云的应用实践》白皮书）
之前的《容器化实践指南》专栏中，我们介绍过很多百度智能云在容器实践方面的积累。本文继续，讲一讲最近才进入大众视野的Kata Containers。
今年4月，Kata Containers被OpenStack基金会董事会正式宣布为OpenStack基金会的顶级开源基础设施项目。
事实上，Kata Containers早就出现了，百度智能云也较早就开始运用了。简单而言，Kata Containers就是比传统容器更安全的容器技术，其通过为容器提供虚拟机级别的安全机制，从而同时拥有容器的形态和虚拟机的安全性。 本篇就Kata Containers是什么，有什么价值等进行全面梳理。
初识Kata Containers
早在2015年，来自英特尔?开源技术中心的工程师就开始探索采用英特尔? 虚拟技术(英特尔? Virtualization Technology，英特尔? VT)来提高容器的安全隔离性，并以此发起了英特尔? Clear 铜镜吟Containers开源项目。
与此同时，来自Hyper.sh（一家中国的高科技初创公司）的工程师也发起了runV开源项目，这两个项目采用的技术和目的都非常相似，都是为了将容器置于一个安全“沙箱”，以便进一步促进该技术发展和成熟。随后在2017年，英特尔?和Hyper.sh团队将这两个开源项目在社区合并成了一个新的项目Kata Containers。
传统虚拟机(VMs)可提供硬件隔离，而容器可快速响应，且占用空间相对较小，Kata Containers将这两者的优势完美结合了起来。每个container或container pod都在自己单独的虚拟机中启动，并不再能够访问主机内核，杜绝了恶意代码侵入其它相临容器的可能。
由于Kata Containers同时具备硬件隔离，也使得互不信任的租户，甚至于生产应用或前生产应用都能够在同一集群内安全运行，从而使得在裸机上运行容器即服务（Containers as a Service, CaaS）成为可能。
（Kata Containers原理）
提高性能的同时保证安全性是难题
百度智能云容器引擎发展至今，可以说经历多多，包括复杂业务、大流量、复杂部署等诸多方面的技术考验和淬炼。例如：
单集群峰值每日网页访问量达10亿+，
单租户容器规模50000+等。
在不断地学习过程中，练就了以Kubernetes为中心的容器技术方向的强大掌控力。
不过现实困难也是存在的，比如基于容器技术实现资源共享在带来业务弹性和资源高利用率的同时，也会增加业务的安全风险几率。此类风险在于同一主机上的多个容器需共享同一个主机内核，而同一宿主机上可能运行不同租户的容器，这就可能会威胁到整个云基础架构和租户业务及数据的安全。
因此，如何在充分发挥容器轻量化和敏捷性的同时，提高其容器隔离性来保障资源共享的安全，就成为百度智能云必须探索的重要课题。
（传统容器架构）
Kata Containers，更好的选择
于是，百度智能云在ClearContainers，也就是现在的Kata Containers发布之后，就开始关注这一安全容器技术，并和相关技术社区进行了多次交流，来调研和测试这一技术。基于广泛的安全容器技术调研，发现Kata Containers是目前具备高度安全和实践性的一项安全容器技术，主要考量因素如下：
Kata Containers是目前高度安全的容器技术。它使用轻量级虚拟机作为容器的安全隔离，而过去十几年的实践证实，虚拟化技术采用的安全模式，是人们共享资源的有效手段。
和传统容器相比，Kata Containers 的性能较高，且更有保障，同时又兼容传统安全技术。
Kata Containers遵循OCI容器实现规范，可以无缝对接容器编排方案，比如Kubernetes等。 Kata Containers 有着较高的成熟度。自从2015年成功推出的两个安全容器项目——英特尔? Clear Containers和Hyper runV——合并以来，相关技术有了重大进展，其功能性和开发基础设施也得到了验证。 Kata Containers获得业界的广泛支持，具备完善活跃的开源社区。基于此，百度智能云开始大规模应用Kata Containers。
截至当前，百度智能云已经将KataContainers应用在多种实践场景，包括基于Kata Containers的函数计算，Kata Containers与OpenStack的融合，Kata Containers在边缘计算的应用等。
不仅仅是用，还在创新
在Kata Containers的应用过程中，百度智能云不只扮演的是用户的角色，还是一个创新者。
以函数计算为例，由于Kata Containers采用虚拟机作为隔离，导致容器的启动速度难以满足函数计算场景的要求。为解决这一问题，百度智能云开发出了许多高效的解决方案。 举个例子，函数冷启动与热启动性能。
函数的冷启动，如图所示，是指函数首次被调用时，必须先准备用于运行的容器，再把用户函数部署上去，然后启动语言runtime。
（非预创建容器流程）
冷启动性能根据用户代码体积会有不同程度的浮动。如果不考虑VPC的切换时间，启动时间需要控制在百毫秒量级。
那么为何冷启动性能这么重要呢？
原因在于上层业务代码的访问超时值是统一设置的，不会为了某次CFC函数调用是冷启动还是热启动而去做动态调整。假如业务的超时设置较小，冷启动的长耗时很容易导致业务有损。根据测试，单纯Kata Containers的启动时间就已经在1s 左右，如果再加上网络CNI的初始化，启动时间会更长，难以满足函数计算的需求。 目前，百度智能云给出的解决方案是通过预先创建Pod池来实现快速响应。
在需要运行用户函数时，从Pod池中获取一个Pod。在该Pod中动态添加业务容器，来执行计算任务。通过这种办法，节省掉了虚机启动时间和网络CNI插件初始化时间，进而大幅度缩短整体冷启动的响应时间。下表比较了不同模式下业务冷启动时间。
可以看到，函数计算在利用kata container提供更好安全隔离性的同时，仍将冷启动时间压缩到了与runc相当的数量级上。
业务启动时间优化对比
（在runc模式下，动态初始化仅包含挂载卷，在kata模式下，动态初始化包含动态创建业务容器并运行等操作）
这样的示例还有很多，比如调度层启动加速、支持动态挂载用户代码等。这些无疑将为后来的使用者提供宝贵的借鉴意义。
正因为有以上创新和在BCI产品体系中的落地，在前不久召开的开源基础设施峰会中，百度智能云团队荣获2019开3D预测专家彩酷酷caikuku源基础设施峰会唯一超级用户大奖。
此奖项代表着百度智能云Kata Containers获得业内顶级专家的认可，并在实践中逐步走向成熟，成为该领域技术创新的先驱者。
效果显著
使用Kata Containers带来的收效是明显的。无论是函数计算还是边缘计算，抑或是其它场景，基于Kata Containers技术都带来了极大的提升。
以百度智能云函数计算CFC为例，百度智能云CFC可以通过一个弹性资源池为众多开发者提供共享的计算资源。在采用Kata Containers的虚拟机隔离模式之后，既保障了容器在多租户环境中的安全隔离，同时也实现了对应用和用户的不可见。
同样，百度智能云容器实例BCI为百度内部的大数据业务提供了强大的基础架构支撑，帮助大数据部门构建起面向多租户的Serverless数据处理平台。 对于大数据部门的平台研发人员，BCI通过与Kubernetes的集成，满足平台研发者使用成熟的Spark社区技术的诉求，而无需额外的学习成本，且不需要关注资源的管理和运维。
对于使用平台的大数据开发者，基于BCI的大数据任务处理平台提供了更加便捷的Spark使用模式，开发者只需要打包数据处理任务，提交至平台，即可等待任务自动运行并获取结果，完全无需关心资源的调度过程，并且不需要自行维护任何Spark基础架构。
在这种多租户的大数据平台场景中，Spark服务的提供方希望尽可能提升资源利用率，同时提供满足用户大规模提交计算任务时的算力。 然而，传统的Kubernetes集群模式很难具备足够弹性，满足这一需求。因此，无需维护服务器，且能在数秒内快速启动的容器实例就成为了平台方的首选方案。
通过使用BCI平台方的任务编排服务可以运行在自己的Kubernetes集群中，而用户提交的任务则通过Virtual-Kubelet，调度用户账号中的BCI资源来运行，一方面平台方的使杀人虎头铡 用模式和传统kubernetes没有差异，另一方面平台方无需为用户任务提前准备资源，这无疑提升了资源利用率。
而Kata Containers则基于底层技术，让用户作业可以运行在隔离的系统内核和隔离的网络空间中，从而为任务执行和数据提供了更高的安全性。 目前，基于Spark的百度流式计算服务BSC已经集成BCI的Serverless容器能力，可以将原本搭建Kubernetes集群的资源成本降低40%~60%，同时还可以获得大量宝贵的平台搭建实践经验。 总结全文，Kata Containers作为一种安全容器解决方案，在百度智能云的容器服务中扮演重要角色。
未来，百度智能云还将继续深化对Kata Containers的使用，为用户提供更优质的容器服务，为推进数字化转型进程添砖加瓦。
