认识kata-containers
1、kata-containers是什么
2、在容器生态系统中的位置
3、包含的组件及其功能介绍
4、现状以及后续的计划
5、在Docker中的使用
本文主要让大家认识什么是kata-containers，它在容器生态系统中的位置，如何跟现有容 器系统进行集成。最后介绍如何在Docker中使用kata-containers。
1、kata-containers是什么
kata containers是由OpenStack基金会管理，但独立于OpenStack项目之外的容器项目。它是一个可 以使用容器镜像以超轻量级虚机的形式创建容器的运行时工具。 kata containers整合了Intel的 Clear Containers 和 Hyper.sh 的 runV，能够支持不同平台的硬件 （x86-64，arm等），并符合OCI(Open Container Initiative)规范，同时还可以兼容k8s的 CRI（Container Runtime Interface）接口规范。目前项目包含几个配套组件，即Runtime，Agent， Proxy，Shim，Kernel等。目前Kata Containers的运行时还没有整合，即Clear containers 和 runV 还在独立的组织内。
如果大家了解Docker技术，就会知道，真正启动Docker容器的命令工具是RunC，它是OCI运行时规范 (runtime-spec)的默认实现。
Kata containers其实跟RunC类似，也是一个符合OCI运行时规范的一种 实现（即Clear Container和runV 都符合OCI规范），不同之处是，它给每个容器（在Docker容器的 角度）或每个Pod（k8s的角度）增加了一个独立的linux内核（不共享宿主机的内核），使容器有更好 的隔离性，安全性。
关于OCI的相关介绍，可以参见开发者社区中的另一篇文章：OCI的前世今生 基于kata containers创建的容器兼具虚机和容器的优点，在隔离性上，跟常规虚机类似，但在部署时 间和运行效率上却与常规容器相近。
2、在容器生态系统中的位置
根据上面的内容，可能很多人还是不清楚Kata Containers到底是用在哪里的。接下来看一下Kata containers在容器生态系统中的位置。
首先我觉得有必要介绍一下，什么是容器的运行时，很多情况下，大家都把docker或者rkt作为容器的 运行时，而在OCI中，将runC称作运行时。
因此，大家都很困惑到底什么是容器运行时。
容器运行时是一个相对的概念，比如，从k8s的角度看，直接创建容器的组件是docker或containerd， 因此，将docker、containerd以及新加入的CRI-O作为容器运行时组件。
而在docker、containerd或 CRI-O的角度看，真正启动容器的组件是runC，因此，docker中将runC作为容器运行时工具，当然在 docker中，runC可以被替换，比如可以替换为本文介绍的kata containers（即clear Container或者 runV）。
接下来，通过几个结构图来说明下，kata containers在docker以及k8s中的位置。 首先看一下docker目前的组件关系图：
我们看到runC处于docker组件图的最底端，runC下面就是容器。目前docker已经不是一个专一的容器 管理组件，而真正的容器管理组件是containerd，而containerd本身也不会直接跟操作系统交互，去 创建、删除容器，而是借助runC来对容器生命周期进行管理。因此这里可以讲runC作为容器运行时。
容器圈中，针对容器运行时指定了OCI规范，因此，实际上Docker的架构已经变成如下结构：
如红色虚线框内所示，也就是说，只要符合OCI规范的运行时工具，都可以被docker（或者说是 containerd）使用。 了解上面的内容，我想kata containers在容器的什么位置，应该就显而易见了。它符合OCI运行时规 范，因此，可以作为runC的替代组件。 下面是k8s组件的结构图：
注： CC 表示 clear containers ， CC 和 runV 有一个虚线框圈起来，表示后续这两个 组件会合并成 kata containers ，目前可以分别使用。 上图中给出了k8s分别将docker、containerd和CRI-O作为容器管理工具（以k8s角度的容器运行时） 的组件关系图。k8s为了能对接多种容器管理工具，抽象了CRI接口，每个容器管理工具只需实现接口
即可，详细内容参见《我们还需要docker吗？》。 每个容器管理工具的最后端直接操作容器的就是上一节介绍的符合OCI的容器运行时（以docker等的角 度看），那kata containers就是符合OCI容器运行时的其中之一。 根据以上分析，我们可以看出，kata containers其实不会替换docker，也不会替换containerd，更不 会替换k8s，而跟他们是协作关系，只是其中的一个组件。
3、包含的组件及其功能介绍
runtime：符合OCI规范的容器运行时命令工具，主要用来创建轻量级虚机，并通过agent控制虚 拟机内容器的生命周期。目前kata containers还没有一个统一的运行时工具，用户可以选择 clear containers和runV中的其中之一。
agent：运行在虚机中的一个运行时代理组件，主要用来执行runtime传给他的指令，在虚机内 管理容器的生命周期。
shim：以对接docker为例，这里的shim相当于是containerd-shim的一个适配，用来处理容器 进程的stdio和signals。shim可以将containerd-shim发来的数据流（如stdin）传给proxy，然 后转交给agent，也可以将agent经由proxy发过来的数据流（stdout/stderr）传给containerdshim，同时也可以传输signal。
这里的shim跟上一节k8s结构图中的shim不是一个组件，上节提到的shim表示 containerd-shim proxy：主要用来为runtime和shim分配访问agent的控制通道，以及路由shim实例和agent之 间的I/O数据流。
kernel：kernel其实比较好理解，就是提供一个轻量化虚机的linux内核，根据不同的需要，提供 几个内核选择，最小的内核仅有4M多。 下图是kata containers官方给出的各组件之间的关系。详细原理还有待进一步研究
4、现状以及后续的计划
kata containers项目刚起步，还没有完整的一套组件供用户使用，只是提出了一套完整的架构。 但是从架构中看，跟clear containers目前采用的架构基本一致，包括架构图以及组件类型。因此，目 前针对kata containers的研究，可以通过clear containers入手。
目前，kata containers项目中，已经增加了包括agent，shim，proxy等组件的代码库，但是还没有针 对runtime的代码库。
在后续的计划中，kata containers将分为三步来实现clear containers和runV两个项目的融合：
首先，在katacontainer中兼容clear containers 和 runV两个运行时 整体采用kata containers的架构 clear containers 和 runV两个运行时可以无缝对接kata containers的其他组件 用户可以在两个运行时之间来回切换
其次，将clear containers 和 runV合并为一个，形成kata containers自己的runtime 最后，废除clear containers 和 runV的兼容。
5、在Docker中的使用
下面以clear containers 3.0为例，介绍在docker 中的使用。
首先，环境中需要安装docker，本机安装的docker版本是V17.06.0-ce，docker的安装就不在这里介
绍了。另外本机使用ubuntu16.04系统，官方要求ubuntu的系统需要是16.04或更新的版本。
安装clear containers的组件，命令如下：
配置docker 的默认容器运行时为clear containers：
重启docker服务并启动clear containers的systemd服务
$ sudo systemctl daemon-reload
$ sudo systemctl enable docker.service
$ sudo systemctl restart docker
$ sudo systemctl enable cc-proxy.socket
$ sudo systemctl start cc-proxy.socket
接下来就可以创建容器了，使用以下命令来创建busybox容器：
查看容器列表：
执行下面的命令，查看容器相关的进程树：
我们会看到下图所示的内容：
进程树中，dockerd为根进程，红色方框标出来的与传统容器有区别的地方，我们可以看到，dockerd 中增加的cc-runtime的运行时工具，并将cc-runtime设置为默认运行时，并有qemu-lite-systemx86_64、cc-proxy、cc-shim等进程。其中qemu-lite-system-x86_64(绿色框内的进程)就是通过 clear container创建的轻量化虚机，其内部部署了busybox容器。 同样可以通过docker exec访问容器：
