← blog/系统底层/Read in English →

剥开 Docker 的画皮：从 Linux 系统调用到硬件虚拟化底层的深度解析

发布于 2026-07-17

引言：打破“轻量级虚拟机”的谎言

如果在面试中被问到“什么是 Docker？”，90% 的开发者会脱口而出：“它是一个轻量级的虚拟机”。

这可能是整个云计算时代最大的谎言。

真相是：在 Linux 内核的源码中，根本不存在“容器”这个概念，也没有任何一个系统调用叫做 create_container。 所谓的容器，不过是一个被施了障眼法的普通 Linux 进程。今天，我们将彻底打破对 Docker 的表面认知，一路下钻到 Linux 源码、页缓存（Page Cache），最后击穿操作系统，直达 CPU 硬件虚拟化的最底层。

第一部分：造梦空间 —— 容器的三大底层支柱

如果容器只是个进程，它是怎么骗过我们，让我们以为它是一台独立机器的？全靠内核提供的“三板斧”。

1. Namespaces（平行宇宙）

平时我们在 Linux 中创建子进程用的是 fork()，但容器引擎用的是更底层的 clone() 系统调用。当传入特殊的标志位（如 CLONE_NEWPID、CLONE_NEWNS）时，生出来的子进程就被戴上了“VR 眼镜”。 在它的视角里，自己就是 PID 1，拥有独立的网卡和主机名，完全不知道宿主机其他进程的存在。

2. Cgroups（紧箍咒）

有了独立空间还不够，进程可能会无限吃内存。很多人以为限制资源需要复杂的 API，但 Linux 的哲学是“一切皆文件”。 限制资源根本不需要特定的系统调用，容器引擎只需在宿主机的虚拟文件系统（VFS）中创建一个目录，把进程 PID 和内存上限数字写进去，内核就会自动在底层进行死扣：

mkdir /sys/fs/cgroup/memory/docker/my-container
echo 512000000 > /sys/fs/cgroup/memory/docker/my-container/memory.limit_in_bytes
echo $$ > /sys/fs/cgroup/memory/docker/my-container/cgroup.procs

3. UnionFS（千层饼的秘密）

容器怎么拥有独立的文件系统？底层利用了 Overlay2 等联合文件系统。它将多层只读镜像叠加，最上面加上可写层。最后，容器引擎调用极其暴力的 pivot_root() 系统调用。它不仅把容器的根目录指向了新的挂载点，还把宿主机原来的根目录彻底卸载。 做完这一步，容器进程彻底断了回家的路，宿主机系统在它的世界里永远消失了。

第二部分：撕开裂缝 —— docker exec 的硬核真相

如果你运行了 docker exec -it my-container bash，你猜这个 bash 是由容器里的主进程（比如 Python）创建出来的吗？

绝对不是。它们毫无血缘关系，只是“合租室友”。

setns() 魔法穿梭

底层的 runc 工具，会在宿主机上通过标准的 open() 系统调用，打开目标 Python 进程暴露在 /proc/<PID>/ns/ 下的各个魔法文件句柄。接着，核心主角 setns(fd, 0) 登场。 这个系统调用能让当前进程强行“寄生”到目标进程的平行宇宙中。穿越完成后，runc 调用 fork() 孵化子进程，再通过 execve() 将自己变身为 bash。这正是为什么在容器里看，Python 是 PID 1，bash 是 PID 2，但它们的父进程 PPID 全都是 0。

上帝的局限性：User Namespace

为什么容器里的 root 动不了宿主机的核心文件？ Linux 内核将权限细分为了 Capabilities。内核魔改了底层的权限校验逻辑 ns_capable()。当容器 root 尝试修改宿主机文件时，内核不仅检查它有没有上帝特权，还会比对特权的生效范围。一旦发现越界，瞬间没收特权，打回普通用户原型。

第三部分：物理复用 —— 内存与存储的极致榨取

如果你启动了 10 个 Ubuntu 容器，内存里会有 10 份 Bash 程序的代码吗？不会，这就是 Docker 极其省资源的底层秘密。

Page Cache 与 Inode

当文件被读取到内存时，Linux 内核通过 address_space 结构（底层由高效的 XArray 树维护）将其缓存在 Page Cache 中。映射的唯一标识是文件的 Inode（物理指针）。 因为 OverlayFS 的存在，如果 10 个容器没有修改底层的 Ubuntu 文件，它们读取的其实是同一个只读层、同一个 Inode 的文件。内核非常聪明，当遇到同一个 Inode 时，会通过 mmap 机制把这 10 个进程的虚拟内存映射到同一块物理内存上。Docker 一行代码都没写，就“白嫖”了操作系统的内存共享魔法。

第四部分：跨越边界 —— 从跨架构到真正的虚拟化

如果在 x86 机器上跑 ARM 容器，它是怎么运行的？

内核中有一个神仙特性叫 binfmt_misc。当内核发现一个无法执行的 ARM 架构 ELF 文件时，它不会报错，而是将其拦截，并转交给提前注册好的翻译器（如 QEMU 或 Apple 的 Rosetta 2 for Linux），将 ARM 指令实时翻译为 x86 指令丢给物理 CPU。

但这里有个核心痛点：macOS 和 Windows 的内核完全不同，没有 Namespaces 和 Cgroups 怎么办？ 答案只能是：启动一台真正的 Linux 虚拟机（VM）。这就引出了终极的技术边界。

第五部分：虚拟化的尽头是融合 —— 深度解析 WSL 2

传统的虚拟机性能极差，因为软件模拟硬件太慢。现代 Hypervisor（如 Hyper-V, KVM）使用的是硬件辅助虚拟化。

两阶段 MMU 与 VM Exit

物理 CPU 内部有 VMX Root（宿主）和 Non-root（客户）模式。虚拟机 OS 运行在真实的硬件思路上。当它尝试越权时，硬件会瞬间产生 VM Exit（陷入），把控制权交还给 Hypervisor。 而内存隔离靠的是硬件级别的两阶段页表（如 Intel EPT 或 ARM 架构 EL2 的 VTTBR_EL2 寄存器）。虚拟机内部做一次地址转换，硬件 MMU 在底层再做一次转换，实现了物理级别的绝对隔离。

WSL 2：披着原生外衣的 UVM

我们在 Windows 上用的 Docker，底层是 WSL 2（一个高度定制的实用工具虚拟机 UVM）。 它为什么不卡？

  1. 闪电启动： 没有 BIOS 和 GRUB，Hyper-V 直接拉起内核。
  2. 内存动态伸缩： 通过 Page Reporting 机制，Linux 用完内存立刻主动还给 Windows。
  3. 9P 协议虫洞： 挂载宿主机目录时，底层通过 9P 协议和内存总线（VMBus）极速通信，直接打破了操作系统的壁垒。

结语：抽象的艺术

行文至此，容器与虚拟机的界限已经非常清晰：

  • 容器（Docker）： 是对 操作系统 API（系统调用、VFS） 的一层隔离抽象。
  • 虚拟机（Hypervisor）： 是对 底层硬件（指令集、MMU） 的一层隔离抽象。

技术的演进就是不断叠加抽象的过程，但只有当我们具备了击穿这些抽象、直视内核与底层硬件运作规律的能力时，我们才真正拥有了解决一切性能瓶颈与诡异 Bug 的上帝视角。