很多人把 Docker 理解为“轻量级虚拟机”。
这是一个非常不严谨的说法。
Docker 本身并不是容器技术的创造者，它只是把 Linux 内核已有的能力工程化、产品化。要理解 Docker，必须回到内核层面。
本文将从以下几个方面展开：
容器与虚拟机的本质区别
Namespace 隔离机制
Cgroups 资源控制
UnionFS 分层文件系统
Docker Engine 架构解析
Docker 与 containerd 的关系
一、容器 vs 虚拟机：本质差异
虚拟机依赖 Hypervisor，在物理机上虚拟出完整硬件环境，每个虚拟机都运行一个完整的 Guest OS。
典型架构如下：
物理机 → Hypervisor → Guest OS → 应用
而容器架构则是：
物理机 → Host OS → 容器（共享内核）→ 应用
关键差异在于：容器共享宿主机内核。
这带来三点核心影响：
启动速度快（无需启动完整 OS）
资源开销小
隔离强度依赖内核机制
Docker 只是将 Linux 提供的隔离与资源控制能力封装成可操作的接口。
二、Namespace：进程隔离的核心机制
Namespace 是 Linux 内核提供的资源隔离机制。
每个容器运行在独立的 Namespace 中。
常见类型：
-
pid：进程隔离
-
net：网络栈隔离
-
mnt：文件系统挂载点隔离
-
uts：主机名隔离
-
ipc：进程通信隔离
-
user：用户映射隔离
举例说明：
当容器内执行 ps aux 时，你看到的只是当前 pid namespace 下的进程，而不是宿主机全部进程。
这意味着：
容器本质上是一组被隔离的进程，而不是一台“虚拟机器”。
这也是容器轻量化的根本原因。
三、Cgroups：资源控制的底层实现
隔离不等于限制。
Namespace 解决“看不见”，Cgroups 解决“用多少”。
Cgroups（Control Groups）用于限制：
-
CPU 使用率
-
内存使用
-
IO 带宽
-
进程数量
-
网络带宽
当你执行：
docker run -m 512m –cpus=1 nginx
本质上是 Docker 在底层创建了对应的 cgroup 控制组，并将容器进程加入该组。
在 Kubernetes 体系中，容器资源限制依然依赖 Cgroups。
四、UnionFS：镜像分层的关键
Docker 镜像之所以体积小、可复用，是因为采用了分层文件系统。
常见实现包括：
-
aufs（早期）
-
overlay2（主流）
UnionFS 的核心思想：
多层只读层 + 一层可写层
每次 Dockerfile 中执行一条指令，就会生成一个新的镜像层。
例如：
FROM ubuntu
RUN apt update
RUN apt install nginx
会产生多个 layer。
容器运行时：
底层镜像只读
最上层添加一层可写层（copy-on-write）
这使得：
镜像可以复用
传输效率高
构建速度快
但也带来一个问题：
层数过多会导致镜像体积膨胀。
五、Docker Engine 架构解析
Docker 的整体架构可以拆分为三部分：
CLI
REST API
daemon
工作流程如下：
docker run → CLI → REST API → dockerd → containerd → runc
核心组件包括：
-
dockerd：守护进程
-
containerd：容器运行管理
-
runc：真正创建容器的低级运行时
这里涉及一个重要组织：
Open Container Initiative
OCI 制定了容器运行时标准。
Docker 后期将底层运行时抽象为符合 OCI 标准的结构，使得 runc 成为标准实现。
六、Docker 与 containerd 的关系
早期 Docker 是一个大而全的系统。
后来架构拆分：
-
Docker 负责镜像管理、构建、CLI
-
containerd 负责容器生命周期管理
-
runc 负责真正调用内核接口
Kubernetes 在 1.24 版本之后移除了 dockershim，直接对接 containerd。
这说明：
Docker 更像一个“开发者工具平台”，
containerd 才是纯粹的容器运行时。
七、总结：Docker 本质是什么？
Docker 不是虚拟机技术。
它是：
Namespace + Cgroups + UnionFS + OCI 标准 的工程整合。
换句话说：
容器不是一个“迷你操作系统”，
它只是被精细隔离与控制的一组进程。
理解这一点，后面学习：
-
容器网络
-
容器存储
-
Kubernetes 调度
-
资源限制
都会变得非常清晰。
