mobile wallpaper 1mobile wallpaper 2mobile wallpaper 3mobile wallpaper 4
2144 字
6 分钟
OverlayFS:容器文件系统
2026-04-19

当你 docker pull nginx 下载一个 187MB 的镜像,然后 docker run nginx 启动容器只花了 0.3 秒——为什么这么快?因为 OverlayFS 让多个容器共享同一个镜像的只读层,每个容器只需要一个薄薄的可写层。镜像不需要复制,容器不需要解压,OverlayFS 把多个目录”叠加”成一个统一的文件系统视图。

OverlayFS 是 Linux 内核的联合挂载文件系统,自 3.18 版本合入主线。它是 Docker 和 containerd 的默认存储驱动,也是容器镜像分层复用的底层基础。

容器镜像的分层存储并非一开始就基于 OverlayFS。Docker 早期使用 AUFS(Another UnionFS),由 Junjiro Okajima 于 2006 年开发,它是最早的联合文件系统之一。但 AUFS 一直未能合入 Linux 主线内核,Docker 需要用户手动安装 AUFS 模块,这带来了兼容性噩梦。2014 年,OverlayFS 合入 Linux 3.18 主线内核,Docker 1.12 开始支持 overlay 存储驱动。初版 OverlayFS 只支持一个 lowerdir,而容器镜像通常有多个只读层,Docker 不得不硬链接合并多层——既低效又脆弱。OverlayFS.v2(Linux 4.0+)支持多个 lowerdir,彻底解决了这个问题。此后 overlay2 成为 Docker 和 containerd 的默认存储驱动,AUFS 逐渐退出历史舞台。理解这段演进,有助于理解为什么 OverlayFS 的某些设计看起来”不够优雅”(如 whiteout 用字符设备标记删除而非原生支持),因为这些设计是在”合入主线内核”的约束下做出的妥协。

前置知识#

  • Ch02 Linux Namespace 深入:Mount Namespace 是 OverlayFS 在容器中生效的前提——每个容器有独立的挂载命名空间
  • Ch03 Cgroup v2 深入:Cgroup 的 IO 控制器可以限制 OverlayFS 的磁盘 IO
  • Linux 文件系统挂载:mount -t overlay 命令是使用 OverlayFS 的基本方式
Note

如果你需要补课 Linux 文件系统基础,推荐阅读姊妹系列「从零剖析 Linux 操作系统」中的 VFS 与文件系统 章节。

本章将深入 OverlayFS 的架构设计、whiteout 机制、copy-up 语义,以及容器运行时如何使用 OverlayFS。

一、OverlayFS 基本原理#

1.1 三层结构#

OverlayFS 由三个目录组成:

目录作用读写性
lowerdir底层目录(可以有多个)只读
upperdir上层目录(只有一个)可读写
workdir工作目录(内核内部使用)内部使用
# 手动创建 OverlayFS
mkdir -p /tmp/overlay/{lower1,lower2,upper,work,merged}
# 在 lower 层创建文件
echo "I am base layer" > /tmp/overlay/lower1/base.txt
echo "I am app layer" > /tmp/overlay/lower2/app.txt
echo "I am shared config" > /tmp/overlay/lower1/config.txt
# 挂载 OverlayFS
sudo mount -t overlay overlay /tmp/overlay/merged \
-o lowerdir=/tmp/overlay/lower2:/tmp/overlay/lower1,\
upperdir=/tmp/overlay/upper,workdir=/tmp/overlay/work
# 查看合并后的文件系统
ls /tmp/overlay/merged/
# app.txt base.txt config.txt
# 读取文件(从 lower 层直接读取)
cat /tmp/overlay/merged/base.txt
# I am base layer

1.2 lowerdir 的叠加规则#

当有多个 lowerdir 时,右边的优先级高于左边(即最右边的 lowerdir 最先被查找):

# 两个 lowerdir 都有同名文件
echo "from lower1" > /tmp/overlay/lower1/same.txt
echo "from lower2" > /tmp/overlay/lower2/same.txt
# lower2 优先级更高(在 lowerdir 参数中更靠右)
cat /tmp/overlay/merged/same.txt
# from lower2

1.3 OverlayFS 的查找流程#

flowchart TB LOOKUP["查找文件 /foo"] --> UPPER{upperdir 中<br/>存在 /foo?} UPPER -->|存在| CHECK_WO{是 whiteout<br/>标记文件?} CHECK_WO -->|是| NOT_FOUND["返回 ENOENT<br/>(文件被删除)"] CHECK_WO -->|否| RETURN_UPPER["返回 upperdir/foo<br/>(已修改的版本)"] UPPER -->|不存在| LOWER{lowerdir 中<br/>存在 /foo?} LOWER -->|存在| RETURN_LOWER["返回 lowerdir/foo<br/>(原始版本)"] LOWER -->|不存在| NOT_FOUND style RETURN_UPPER fill:#c8e6c9,stroke:#2e7d32 style RETURN_LOWER fill:#bbdefb,stroke:#1565c0 style NOT_FOUND fill:#ffcdd2,stroke:#c62828

二、OverlayFS 写操作全流程#

读操作直接从 lowerdir 或 upperdir 返回,写操作则涉及 copy-up 和 whiteout 两条路径:

flowchart TB OP{"写操作类型"} OP -->|"修改已有文件"| COPYUP["Copy-Up<br/>1. 从 lowerdir 复制文件到 upperdir<br/>2. 在 upperdir 中修改"] OP -->|"创建新文件"| CREATE["直接写入 upperdir<br/>无需 copy-up"] OP -->|"删除文件"| WHITEOUT["Whiteout<br/>在 upperdir 创建字符设备 0:0<br/>标记 lowerdir 文件为已删除"] OP -->|"删除目录"| OPAQUE["Opaque 目录<br/>在 upperdir 创建同名目录<br/>设置 trusted.overlay.opaque=y"] COPYUP --> MERGED1["merged 视图:看到修改后的内容"] CREATE --> MERGED2["merged 视图:看到新文件"] WHITEOUT --> MERGED3["merged 视图:文件消失"] OPAQUE --> MERGED4["merged 视图:整个目录消失"] style COPYUP fill:#fff3e0,stroke:#e65100 style CREATE fill:#c8e6c9,stroke:#2e7d32 style WHITEOUT fill:#ffcdd2,stroke:#c62828 style OPAQUE fill:#ffcdd2,stroke:#c62828

三、Copy-Up 机制#

3.1 写时复制(Copy-on-Write)#

当修改 lowerdir 中的文件时,OverlayFS 不会直接修改 lowerdir(它是只读的),而是将文件复制到 upperdir,然后在 upperdir 中修改。这就是 copy-up:

# 修改 lower 层的文件(触发 copy-up)
echo "modified" >> /tmp/overlay/merged/base.txt
# 查看 upperdir——文件被复制到这里
ls /tmp/overlay/upper/
# base.txt
cat /tmp/overlay/upper/base.txt
# I am base layer
# modified
# lowerdir 的原始文件不变
cat /tmp/overlay/lower1/base.txt
# I am base layer

3.2 Copy-Up 的触发条件#

操作是否触发 Copy-Up说明
读取文件直接从 lowerdir 读取
修改文件内容整个文件复制到 upperdir
修改文件属性(chmod/chown)元数据复制到 upperdir
创建新文件(直接在 upperdir 创建)不涉及 lowerdir
删除文件(创建 whiteout)见下节
修改目录属性目录元数据复制

3.3 Copy-Up 的性能影响#

Copy-Up 有两个性能问题:

  1. 大文件修改:即使只修改 1 字节,也要复制整个文件
  2. 元数据修改:chmod/chown 也会触发 copy-up
# 性能对比:修改大文件
# 创建一个 1GB 的文件在 lower 层
dd if=/dev/zero of=/tmp/overlay/lower1/bigfile bs=1M count=1024
# 修改 1 字节(触发 copy-up,复制整个 1GB 文件)
time echo "x" >> /tmp/overlay/merged/bigfile
# real 0m0.832s ← copy-up 1GB 文件的时间
# 对比:直接在 upperdir 创建新文件
time dd if=/dev/zero of=/tmp/overlay/merged/newfile bs=1M count=1024
# real 0m0.521s ← 直接写入,无需 copy-up
Warning

在容器中修改大文件会导致 copy-up,消耗大量磁盘 IO 和时间。最佳实践是:大文件应放在 Volume 中,而非容器的可写层。

四、Whiteout 机制#

4.1 删除文件:Whiteout 标记#

当删除 lowerdir 中的文件时,OverlayFS 不能真的删除 lowerdir 的文件(它是只读的),而是在 upperdir 中创建一个 whiteout 标记文件(0 字节的字符设备,major=0, minor=0):

# 删除 lower 层的文件
rm /tmp/overlay/merged/config.txt
# 查看 upperdir——出现了 whiteout 文件
ls -la /tmp/overlay/upper/
# -rw-r--r-- base.txt
# c--------- config.txt ← whiteout 标记(字符设备 0:0)
# whiteout 文件的设备号
stat /tmp/overlay/upper/config.txt
# Device type: 0,0 ← major=0, minor=0 标识 whiteout

4.2 删除目录:Opaque 目录#

删除 lowerdir 中的目录更复杂——需要在 upperdir 中创建同名目录,并设置 opaque 标记(扩展属性 trusted.overlay.opaque=y):

# 创建目录结构
mkdir -p /tmp/overlay/lower1/mydir
echo "file1" > /tmp/overlay/lower1/mydir/file1.txt
echo "file2" > /tmp/overlay/lower1/mydir/file2.txt
# 重新挂载(确保看到最新内容)
sudo mount -t overlay overlay /tmp/overlay/merged \
-o lowerdir=/tmp/overlay/lower2:/tmp/overlay/lower1,\
upperdir=/tmp/overlay/upper,workdir=/tmp/overlay/work
# 删除目录
rm -rf /tmp/overlay/merged/mydir
# 查看 upperdir
ls -la /tmp/overlay/upper/mydir/
# -c--------- file1.txt ← whiteout
# -c--------- file2.txt ← whiteout
# 或者使用 opaque 目录(更高效)
# 设置扩展属性
setfattr -n trusted.overlay.opaque -v "y" /tmp/overlay/upper/mydir

4.3 Whiteout 类型对比#

Whiteout 类型适用场景实现
字符设备 0:0删除单个文件upperdir 中创建 0 字节字符设备
目录内 whiteout删除目录内文件目录内每个文件一个 whiteout
Opaque 目录隐藏整个 lower 目录设置 trusted.overlay.opaque 扩展属性

五、容器中的 OverlayFS#

5.1 Docker 的 OverlayFS 布局#

Docker 使用 OverlayFS 的存储驱动为 overlay2,目录结构如下:

/var/lib/docker/overlay2/
├── <layer-id-1>/ # 镜像第 1 层(base)
│ ├── diff/ # 层内容
│ └── link # 短链接名
├── <layer-id-2>/ # 镜像第 2 层(app)
│ ├── diff/ # 层内容
│ ├── lower # 指向下一层的短链接
│ └── link # 短链接名
├── <container-id>/ # 容器可写层
│ ├── diff/ # upperdir(容器修改)
│ ├── lower # 指向镜像层的短链接
│ ├── merged/ # 合并后的文件系统
│ └── work/ # workdir
└── l/ # 短链接目录
├── <short-id-1> -> ../<layer-id-1>/diff
├── <short-id-2> -> ../<layer-id-2>/diff
└── ...
# 查看容器的 OverlayFS 挂载
mount | grep overlay
# 查看容器的镜像层
docker inspect nginx --format '{{json .RootFS.Layers}}' | python3 -m json.tool
# 查看容器可写层的大小
docker ps -s
# SIZE: 容器可写层大小
# VIRTUAL SIZE: 镜像 + 可写层总大小

5.2 镜像层复用#

OverlayFS 的最大优势是镜像层复用——多个容器共享同一个镜像的只读层:

graph TB subgraph 镜像层["只读镜像层(共享)"] L1["Layer 1: Ubuntu base<br/>72MB"] L2["Layer 2: nginx 包<br/>23MB"] L3["Layer 3: 配置文件<br/>2MB"] end subgraph 容器1["容器 1"] C1["upperdir 1<br/>4KB(日志)"] M1["merged 1"] end subgraph 容器2["容器 2"] C2["upperdir 2<br/>8KB(日志+缓存)"] M2["merged 2"] end subgraph 容器3["容器 3"] C3["upperdir 3<br/>2KB(日志)"] M3["merged 3"] end L1 --> M1 L2 --> M1 L3 --> M1 C1 --> M1 L1 --> M2 L2 --> M2 L3 --> M2 C2 --> M2 L1 --> M3 L2 --> M3 L3 --> M3 C3 --> M3 style 镜像层 fill:#bbdefb,stroke:#1565c0 style 容器1 fill:#c8e6c9,stroke:#2e7d32 style 容器2 fill:#fff3e0,stroke:#e65100 style 容器3 fill:#e1bee7,stroke:#6a1b9a

5.3 容器层叠模型#

读写性内容生命周期
镜像基础层只读OS 基础文件镜像存在期间
镜像中间层只读应用依赖镜像存在期间
镜像顶层只读应用代码镜像存在期间
容器可写层读写运行时修改容器删除即丢失
Volume读写持久化数据独立于容器生命周期

六、容器 OverlayFS 的完整挂载路径#

docker run 到内核 mount 系统调用,OverlayFS 的挂载经过以下步骤:

sequenceDiagram participant CTNRD as containerd participant SNAP as Snapshot Service participant SHIM as containerd-shim participant RUNC as runc init participant KERNEL as Linux 内核 CTNRD->>SNAP: Prepare(containerID, parentSnapshot) SNAP->>SNAP: 创建 upperdir + workdir SNAP-->>CTNRD: 返回 mount 选项 (lowerdir=...:upperdir=...:workdir=...) CTNRD->>SHIM: Create(bundle, rootfs=mounts) SHIM->>RUNC: runc create RUNC->>KERNEL: mount("overlay", merged, "overlay", 0, "lowerdir=...:upperdir=...:workdir=...") KERNEL-->>RUNC: OverlayFS 挂载成功 RUNC->>KERNEL: pivot_root(merged, put_old) Note over RUNC: 容器根文件系统切换完成

七、OverlayFS 与其他存储驱动对比#

7.1 Docker 存储驱动对比#

存储驱动技术性能稳定性适用场景
overlay2OverlayFS默认推荐
fuse-overlayfsFUSE OverlayFSRootless 容器
devicemapperDevice Mapper旧系统兼容
btrfsBtrfs 子卷Btrfs 文件系统
zfsZFS 数据集ZFS 文件系统
vfs纯目录复制调试/测试
# 查看当前存储驱动
docker info | grep "Storage Driver"
# Storage Driver: overlay2
# 修改存储驱动(需要清空 /var/lib/docker)
# 编辑 /etc/docker/daemon.json
{
"storage-driver": "overlay2",
"storage-opts": [
"overlay2.override_kernel_check=true"
]
}

八、OverlayFS 高级特性#

8.1 多层 lowerdir 优化#

Linux 4.0+ 支持 OverlayFS 多层 lowerdir(最多 500 层),避免了深层嵌套挂载:

# 旧方式:嵌套挂载(每 128 层需要一次嵌套)
# mount -t overlay overlay /merged -o lowerdir=l3:l2:l1,upperdir=upper,workdir=work
# mount -t overlay overlay /merged2 -o lowerdir=l6:l5:l4:/merged,upperdir=upper2,workdir=work2
# 新方式:多层 lowerdir(一次挂载)
sudo mount -t overlay overlay /merged \
-o lowerdir=l6:l5:l4:l3:l2:l1,upperdir=upper,workdir=work

8.2 OverlayFS 元数据复制#

Linux 5.11+ 支持 metacopy 特性——当只修改文件元数据(chmod/chown)时,只复制元数据而非整个文件:

# 启用 metacopy(在 daemon.json 中)
# "storage-opts": ["overlay2.metacopy=on"]
# 效果:chmod 只复制元数据(几 KB),而非整个文件

8.3 index 和 xino 选项#

# index: 硬链接保证(同一 lower 文件的硬链接在 merged 中保持一致)
# "storage-opts": ["overlay2.index=on"]
# xino: 扩展 inode 编号(避免 inode 冲突)
# "storage-opts": ["overlay2.xino=on"]

九、动手实践#

9.1 完整的 OverlayFS 容器文件系统模拟#

#!/bin/bash
# 模拟 Docker 的 OverlayFS 容器文件系统
# 1. 创建镜像层
mkdir -p /tmp/container-sim/{layer1,layer2,layer3,upper,work,merged}
# Layer 1: 基础系统
mkdir -p /tmp/container-sim/layer1/{bin,lib,etc,dev,proc,sys,usr,var}
echo "root:x:0:0:root:/root:/bin/bash" > /tmp/container-sim/layer1/etc/passwd
echo "nameserver 8.8.8.8" > /tmp/container-sim/layer1/etc/resolv.conf
# Layer 2: 应用依赖
mkdir -p /tmp/container-sim/layer2/usr/local/{bin,lib}
echo "#!/bin/sh" > /tmp/container-sim/layer2/usr/local/bin/myapp
echo "echo 'Hello from myapp!'" >> /tmp/container-sim/layer2/usr/local/bin/myapp
chmod +x /tmp/container-sim/layer2/usr/local/bin/myapp
# Layer 3: 应用配置
mkdir -p /tmp/container-sim/layer3/etc/myapp
echo "port=8080" > /tmp/container-sim/layer3/etc/myapp/config.ini
# 2. 挂载 OverlayFS(模拟容器启动)
sudo mount -t overlay mycontainer /tmp/container-sim/merged \
-o lowerdir=/tmp/container-sim/layer3:/tmp/container-sim/layer2:/tmp/container-sim/layer1,\
upperdir=/tmp/container-sim/upper,workdir=/tmp/container-sim/work
# 3. 查看合并后的文件系统
echo "=== 合并后的文件系统 ==="
find /tmp/container-sim/merged -type f
# 4. 修改文件(触发 copy-up)
echo "nameserver 1.1.1.1" > /tmp/container-sim/merged/etc/resolv.conf
# 5. 查看可写层
echo "=== 可写层(upperdir) ==="
find /tmp/container-sim/upper -type f
# 6. 删除文件(创建 whiteout)
rm /tmp/container-sim/merged/etc/myapp/config.ini
# 7. 查看 whiteout
echo "=== Whiteout 标记 ==="
ls -la /tmp/container-sim/upper/etc/myapp/
# 8. 清理
sudo umount /tmp/container-sim/merged
rm -rf /tmp/container-sim

9.2 镜像层大小分析#

#!/bin/bash
# 分析 Docker 镜像的层大小
IMAGE=$1
echo "=== 镜像层分析 ==="
echo "层 ID | 大小 | 命令"
echo "------|------|------"
# 获取镜像历史
docker history $IMAGE --no-trunc --format \
'{{.ID}} | {{.Size}} | {{.CreatedBy}}' | head -20
echo ""
echo "=== 总大小 ==="
docker images $IMAGE --format '{{.Size}}'
echo ""
echo "=== 层复用分析 ==="
echo "使用该镜像层的容器:"
docker ps --filter "ancestor=$IMAGE" --format "{{.ID}}\t{{.Names}}"

十、OverlayFS 常见问题与排查#

10.1 可写层膨胀#

容器运行时间越长,可写层可能越大(日志、缓存、临时文件):

# 查看容器的可写层大小
docker ps -s
# SIZE 列显示可写层大小
# 查看可写层中的文件
docker diff mycontainer
# A /app/logs/access.log ← 新增文件
# C /etc/nginx/nginx.conf ← 修改文件
# D /app/cache/old_data ← 删除文件(whiteout)
# 清理可写层中的大文件
docker exec mycontainer find /app/logs -name "*.log" -mtime +7 -delete

10.2 OverlayFS 与 inotify#

OverlayFS 对 inotify 的支持有限——在 merged 目录上的 inotify 监听可能无法正确报告 lowerdir 中的变更:

# inotify 在 OverlayFS 上的已知限制
# 1. lowerdir 中的文件变更可能不会触发 inotify 事件
# 2. copy-up 后的文件变更可以正常触发
# 3. Linux 5.11+ 改善了 inotify 支持
# 解决方案:将需要 inotify 的目录放在 Volume 中
docker run -v /app/data:/app/data myapp

10.3 OverlayFS 性能调优#

# 1. 减少层数(合并 RUN 指令)
# 每条 RUN 一个层
# RUN apt-get update
# RUN apt-get install -y nginx
# 合并
# RUN apt-get update && apt-get install -y nginx
# 2. 使用 BuildKit 缓存挂载
# RUN --mount=type=cache,target=/var/cache/apt \
# apt-get update && apt-get install -y nginx
# 3. 大文件使用 Volume
# docker run -v /data:/app/data myapp
# 4. 查看 OverlayFS 的内核统计
cat /proc/fs/overlay/stats

附、实践:手工挂载 OverlayFS#

本节手工创建 OverlayFS 目录结构并挂载,观察 copy-up 和 whiteout 机制。所有命令需要 root 权限。

附.1 创建 OverlayFS 目录结构#

mkdir -p /tmp/overlay-demo/{lower1,lower2,upper,work,merged}
# 在 lower 层创建文件
echo "I am base layer (lower1)" > /tmp/overlay-demo/lower1/base.txt
echo "I am app layer (lower2)" > /tmp/overlay-demo/lower2/app.txt
echo "I am shared config" > /tmp/overlay-demo/lower1/config.txt
echo "I will be modified" > /tmp/overlay-demo/lower1/modify.txt

附.2 挂载 OverlayFS#

mount -t overlay overlay \
-o lowerdir=/tmp/overlay-demo/lower2:/tmp/overlay-demo/lower1,\
upperdir=/tmp/overlay-demo/upper,workdir=/tmp/overlay-demo/work \
/tmp/overlay-demo/merged

注意lowerdir 中多个目录用 : 分隔,右侧优先级更高。这里 lower2 在前,lower1 在后,所以 lower2 的文件会覆盖 lower1 中同名文件。

附.3 查看合并后的文件#

ls /tmp/overlay-demo/merged/
# app.txt base.txt config.txt modify.txt
cat /tmp/overlay-demo/merged/base.txt
# I am base layer (lower1)
cat /tmp/overlay-demo/merged/app.txt
# I am app layer (lower2)

OverlayFS 将 lower1 和 lower2 的文件”叠加”成一个统一视图。

附.4 Copy-up 测试:修改文件#

# 修改 merged 中的文件
echo "I am modified!" > /tmp/overlay-demo/merged/modify.txt
# 查看 merged 中的内容(已修改)
cat /tmp/overlay-demo/merged/modify.txt
# I am modified!
# 查看 upperdir 中的内容(copy-up 发生在这里)
cat /tmp/overlay-demo/upper/modify.txt
# I am modified!
# 查看 lowerdir 中的原始文件(未变!)
cat /tmp/overlay-demo/lower1/modify.txt
# I will be modified

关键观察:修改文件时,OverlayFS 将文件从 lowerdir 复制到 upperdir(copy-up),然后在 upperdir 中修改。lowerdir 的原始文件始终不变——这正是容器镜像层可以安全共享的原因。

附.5 Whiteout 测试:删除文件#

# 删除 merged 中的 app.txt
rm /tmp/overlay-demo/merged/app.txt
# merged 中已无 app.txt
ls /tmp/overlay-demo/merged/
# base.txt config.txt modify.txt
# upperdir 中出现 whiteout 标记(字符设备 0,0)
ls -la /tmp/overlay-demo/upper/
# c--------- 2 root root 0, 0 May 8 01:33 app.txt
# -rw-r--r-- 1 root root 15 May 8 01:33 modify.txt
# lowerdir 中的原始文件仍在
cat /tmp/overlay-demo/lower2/app.txt
# I am app layer (lower2)

关键观察:删除文件时,OverlayFS 在 upperdir 中创建一个**字符设备(0,0)**作为 whiteout 标记。merged 层看到 whiteout 标记后,会忽略 lowerdir 中的同名文件。lowerdir 的原始文件始终不变。

注意:实验结束后清理:umount /tmp/overlay-demo/merged && rm -rf /tmp/overlay-demo

十一、本章小结#

上一章剖析了Cgroup v2 的资源控制。

概念说明关键点
lowerdir只读底层目录可多层,右优先
upperdir可写上层目录容器修改存储于此
workdir工作目录内核内部使用
copy-up写时复制修改 lower 文件时触发
whiteout删除标记字符设备 0:0
opaque目录隐藏扩展属性标记
Note

OverlayFS 是容器快速启动和镜像层复用的关键。理解 copy-up 和 whiteout 机制,有助于优化 Dockerfile(减少层数、避免大文件修改)和排查存储问题(可写层膨胀、性能下降)。

支持与分享

如果这篇文章对你有帮助,欢迎支持作者或分享给更多人

OverlayFS:容器文件系统
https://blog.souloss.com/posts/container-runtime/overlayfs-container-filesystem/
作者
Souloss
发布于
2026-04-19
许可协议
CC BY-NC-SA 4.0

部分信息可能已经过时

相关文章 智能推荐
1
容器存储
容器运行时 容器的可写层随容器删除而丢失,数据持久化需要 Volume。一网打尽容器存储的完整方案——Volume(绑定挂载/命名卷/tmpfs)、存储驱动(overlay2/devicemapper/btrfs)、CSI(容器存储接口)插件机制,以及 Kubernetes 的 PV/PVC/StorageClass 体系——从「docker run -v」到「理解容器存储的每一条挂载规则」。
2
容器网络
容器运行时 容器网络的核心问题是——隔离的 Network Namespace 如何与外部通信?详细解读 veth pair(虚拟网卡对)、bridge(虚拟网桥)、iptables/NAT(地址转换)、CNI(容器网络接口)的完整链路,以及 Docker 的四种网络模式和 Kubernetes 的 Pod 网络模型——从「容器能 ping 通外网」到「理解每一条网络规则」。
3
容器在 Kubernetes 中
容器运行时 深入容器在 Kubernetes 中的运行机制——CRI 接口、Pod Sandbox 创建、多容器模式、Init Container、Sidecar 注入,以及 kubelet 如何通过 CRI 与容器运行时交互。
4
综合实战:构建一个迷你容器运行时
容器运行时 综合实战——用 Go 从零构建一个迷你容器运行时——实现 Namespace 隔离(PID/Mount/UTS/IPC/Network)、Cgroup 资源限制(CPU/内存)、OverlayFS 分层文件系统、OCI Bundle 解析,最终实现一个能运行容器的 minirunc。将前 15 章的知识融会贯通,从「理解原理」到「动手实现」。
5
Wasm 容器:WasmEdge/WASI
容器运行时 WebAssembly(Wasm)正在从浏览器走向服务器——WASI(WebAssembly System Interface)定义了 Wasm 访问操作系统的标准接口,WasmEdge/runwasi 等运行时让 Wasm 模块可以作为容器运行。详细解读 Wasm 容器的架构、WASI 接口、与 OCI 的集成、与 Linux 容器的对比——从「Wasm 只能在浏览器运行」到「Wasm 是下一代容器运行时」。