rkt 0.8发布，CoreOS与Intel合作改善容器隔离性

因不满于Docker的发展路线，CoreOS在2014年12年开始了自己的容器计划。rkt便是该计划中开放应用容器规范（Application Container Specification，AppC）中的一个具体实现。经过8个月的发展，CoreOS近日公布了rkt的0.8.0版本，利用Intel的 Clear Container项目，进一步加强了容器的安全性。接下来，本文就分析该版本有哪些新的功能和特性。

作为Docker的企业级用户，CoreOS起初与Dokcer一直保持了良好的合作关系，伴随着其从最初的0.1版本一直走到了正式发布的1.0版本。然而，随着Docker的一步步壮大，其臃肿而受单方面控制的容器规范，是作为虚拟机厂商的CoreOS所无法忍受的。于是，CoreOS在去年底公布了自己的容器计划，并在之后开始制定新的开放而中立的应用容器规范——AppC。Rkt就是作为此规范中的一个具体实现而不断发展的。在半年左右的时间中，CoreOS共发布了18个版本的rkt。近日，CoreOS公布了rkt的0.8.0版本，增加了对用户命名空间的支持和利用Intel公司的硬件虚拟化实现了强加的容器隔离等特性。此外，该版本还在宿主机日志集成、容器socket激活、镜像缓冲和运行速度等方面进行了改进。

首先，利用硬件虚拟化实现加强型的容器隔离方面。rkt采用了分段式架构（staged architecture），使得不同阶段可以采用不同的组件。例如，架构中的第二阶段（stage1）负责创建和启动容器。默认情况下，系统会启动基于cgroups和命名空间的rkt。然而，这种方式并不能很好的实现容器中应用程序的隔离。在该版本中，rkt添加了新的stage1选项。这一特性主要得益于Intel公司一直进行的Clear Container计划。该计划努力利用嵌入硬件的虚拟化技术特性来更好的保证容器运行时的安全和应用程序间的隔离。在5月份，Intel公开宣布实现了利用新的stage1的rkt中的应用可以与运行在同样物理硬件中的主机内核完全隔离的功能。之后，CoreOS团队与Intel的工程师紧密合作，终于在新版本中实现了该功能。之前，用户利用systemd-run启动容器后，再利用systemctl命令查看运行状态可发现：pod中的进程层次包含了一个systemd实例和etcd进程。在新版本中，用户通过添加--stage1-
image参数启动包含基于kvm的stage1的容器后，可以发现：此时的进程层次到lkvm即结束。这就意味着，包括systemd进程和etcd进程在内的整个pod都是在一个KVM进程中执行的。对于宿主系统而言，这个进程就像一个单独的虚拟机进程。这样，容器的隔离性和安全性就可以得到很大提高。

此外，新版本的rkt自动与宿主机的日志集成在一起，提供了systemd的原生日志管理功能。用户只需要在主机的journalctl命令中添加一个像-M rkt-$UUID这样的机器符，即可探索rkt pod的日志。而且，该版本添加了对用户命名空间的支持来改善容器的隔离。用户通过添加--private-users和--no-overlay两个参数，即可打开用户命名空间。其中，前者负责打开用户命名空间特性，而后者负责关闭与用户命名空间不兼容的rkt的olverlayfs的子系统。通过使用用户命名空间，应用程序可以在容器内以根用户的身份运行，在容器外映射为一个非根用户。通过把容器与宿主机上的根用户隔离，该举措添加了一个额外的安全层。目前，该特性还处于实验阶段。未来，CoreOS团队会对其进行进一步的完善。

从以上分析可以看出，rkt v0.8.0在安全方面进行了进一步的加强。CoreOS团队也表示，rkt目前还只是AppC的实现。未来，他们将努力将其变为开放容器计划（Open Container Initiative，OCI）的实现。

感谢郭蕾对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至[email protected]。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号：InfoQChina）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入InfoQ读者交流群）。