为什么 Kata 容器不会取代kubernets：关于 Kata 容器的自述

Kata 容器项目于2017年12月开始启动，用于构建与容器生态系统无缝对接的轻量级虚拟机。Kata容器结合了来自Intel Clear Containers 和Hyper runV 的技术，使得容器拥有虚拟机般的安全性。

Kata 容器解决了传统容器的安全缺陷

Kata 容器缩短了与传统VM的安全性和传统Linux容器的轻量级优点之间的差距。传统的容器们共享同一个底层linux内核。已知的漏洞允许恶意用户“逃离”容器并访问内核和共享的容器。尤其在多租户环境中，针对这种情况需要做出大量努力才能保障系统安全。

传统的容器使用 Linux control groups,又称cgroups，用来管理和分配资源与namespaces，以提供容器间的隔离。更进一步的安全隔离是通过弃用linux功能，使用read-only挂载方式，强制访问控制（MAC）策略有如像SELinux和 AppArmor*，

放弃系统调用转而使用SECCOMP。这是很困难的，如果有可能的话，应该将这些安全策略应用到更加复杂的应用中去。

注：Seccomp(secure computing)是Linux kernel （自从2.6.23版本之后）所支持的一种简洁的sandboxing机制

如你所见，大多数情况下，容器们都是在同一个VM中，这使得容器的性能无法得到保障。保障这些环境中的安全是Kata容器项目背后的驱动因素之一

Kata 通过使用硬件虚拟化来提供容器间隔离。就Docker*而言，kata-runtime在容器级别提供VM隔离；像Kubernetes，是在pod级别提供VM隔离；在后面的内容中，当我们提到container/pod时，意思是: container指docker，pod指kubernetes

对于Kata 容器而言，每个container/pod都是作为一个轻量级VM启动的，有自己独有的内核。由于每个container/pod现在都使用自己的VM运行，因此它们不能够访问主机内核，并且能够获得VM的所有安全方面的优势。这简化了为保护主机内核和容器漏洞所做的安全策略。

Kata 容器还使得container-as-a-service (CaaS)能在裸金属上运行容器。由于容器之间的硬件隔离，Kata容器允许互不信息的用户使用相同的集群，前提是有网络安全策略来提供群集内租户之间的网络隔离。

Kata 容器如何与容器生态系统相适应

container中的runtime是处理容器生命周期的组件，它实现了诸如创建、启动、停止、和删除容器等workload。在Open Container Initiative (OCI)中，有一个runtime的规范，详细说明了面向OCI-compatible runtime的API。

runC是OCI runtime的标准解决方案，它被描述为“根据OCI规范来生成和运行容器的CLI工具”。runC使用linux cgroups和namesapces来提供隔离。

Kata 容器是OCI的成员，而Kata 容器的runtime (Kata -runtime)将与OCI兼容

在Kubernetes中，runtime称之为Container Runtime Interface (CRI)，它处于一个更高的抽象级别，不应该与OCI-compatible runtime混淆

与docker引擎交互

对于Docker来说，kata-runtime是另一个可以使用的OCI-compatible runtime选项

在默认配置中，如果你安装并运行Docker，那Docker引擎会：

1. 创建一个容器配置

2. 将此配置传递给runC

3. runC将根据Docker引擎提供的配置和workload创建一个容器

如果你安装了Kata Container’s runtime, 即kata-runtime，您可以给Docker配置两个container runtimes，让用户可以在每个容器的粒度上选择使用哪一个；kata-runtime补充了runC并增强了Docker提供的解决方案。

有关更多细节，请参见Docker runtime文档

https://docs.docker.com/engine/reference/commandline/dockerd/#docker-runtime-execution-options

在使用kata-runtime时，每个Docker容器将在它自己的轻量级VM中运行

Kata 容器与Kubernetes

Kubernetes 1.5引入了CRI (Container Runtime Interface)，使得各种容器runtimes很容易接入。在此之前，Kubernetes只使用默认的Docker映像库和它的默认OCI-compatible runtime ：runC。由于runtime经常使用，在接下来讨论中，我们管CRI runtime称之为：CRI shim，runtime描述为 OCI-compatible runtime

自引进CRI后，一些CRI shims被引进，像cri-containerd, CRI-o, dockershim, and frakti。其中一些是调用OCI-based runtime，另外一些则是整体的解决方案。下图展示了通过CRI实现解决方案的高级概览。请注意，dockershim目前只支持runC，不支持kata-runtim。

Kata 容器为CRI shims提供了两个接口，以管理基于Kubernetes pod的硬件虚拟化：

1. OCI-compatible runtime, 即kata-runtime。这是当前可用的CRI解决方案：cri-containerd 和 CRI-O。

2. 一个硬件虚拟化runtime API库供CRI shims使用， 并提供了一些CRI-native implementations，Frakti就是一个样例。

虽然安全沙箱的概念仍在工作在Kubernetes级别，但一些CRI implementations已经支持在单个节点上运行多个runtimes。例如，CRI-O支持受信任和不信任的沙箱。基于pod注解和默认的CRI-O配置，您可以混合运行VM和namespace-based pods。

下面这篇文章深入探讨了在今天如何使用CRI-O实现这一点。

https://medium.com/cri-o/intel-clear-containers-and-cri-o-70824fb51811

VM隔离是在pod级别为kata-runtime提供的。在Kata容器内运行的容器通过命名空间和cgroups进行隔离和管理，类似于runC所做的工作。

你可以试试Kata 容器

Kata 容器1.0尚未发布，参与者正忙于完成kata-runtime特性；但是您可以使用runV或Clear Containers runtimes尝试预览Kata容器。

看看这个开发者指南：

https://github.com/kata-containers/documentation/wiki/Developer-Guide

Kata 容器是一个完全开源的项目——期待你的加入：Kata Containers on GitHub

katacontainers.io

GitHub：https://github.com/kata-containers

Slack: link: https://katacontainers.slack.com ; invite: http://bit.ly/KataSlack

IRC: #kata-dev on Freenode

Mailing list: http://lists.katacontainers.io/cgi-bin/mailman/listinfo

https://katacontainers.io/posts/why-kata-containers-doesnt-replace-kubernetes/

译者介绍：

刘福，目前就职北京海云捷迅，呆萌运维一枚