码迷,mamicode.com
首页 > 其他好文 > 详细

docker 镜像管理之 overlay2 最佳实践

时间:2021-05-24 02:04:43      阅读:0      评论:0      收藏:0      [点我收藏+]

标签:www   roc   sts   k8s   ram   white   因此   repos   docker 容器   

1. Docker 镜像

Docker 镜像是个只读的容器模板,它组成了 Docker 容器的静态文件系统运行环境 rootfs,是启动 Docker 容器的基础。

Docker 镜像是容器的静态视角,容器是镜像的运行状态。那么,怎么构建 Docker 镜像呢?这就要涉及到 Liunx 的联合文件系统(union filesystem)了。

1.1 联合文件系统

联合文件系统是实现联合挂载技术的文件系统。联合挂载技术可以实现在一个挂载点同时挂载多个文件系统,将挂载点的原目录与被挂载内容进行整合,使得最终可见的文件系统包含整合之后的各层文件和目录。

以 aufs(advanced multi layered unification filesystem) 联合文件系统举例。首先,创建 aufs 联合文件系统如下:

root@vcu-robot-pc-ipv4-bak:~/hxia/docker# ls -R
.:
beautifulGirl  handsomeBoy  mnt

./beautifulGirl:
chunqiu_girlfriend  root

./beautifulGirl/root:
baby

./handsomeBoy:
chunqiu  root

./handsomeBoy/root:
baby

./mnt:
root@vcu-robot-pc-ipv4-bak:~/hxia/docker# mount -t aufs -o dirs=./beautifulGirl/:./handsomeBoy/ none ./mnt
root@vcu-robot-pc-ipv4-bak:~/hxia/docker# df -hT | grep aufs
none                                                   aufs      150G  143G  840M 100% /root/hxia/docker/mnt
root@vcu-robot-pc-ipv4-bak:~/hxia/docker# ls -R ./mnt/
./mnt/:
chunqiu  chunqiu_girlfriend  root

./mnt/root:
baby

可以看到,目录 beautifulGirl 和 handsomeBoy 的内容被联合挂载到 mnt 目录下,修改 mnt 目录下的文件:

root@vcu-robot-pc-ipv4-bak:~/hxia/docker/mnt# echo ‘who?‘ > chunqiu_girlfriend
root@vcu-robot-pc-ipv4-bak:~/hxia/docker/mnt# echo ‘chunqiu‘ > chunqiu
root@vcu-robot-pc-ipv4-bak:~/hxia/docker/mnt# echo ‘who?‘ > root/baby

root@vcu-robot-pc-ipv4-bak:~/hxia/docker# ls -R ./beautifulGirl/ handsomeBoy/
./beautifulGirl/:
chunqiu  chunqiu_girlfriend  root

./beautifulGirl/root:
baby

handsomeBoy/:
chunqiu  root

handsomeBoy/root:
baby

root@vcu-robot-pc-ipv4-bak:~/hxia/docker# cat beautifulGirl/chunqiu beautifulGirl/chunqiu_girlfriend
chunqiu
who?
root@vcu-robot-pc-ipv4-bak:~/hxia/docker# cat handsomeBoy/chunqiu

root@vcu-robot-pc-ipv4-bak:~/hxia/docker# cat beautifulGirl/root/baby
who?
root@vcu-robot-pc-ipv4-bak:~/hxia/docker# cat handsomeBoy/root/baby

看起来很奇怪,修改 mnt 下 chunqiu 的内容会将改动写到 beautifulGirl 目录下,而修改 root 目录下的 baby 修改只显示在 beautifulGirl 目录下。这是因为 mount aufs 命令未指定目录的权限,默认第一个出现的目录是可读写目录,而后面出现的目录是只读目录。所以,写入文件实际上都是写到可读写目录 beautifulGirl 目录下。那如果删除文件呢?这里介绍一种特殊的删除联合文件系统的特性,称为 whiteout,如下:

root@vcu-robot-pc-ipv4-bak:~/hxia/docker/handsomeBoy# touch whiteout
root@vcu-robot-pc-ipv4-bak:~/hxia/docker/handsomeBoy# ls
chunqiu  root  whiteout

root@vcu-robot-pc-ipv4-bak:~/hxia/docker/mnt# ls
chunqiu  chunqiu_girlfriend  root  whiteout
root@vcu-robot-pc-ipv4-bak:~/hxia/docker/mnt# rm -rf whiteout

root@vcu-robot-pc-ipv4-bak:~/hxia/docker/handsomeBoy# ls
chunqiu  root  whiteout

root@vcu-robot-pc-ipv4-bak:~/hxia/docker/beautifulGirl# ls -al
total 28
drwxr-xr-x 5 root root 4096 May  8 06:11 .
drwxr-xr-x 5 root root 4096 May  8 05:43 ..
-rw-r--r-- 1 root root    8 May  8 05:56 chunqiu
-rw-r--r-- 1 root root    5 May  8 05:56 chunqiu_girlfriend
drwxr-xr-x 2 root root 4096 May  8 05:44 root
-r--r--r-- 2 root root    0 May  8 05:45 .wh.whiteout

在只读目录 handsomeBoy 下创建文件 whiteout,这个文件被映射到 mnt 目录下。在 mnt 目录下删除该文件,会发现 handsomeBoy 下这个文件还是存在(因为它是只读目录),而在可读写目录 beautifulGril 下多了个隐藏文件 .wh.whiteout。这就是 whiteout 的特性,它是上层目录覆盖下层相同名字目录,用于隐藏低层分支的机制。

简要介绍联合文件系统,可以发现它将目录以层级的形式表现出来。相比于联合文件系统,容器文件系统利用联合挂载技术将可读写层(read-write layer 以及 volumes),init-layer,只读层组合在一起呈现给容器内的进程,进程是感受不到这些层级结构的。那么,让我们开始容器文件系统的学习吧

1.2 Docker overlay2 最佳实践

容器文件系统有多种存储驱动实现方式,aufs,devicemapper,overlay,overlay2 等。这里选其中一种 overlay2 加以介绍。

在介绍 overlay2 之前需要先介绍下 docker 镜像相关概念,理解它们是后续介绍的基础:

  • registry/repository: registry 是 repository 的集合,repository 是镜像的集合。
  • image:image 是存储镜像相关的元数据,包括镜像的架构,镜像默认配置信息,镜像的容器配置信息等等。它是“逻辑”上的概念,并无物理上的镜像文件与之对应。
  • layer:layer(镜像层) 组成了镜像,单个 layer 可以被多个镜像共享。

首先通过 docker info 命令查看宿主机上使用的存储驱动是否是 overlay2(配置 overlay2 可看这里):

[root@k8s-master-node-1 centos]# docker info | grep overlay
 Storage Driver: overlay2

宿主机上已经配置好了 overlay2 存储驱动,使用 docker pull 下载 ubuntu 镜像:

[root@k8s-master-node-1 overlay2]# docker pull ubuntu
Using default tag: latest
latest: Pulling from library/ubuntu
345e3491a907: Pull complete
57671312ef6f: Pull complete
5e9250ddb7d0: Pull complete
Digest: sha256:cf31af331f38d1d7158470e095b132acd126a7180a54f263d386da88eb681d93
Status: Downloaded newer image for ubuntu:latest
docker.io/library/ubuntu:latest

可以看到 ubuntu 镜像分为三层,那我们怎么找到这三层呢?
首先查看 ubuntu 镜像:

[root@k8s-master-node-1 centos]# docker image ls | grep ubuntu
ubuntu                               latest              7e0aa2d69a15        2 weeks ago         72.7MB

镜像 ubuntu 的短 ID 为 7e0aa2d69a15,通过该短 ID 我们就可以查找到镜像的三层结构。查看目录:

[root@k8s-master-node-1 centos]# cd /var/lib/docker/image/overlay2/
distribution/      imagedb/           layerdb/           repositories.json

这个目录是查找的入口,非常重要。它存储了镜像管理的元数据。其中, repositories.json 记录了 repo 与镜像 ID 的映射关系。imagedb 记录了镜像架构,操作系统,构建镜像的容器 ID 和配置以及 rootfs 等信息。layerdb 记录了每层镜像层的元数据。

通过短 ID 查找 repositories.json 文件,找到镜像 ubuntu 的长 ID,通过长 ID 在 imagedb 中找到该镜像的元数据如下:

[root@k8s-master-node-1 overlay2]# cat repositories.json | grep 7e0aa2d69a15
...
{"ubuntu:latest":"sha256:7e0aa2d69a153215c790488ed1fcec162015e973e49962d438e18249d16fa9bd","ubuntu@sha256:cf31af331f38d1d7158470e095b132acd126a7180a54f263d386da88eb681d93":"sha256:7e0aa2d69a153215c790488ed1fcec162015e973e49962d438e18249d16fa9bd"}

[root@k8s-master-node-1 overlay2]# cat imagedb/content/sha256/7e0aa2d69a153215c790488ed1fcec162015e973e49962d438e18249d16fa9bd
"rootfs": {
		"type": "layers",
		"diff_ids": [
		"sha256:ccdbb80308cc5ef43b605ac28fac29c6a597f89f5a169bbedbb8dec29c987439",
		"sha256:63c99163f47292f80f9d24c5b475751dbad6dc795596e935c5c7f1c73dc08107",
		"sha256:2f140462f3bcf8cf3752461e27dfd4b3531f266fa10cda716166bd3a78a19103"]
	}
...

这里省去了很多不必要的元数据,仅保留我们想要的部分。在 rootfs 中我们看到 layers 有三层,这三层即对应镜像的三层镜像层。并且,自上而下分别映射到容器的底层到顶层。找到了镜像的三层,接下来的问题是每层的文件内容在哪里呢?

layerdb 元数据会给我们想要的信息,通过底层 diff id: ccdbb80308cc5ef43b605ac28fac29c6a597f89f5a169bbedbb8dec29c987439 我们查到最底层镜像层的 cache_id,通过 cache_id 即可查找到镜像层的内容,如下:

[root@k8s-master-node-1 ccdbb80308cc5ef43b605ac28fac29c6a597f89f5a169bbedbb8dec29c987439]# ls
cache-id  diff  size  tar-split.json.gz
[root@k8s-master-node-1 ccdbb80308cc5ef43b605ac28fac29c6a597f89f5a169bbedbb8dec29c987439]# cat cache-id
1c3b24824b7026813cc6e62b1f217f5b5bf17d67c2bc30a90bc68d286348b7b7[root@k8s-master-node-1 ccdbb80308cc5ef43b605ac28fac29c6a597f89f5a169bbedbb8dec29c987439]# cat diff
sha256:ccdbb80308cc5ef43b605ac28fac29c6a597f89f5a169bbedbb8dec29c987439[root@k8s-master-node-1 ccdbb80308cc5ef43b605ac28fac29c6a597f89f5a169bbedbb8dec29c987439]# pwd
/var/lib/docker/image/overlay2/layerdb/sha256/ccdbb80308cc5ef43b605ac28fac29c6a597f89f5a169bbedbb8dec29c987439

[root@k8s-master-node-1 ccdbb80308cc5ef43b605ac28fac29c6a597f89f5a169bbedbb8dec29c987439]# cd /var/lib/docker/overlay2/1c3b24824b7026813cc6e62b1f217f5b5bf17d67c2bc30a90bc68d286348b7b7/
[root@k8s-master-node-1 1c3b24824b7026813cc6e62b1f217f5b5bf17d67c2bc30a90bc68d286348b7b7]# ls
committed  diff  link
[root@k8s-master-node-1 1c3b24824b7026813cc6e62b1f217f5b5bf17d67c2bc30a90bc68d286348b7b7]# cd diff/
[root@k8s-master-node-1 diff]# ls
bin  boot  dev  etc  home  lib  lib32  lib64  libx32  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
[root@k8s-master-node-1 diff]#
[root@k8s-master-node-1 1c3b24824b7026813cc6e62b1f217f5b5bf17d67c2bc30a90bc68d286348b7b7]# cat link
5OLEHO4UPBPTXSVUTVZ2JB2WJR

上示例中,镜像元数据和镜像层内容是分开存储的。因此通过 cache-id 我们需要到 /var/lib/docker/overlay2 目录下查看镜像层内容,它就存在 diff 目录下,其中 link 存储的是镜像层对应的短 ID,后面会看到它的用场。

找到了镜像层的最底层,接着查找镜像层的“中间层”,发现在 layerdb 目录下没有 diff-id 63c99163f47292f80f9d24c5b475751dbad6dc795596e935c5c7f1c73dc08107 的镜像层:

[root@k8s-master-node-1 layerdb]# cd sha256/63c99163f47292f80f9d24c5b475751dbad6dc795596e935c5c7f1c73dc08107
bash: cd: sha256/63c99163f47292f80f9d24c5b475751dbad6dc795596e935c5c7f1c73dc08107: No such file or directory
[root@k8s-master-node-1 layerdb]#

这是因为 docker 引入了内容寻址机制,该机制会根据文件内容来索引镜像和镜像层。docker 利用 rootfs 中的 diff_id 计算出内容寻址的 chainID,通过 chainID 获取 layer 相关信息,最终索引到镜像层文件内容。对于最底层镜像层其 diff_id 即是 chainID,因此我们可以查找到它的文件内容。除最底层外,chainID 需通过公式 chainID(n) = SHA256(chain(n-1) diffID(n)) 计算得到,计算“中间层” chainID:

[root@k8s-master-node-1 layerdb]# echo -n "sha256:ccdbb80308cc5ef43b605ac28fac29c6a597f89f5a169bbedbb8dec29c987439 sha256:63c99163f47292f80f9d24c5b475751dbad6dc795596e935c5c7f1c73dc08107" | sha256sum -
8d8dceacec7085abcab1f93ac1128765bc6cf0caac334c821e01546bd96eb741  -
[root@k8s-master-node-1 layerdb]#

根据 “中间层” chainID 查找文件内容:

[root@k8s-master-node-1 8d8dceacec7085abcab1f93ac1128765bc6cf0caac334c821e01546bd96eb741]# ls
cache-id  diff  parent  size  tar-split.json.gz
[root@k8s-master-node-1 8d8dceacec7085abcab1f93ac1128765bc6cf0caac334c821e01546bd96eb741]# cat cache-id
4d615a437c68f0853db7749bf3d7d268efaebbe045a2af4d8b8e1148fc1acd91
[root@k8s-master-node-1 8d8dceacec7085abcab1f93ac1128765bc6cf0caac334c821e01546bd96eb741]# cat diff
sha256:63c99163f47292f80f9d24c5b475751dbad6dc795596e935c5c7f1c73dc08107
// 镜像层的 diff-id
[root@k8s-master-node-1 8d8dceacec7085abcab1f93ac1128765bc6cf0caac334c821e01546bd96eb741]# cat parent
sha256:ccdbb80308cc5ef43b605ac28fac29c6a597f89f5a169bbedbb8dec29c987439
// 该层镜像层的父镜像层 diff-id

[root@k8s-master-node-1 4d615a437c68f0853db7749bf3d7d268efaebbe045a2af4d8b8e1148fc1acd91]# ls
committed  diff  link  lower  work
[root@k8s-master-node-1 4d615a437c68f0853db7749bf3d7d268efaebbe045a2af4d8b8e1148fc1acd91]# ls diff/
etc  usr  var
// 镜像层文件内容
[root@k8s-master-node-1 4d615a437c68f0853db7749bf3d7d268efaebbe045a2af4d8b8e1148fc1acd91]# cat link
GALK5TGULR45FL2NKY54EPAQ3C
// 镜像层文件内容短 ID
[root@k8s-master-node-1 4d615a437c68f0853db7749bf3d7d268efaebbe045a2af4d8b8e1148fc1acd91]# cat lower
l/5OLEHO4UPBPTXSVUTVZ2JB2WJR
// “父”镜像层文件内容短 ID

找到最底层文件内容和“中间层”文件内容,再去找最顶层文件内容就变的不难了,这里就不多做赘述啦~

这一节知道了如何去查找镜像的镜像层文件内容,那么 docker 容器是怎么将镜像和容器结合起来的呢?为什么说“镜像是容器的静态视角,容器是镜像的运行状态”呢?我们接着看。

1.2.1 docker 容器与镜像

通过 docker run 命令启动一个镜像为 ubuntu 的容器:

[root@k8s-master-node-1 centos]# docker ps | grep ubuntu
156d4506b7ae        ubuntu                  "/bin/bash"              24 hours ago        Up 23 hours                             great_williamson

[root@k8s-master-node-1 centos]# mount | grep overlay
overlay on /var/lib/docker/overlay2/5d0cbbdeb08f0b3087d6635f764aa51654eb6b9fbdc7265248fd9815855c2a4d/merged type overlay 
(rw,relatime,lowerdir=/var/lib/docker/overlay2/l/Q6HPGILSGOQG5JGUURP2357S4X:/var/lib/docker/overlay2/l/Y2WW3FGR4WZDFTNZTTLGI7L24E:/var/lib/docker/overlay2/l/GALK5TGULR45FL2NKY54EPAQ3C:/var/lib/docker/overlay2/l/5OLEHO4UPBPTXSVUTVZ2JB2WJR,upperdir=/var/lib/docker/overlay2/5d0cbbdeb08f0b3087d6635f764aa51654eb6b9fbdc7265248fd9815855c2a4d/diff,workdir=/var/lib/docker/overlay2/5d0cbbdeb08f0b3087d6635f764aa51654eb6b9fbdc7265248fd9815855c2a4d/work)

可以看到,启动容器会 mount 一个 overlay 的联合文件系统到容器内。这个文件系统由三层组成:

  • lowerdir:只读层,即为镜像的镜像层。
  • upperdir:读写层,该层是容器的读写层,对容器的读写操作将反映在读写层。
  • workdir: overlayfs 的内部层,用于实现从只读层到读写层的 copy_up 操作。
  • merge:容器内作为同一视图联合挂载点的目录。

这里需要着重介绍的是容器的 lowerdir 镜像只读层,查看只读层的短 ID:

Q6HPGILSGOQG5JGUURP2357S4X

Y2WW3FGR4WZDFTNZTTLGI7L24E
GALK5TGULR45FL2NKY54EPAQ3C
5OLEHO4UPBPTXSVUTVZ2JB2WJR

镜像层只有三层这里的短 ID 却有四个呢?在 /var/lib/docker/overlay2/l 目录下我们找到了答案:

[root@k8s-master-node-1 l]# pwd
/var/lib/docker/overlay2/l

[root@k8s-master-node-1 l]# ls -l Q6HPGILSGOQG5JGUURP2357S4X
lrwxrwxrwx 1 root root 77 May  7 08:47 Q6HPGILSGOQG5JGUURP2357S4X -> ../5d0cbbdeb08f0b3087d6635f764aa51654eb6b9fbdc7265248fd9815855c2a4d-init/diff

[root@k8s-master-node-1 l]# ls -l Y2WW3FGR4WZDFTNZTTLGI7L24E
lrwxrwxrwx 1 root root 72 May  7 08:13 Y2WW3FGR4WZDFTNZTTLGI7L24E -> ../7e27874bb1acb324bf692d0fb53ad0ebaed0837cfe650eab42cd9f8c2c592c85/diff
[root@k8s-master-node-1 l]# ls -l GALK5TGULR45FL2NKY54EPAQ3C
lrwxrwxrwx 1 root root 72 May  7 08:13 GALK5TGULR45FL2NKY54EPAQ3C -> ../4d615a437c68f0853db7749bf3d7d268efaebbe045a2af4d8b8e1148fc1acd91/diff
[root@k8s-master-node-1 l]# ls -l 5OLEHO4UPBPTXSVUTVZ2JB2WJR
lrwxrwxrwx 1 root root 72 May  7 08:13 5OLEHO4UPBPTXSVUTVZ2JB2WJR -> ../1c3b24824b7026813cc6e62b1f217f5b5bf17d67c2bc30a90bc68d286348b7b7/diff

[root@k8s-master-node-1 l]# ls -R ../5d0cbbdeb08f0b3087d6635f764aa51654eb6b9fbdc7265248fd9815855c2a4d-init/diff
../5d0cbbdeb08f0b3087d6635f764aa51654eb6b9fbdc7265248fd9815855c2a4d-init/diff:
dev  etc

../5d0cbbdeb08f0b3087d6635f764aa51654eb6b9fbdc7265248fd9815855c2a4d-init/diff/dev:
console  pts  shm

../5d0cbbdeb08f0b3087d6635f764aa51654eb6b9fbdc7265248fd9815855c2a4d-init/diff/dev/pts:

../5d0cbbdeb08f0b3087d6635f764aa51654eb6b9fbdc7265248fd9815855c2a4d-init/diff/dev/shm:

../5d0cbbdeb08f0b3087d6635f764aa51654eb6b9fbdc7265248fd9815855c2a4d-init/diff/etc:
hostname  hosts  mtab  resolv.conf

镜像层 Y2WW3FGR4WZDFTNZTTLGI7L24E / GALK5TGULR45FL2NKY54EPAQ3C / 5OLEHO4UPBPTXSVUTVZ2JB2WJR 分别对应镜像的三层镜像层文件内容,它们分别映射到镜像层的 diff 目录。而 Q6HPGILSGOQG5JGUURP2357S4X 映射的是容器的初始化层 init,该层内容是和容器配置相关的文件内容,并且它是只读的。

这里启动了容器,docker 将镜像的内容 mount 到容器中。那么,如果在容器中读写文件会对镜像有什么影响呢?

1.2.2 容器内写文件

不难理解,镜像层是只读的,在容器中写文件其实是将文件写入到 overlay 的可读写层。这里有几个 case 可以测试:

  • 读写层不存在该文件,只读层存在。
  • 读写层存在该文件,只读层不存在。
  • 读写层和只读层都不存在该文件。

这里简单构建一种读写层和只读层都不存在的场景:

root@156d4506b7ae:/etc# touch temp.txt
root@156d4506b7ae:/etc# ls
temp.txt  ...

查看读写层是否有该文件:

[root@k8s-master-node-1 diff]# cd /var/lib/docker/overlay2/5d0cbbdeb08f0b3087d6635f764aa51654eb6b9fbdc7265248fd9815855c2a4d/diff
[root@k8s-master-node-1 diff]# ls
etc
[root@k8s-master-node-1 diff]# ls etc/
temp.txt

1.2.3 docker commit

上节提到容器内写文件会反映在 overlay 的可读写层,那么读写层的文件内容可以做成镜像吗?
可以。docker 通过 commit 和 build 操作实现镜像的构建。commit 是将容器提交为一个镜像,而 build 是在一个镜像的基础上构建镜像。这里使用 commit 将上节的容器的容器提交为一个镜像:

[root@k8s-master-node-1 diff]# docker commit 156d4506b7ae
sha256:71cf2c4aad14d18e9d0ee8bfb2cdd16ea5216f68c6d4d81062143fe58fbe48a4
[root@k8s-master-node-1 diff]# docker image ls
REPOSITORY                           TAG                 IMAGE ID            CREATED             SIZE
<none>                               <none>              71cf2c4aad14        9 seconds ago       72.7MB
ubuntu                               latest              7e0aa2d69a15        2 weeks ago         72.7MB

image 短 ID 71cf2c4aad14 即为容器提交的镜像,查看镜像的 imagedb 元数据:

[root@k8s-master-node-1 diff]# cat /var/lib/docker/image/overlay2/imagedb/content/sha256/71cf2c4aad14d18e9d0ee8bfb2cdd16ea5216f68c6d4d81062143fe58fbe48a4
"rootfs": {
		"type": "layers",
		"diff_ids": [
		"sha256:ccdbb80308cc5ef43b605ac28fac29c6a597f89f5a169bbedbb8dec29c987439",
		"sha256:63c99163f47292f80f9d24c5b475751dbad6dc795596e935c5c7f1c73dc08107",
		"sha256:2f140462f3bcf8cf3752461e27dfd4b3531f266fa10cda716166bd3a78a19103",
		"sha256:7dd12b1505cdc6bebe28cf63d5b374890908dcc9b1a23ca4dcc21e9de033c209"]
	}
...

可以看到镜像层自上而下的前三个镜像层 diff_id 和 ubuntu 镜像层 diff_id 是一样的,说明每层镜像层可以被多个镜像共享。这里多出来的一层镜像层内容即是上节我们写入文件的内容:

[root@k8s-master-node-1 diff]# echo -n "sha256:3dd8c8d4fd5b59d543c8f75a67cdfaab30aef5a6d99aea3fe74d8cc69d4e7bf2 sha256:7dd12b1505cdc6bebe28cf63d5b374890908dcc9b1a23ca4dcc21e9de033c209" | sha256sum -
0f3060e8fee611c68417fecbfc52734563ddea02157eaa7624fa23043af0bfb6  -

[root@k8s-master-node-1 diff]# cd /var/lib/docker/image/overlay2/layerdb/sha256/0f3060e8fee611c68417fecbfc52734563ddea02157eaa7624fa23043af0bfb6/
[root@k8s-master-node-1 0f3060e8fee611c68417fecbfc52734563ddea02157eaa7624fa23043af0bfb6]# ls
cache-id  diff  parent  size  tar-split.json.gz

[root@k8s-master-node-1 48e27ff2ff5302bd2dfd244610a61cc5032ec88b79b0953eb2c933a1f4146a36]# ls
diff  link  lower  work
[root@k8s-master-node-1 48e27ff2ff5302bd2dfd244610a61cc5032ec88b79b0953eb2c933a1f4146a36]# cd diff/
[root@k8s-master-node-1 diff]# ls etc/
temp.txt

docker 镜像管理之 overlay2 最佳实践

标签:www   roc   sts   k8s   ram   white   因此   repos   docker 容器   

原文地址:https://www.cnblogs.com/xingzheanan/p/14746121.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!