Kata Containers 1.0 问世


【编者的话】Kata Containers整合了intel的Clear Containers和Hyper.sh的runV,能够提供给虚拟化容器一个独立的运行环境。

Kata Containers今天发布了1.0稳定版本,它成功整合了intel的Clear Containers和Hyper.sh的runV技术,能够提供给虚拟化容器一个独立的运行环境,在运行效率与安全级别上与虚拟机相差不大。

开启Kata Containers之旅,传送门:Kata’s GitHub

Kata Containers 弥补了传统容器技术安全性的缺点

Kata Containers填补了传统的虚拟机和基于LCX技术的容器安全性缺陷的空白。传统的容器之前主要是通过底层的LCX技术来实现共享。据我们所知,存在恶意用户通过"逃离"容器来获取使用宿主机内核的权限和共享容器。在多租户工作负载未知的信任级别的环境下,需要付出很多精力来确保系统的安全。

传统的容器技术通过Linux控制组来提供容器之间的隔离,即通过cgroups来管理和分配系统资源与命名空间。进一步的安全隔离是通过放弃Linux的扩展能力,仅使用可读的挂载目录,强制访问控制(MAC)的方式如SElnux和AppArmor *,或是使用SECCOMP删除系统调用等方式。而将这些安全策略应用到这些复杂的应用中是相对困难的。

最终大多数的容器没有遵守容器的规约,使用自己完整的虚拟机来运行,Kata Containers背后的驱动就是在这种环境下保护机器不受安全漏洞的损害。
请输入图片名称
Kata Containers通过使用硬件虚拟化来达到容器隔离的目的。拿Docker来举个例子,kata-runtime从容器级别来提供虚拟机之间的隔离。对于Kubernates来讲,通过Pod级别来达到虚拟机隔离。(除非特殊说明,文章中出现的container都是基于Docker,Pod都是基于Kubernetes来描述。)

对于Kata Containers,每一个container/pod 都是基于一个独立的kernel实例来作为一个轻量级的虚拟机。自从每一个container/pod运行与独立的虚拟机上,他们不再从宿主机内核上获取相应所有的权限。这种措施简化了您需要采取的安全策略,而且能更好的避免容器攻击宿主机内核的可能性。
请输入图片名称
Kata Containers使得容器能够作为CaaS(容器即服务)在任意的裸机上运行。由于容器之间有硬件来作为隔离,它允许互不信任的租户使用同一个集群。假定还有网络安全策略来提供集群内租户之间的网络隔离。

Kata Containers是如何融入容器技术的生态圈的?

容器运行时是通过组件来管理容器的生命周期,一些基本的概念像容器创建、启动、停止和移除容器的工作空间。The Open Container Initiative(OCI)为容器运行时制定了详细的API和容器运行时规范。runC作为OCI运行解决方案的典范,它作为生产与运行时的“容器运行时规范的客户端工具"。 runC同样使用Linux中cgroups和namespaces来提供容器隔离。

Kata Containers runtime作为实现OCI的运行时规范的一份子,它能够兼容实现OCI的其他容器。

另一个容器运行时规范是Kubernetes提供的Container Runtime Interface容器运行接口(CRI),CRI runtimes从更高层进行抽象,我们不应该把它与OCI混为一淆。

与Docker引擎进行交互

对于Docker容器来讲,kata-runtime仅仅是可供选择的实现兼容OCI运行规范之一。

如果你安装了Docker,默认的配置中,Docker引擎将会提供:
  1. 创建默认的容器配置
  2. 将默认的容器配置传递给runC
  3. runC将会基于Docker引擎提供的配置文件和工作量来创建一个容器


如果你安装了kata-runtime,在容器运行时你可以选择Docker基于哪种运行时规范来运行,并提供给用户在单个容器粒度上进行选择。kata-runtime实现runC并提供给Docker更良好的支持(详情请查看 Docker’s runtime documentation)。当使用kata-runtime,每一个Docker容器会运行在自己独立的轻量级虚拟机上。

请输入图片名称

Kata Containers与Kubernates

Kubernetes 1.5版本介绍了CRI(容器运行接口),它能够轻易的支持各种具有OCI实现的容器并具备可拔插功能。在此之前,Kubernetes仅利用默认的Docker镜像仓库并且它基于OCI运行规范的runC。自从“runtime"不断发展,在这篇文章中我们称CRI runtime 为CRI shim并且使用“runtime"去描述OCI兼容运行时规范。

介绍完CRI后,接下来我们介绍其他的CRI shims,包括cri-containerd,CRI-o,dockershim和frakti。其中一些基于OCI的runtime,其他一些是monolithic solution。 从更高层次来看通常实现via CRI的如下图所示。注意:dockershim目前只支持runC,而不支持kata-runtime。

请输入图片名称

Kata Containers提供给CRI shims两个接口去管理基于Kubernetes Pod的硬件虚拟化:
  1. OCI兼容的runtime,kata-runtime。现在可用于CRI,cri-containerd和OCI-O的解决方案。
  2. 提供CRI shims硬件虚拟化runtimeAPI库消费和提供给CRI-native实现。Frakti在这是CRI shim的一个例子。


当定义安全沙箱的工作持续在Kubernates level上进行时,现在已经有些CRI实现支持在单个节点上运行多种运行时环境。举个例子,CRI-O支持可信和不可信的沙箱。基于Pod注释和默认的CRI-O的配置,你可以使用多种混合OCI运行规范的基于命令空间的Pods。这篇文章将带你深入了解CRI-O是如何工作运行的。

请输入图片名称

对于kata-runtime来说,虚拟机隔离提供的是Pod级别的隔离。容器在Kata Containers内部互相隔离运行,并且通过 namespaces和cgroups管理,跟runC做法比较类似。

如何尝试并且使用Kata Containers

Kata Containers目前是一个完全开源的项目,1.0版本现在已经整装待发了。check out Kata Containers on GitHub 并且加入到下面的渠道,你可以了解如何给项目作出贡献。

katacontainers.io

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

Slack:linkinvite

IRC: #kata-dev on Freenode

Mailing list:http://lists.katacontainers.io ... tinfo

原文链接:Say hello to Kata Containers 1.0(翻译:刘明)

0 个评论

要回复文章请先登录注册