安全容器（Kata、Firecracker）与Kubernetes

安全容器（Kata、Firecracker）与Kubernetes

kata 简介

Kata源自希腊文Καταπίστευμα(ka-ta-PI-stev-ma)，原意是值得信任的人，katacontainer正是解容器安全的问题而诞生的。传统的容器是基于namespace和cgroup进行隔离，在带来轻量简洁的同时，也带来了安全的隐患。事实上容器虽然提供一个与系统中的其它进程资源相隔离的执行环境，但是与宿主机系统是共享内核的，一旦容器里的应用逃逸到内核，后果不堪设想，尤其是在多租户的场景下。Kata就是在这样的背景下应运而生，kata很好的权衡了传统虚拟机的隔离性、安全性与容器的简洁、轻量。这一点和firecracker很相似，都是轻量的虚拟机。但是他们的本质的区别在于：kata虽然是基于虚机，但是其表现的却跟容器是一样的，可以像使用容器一样使用kata；而firecracker虽然具备容器的轻量、极简性，但是其依然是虚机，一种比QEMU更轻量的VMM，暂时不能兼容容器生态。

Kata的基本原理是，为每一个容器单独开一个虚机（如果是k8s下作为runtime，则是一个pod对应一个虚机而不是容器），具有独立的内核，这样交付的容器就具备了虚机级别的隔离和安全性。kata的原理图如下所示：

早期的k8s使用docker作为默认的runtime，后来又加入rkt，每加入一种新运行时，k8s都要修改接口来关联新的容器运行时。随着越来越多的容器运行时想加入k8s运行时，而且不同的容器的实现和功能差异很大，比如docker已经再不是一个单纯的容器运行时，这时候亟需一套标准来定义k8s支持的运行时。这套标准就是CRI（Container RunTime Interface）。k8s（甚至k8s用户）不再关心底层的容器运行时，kubelet只感知到CRI server，而CRI server只需遵循CRI标准实现对应的runtime的标准化的接口。

CRI server包括 RuntimeService 和 ImageService 两个服务，均为gRPC server。ImageService负责镜像的管理，比如查询、拉取、删除镜像等；RuntimeService负责四大块：PodSandbox（Pause容器或者一台虚拟机，取决于具体的runtime实现），Container，Streaming API（exec），状态查询接口等。下面分别以k8s create pod和stream API exec来分析CRI工作的流程：

CRI分类

CRI第一个实现就是k8s自己提供的针对Docker运行时的dockerShim，也是目前k8s使用docker的标准方式，已经集成在k8s的源码中。如今CRI的众多实现中除了dockershim外，比较具有代表性的还有有CRI-containerd, CRI-O以及frakti。rkt作为k8s最早支持的运行时之一，现在也开始转向标准的CRI实现rktlet，这是k8s未来使用rkt的标准方式。该项目的目标就是像现在的dockerShim一样，而社区貌似并不活跃。目前主流的几种CRI实现的生产容器的流程图如下所示：

其中dockershim、CRI-containerd、CRI-O属于基于OCI的CRI，dockershim目前不支持kata runtime，其他的两种CRI-containerd、CRI-O均支持runc和kata runtime。frakti是一种特殊的CRI实现，它不依赖于任何runtime，而是可以直接使用kata提供的硬件虚拟化API库来实现CRI的标准接口，即直接开VM然后runv启动pod和容器。frakti虽然相比于其他的CRI实现复杂、接口偏重，但是实现的灵活性更强。

Dockershim

k8s开始支持CRI之后，k8s便不再以之前的方式依赖docker，而是采用标准的CRI的方式来使用docker运行时。Dockershim便是k8s对CRI的一个标准实现，已经集成在了k8s的源码中，这里重点看下k8s中dockershim的实现。

CRI-O

本节重点分析CRI-O的实现。如果说dockerShim只是针对dockerruntime的标准实现，那CRI-O就是真正的兼容OCI标准的实现：CRI-O全名即为CRI-OCI。CRI-O默认会使用runc，但是能够识别k8spod的注解annotations:io.kubernetes.cri-o.TrustedSandbox，用户可以使用这个注解来通过CRI-O选择合适的runtime。比如，对安全级别要求较高，可以将注解的值设置为false，CRI-O就会使用kata-runtime，即每个pod对应一个虚机（这和docker使用kata-runtime稍有区别，docker中默认每个kata container对应一个虚机隔离，而在k8s pod中的一组容器往往是业务上相互协作的应用，他们之间的安全隔离性不需要很高，所以pod内的一组容器和runc的类似，只是在pod层需要达到虚机级别的隔离）。还需要说明的是，CRI-O支持一个节点上同时运行两种不同类型runtime的pod。

Kata + Firecracker

在没有firecracker之前，CRI-O就可以通过k8s注解或者配置文件的方式将默认的runtime替换为kata runtime，进而为容器（pod）开独立的虚机。firecracker本质上是虚拟化技术，和qemu在一个层面，只是它更加轻量、精简。所以很自然的会想到，kata能否直接开出firecracker虚机，在虚机里运行容器？答案是肯定的。

在最新发布的kata1.5中，已经开始支持firecracker。通过k8spod的runtimeClass字段来设定pod内容器的运行时。runtimeClass也是k8s的新增的字段，属于beta版。目前支持的最小粒度为pod，即一个node上可以运行多种runtime的pod，但是每个pod内部的容器的运行时必须相同。因为在一个pod内，容器和虚机的数据共享和网络通信是非常的麻烦，超出了k8s目前的能力。但是抽象到pod层以上，在k8s看来，虚机和pod就没有差异了。

但是，限于firecracker本身功能过于简单，因为其设计之初就是追求最少的设备、最简洁的功能，firecracker目前很多k8s的功能还不支持，比如volume、secret、configmap等。如果应用比较复杂，对运行环境的要求比较高，就只能使用qemu vm。

从firecracker去年开始问世至今，将firecracker融入如今的容器生态一直是AWS和开源社区在致力推进。从最开始初见雏形的containerd+firecracker到如今已经接近成熟的kata+firecracker，未来firecracker在容器生态中将处于什么样的地位，是通过containerd和kata成为qemu一样的runtime选项，还是作为serverless容器底层沙箱的的标准(类似如今AWS的Lambda和Fargat)，现在还不能有定论。但是serverless领域对极简极快的追求和firecracker这种极简的VMM设计是完全契合的。qemu是没有做到最精简，依然有很多不必要的模块。用firecracker替换qemu（或者借鉴firecracker的思路构建自己的面向severless的轻量级容器底层沙箱）是未来可以尝试的方向。

1. Kubernetes + CRI + Kata + Firecracker

https://blog.csdn.net/com_stu_zhang/article/details/104903920

2. AWS Serverless服务和Firecracker技术的介绍

https://yisu.***/zixun/22225.html

3. 深度解析 AWS Firecracker 实战篇 – 一起动手点炮竹

https://aws.amazon.***/cn/blogs/china/in-depth-analysis-of-aws-firecracker/

4. 深度解析 AWS Firecracker 原理篇 – 虚拟化与容器运行时技术

https://aws.amazon.***/cn/blogs/china/deep-analysis-aws-firecracker-principle-virtualization-container-runtime-technology/

5.Kata Containers 1.5 版发布并提供 Firecracker 支持

https://aws.amazon.***/cn/blogs/china/kata-containers-1-5-firecracker-support/