首页 资讯频道 互联频道 智能频道 网络 数据频道 安全频道 服务器频道 存储频道

容器镜像有哪些缺点?容器镜像中那些让人一言难尽的事情

2020-12-18 10:40:53 来源 : 云巅论剑公众号

容器镜像中那些让人一言难尽的事情

现如今容器生态大受欢迎有许多原因,其中一个就是应用部署上的优秀体验,容器镜像的出现是这种体验能够成为现实的一个基础。

简要回顾一下容器镜像,概括为几点:

它提供了一个应用软件运行的完整操作系统包,是不可变基础设施的一部分,其格式如下图1 所示。

镜像中一个重要的概念是layer,引用docker documentation中的介绍,"Each layer is only a set of differences from the layer before it. The layers are stacked on top of each other."

一个容器镜像是由一个或多个layer组成的。

容器镜像是存储在registry中的,诸如 Docker Hub和公有云提供商的registry service。

但今天我们要一起来吐槽一下容器镜像。

1. 首次启动中大型镜像很慢

第一次运行时总是需要等上几分钟,这是因为在正式启动一个容器之前,还需要一些准备工作:

从registry下载镜像,包含了镜像的所有layers,比如上图的镜像"rust:latest"中包含6 layers,

把镜像layers一个接一个地解压到本地filesystem中,

最后用overlayfs 将这些layer组合为一个mount point作为容器的rootfs,

启动容器。

其中,当启动一个庞大的镜像时,最耗时的是第一步中的下载镜像,但因为单一layer是一个整体,对同一个layer无法并行下载,与此同时镜像size很大通常意味着包含的layer size也很大,所以大部分时间都花在了网络传输上。

2. 去重低效

如果大家关注过镜像base layer,比如上图中的CentOS 和 Ubuntu,其中的目录结构是相同的标准操作系统根分区结构,内容也是类似的,那么我们很自然地可以想到,在registry中存储的时候会将他们去重(Deduplication)吗?

对于上图这种情况,registry 现在不会做去重,原因仍是“单一layer是一个整体”,registry 的去重是基于layer的digest id的,即如果两个不同镜像使用了同一个layer,那么在registry上只存一个layer。

3. 对删除和链接的处理

先说删除,当对lower layer中的一个file做unlink时,会在upper layer 发生什么?

现在的逻辑是在upper layer添加一个特殊的white-out empty file来表示被unlink的file,以达到最终视图上的unlink效果。

“你说你一个没点,完事我们还得搭一个是不"

想象一下,如果想删掉一个password file,这个white-out 做法会带来什么后果?

再说hardlink,当对lower layer中的一个file做hardlink时,会在upper layer发生什么?当前采取了一种笨拙的做法,即把lower layer file拷贝一份到upper layer,再添加对应的hardlink。当这个file size 很大时,那么浪费的存储空间就相当可观了。

4. 安全审计不完整

再说一个安全审计上的问题,因为镜像每一个layer都有对应的digest id,在镜像下载之后可以对layer进行校验,但当把镜像layers一个接一个地解压到本地filesystem中之后呢?我们没有办法再去校验了,因为本质上解压后的filesystem目录和镜像的layers是两种不同的形态了,所以运行时的安全审计是缺失的。

成也layer,败也layer

我们回过头来看,上面的问题除了最后的安全审计,其它的原因都可以归结为“以layer为基本单位的镜像格式”。所以,虽然选择layer的设计是为了让不同的应用软件镜像能够共用同一部分基础系统,达到节省存储和节省传输的目的,但是在实践中用户们也逐渐发现了它带来的难以workaround的问题。

关键词:容器镜像

最近更新