【AI 总结】How does Docker ACTUALLY work?

How does Docker ACTUALLY work? The Hard Way: A Comprehensive Technical Deep Diving | AI 总结

一、Docker 基础认知

定义：Docker 是一个开源平台，用于在容器内开发、交付和运行应用程序，借助容器化技术简化应用的创建、分发和运行流程，实现应用与基础设施的分离，以标准化方式打包和部署软件，缩短代码编写到生产运行的时间差
容器兴起背景：过去软件多为单体架构，更新频率低、部署困难且难以及时响应新功能需求，微服务架构应运而生，但微服务数量增多带来了运维工作量大、管控难、硬件成本高的问题，容器技术由此得到发展，可在同一机器上运行多个微服务且无需为每个服务准备单独环境，并实现服务间隔离
容器与虚拟机（VM）对比：虚拟化技术通过虚拟机在硬件抽象层运行多个操作系统，每个虚拟机包含完整操作系统、应用及所有依赖，存在管理配置复杂、硬件资源浪费、成本高的问题；而 Linux 容器技术可在同一机器运行多个微服务，无需单独环境且实现隔离，更轻量、高效

二、Docker 架构

高层架构：采用客户端 - 服务器模型，核心组件包括 Docker 客户端、Docker 守护进程（Docker Engine）、Docker Desktop 和 Docker Registry
- Docker 客户端：命令行工具、API 或图形界面，用户通过其发出命令并管理 Docker 资源，将请求发送给 Docker 守护进程
- Docker 守护进程：运行在主机上的后台服务和长期进程，负责运行和管理容器及容器镜像，处理客户端请求，与主机操作系统内核交互，利用内核特性实现容器化、网络和存储功能
- Docker Desktop：适用于 Mac、Windows 或 Linux 环境的易安装应用，支持构建和共享容器化应用及微服务，可通过 Docker 扩展集成第三方工具增强功能
- Docker Registry：存储容器镜像的仓库，Docker Hub 是默认的公共仓库
低层架构
- Docker Desktop 借助虚拟机提供必要的 Linux 环境
- 在虚拟机内，Docker 客户端通过 RESTful API 与 Docker 守护进程（dockerd）交互
- 以 containerd 作为容器运行时，containerd 是行业标准运行时，可管理容器生命周期，还可通过插件扩展功能
- 启动容器时，containerd 的 shim（runtime v2）API 作为 containerd 与 OCI 运行时的中间层
- OCI 运行时负责设置容器的命名空间、控制组（cgroups）、权限等，利用 Linux 内核特性实现容器隔离、资源控制和安全保障

三、关键组件详解

Docker CLI：与 dockerd 守护进程交互的命令行工具，支持标准 UNIX 风格参数，多数命令有长短两种形式，相关命令可在对应仓库查看
Docker Registry：存储和分发容器镜像的服务，可集中式或分布式部署，除 Docker Hub 外还有 OpenRegistry 等去中心化仓库，另有 crane、skopeo、regctl 等工具可与 Registry API 交互
BuildKit：并发、缓存高效且与 Dockerfile 无关的构建工具包，集成后可提升性能、存储管理、功能和安全性，通过设置环境变量或配置文件启用，包含 buildctl 和 buildkitd 两个主要组件，支持多平台构建和生成 SLSA Provenance（软件工件供应链级别，一种保障软件完整性和安全性的框架）
Buildx：Docker CLI 插件，基于 Moby BuildKit 扩展 docker 命令功能，默认启用 BuildKit，支持创建限定范围的构建实例、并发多节点构建，还提供多种构建 OCI 兼容容器镜像的替代工具，如 ko、apko 等
Container Runtime Interface (CRI) ：使 Kubernetes 能使用任何符合 CRI 标准的运行时，Kubernetes 的 kubelet 组件依赖容器运行时，常见的符合 CRI 标准的运行时包括 containerd（CNCF 毕业项目）、CRI-O（CNCF 孵化项目）等，Kubernetes 在 v1.20 后弃用 Docker 作为容器运行时，推荐使用 containerd，过去 Kubernetes 通过 dockerd 实现 CRI 支持，后续 dockerd 不再维护，Mirantis 和 Docker 合作将其作为独立开源项目维护
Containerd：注重简洁、稳健和可移植性的行业标准容器运行时，可管理容器完整生命周期，通常嵌入更大系统而非直接供开发者或终端用户使用，有 crictl、nerdctl、ctr 等相关命令行工具，crictl 用于容器运行时故障排查，与 Docker CLI 类似但功能有限；nerdctl 是兼容 Docker 的 containerd CLI，支持多种高级功能；ctr 是 containerd 的原生命令行客户端
容器镜像：不可变的静态文件，包含可执行代码，可在任意环境一致部署并运行隔离进程，具有父子关系和镜像分层特性，由 JSON 清单和文件系统层组成，基于基础镜像构建，支持标签标识或通过唯一标识符查找，遵循 OCI 运行时规范，其存储依赖 containers/storage 库，Dockerfile 是创建容器镜像的文本脚本，镜像层对应 Dockerfile 中的指令，容器是镜像的可读写层，删除容器后可读写层随之删除，镜像保持不变
容器：本质是在 Linux 上运行的隔离且受限制的进程集合，拥有独立的进程命名空间，通常每个容器运行一个进程，进程生命周期与容器紧密关联，容器内打包了除内核外的所有依赖，共享主机内核，拥有独立的文件系统子集，Linux 容器的隔离和资源控制依赖命名空间和控制组（cgroups）
- 命名空间：Linux 内核特性，实现资源隔离，包括 USER（用户和组 ID 隔离）、PID（进程 ID 隔离）、UTS（主机名和 NIS 域名隔离）、NET（网络资源隔离）、MNT（文件系统挂载点隔离）、IPC（进程间通信隔离）等类型，未来可能引入时间命名空间
- 控制组（cgroups）：限制进程能力、设置资源限额，启动容器时运行时会创建新的 cgroups，可限制 CPU、内存、设备访问等，还能限制控制组内进程数量以防 fork 炸弹，内核通过 /sys/fs/cgroup 下的伪文件系统提供 cgroups 信息
- 无 root 容器：默认容器以 root 用户运行存在安全风险，无 root 容器基于 Linux 内核 user_namespaces (7) 模拟必要权限创建容器，Docker 19.03 及以上版本支持无 root 模式的多数功能，20.10 版本利用 Control Group v2 实现资源限制，还需依赖 slirp4netns、fuse-overlayfs 等库及 RootlessKit 工具保障安全
内核与 OCI
- 内核：操作系统核心程序，常驻内存，协调硬件与软件交互，控制硬件资源，处理进程资源竞争，优化资源利用，进程通过系统调用请求内核服务，Docker 依赖内核模块实现容器化和存储功能，如 overlay2 存储驱动利用内核 overlay 文件系统实现镜像分层
- **Open Container Initiative (OCI)**：Linux 基金会旗下的开放治理项目，制定容器格式和运行时的开放行业标准，包含运行时规范（runtime-spec）和镜像规范（image-spec），确保不同容器实现的兼容性
- OCI Runtime Spec：定义容器配置、执行环境和生命周期，容器配置以 config.json 文件指定，运行时需支持 state、create、start、kill、delete 等操作，常见的 OCI 运行时实现有 runc（Go 语言编写，Docker 捐赠给 OCI）、crun（C 语言编写，Red Hat 主导，速度快、内存占用低）、railcar（Rust 语言编写，已归档）、youki（Rust 语言编写，受 railcar 启发，注重内存安全和性能）
OCI Runtime Tools：包含 oci-runtime-tool 等工具，可生成 OCI bundle 的配置 JSON、验证 OCI bundle，还能运行运行时验证套件，不同运行时采用不同工具进行集成测试

▶

术语拆解

我们可以用一个 “精装修公寓” 的类比来把这些生涩的术语拆解开，你会发现它们其实各司其职：

1. 核心铁三角：镜像、容器、仓库

这是你最先接触的三个概念，也是最基础的：

容器镜像 (Image) —— “精装修图纸 / 样板房快照” ：它是一个只读的模板，里面打包了程序运行需要的所有东西（代码、库、配置）。你可以把它想象成一个已经装好的硬盘镜像，或者是还没拆封的乐高积木包。
容器 (Container) —— “实际住人的房间” ：当你根据 “图纸”（镜像）把房间盖好并让租客住进去，它就成了 “容器”。它是一个正在运行的程序。
Docker Registry —— “图纸超市” ：存放各种镜像的地方（比如 Docker Hub）。你需要什么环境，就去超市里 “拉取”（Pull）对应的图纸。

2. 幕后大管家：CRI 和 Containerd

这部分最容易让人头大，其实它们是在分工：

Containerd —— “通用发动机” ：以前 Docker 是个大胖子，什么都干。后来大家把 “拉取镜像、管理容器生命周期” 这部分最核心的功能抽出来，做成了 Containerd。它现在是工业标准，不仅 Docker 在用，Kubernetes 也在用。
CRI (容器运行时接口) —— “统一插座” ：Kubernetes 为了能支持各种不同的 “发动机”（比如 Containerd 或其他的），定了一个标准的 “插口”，这个插口就叫 CRI。

3. 隔离的魔法：Namespaces 和 Cgroups

这是 Linux 内核给 Docker 提供的超能力，也是最难懂的部分：

命名空间 (Namespaces) —— “隐身衣与独立房间”：
- PID 隔离：让容器里的进程觉得自己是 1 号进程（就像在自己家，你是家里的老大，看不到别人家的人）。
- 网络隔离：给容器分配独立的 IP，不和主机打架。
- 结果：容器之间互相看不见，以为自己独占了整台电脑。
控制组 (cgroups) —— “资源配额表”：
- 防止某个容器 “发疯” 吃光所有内存或 CPU。
- 比如规定：这个房间只能用 512MB 内存，超了就强行限制。

4. 构建工具：BuildKit 和 Buildx

它们是帮你 “画图纸” 的工具：

BuildKit：新一代的构建引擎。比老版快得多，支持并行处理，就像请了几个工头同时盖房子。
Buildx：Docker CLI 的插件，它是 BuildKit 的 “指挥官”。

总结一下

Docker CLI：你的遥控器。
Containerd：真正的苦力（启动和管理容器）。
OCI：大家约好的协议（保证你的镜像在谁家都能跑）。
Namespace / Cgroups：Linux 提供的 “围墙” 和 “限额”，保证容器安全和独立。

如果你只需要记住一句话： Docker 就是利用 Linux 内核的 “围墙”（Namespaces）和 “限额”（cgroups），把 “图纸”（镜像） 变成 “活的房间”（容器） 的一套自动化工具。