【Docker】2.Docker 核心原理与架构

文章目录

[1. 什么是虚拟化、容器化](#1. 什么是虚拟化、容器化)
- [1.1 虚拟化](#1.1 虚拟化)
- [1.2 容器化](#1.2 容器化)
[2. 为什么要虚拟化、容器化？](#2. 为什么要虚拟化、容器化？)
- [2.1 极致的资源利用率与响应速度](#2.1 极致的资源利用率与响应速度)
- [2.2 环境标准化（一次构建，随处运行）](#2.2 环境标准化（一次构建，随处运行）)
- - [2.2.1 为什么这对于现代开发至关重要？](#2.2.1 为什么这对于现代开发至关重要？)
- [2.3 资源弹性伸缩](#2.3 资源弹性伸缩)
- [2.4 差异化环境提供](#2.4 差异化环境提供)
- [2.5 沙箱安全](#2.5 沙箱安全)
[3. Docker 核心原理与架构](#3. Docker 核心原理与架构)
- [3.1 虚拟机 vs Docker](#3.1 虚拟机 vs Docker)
- - [3.1.1 虚拟机架构：完整的"重量级"模拟](#3.1.1 虚拟机架构：完整的“重量级”模拟)
  - [3.1.2 Docker 架构：轻量级的"进程隔离"](#3.1.2 Docker 架构：轻量级的“进程隔离”)
- [3.2 Namespace 与 Cgroups 原理](#3.2 Namespace 与 Cgroups 原理)
- - [3.2.1 Namespace](#3.2.1 Namespace)
  - - [为什么 Namespace 如此高效？](#为什么 Namespace 如此高效？)
  - [3.2.2 Cgroups 的配额制](#3.2.2 Cgroups 的配额制)
  - [3.2.3 Namespace 与 Cgroups](#3.2.3 Namespace 与 Cgroups)
- [3.3 从 LXC 到 Docker 的进化史](#3.3 从 LXC 到 Docker 的进化史)
- - [3.3.1 LXC：容器技术的"开荒者"](#3.3.1 LXC：容器技术的“开荒者”)
  - - [3.3.1.1 为什么 Docker 早期要依赖 LXC？](#3.3.1.1 为什么 Docker 早期要依赖 LXC？)
    - [3.3.1.2 历史的转折：从"借用"到"自立门户"](#3.3.1.2 历史的转折：从“借用”到“自立门户”)
    - [3.3.1.3 自立门户：libcontainer 的诞生](#3.3.1.3 自立门户：libcontainer 的诞生)
    - [3.3.1.4 现代架构：runC 与 OCI 标准](#3.3.1.4 现代架构：runC 与 OCI 标准)
    - [3.3.1.5 总结](#3.3.1.5 总结)

1. 什么是虚拟化、容器化

1.1 虚拟化

是指通过虚拟化技术将一台计算机虚拟为多台逻辑计算机。在一台计算机上同时运行多个逻辑计算机，每个逻辑计算机可运行不同的操作系统，并且应用程序都可以在相互独立的空间内运行而互不影响，从而显著提高计算机的工作效率。
传统的虚拟化技术（如 VMware, KVM）主要作用在硬件层 和操作系统层 之间。它通过一个名为 Hypervisor（虚拟机管理器）的软件，在物理硬件上"伪造"出多套虚拟硬件。

1.2 容器化

容器化 (Containerization)：又称操作系统层虚拟化。它通过"伪造"操作系统的接口，将应用程序及其所需的库文件封装在一个独立的单元中。容器之间共享同一个宿主机内核，因此极其轻量。
容器技术（如 Docker）则更进一步，它作用在操作系统层 和程序库层 之间。容器不再伪造硬件，而是利用 Linux 内核的隔离特性（Namespace 和 Cgroups），直接在宿主机内核上划分子空间。
三大时代：

物理机时代：一台机器一个系统，资源浪费严重，扩展困难。

虚拟机时代 ：通过 Hypervisor 实现资源隔离，提高了利用率，但 Guest OS 带来了沉重的额外开销。

容器时代 ：舍弃了冗余的 Guest OS，直接共享内核，实现了秒级启动和极高的运行效率。

2. 为什么要虚拟化、容器化？

2.1 极致的资源利用率与响应速度

在物理机或虚拟机时代，由于每个应用都需要绑定一个完整的操作系统，资源的开销是非常庞大的。而容器化通过共享内核的方式，实现了资源利用的"高密度"。

高密度部署 ：容器极其轻量（通常只有几十 MB），这意味着在同样的硬件资源下，你可以运行比虚拟机多出数倍的容器实例。

秒级启动 ：因为容器不需要像虚拟机那样经历漫长的硬件自检和内核加载过程（OS Boot），它本质上只是宿主机上的一个进程。启动应用就像打开一个 App 一样快。虚拟机需要分钟级的耗时，容器只需要毫秒级的耗时。

2.2 环境标准化（一次构建，随处运行）

作为开发者，你一定听过或说过："这段代码在我机器上运行得好好的啊！"

这就是典型的环境不一致问题。

由于开发、测试和生产环境的操作系统版本、依赖库甚至配置文件的细微差别，往往会导致难以排查的 Bug。
Docker 通过**镜像（Image）**技术，将应用程序及其运行所需的全部依赖（包括二进制文件、库、配置文件等）打包在一起。这就像是给你的程序发了一个"集装箱"，无论这个集装箱被运到哪里，内部的物品和环境都是完全一样的。
实现效果：

消除环境差异：确保开发环境、测试环境和生产环境的绝对统一。

快速分发与回滚：如果上线版本有问题，只需一行命令拉取旧版镜像即可实现快速回滚。

2.2.1 为什么这对于现代开发至关重要？

在追求"持续交付"的今天，软件发布的频率从月级缩短到了天级甚至小时级。

只有实现了资源的高效调度 和环境的标准化，我们才能在复杂的分布式系统中保持敏捷性，而不至于陷入维护环境的泥潭。

2.3 资源弹性伸缩

在互联网业务中，流量往往像潮汐一样有高峰和低谷。

比如电商在大促期间流量会瞬间暴涨，而平时则相对平稳。容器化让这种"动态调整"变得轻而易举。
场景模拟：双 11 扩容

自动扩容 ：当监控到 CPU 负载过高时，系统可以瞬间启动 100 个新的容器实例来分担压力。

快速收缩：活动结束后，只需几秒钟即可销毁多余容器，释放资源以节省成本。

2.4 差异化环境提供

在同一个开发团队中，不同的项目可能依赖完全不同的软件栈。

比如项目 A 需要 Ubuntu + Python 2，而项目 B 需要 CentOS + Python 3。在物理机上同时安装这些环境往往会发生冲突。

多版本共存：容器化允许你在同一台宿主机上，通过不同的容器运行完全互斥的环境，互不干扰。

轻量级隔离：无需为每个环境购买昂贵的物理机或配置沉重的虚拟机。

2.5 沙箱安全

对于不安全或不稳定的软件，我们最担心它会"搞坏"整个操作系统。容器提供了一个独立的运行空间（沙箱），确保风险被锁定在容器内部。
危险操作示范：

如果在容器内执行 rm -rf /*（格式化命令），它只会破坏当前容器的文件系统，而不会影响宿主机或其他运行中的容器。
注意：

虽然容器提供了进程级的隔离，但由于共享内核，其安全性略逊于完全硬件隔离的虚拟机。在处理极高安全需求时，需配合安全策略使用。

3. Docker 核心原理与架构

3.1 虚拟机 vs Docker

3.1.1 虚拟机架构：完整的"重量级"模拟

虚拟机通过 Hypervisor（虚拟机管理程序） 在物理硬件上虚拟出一套完整的硬件环境。在每个虚拟机内部，都必须安装一个完整的 Guest OS（客户操作系统）。

层级结构 ：硬件 ➔ 宿主机 OS ➔ Hypervisor ➔ Guest OS ➔ 库/依赖 ➔ 应用。

资源消耗 ：由于每个 VM 都有自己的内核，即使只运行一个简单的 Hello World 程序，也要加载几百 MB 甚至几个 GB 的操作系统文件。

启动速度 ：启动过程包含硬件自检和完整的 OS 引导，通常需要几分钟。

3.1.2 Docker 架构：轻量级的"进程隔离"

与虚拟机不同，Docker 容器不携带自己的内核 。它直接利用宿主机的内核，通过 Docker Engine 进行调度和隔离。
Docker Engine (Docker 引擎)：

它是容器的"管理者"，负责在宿主机操作系统之上创建、运行和管理容器。它不像 Hypervisor 那样去模拟硬件，而是利用 Linux 内核的隔离特性（如 Namespace 和 Cgroups）来确保容器间的独立性。

虚拟机与Docker容器架构层级对比：

这种架构上的根本差异，直接导致了性能上的巨大鸿沟：

启动速度 ：Docker 只是启动一个受限的进程，实现"秒级"甚至"毫秒级"启动；而 VM 需要启动整个 OS，需要"分钟级"。

资源利用 ：Docker 引擎占用资源极低，一台普通服务器能跑成百上千个容器，但可能只能跑十几个虚拟机。

封装程度 ：VM 封装的是整个操作系统，而 Docker 封装的是应用代码及其依赖环境。

3.2 Namespace 与 Cgroups 原理

如果把 Docker 比作一座宏伟的大厦，那么支撑它的有两大技术支柱：Namespace（命名空间） 和 Cgroups（控制组）

Namespace（命名空间） ：负责隔离。它负责给进程"蒙上眼睛"，让进程觉得自己身处一个独立的世界。

Cgroups（控制组） ：负责限制。它负责给进程"戴上枷锁"，规定它最多能用多少 CPU 和内存。

3.2.1 Namespace

Namespace (命名空间)：

它是 Linux 内核用来隔离内核资源的方式。通过将进程的相关资源指定在特定的 Namespace 中，可以让进程只能看到属于自己的那一部分资源，而完全感知不到其他进程的存在。

Namespace 就像是为每一个容器搭建了一个"楚门的世界"。在这个"摄影棚"里，容器（楚门）看到的街道、网络、进程列表全是他自己的。即使外面（宿主机）有成千上万个进程在跑，只要 Namespace 没开放权限，容器就永远觉得自己是这片天地的主宰。
Linux 内核提供了多种不同类型的 Namespace，它们分别负责不同维度的隔离，共同构建了一个完整的容器运行环境：

PID Namespace ：让容器拥有独立的进程 ID。比如容器里的 1 号进程，在宿主机上其实可能是一个几万号的普通进程。

Network (Net) Namespace ：提供独立的网络栈（网卡、IP、端口）。这就是为什么多个容器能同时监听 80 端口而互不冲突的原因。

Mount (MNT) Namespace：隔离挂载点。容器看到的根目录 / 是属于它自己的，看不到宿主机的文件系统。

UTS Namespace ：让容器拥有独立的主机名 (Hostname) 和域名。

IPC Namespace：隔离进程间通信（如消息队列）。

User Namespace ：让容器内的 root 用户不等于宿主机的 root 用户，增强安全性。

为什么 Namespace 如此高效？

这种"视图隔离"不需要像虚拟机那样去伪造一套硬件。它只是在内核调用时，通过参数过滤了一下信息。

Namespace 改变的是进程的视角，而不是它运行的实体。这正是 Docker 能够实现秒级启动的原因------它只是启动了一个被"蒙住眼睛"的普通进程，而不是启动一整个操作系统。

3.2.2 Cgroups 的配额制

Cgroups (Control Groups, 控制组)：

它是 Linux 内核提供的一种机制，可以根据需求把一系列系统任务及其子任务整合到按资源划分等级的不同组内，从而为系统资源管理提供一个统一的框架。

简单来说，Cgroups 的作用就是限制、记录、隔离 进程组所使用的物理资源（如 CPU、内存、磁盘 I/O 等）。
以上述楚门的世界举例：如果楚门是饕餮转世，一个人可以把一个世界的食物都吃掉（占用 100% CPU），或者搬空了公共水库（耗尽所有内存），即便他看不见别人，世界最终也会因为资源枯竭而崩塌。
在 Linux 中，Cgroups 是通过一系列子系统来实现精细化控制的：

cpu ：限制进程可使用的 CPU 时间片分配。

memory：限制任务的可用内存上限，并自动生成资源占用报告。

blkio ：对块设备（如硬盘）的输入/输出（I/O）进行限制。

cpuset ：为任务分配独立的 CPU 核心（在多核系统中非常有用）和内存节点。

pids ：限制 cgroup 中允许创建的进程总数，防止"分身术"耗尽系统资源。

3.2.3 Namespace 与 Cgroups

这对搭档的配合非常默契，它们共同完成了"容器"的定义：

Namespace（隔离） ：解决了安全性 和冲突问题。它让容器拥有独立的主机名、网络和 PID，让应用觉得自己在独占系统。

Cgroups（限制） ：解决了稳定性 和公平性问题。它确保没有哪个"霸道"的容器可以抢走宿主机的全部家当。
当你执行 docker run 时，Docker 引擎实际上是在后台调用内核 API，先用 Namespace 创建一个"隔离的房间"，再用 Cgroups 给这个房间挂上"电表和水表"。这种不模拟硬件、只做内核标记的方式，正是 Docker 极致轻量化的核心秘密。

3.3 从 LXC 到 Docker 的进化史

3.3.1 LXC：容器技术的"开荒者"

LXC (Linux Containers)：

它是 Linux 内核容器功能的一个用户空间接口。简单来说，LXC 是最早一批真正把 Namespace 的隔离能力和 Cgroups 的限制能力封装在一起，并提供给用户使用的工具集。

在 Docker 诞生的早期（0.9 版本之前），Docker 自身并不直接操作内核，而是像一个"翻译官"一样，把用户的指令转发给 LXC，由 LXC 去调用底层的隔离和限制功能。
形象类比：手动工具箱 vs 自动化工厂

LXC 就像是一个"手动工具箱"：它里面有各种扳手和螺丝刀（命令工具和模板），虽然你能用它盖起一座房子（容器），但你需要手动去拧每一颗螺丝，数据迁移和大规模部署非常麻烦。

Docker 就像是一座"自动化工厂" ：它早期借用了 LXC 的工具箱，但它加上了流水线（镜像技术）和物流中心（Docker Hub）。它不再要求你手动盖房子，而是让你直接下载"精装房模块"，一键落地。

3.3.1.1 为什么 Docker 早期要依赖 LXC？

降低门槛 ：Namespace 和 Cgroups 的内核 API 非常底层且复杂，LXC 提供了第一层封装，让开发者能通过简单的命令创建容器。

验证可行性 ：LXC 证明了在 Linux 上不使用笨重的虚拟机（VM），仅靠内核特性就能实现高效隔离。

Docker 的起步 ：Docker 最初被定义为"LXC 的二次封装发行版"，它的核心贡献在于引入了**镜像（Image）**的概念，解决了"环境一致性"这个痛点。

3.3.1.2 历史的转折：从"借用"到"自立门户"

虽然 LXC 很好用，但它毕竟不是 Docker 亲生的，存在跨平台兼容性差、管理不统一等问题。随着 Docker 的壮大，它开始觉得这个"手动工具箱"束缚了自己的手脚。

3.3.1.3 自立门户：libcontainer 的诞生

虽然 LXC 帮 Docker 搞定了早期的底层隔离，但 Docker 团队发现，过度依赖外部工具包会导致跨平台兼容性（不同发行版的 LXC 版本不一）和开发灵活性受限。

于是在 0.9 版本中，Docker 引入了 libcontainer 。这是 Docker 团队用 Go 语言编写的、直接与 Linux 内核交互的模块，它彻底取代了 LXC，成为了 Docker 的默认执行驱动。

3.3.1.4 现代架构：runC 与 OCI 标准

随着容器技术的爆发，厂商们意识到如果不统一标准，市场会陷入混乱。于是 OCI (Open Container Initiative) 标准应运而生。Docker 顺应潮流，将 libcontainer 进一步重构并捐赠给了社区，这就是现在大名鼎鼎的 runC。
runC & containerd：

runC ：一个轻量级的工具，只负责按照 OCI 标准去创建和运行容器。它就像是容器的"启动马达"。

containerd ：一个守护进程，负责管理容器的生命周期（推送/拉取镜像、管理存储和网络等）。它调用 runC 来干活。
形象类比：从"一体化机床"到"乐高积木"

早期的 Docker 像是一个大型的一体化机床，坏了一个零件可能整个都要检修。而现代 Docker 架构则变成了**"乐高积木"**：

标准化接口 ：只要符合 OCI 这个"积木凸点"标准，你可以用 Docker 的积木，也可以用其他的积木（如 Kubernetes 的运行时）。

解耦的意义 ：这种解耦让系统极其稳定。即使 Docker 守护进程本身崩溃了，已经在运行的容器（由 runC 启动）也不会立刻死掉，极大地提高了生产环境的容错率。

3.3.1.5 总结

Docker 的进化史，本质上是一个**"从依赖工具，到成为工具，再到制定标准"**的过程：

LXC 时代 ：借用别人的手动工具箱（0.9 之前）。

libcontainer 时代 ：开发自己的专用生产线（0.9 - 1.10）。

OCI / runC 时代：制定全球统一的工业生产模具（现代版本）。