码迷，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）
登录后才能评论！
分享档案
更多>
2021年07月29日 (22)
2021年07月28日 (40)
2021年07月27日 (32)
2021年07月26日 (79)
2021年07月23日 (29)
2021年07月22日 (30)
2021年07月21日 (42)
2021年07月20日 (16)
2021年07月19日 (90)
2021年07月16日 (35)
周排行
mamicode.com排行更多图片
更多
友情链接
兰亭集智   国之画   百度统计   站长统计   阿里云   chrome插件   新版天听网
关于我们 - 联系我们 - 留言反馈
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码！