大家好，我是小白。下面由我给白白们讲解一下Kata Container…
一、Kata Container背景
我们知道，容器的本质是宿主机上的进程，通过namespace实现资源隔离，通过cgroups实现资源限制，通过写时复制机制实现高效的文件操作。所以，容器和宿主机使用的是同一操作系统内核,如果公有云用户使用容器过程中探测到内核安全漏洞，后果可想而知。那么问题来了，如何提高容器的安全性？答案就是kata Container！
Kata Container的设计思路:
- 如今最安全的莫过于VM虚拟机，只要能做到「secure of VM」，那这个安全性就可以满足公有云的需求了
- 操作系统本身的容器机制没法解决安全性问题，需要一个隔离层，
借鉴虚拟机的实现方式吧 - 虚拟机中如果有个内核，就可以支持我们刚才所提到的 OCI 的定义，也就是说提供了 Linux ABI 的运行环境，在这个运行环境中跑一个 Linux 应用不太难实现。
二、Kata Container架构
目前kata 已经发展到v2版本，对架构做了很大改进，下面内容均以v2版本说明
上面图片就是kata container的架构图, 由图中我们可以看出, kata 其实和runc是平级的，不同的是runc直接启动容器，而kata启动的是 hypervisor，当hypervisor启动VM之后，agent也启动好了，再grpc通知agent启动容器。
具体的过程是这样的：
当 containerd 拿到一个请求的时候，它会首先创建一个 shim-v2。这个 shim-v2 就是一个 PodSandbox 的代表，也就是那个 VMM 的代表；
每一个 Pod 都会有一个 shim-v2 来为 containerd/CRI-O 来执行各种各样的操作。shim-v2 会为这个 Pod 启动一个hypervisor虚拟机，在每个hypervisor虚拟机里面分别运行着一个 linux os kernel。比如这里面用的是 qemu 的话，这里使用的是qemu-lite, 一个社区高效精简过的qemu。同时这个里面也没有额外的 Guest 操作系统，不会跑一个完整的像 CentOS, Ubuntu 这样的操作系统；
后我们会把这个容器的 spec 以及这个容器本身打包的存储，包括 rootfs 和文件系统，交给这个 PodSandbox。这个 PodSandbox 会在虚机中由 kata-agent 把容器启动起来；
依照 CRI 语义和 OCI 规范，在一个 Pod 里面是可以启动多个相关联的容器的。它们会被放到同一个虚拟机里面，并且可以根据需求共享某些 namespace；
除了这些之外，其它的一些外置的存储和卷也可以通过热插拔的方式来插到这个 PodSandbox 里面来；
对于网络来说，目前使用 tcfilter 就可以无缝地接入几乎所有的 Kubernetes 的 CNI 插件。而且我们还提供了一个 enlightened 的模式，这样的话会有一个特制的 CNI 插件来提高容器的网络能力。
这里可能会有些疑问：
- hypervisor 的选择 qemu / cloud-hypervisor / firecraker ， 速度会如何？
- 为什么会有个agent？