转载自 阿里云智能基础软件部-技术博客-The Future of Docker Containers

A video of this talk is available.

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

图来自 containerd官网

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

Crosby最感兴趣的领域之一是改善Docker的状态化能力，在他看来目前相当有限。更好的状态化能力包括对于单个容器的备份（backup）、还原（restore）、克隆（clone）和迁移（migrate）功能。Crosby解释到当前Docker的状态化管理通常依赖于存储（storage volume）而不是容器本身。

“我们现在的理解是镜像（images）是可移植的，但是我们想把容器视为对象可以从一个机器移到另外一个” Crosby说，“我们想让 RW（read/write layer）可以随容器一起移动，而不必依赖存储卷”。Crosby补充说到，不仅是文件系统数据，也包括容器配置，用户级数据和网络信息。

Rethinking container image delivery

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