12月5日，OpenAnolis社区首场线下Cloud Native Infrastructures Meetup在北京举办。来自阿里云、蚂蚁集团，Intel，中国移动，红帽等公司的技术专家围绕内核、容器及虚拟化等云原生基础设施技术展开了探讨，解析相关开源技术内 幕及社区进展，分享企业落地及实践经验。
今天中国移动云能力中心基础软件产品团队分享的主题是“kata containers 2.0性能调优探索与实践”。本议题主要介绍了移动云和kata containers的联系，分享了移动云选用kata containers作为安全容器方案所考量的一些出发点，以及针对kata containers做的一些性能调优探索与优化思路。
一、为什么我们需要kata容器?
背景介绍
当下背景是我们要做移动云serverless架构的函数计算服务产品，不久的未来，要做安全容器服务产品。这两个产品都对容器安全性要求很高，从0开发安全容器技术作为解决方案代价大、周期长、成本高，所以我们希望借助开源的力量，基于现有的开源的安全容器技术来帮助我们移动云的技术产品落地。
安全容器方案技术选型
我们对比了目前较为主流的安全容器方案：
google的gvisor从零设计、实现了一种安全沙盒，使用ptrace或kvm来拦截container中进程的系统调用，实现了一个用户态内核来作为隔离层，安全性很高，但是性能表现一般，并且仅支持有限的系统调用，不具备通用性;
aws的firecracker不是一种云原生的方式，虽然也能和kubernetes对接，但是相对来说比复杂;
kata容器则是基于已有的虚拟化技术，使用轻量化的kvm虚拟机作为安全沙盒运行容器，将虚拟机作为安全隔离层。
kata本身设计为容器的一种runtime，原生兼容OCI和CRI，相比gvisor和firecracker，kata更加地云原生和k8s对接也更方便。Kata目前官方支持4种hypervisor：
Qemu: 成熟的老牌虚拟化软件
Firecracker：awk专为serverless场景打造的轻量级vmm，仅支持有限的虚拟设备
Cloud-hypervisor是intel针对云原生场景设计的hypervisor
ACRN是一种针对边缘端场景开发的hypervisor
目前kata支持的hypervisor可以说是覆盖了各种需求场景，因此我们在调研基于kata来满足我们一些业务场景的需求。
二、Kata安全容器技术方案介绍
架构调研
我们基于kata 2.0版本做了架构调研，2.0版本相比于1.0版本，减少了部分工作组件，降低了额外组件带来的开销，也让架构更加清晰。
kata核心思想用虚拟机作为安全沙箱，主要解决的是一个如何管理虚拟机里面的容器的问题，隔了一层虚拟机，容器管理工作没法直接做了，需要虚拟机里面的代理人kata-agent来做代理完成。
从技术实现上讲，这里主要涉及到3个核心问题需要解决：
虚拟机外的shim进程和虚拟机内的agent进程如何通信?
kata 2.0则使用virtio-vsock来作为虚拟机内外通信的信道，解决了shim和agent的通信问题。
虚拟机外的镜像rootfs如何让虚拟机内的container访问到，以支持容器创建、运行?
agent创建容器根据OCI SPEC，需要一个oci bundle，oci bundle则是由描述容器配置的config.json和容器的rootfs构成，config.json只需要shim通过vsock发送给agent就好。容器所需的rootfs是在host上的，虚拟机里面的容器rootfs怎么访问到呢?kata主要通过两种方式实现：
共享文件系统，将host上目录挂载到虚拟机里面使用。kata支持了virtio-9p、virtio-fs来两种guest与host共享文件系统的实现方式，2.0中默认采用virtio-fs，其性能比virtio-9p优出很多;
透传块设备，将host上基于device mapper实现的镜像rootfs块设备透传进虚拟机中。
虚拟机网络如何与现有容器网络(例如CNI)对接?
目前kata连通veth和tap有两种方式：tcfilter和macvtap
tcfilter是使用tc规则，将veth的ingress和egress分别跟tap的egress和ingress对接，效果就将veth的收发端跟tap的发、收端串联了起来，整体效果相当于一张网卡;
macvtap也是虚拟机网络虚拟化中很成熟的技术，如果采用了macvtap，当veth收到包时，会判断目的mac地址是否匹配，匹配把包直接转给tap设备。
优化思路
针对kata的网络模型的工作原理，我们提供了一些优化思路：
1、可以抛弃veth pair，直接kata vm的tap和cni0网桥桥接;
2、可以基于dpdk来实现，cni0基于dpdk实现为一个高性能vswitch，利用vhost-user通信机制，将虚拟机网卡与dpdk vswitch相接，实现一个从虚拟机网卡到cni0网桥的高性能用户态网络。
这两个方向都是现有的虚拟机网络中比较成熟的方案，重点、难点在于如何重新设计CNI插件。
技术要点总结
关于kata容器实现的技术要点我们可以做一个总结：
VM作为安全沙箱
支持多种虚拟化方案，qemu、firecracker、cloud-hypervisor等
vm中agent负责直接创建、更新、销毁容器
使用vsock作为shim v2进程与agent的通信信道
使用tc规则、macvtap链接veth和tap，来打通CNI和VM网络
通过virtio-9p、virtio-fs将host上镜像挂载到vm中
通过块设备透传，将host上块设备作为容器rootfs
到此，跟大家分享了我们选择kata来作为安全容器方案的选型思考，以及对kata技术细节的一些分析、总结和我们自己的优化思路。
三、展望
Kata Containers为我们带来了虚拟机级别的安全性和隔离性，同时还提供了容器级别的启动速度。kata目前的发展我们认为正走向轻量化之路，kata 2.0中用rust重写了部分组件，带来了更低的开销。同时intel也基于rust-vmm开发了面向云原生场景的轻量化hypervisor，cloud-hypervisor的面向云原生的设计理念与kata完美匹配，kata中也增加了对cloud-hypervisor的支持，未来cloud-hypervisor会成为kata的主力hypervisor。两者搭配，我们认为未来会是面向云原生的安全容器主要解决方案。
