为什么 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/

译者介绍:

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

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180323A1T9SM00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励