原文链接:https://lwn.net/Articles/788282/

发布日期:2019-05-15

译者:灵甫

译者注:本文非全文直译,已省略部分关于原作者和docker公司的介绍,只针对技术部分翻译,并附上本人的一些理解,仅供参考。


Docker在2013年开始使用LXC作为其基础技术,但它在过去六年中已经远不止于此,例如由docker主导的libcontainer项目,以及参与OCI标准制定,后者已经成为了容器运行时的实现规范。该规范包括runc容器运行时(container runtime),同时也是开源项目Containerd的核心。Containerd是Cloud Native Computing Foundation(CNCF)的托管项目成员,在项目稳定性和成熟度方面已达到CNCF中的顶级水平。

docker 19.03

在Docker CE 19.03开始将全面支持NVIDIA GPU,这标志着Docker首次以无缝方式集成了GPU支持。 NVIDIA GPU 支持将使容器工作负载能够充分利用这些GPU提供的额外处理能力,这通常在人工智能和机器学习用例中被广泛应用。

Containerd版本也将升级到1.2版本。除了多个bugfix和性能提升,还包括一个集成了gRPC接口的容器运行时,旨在简化容器管理。

the future of docker

Docker容器最初是为了能充分利用Linux内核特性而设计的,而Docker的未来也是要更充分地去利用更新的内核功能。 容器由各种内核功能组成,如cgroups,命名空间,LSM和seccomp,我们必须把所有这些东西结合起来,以创造我们现在所知的容器。

展望容器和Docker的未来,主要是处理近年来出现的不同需求。这些需求之一是利用Linux 5.0及更高版本中的现代内核功能,以及处理不同类型的新应用负载,包括有状态的应用负载(stateful workload)。这需要一定程度的持久化能力,而无状态负载中不需要这种持续性。 用于网络边缘部署的边缘负载是另一个新兴的用例。 物联网(IoT)、小型设备和工业设置中的嵌入式负载也是Docker在2019年的一个重要用例。

Docker将在未来充分利用的Linux内核功能之一是 eBPF ,未来可能用于编写seccomp filter。seccomp和BPF允许在内核中进行灵活的系统调用拦截,这为容器的控制和安全打开了新的大门。

Cgroups v2 是另一个重要的Linux特性。 自Linux 4.5发布以来,cgroups v2一直在内核中,但Docker并没有立即采用它作为支持技术。 该项目并不是唯一一个不立即支持cgroups v2,Red Hat的Fedora也没有集成cgroups v2,尽管它计划发布目前定于11月发布的Fedora 31版本。然而,cgroups v2将为Docker提供更好的资源隔离和管理功能。

增强用户名称空间支持(Enhanced user namespace support) 也在docker发展的roadmap中,主要是为了增强非根权限容器(rootless container)的相关功能。在默认情况下不使用更高权限来运行容器将有助于提高安全性。使用用户命名空间运行 rootless container 的想法并不是一个新概念,但它很快就会成为技术现实。

更多的内核安全支持会不断加入到docker中。 SELinux和AppArmor不再是开发人员想要的唯一Linux安全模块(LSM)。 Docker开发人员正在努力支持的新兴LSM是 Landlock 。用户还可以使用eBPF编写自己的自定义LSM。seccomp BPF的出现也值得关注。

Making containers more stateful

Docker的状态化能力(stateful capabilities)目前相对有限。 更好的状态化能力包括单个容器的备份(backup),还原(restore),克隆(clone)和迁移(migrate)功能。今天Docker中的状态化能力通常依赖于存储(storage volume)而不是实际的容器本身。

我们现在都知道容器镜像是可移植的(在多个地方使用),但是容器是否也可以作为一个可移植对象从一台机器挪到另一台机器呢。我们希望创作一个可随容器移动的读写层,而不再需要依赖存储。不仅是容器的文件系统数据,还需要在容器配置之间建立联系,包括用户态数据和网络信息。

Rethinking container image delivery

现在的容器镜像主要通过container registry 进行分发,例如用于公共访问的Docker Hub,或内部registry。Docker镜像是用registry中的名称来进行标识的。每个容器镜像下载时都有对应digest,包含了镜像里所有内容(json文件和每一层的内容)的hash。 Docker现在正在考虑的是一种方法,即通过跨节点的某种形式的点对点(P2P)传输方法来访问和共享容器镜像,而不是依靠集中式registry来分发镜像。即使如此,仍然需要一个集中式的registry来处理镜像的命名,不过内容地址blobs可以从一台机器转移到另一台机器,而无需直接与registry交互。 在用于镜像传递的P2P模型中,registry可以将容器图像发送到一个节点,然后用户可以使用诸如BitTorrent同步之类的东西来共享和分发镜像。


译者简评

虽然集团容器技术上已经与docker渐行渐远,新的pouch container 主要围绕containerd进行定制和功能增强。但是docker在社区的影响力还是不小的,其发展策略值得参考。文中提到几点:

  • 全面支持GPU,可以在容器中无缝使用gpu driver。目前支持gpu runtime的container runtime除了docker还有cri-o。
  • eBPF与cgroups v2。作为容器安全和资源隔离技术方面的改进,如果是在安全容器场景下,可能需求不大,毕竟已经有一层VMM作隔离了。但是在将来,安全容器与普通容器混部似乎无法避免,这种改变可能也会影响到整个宿主机的部署环境,我们可以提前关注一下。
  • 容器状态化能力。这种场景可能更多发生在容器热迁移,或者底层组件热升级上。由于OCI标准中只定义了容器管理的一套接口,但其中并没有包含像 save/restore 这种接口的实现。以containerd为例,可以认为容器的状态只有在RuntimeClass 执行的时候才会被短暂load到内存中,其他时候都是被保存到disk上的。从v1接口升级到v2接口后,虽然底层container runtime被整合到containerd-shim里了,但是依然延续了这个设计。
  • 镜像分发P2P。这个我们内部早有实现,就是Dragonfly(蜻蜓),并且已经进入CNCF,这里不再展开。

Reference

[1] https://www.kernel.org/doc/Documentation/cgroup-v2.txt

[2] https://devblogs.nvidia.com/gpu-containers-runtime/