# 原理

# 架构

  • 容器(Container)是一个像虚拟机的沙盒,内部可以运行一组进程。
  • 镜像(Image)是用于创建容器的模板,包含了应用程序的可执行文件文件、依赖文件、配置信息等。
  • Docker 采用 C/S 架构工作:
    • 在宿主机上运行一个守护进程 dockerd ,作为服务器,负责管理本机的容器、镜像、数据卷、网络等对象。
      • 早期版本的 dockerd 以子进程的形式运行各个容器的 1 号进程,存在单点故障的风险。
      • 后来,改为给每个容器创建一个守护进程 containerd-shim (新版本为 containerd-shim-runc-v2 ),作为容器的父进程。
    • 用户可以在宿主机上执行 docker 命令,作为客户端,与 dockerd 交互,比如请求启动容器。
      • 客户端默认通过本机的 /var/run/docker.sock 文件与 dockerd 通信,也可通过 tcp 端口访问本机或其它主机的 dockerd 。
      • 非 root 用户无权访问 docker.sock 文件,导致无权执行 docker ps 等命令。可以将该用户加入 docker 用户组:sudo usermod leo -aG docker ,从而开通权限。

# namespace

  • Docker 基于 Linux namespace 技术隔离了各个容器可见的系统资源。

    • 隔离了进程、网络、文件系统等系统资源,从而为每个容器创建一个运行环境,模拟一个独立的虚拟机。
    • 没有隔离硬件资源。例如:一个容器可能占用全部的 CPU 、内存、磁盘;在容器内执行 top 命令会显示整个宿主机的 CPU、内存量。
    • 没有隔离 Linux 内核。容器内外的所有进程调用同一个 Linux 内核,容器内进程可能通过内核漏洞逃逸到宿主机上。
  • namespace 分为多种类型,分别用于隔离不同的系统资源。如下:

    类型 Flag 隔离资源
    ipc CLONE_NEWIPC System V 系统的 IPC 对象、POSIX 系统的消息队列
    network CLONE_NEWNET IP、Socket、路由器、iptables 防火墙
    mnt CLONE_NEWNS 文件系统的挂载点
    pid CLONE_NEWPID 进程的 PID
    user CLONE_NEWUSER 用户、用户组
    uts CLONE_NEWUTS 主机名、域名
    • 每种类型的 namespace 可以创建多个实例。
      • 每个进程可以同时使用多种类型的 namespace 实例。
      • 如果一个 namespace 内的所有进程都退出,则内核会自动销毁该 namespace 。除非 /proc/<pid>/ns/<namespace> 文件被一直打开或挂载。
    • 例:
      • 不同 pid namespace 中的进程可以分配相同的 PID 。
      • docker 容器内,第一个启动的进程被分配的 PID 为 1 ,而 PPID 为 0 。
  • 关于 pid namespace :

    • pid namespace 支持嵌套,当前 pid namespace 中创建的所有 pid namespace 都属于子实例。
      • 父实例可以看到子孙实例的进程信息,但反之不行。
        比如在父实例中执行 ps -ef 命令,会将子孙实例中的进程也显示出来,并将它们的 PID 转换成父实例中的 PID 。
      • 主机启动之后,第一个创建的 pid namespace 就是最上层的实例。
    • 每个 pid namespace 中,第一个创建的进程的 PID 为 1 ,称为 1 号进程。
      • 如果其它进程产生了孤儿进程,则内核会将它们改为当前 pid namespace 的 1 号进程的子进程。
      • 如果 1 号进程退出,则内核会向当前及子孙 pid namespace 中的所有进程发送 SIGKILL 信号,杀死它们。
      • 内核函数 kill() 只允许将已注册 handler 的信号发送给 1 号进程,会忽略 SIGKILL、SIGSTOP 等信号。
        • 因此,在容器内执行 kill -9 1 命令不会杀死 1 号进程。但可以在宿主机上查到容器内 1 号进程的 PID ,用 kill 命令杀死它,这样会导致子孙 pid namespace 被销毁。
    • 调用 setns() 或 unshare() 时,不会改变当前进程的 pid namespace ,而是影响之后创建的子进程。
      • 因此,一个进程在创建之后,其 PID 总是不变。成为孤儿进程时, PPID 会变为 1 。
    • 相关 API :
      #include <unistd.h>
      
      pid_t getpid(void);   // 返回当前进程的 PID ,属于当前的 pid namespace
      pid_t getppid(void);  // 返回父进程的 PID 。如果父进程属于不同的 pid namespace ,则返回 0
      
  • /proc/<pid>/ns/ 目录下,通过一些软链接,记录了进程所属的 namespace ID 。如下:

    [root@CentOS ~]# ll /proc/1/ns
    total 0
    lrwxrwxrwx. 1 root root 0 Mar 26 13:25 ipc -> ipc:[4026531839]
    lrwxrwxrwx. 1 root root 0 Mar 26 13:25 mnt -> mnt:[4026531840]
    lrwxrwxrwx. 1 root root 0 Mar 26 13:25 net -> net:[4026531956]
    lrwxrwxrwx. 1 root root 0 Mar 26 13:25 pid -> pid:[4026531836]
    lrwxrwxrwx. 1 root root 0 Mar 26 13:25 user -> user:[4026531837]
    lrwxrwxrwx. 1 root root 0 Mar 26 13:25 uts -> uts:[4026531838]
    
    • 如果两个进程的某种 namespace ID 相同,则说明属于这种类型的同一个 namespace 实例。
    • 创建子进程时,默认继承父进程的 namespace 实例。
  • 相关 API :

    #include <sched.h>
    
    int clone(int (*child_func)(void *), void *child_stack, int flags, void *arg);
        // 创建一个子进程,并创建指定类型的 namespace ,让子进程加入其中
        // child_func   :子进程要运行的函数
        // child_stack  :子进程使用的栈空间
        // flags        :一种或多种 namespace 的 flag ,比如 flags = CLONE_NEWNS | CLONE_NEWPID | CLONE_NEWUSER
        // args         :传给子进程的参数
    
    int setns(int fd, int nstype);
        // 让当前进程加入已存在的 namespace
        // fd     :一个 namespace 的文件描述符
        // nstype :用于检查 fd 指向的 namespace 类型,填 0 则不检查
    
    int unshare(int flags);
        // 根据 flags 创建新的 namespace ,然后让当前进程加入其中。这会先离开已加入的同类型 namespace
    

# Cgroup

  • Docker 基于 Linux Cgroup 技术限制容器对 CPU、内存等系统资源的使用量,每个容器属于一个独立的 Cgroup 节点。

    • 在 Cgroup 技术之前,通常通过 ulimit 命令限制 shell 终端对系统资源的使用量,但功能较少。
  • Cgroup 的版本:

    • v1
    • v2
      • 将所有 subsystem 关联到同一个 hierarchy 中。
      • 同一个 subsystem 不能同时关联 v1 和 v2 版本的 hierarchy 。
      • 只允许在根节点、叶子节点创建 cgroup 。
      • 支持限制磁盘 iops 。

# 主要概念

  • task
    • :代表一个进程。
  • cgroup
    • :控制组,包含一组进程。
    • cgroup 的最小管理单位是进程,不能管理进程中的某个线程。
    • 创建子进程时,默认继承父进程的 cgroup 。但是创建之后,修改父进程或子进程的 cgroup ,不再相互影响。
  • hierarchy
    • :层级,是由多个 cgroup 实例组成的一个目录树。
    • 通过挂载文件系统的方式,创建 hierarchy 。
      • 一般将 hierarchy 挂载在 /sys/fs/cgroup/ 目录下。
      • 通过在 hierarchy 目录下创建、删除子目录的方式,创建、删除 cgroup 节点。
      • cgroup 子节点默认继承父节点的属性。
      • 如果一个 cgroup 节点不包含任何进程,也没有子节点,则称为空节点,允许被删除。
      • 创建 hierarchy 时,根路径下的 cgroup 节点是第一个创建的节点,称为 root cgroup 。
    • 每个进程同时可以存在于多个 hierarchy 中。
      • 在同一个 hierarchy 中,每个进程同时只能属于一个 cgroup ,但可以切换到其它 cgroup 。
  • subsystem
    • :资源控制器(Resource Controller)。
    • 通过将 subsystem 关联到 hierarchy 的方式,控制 cgroup 内进程占用的系统资源。
      • 每个 subsystem 同时只能关联一个 hierarchy 。
      • 每个 hierarchy 同时可以关联多个 subsystem 。
    • subsystem 分为多种类型:
      pids        # 限制、统计进程总数,包括 Cgroup 当前节点及其子节点
      
      cpu         # 限制 CPU 使用量
      cpuacct     # 统计 CPU 使用量
      cpuset      # 只允许使用 CPU 指定几个编号的核
      
      memory      # 限制、统计内存的使用量
      
      blkio       # 限制对块设备的 IO 速度
      devices     # 控制能否访问某些设备
      freezer     # 暂停进程。这不是通过发送 SIGSTOP 信号,而是在进程被 CPU 执行时突然阻塞。此时进程依然存在,不能继续执行,不能响应信号
      hugetlb     # 限制 huge page 的使用量
      perf_event  # 允许进程被 perf 命令监控
      
      net_prio    # 设置对网络接口的访问优先级
      net_cls     # 通过等级识别符 (classid) 标记进程发出的网络数据包,便于被 iptables 等工具统计
      
    • 每种 subsystem 通过读写一组文件来实现配置,例如:
      pids.max              # 限制进程总数,取值为 max 则不限制
      pids.current          # 监控当前的进程总数
      
      cpu.cfs_period_us     # Cgroup 的 CPU 调度器采用 CFS ,可以配置 CFS 周期的长度。单位为 us ,取值范围为 1ms~1s ,默认为 100000us 即 100ms
      cpu.cfs_quota_us      # 限制当前 Cgroup 节点在每个 CFS 周期内,占用 CPU 的最大时长。取值范围为 >1ms ,默认为 0 ,表示不限制
      cpu.shares            # 多个 Cgroup 节点同时申请使用 CPU 时,Linux 会根据每个节点的 cpu_shares 大小比例来分配 CPU 时长
      
      memory.limit_in_bytes     # 限制进程最大的内存使用量,取值为 -1 则不限制
      memory.oom_control        # 取值为 0 时,启用 OOM-killer ,当进程占用的内存超过限制时杀死它。取值为 1 时,禁用 OOM-killer ,只会暂停进程
      memory.usage_in_bytes     # 监控进程当前的内存使用量,包括 RSS、swap、Page Cache
      memory.max_usage_in_bytes # 监控进程历史最大的内存使用量
      
      • 有的程序会自动读取 /sys/fs/cgroup/memory/memory.limit_in_bytes ,作为自己的内存上限,从而准确地控制自己的内存开销。而有的程序不会发现自己被 Cgroup 限制,依然尝试使用主机的全部内存,可能占用过多内存而被 OOM 杀死。
    • 关于 cpu.shares 。
      • docker 创建每个容器所属的 Cgroup 节点时,默认配置 cpu.shares=1024 。因此所有容器的 cpu.shares 之和,可能超过主机的 CPU 总量。
      • k8s 中,假设 Pod 配置了 limits.cpu=1 和 requests.cpu=1 ,则创建 Pod 所属的 Cgroup 节点时,会自动配置 cpu.cfs_quota_us=100000 和 cpu.shares=1024 。
      • k8s 会严格限制每个 Pod 的 CPU 开销,确保每个主机上所有 Pod 的 requests.cpu 之和,不能超过主机的 CPU 总量。

# 查看

  • 例:查看指定进程的 cgroup 信息

    [root@CentOS ~]# cat /proc/$$/cgroup
    11:memory:/user.slice
    10:cpuset:/
    9:cpuacct,cpu:/user.slice
    8:hugetlb:/
    7:net_prio,net_cls:/
    6:devices:/user.slice
    5:freezer:/
    4:blkio:/user.slice
    3:pids:/user.slice
    2:perf_event:/
    1:name=systemd:/user.slice/user-1000.slice/session-3785.scope
    
    • 每行的三个字段分别表示:
      • cgroup ID 。
      • cgroup 绑定的所有 subsystem 的名称,用逗号分隔。
        • name=systemd 表示没有绑定 subsystem ,只是定义了名称。
      • 进程在 cgroup 树中的路径。
        • 这是对于挂载点的相对路径,以 / 开头。
    • 对于 Cgroup v2 ,每行总是显示成 0::<PATH> 的格式。
  • 例:查看系统的所有 subsystem

    [root@CentOS ~]# cat /proc/cgroups
    #subsys_name    hierarchy       num_cgroups     enabled
    cpuset          10              5               1
    cpu             9               71              1
    cpuacct         9               71              1
    memory          11              71              1
    devices         6               71              1
    freezer         5               5               1
    net_cls         7               5               1
    blkio           4               71              1
    perf_event      2               5               1
    hugetlb         8               5               1
    pids            3               71              1
    net_prio        7               5               1
    
    • 四列分别表示 subsystem 的:
      • 名称
      • 关联的 hierarchy ID
      • 关联的 cgroup 中的进程数
      • 是否启用

# 创建

创建 Cgroup 的示例:

  1. 通过挂载文件系统的方式,创建 hierarchy :

    mkdir -p /cgroup/hierarchy_1
    
    # 挂载一个 cgroup 类型的虚拟文件系统,作为 hierarchy ,命名为 hierarchy_1 。默认关联所有 subsystem
    # mount -t cgroup hierarchy_1 /cgroup/hierarchy_1
    
    # 可以通过 -o 选项传入一些参数,这里是只关联指定的 subsystem
    # mount -t cgroup -o cpuset,cpuacct hierarchy_1 /cgroup/hierarchy_1
    
    # 挂载 hierarchy ,关联的 subsystem 为空
    mount -t cgroup -o none,name=subsystem_1  hierarchy_1  /cgroup/hierarchy_1
    
    • 如果使用的 subsystem 已经被关联,则挂载 hierarchy 时会报错:
      mount: hierarchy_1 is already mounted or /cgroup/hierarchy_1 busy
      
    • 删除 hierarchy 的命令:
      umount      /cgroup/hierarchy_1
      /bin/rm -r  /cgroup/hierarchy_1
      
  2. hierarchy 在挂载之后会自动创建 root cgroup 节点,生成一些默认文件。如下:

    [root@CentOS ~]# cd /cgroup/hierarchy_1
    [root@CentOS /cgroup/hierarchy_1]# ll
    total 0
    -rw-r--r--. 1 root root 0 Mar 26 17:17 cgroup.clone_children  # 文件内容默认为 0 。如果为 1 ,则创建子节点时会拷贝当前节点的 cpuset subsystem 配置
    --w--w--w-. 1 root root 0 Mar 26 17:17 cgroup.event_control
    -rw-r--r--. 1 root root 0 Mar 26 17:17 cgroup.procs           # 记录该 cgroup 关联的所有进程,每行一个 PID
    -r--r--r--. 1 root root 0 Mar 26 17:17 cgroup.sane_behavior
    -rw-r--r--. 1 root root 0 Mar 26 17:17 notify_on_release      # 文件内容默认为 0 。如果为 1 ,则 cgroup 退出时会执行 release_agent
    -rw-r--r--. 1 root root 0 Mar 26 17:17 release_agent          # 该文件只存在于 root cgroup 中,包含一些 cgroup 退出时需要执行的命令
    -rw-r--r--. 1 root root 0 Mar 26 17:17 tasks                  # 与 cgroup.procs 类似,记录进程中主线程的 TID ,即与 PID 一致
    [root@CentOS /cgroup/hierarchy_1]# head cgroup.procs          # root cgroup 默认包含系统的所有进程
    1
    2
    4
    6
    7
    8
    9
    10
    11
    12
    
  3. 在 hierarchy 目录下添加 cgroup 节点:

    [root@CentOS /cgroup/hierarchy_1]# mkdir cgroup_1             # 创建一个 cgroup 子节点,这会自动生成一些默认文件
    [root@CentOS /cgroup/hierarchy_1]# cd cgroup_1/
    [root@CentOS /cgroup/hierarchy_1/cgroup_1]# ll
    total 0
    -rw-r--r--. 1 root root 0 Mar 26 17:35 cgroup.clone_children
    --w--w--w-. 1 root root 0 Mar 26 17:35 cgroup.event_control
    -rw-r--r--. 1 root root 0 Mar 26 17:35 cgroup.procs
    -rw-r--r--. 1 root root 0 Mar 26 17:35 notify_on_release
    -rw-r--r--. 1 root root 0 Mar 26 17:35 tasks
    [root@CentOS /cgroup/hierarchy_1/cgroup_1]# cat cgroup.procs  # 非 root cgroup 的节点,默认不包含任何进程
    
  4. 在 cgroup 节点中增加进程:

    [root@CentOS /cgroup/hierarchy_1/cgroup_1]# echo 1 >> cgroup.procs   # 向该 cgroup 分组加入一个进程,这会自动将该进程移出之前的 cgroup
    [root@CentOS /cgroup/hierarchy_1/cgroup_1]# cat cgroup.procs
    1
    [root@CentOS /cgroup/hierarchy_1/cgroup_1]# head ../cgroup.procs
    2
    4
    6
    7
    8
    9
    10
    11
    12
    13
    [root@CentOS /cgroup/hierarchy_1/cgroup_1]# cat ../cgroup.procs >> cgroup.procs # 每次只能加入一个 PID
    cat: write error: Argument list too long
    [root@CentOS /cgroup/hierarchy_1/cgroup_1]# echo 3 >> cgroup.procs              # 不能加入不存在的进程的 PID
    -bash: echo: write error: No such process
    [root@CentOS /cgroup/hierarchy_1/cgroup_1]# echo > cgroup.procs                 # 只能在 cgroup 中加入进程,不支持删除进程
    [root@CentOS /cgroup/hierarchy_1/cgroup_1]# cat cgroup.procs
    1
    [root@CentOS /cgroup/hierarchy_1/cgroup_1]# echo $$ > cgroup.procs  # 加入当前终端的 PID
    [root@CentOS /cgroup/hierarchy_1/cgroup_1]# cat cgroup.procs
    1
    4593
    6121                                                                # 终端执行命令时创建了子进程,因此也加入了其 PID
    [root@CentOS /cgroup/hierarchy_1/cgroup_1]# echo $$ > cgroup.procs  # 加入 PID 时,会自动排序、去重、去掉不存在的 PID
    [root@CentOS /cgroup/hierarchy_1/cgroup_1]# cat cgroup.procs
    1
    4593
    6160
    
    • 非 root 用户只允许修改自己进程所属的 cgroup 。
    • 非空节点的 cgroup 不允许被删除:
      [root@CentOS /cgroup/hierarchy_1/cgroup_1]# cd ..
      [root@CentOS /cgroup/hierarchy_1]# rm -rf cgroup_1/
      /bin/rm: cannot remove ‘cgroup_1/cgroup.clone_children’: Operation not permitted
      /bin/rm: cannot remove ‘cgroup_1/cgroup.event_control’: Operation not permitted
      /bin/rm: cannot remove ‘cgroup_1/notify_on_release’: Operation not permitted
      /bin/rm: cannot remove ‘cgroup_1/cgroup.procs’: Operation not permitted
      /bin/rm: cannot remove ‘cgroup_1/tasks’: Operation not permitted
      

# libcgroup-tools

:一个用于查看、配置 Cgroup 的工具包。

  • 安装:yum install -y libcgroup-tools
  • 命令:
    lscgroup        # 显示本机的所有 cgroup
    
    lssubsys        # 显示已挂载的 subsystem
            -a      # 显示所有 subsystem
            -m      # 增加显示每个 subsystem 的挂载点
            -i      # 增加显示每个 subsystem 关联的 hierarchy ID
    
    cgdelete [<controllers>:<path>]...  # 删除 cgroup
    
  • 例:
    [root@CentOS ~]# lscgroup
    ...
    cpu,cpuacct:/               # 每行的格式为 <controllers>:<path> ,即 subsystem 的类型、cgroup 在 hierarchy 下的相对路径
    cpu,cpuacct:/docker
    cpu,cpuacct:/docker/baf31e1d1a0b055b7f7d9947ec035d716a2d7788ee47473f85f9f4061633fabe
    cpu,cpuacct:/docker/ba919a1393fbd560291ec8dd28eedf12b1e6ce4f0c1ab4df04d929074a436661
    cpu,cpuacct:/user.slice
    cpu,cpuacct:/system.slice
    cpu,cpuacct:/system.slice/iptables.service
    cpu,cpuacct:/system.slice/run-user-1000.mount
    cpu,cpuacct:/system.slice/crond.service
    cpuset:/
    cpuset:/docker
    cpuset:/docker/baf31e1d1a0b055b7f7d9947ec035d716a2d7788ee47473f85f9f4061633fabe
    cpuset:/docker/ba919a1393fbd560291ec8dd28eedf12b1e6ce4f0c1ab4df04d929074a436661
    name=subsystem_1:/
    

# layer

  • Docker 容器内采用联合挂载(Union mount)技术挂载多层文件系统(file system layer)。

    • mount 命令会让挂载的 layer 覆盖挂载点,而 Union mount 会让挂载的 layer 与挂载点合并:路径不同的文件会混合,路径相同的文件会覆盖。
    • 支持 Union mount 的 layer 称为 Union Filesystem ,比如 UnionFS、AUFS、OverlayFS 等。
    • 使用 Union mount 合并多层 layer 时,只有最上层的那个 layer 为读写模式(称为 top layer),其它 layer 都为 read-only 模式。
  • 新建一个 Docker 容器时,docker daemon 组装 layer 的流程如下:

    1. 先根据 Docker 镜像创建一个只读模式的 RootFS 文件系统,包含 /bin、/dev、/home 等 FHS 标准目录。
    2. 然后挂载一层读写模式的 top layer ,内容为空,不包含任何文件。
      • 容器内创建、修改的所有文件,都存储在 top layer 中。
      • 当容器读取某个路径的文件时,如果在 top layer 中不存在该文件,则会尝试在 read-only layer 中读取该文件。
      • 当容器删除 read-only layer 中的文件时,会在 top layer 中相同路径创建一个空文件,覆盖 read-only layer 中的原文件。这个空文件在容器中看不到,但可以在宿主机 /var/lib/docker/overlay2/<cache-id>/diff/ 目录中看到。
      • 当容器修改 read-only layer 中的文件时,采用写时复制(Copy On Write ,COW)方式,自动将该文件拷贝到 top layer 中,供容器修改,并覆盖 read-only layer 中的原文件。

# overlay2

  • 容器的存储驱动器默认为 overlay2 。参考 官方文档 (opens new window)

  • 一个 Docker image 由一层或多层 layer 组成,每层 layer 分别计算一个 SHA256 哈希值作为 id 标识。

    • 注意 layer hash 并不是 image hash 。
    • 一个 image 在宿主机上存储为一些零散文件,位于以下目录:
      /var/lib/docker/image/    # 存储 image、layer 的配置文件
      /var/lib/docker/overlay2/ # 存储 layer 的内容
      
  • 对于镜像中每个 layer ,Docker 会将该 layer 的配置文件存储到 /var/lib/docker/image/overlay2/layerdb/sha256/<layer_hash>/ 目录下,例如:

    [root@CentOS ~]# ls -lh /var/lib/docker/image/overlay2/layerdb/sha256/592f9d458d3943eca6c1bf2b8f98ce5fb7758a75c4e698592e9e4a73407cff31/
    -rw-r--r-- 1 root root  64 May 24 13:37 cache-id          # 记录该 layer 的缓存目录名
    -rw-r--r-- 1 root root  71 May 24 13:37 diff              # 记录该 layer 的哈希值,又称为 diff_id
    -rw-r--r-- 1 root root  71 May 24 13:37 parent            # 记录父级 layer 的哈希值。父级 layer 是指构建镜像时,在当前 layer 之前构建的一层 layer
    -rw-r--r-- 1 root root   3 May 24 13:37 size              # 记录该 layer 的体积
    -rw-r--r-- 1 root root 340 May 24 13:37 tar-split.json.gz # 一个配置文件,用于从镜像的 tar 包中分离出该 layer 的二进制流
    

    Docker 还会为该 layer 创建一个随机编号的缓存目录 /var/lib/docker/overlay2/<cache-id>/ 。例如:

    [root@CentOS ~]# ls -lh /var/lib/docker/overlay2/1c9408d89ae7884ae7f5aad46118d5af9247b2735f0d98c73686b06d2bce347a/
    -rw------- 1 root root    0 May 24 13:37 committed
    drwxr-xr-x 3 root root 4.0K May 24 13:37 diff/    # 存储该 layer 包含的所有文件,比如 bin、usr 目录
    -rw-r--r-- 1 root root   26 May 24 13:37 link     # 记录 diff 目录的软链接名称
    -rw-r--r-- 1 root root  434 May 24 13:37 lower    # 记录在当前 layer 之前构建的所有层 layer 的 diff 目录的软链接名称
    drwx------ 2 root root 4.0K May 24 13:37 work/    # 该目录供 OverlayFS 内部使用,通常为空
    
    • 为了避免挂载路径太长,超过 mount 命令的 page size ,Docker 会为每个 diff 目录创建一个名称较短的软链接文件,存储在 /var/lib/docker/overlay2/l/ 目录下。
  • 新建一个容器时,Docker 会为它创建一个随机编号的缓存目录 /var/lib/docker/overlay2/<cache-id>/ 。例如:

    [root@CentOS ~]# ls -lh /var/lib/docker/overlay2/16984e006f624d24b47ce9caa27ce074ecbf48980af0d084497c4a830557aa91
    drwxr-xr-x 5 root root 4.0K Jun 25 02:29 diff/    # 存储该容器的 top layer
    -rw-r--r-- 1 root root   26 Jun 25 02:29 link
    -rw-r--r-- 1 root root  463 Jun 25 02:29 lower
    drwxr-xr-x 1 root root 4.0K Jun 25 02:29 merged/  # 存储该容器的 read-only layer
    drwx------ 3 root root 4.0K Jun 25 02:29 work/
    
    • 根据镜像创建容器时,Docker 会将所有 layer 的 diff 目录,用 mount 命令联合挂载到宿主机的 /var/lib/docker/overlay2/<cache-id>/merged/ 目录。
    • merged 目录采用 overlay 文件系统,其下的所有文件都是通过硬链接共享镜像 layer 中的文件,因此新增 merged 目录并不会占用新的磁盘空间。
    • 执行命令 df | grep overlaymount | grep overlay 可查看所有 merged 目录。
  • 综上,/var/lib/docker/overlay2/ 目录下的缓存目录分为两种用途:

    • 镜像层(image layer):供镜像使用,diff 目录的内容静态不变。
    • 容器层(container layer):供容器使用,diff 目录的内容可能变化,包含 merged 目录。