Docker 的底层机制：容器并非独立实体
尽管 Docker 的使用已相当普及，但其内部运作机制仍有许多反直觉之处。深入剖析可以发现，Docker 的实现方式与大众认知存在显著差异。
容器本质上是受限进程
与虚拟机不同，容器并没有独立的内核。容器本质上只是运行在主机内核上的、具有特殊限制条件的进程。用户甚至可以直接在宿主机的 /proc 文件系统中找到对应的进程信息。
“容器”概念的技术解构
Linux 内核中并不存在名为“容器”的原生功能。所谓的容器，实际上是多个 Linux 内核特性的组合应用：
- Namespace（命名空间）：隔离主机与容器可见的资源视图。
- Cgroups（控制组）：限制容器对 CPU、内存等资源的使用。
- 网络虚拟化：通过复杂的网络配置实现隔离与通信。
镜像处理与根目录切换
容器镜像本质上只是一个文件。Docker 通过调用 chroot 或 pivot_root 系统调用，将该文件挂载为容器进程的新根目录。以命令 docker run -it --rm ubuntu /bin/bash 为例，其执行流程包括：
- 从 Docker Hub 下载 Ubuntu 镜像。
- 将镜像解压并放置于特定存储位置。
- 基于该文件系统启动受限进程。
Runc 运行时与 Go 语言的设计挑战
Docker 的核心容器运行时 Runc 采用 Go 语言编写。Go 原生支持多线程运行时，这一特性虽然强大，但在容器运行时场景下带来了一定复杂性。许多 Linux 系统调用要求在单线程环境中执行，因此 Runc 不得不引入 C 语言模块来处理相关逻辑。
此外，Runc 不直接使用传统的 fork() 系统调用。为了绕过某些限制，Runc 通过执行 /proc/self/exe 并传递特殊命令行参数，以子进程的方式模拟 fork 行为，进而设置资源限制并执行目标进程。
Root 权限依赖与安全性考量
Docker 守护进程通常需要以 root 权限运行。这是因为许多用于构建容器的 Linux 内核 API 需要特权访问。对于 macOS 用户而言，由于底层架构差异，这一细节容易被忽略。目前，除了网络栈部分外，非 root 容器运行时的发展取得了一定进展，但若要在无 root 环境下运行，往往需要在用户空间重新实现完整的网络堆栈，这增加了技术实现的难度。
自研工具作为学习路径
开发简易的容器运行时是理解 Docker 底层原理的有效途径。通过亲手实现类似工具，开发者能够更清晰地掌握 Namespace、Cgroups 以及文件系统挂载等核心概念的实际应用场景。
