🌟 前言

在上一篇博文中，我们完成了 Docker 环境的搭建与镜像构建。但 Docker 容器究竟是如何实现“逻辑隔离”和“资源限制”的？为什么镜像构建速度会这么快？

今天我们通过实验，直接穿透 Docker 的表象，去 Linux 内核里寻找 Namespace、Cgroup 和 UnionFS 的真相。

---

一、 Namespace：容器的“隐身术”

容器之所以觉得自己运行在一个独立的环境中，是因为 Linux 内核的 Namespace（命名空间） 为其做了视图隔离。

1. 寻找容器的真实身份

通过 docker inspect，我们可以找到容器在宿主机上的真实进程 PID。

docker inspect -f '{{.State.Pid}}' my-nginx

2. 深度对比：容器 vs 宿主机

我们分别查看容器进程和宿主机 Shell 进程的 Namespace 节点：

# 查看容器 Namespace
sudo ls -l /proc/<容器PID>/ns/

# 查看宿主机 Shell Namespace
sudo ls -l /proc/$$/ns/

🔍 实验观察：

• 不同点：你会发现 pid、net、mnt、uts 等 inode 号完全不同。这意味着容器拥有独立的进程空间、网络堆栈和挂载点。
• 相同点：user 或 cgroup 有时可能相同，这取决于 Docker 的配置模式。

---

二、 Cgroup：给容器加个“紧箍咒”

Namespace 解决了“能看到什么”的问题，而 Cgroup (Control Groups) 解决了“能用多少”的问题。

1. 启动资源受限的容器

我们启动一个限制内存为 128MB，CPU 为 0.5 核 的容器：

docker run -d --name limited-nginx --memory 128m --cpus 0.5 nginx:1.25

2. 内核文件实证

在 Ubuntu 22.04（Cgroup v2）中，我们直接去内核文件系统中读取限制数值：

# 查看内存上限
cat /sys/fs/cgroup/system.slice/docker-<CID>.scope/memory.max

# 查看 CPU 上限
cat /sys/fs/cgroup/system.slice/docker-<CID>.scope/cpu.max

📝 换算小课堂：

• 内存：$128\times 1024\times 1024=134,217,728$ 字节。内核数值精准匹配！
• CPU：配额 (50000) / 周期 (100000) = 0.5 核。

---

三、 UnionFS：镜像构建的“乐高艺术”

Docker 镜像并不是一个巨大的二进制文件，而是由多层只读层堆叠而成的。这就是 UnionFS（联合文件系统） 的魅力。

1. 查看镜像层级 (RootFS)

docker image inspect lab1-flask:v1 | grep -A 20 '"RootFS"'

2. 增量构建实验：v1 vs v2

当我们修改 app.py 的代码后重新构建 v2 镜像，会发生什么？

docker build -t lab1-flask:v2 .

🔍 实验发现：

• 层复用 (Cache)：基础镜像和 WORKDIR 等未改变的层显示为 52 minutes ago（复用 v1 的层）。
• 层更新 (New)：从 COPY app.py 开始，后续所有层的 ID 都更新了（显示为 16 seconds ago）。
• 结论：Docker 只会重新构建发生变动的层及其上层，这极大地提高了开发迭代的效率。

---

四、 总结

通过本次实验，我们实证了 Docker 的三大核心支柱：

1. Namespace：资源视图隔离（逻辑上的独立）。
2. Cgroup：资源配额限制（物理上的约束）。
3. UnionFS：镜像分层存储（存储上的高效）。

掌握了这些底层逻辑，我们在后续面对复杂的 Kubernetes 编排时，才能更加游刃有余！

• 你在做 Cgroup 限制时，有没有遇到过 OOM（内存溢出）的问题？

---

🚀 下一篇预告：从 Docker 到 Kubernetes，Minikube 集群搭建全记录！