很多人把 Docker 理解为'轻量级虚拟机'。这是一个非常不严谨的说法。
Docker 本身并不是容器技术的创造者，它只是把 Linux 内核已有的能力工程化、产品化。要理解 Docker，必须回到内核层面。
一、容器 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 调度
- 资源限制
都会变得非常清晰。