Docker容器

The Future of Docker Containers

本文主要是介绍The Future of Docker Containers,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

转载自 阿里云智能基础软件部-技术博客-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同步之类的东西来共享和分发镜像。

这篇关于The Future of Docker Containers的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!