【Docker】3.Docker 组件与生产应用

文章目录

[1. Docker 组件与生产应用](#1. Docker 组件与生产应用)
- [1.1 Docker 官方架构与生活化案例拆解](#1.1 Docker 官方架构与生活化案例拆解)
- - [1.1.1 核心组件的交互流程](#1.1.1 核心组件的交互流程)
- [1.2 **Docker 核心组件拆解**](#1.2 Docker 核心组件拆解)
- - [1.2.1 Docker 镜像 (Image)：标准化的装修模板](#1.2.1 Docker 镜像 (Image)：标准化的装修模板)
  - [1.2.2 Docker 容器 (Container)：实际入住的客房](#1.2.2 Docker 容器 (Container)：实际入住的客房)
  - [1.2.3 Docker 仓库 (Registry)：全球装修方案库](#1.2.3 Docker 仓库 (Registry)：全球装修方案库)
- [1.3 组件的转换](#1.3 组件的转换)
[2. Docker 版本选择与生产环境实践](#2. Docker 版本选择与生产环境实践)
- [2.1 从 Docker 到 Moby：开源的转折点](#2.1 从 Docker 到 Moby：开源的转折点)
- [2.2 Docker CE vs Docker EE：社区与企业的抉择](#2.2 Docker CE vs Docker EE：社区与企业的抉择)
- [2.3 为什么版本选择在生产中至关重要？](#2.3 为什么版本选择在生产中至关重要？)
[3. 运行时之战：Docker 还是 Containerd？](#3. 运行时之战：Docker 还是 Containerd？)
- [3.1 Docker 的内部"套娃"结构](#3.1 Docker 的内部“套娃”结构)
- [3.2 为什么 Kubernetes 弃用 Docker 转向 containerd？](#3.2 为什么 Kubernetes 弃用 Docker 转向 containerd？)
- [3.3 生产环境建议：该选哪一个？](#3.3 生产环境建议：该选哪一个？)

1. Docker 组件与生产应用

1.1 Docker 官方架构与生活化案例拆解

虽然 Docker 的底层是 Namespace 和 Cgroups，但为了让用户用得爽，Docker 设计了一套非常精巧的客户端-服务器 (C/S) 架构。
Docker 并不是一个孤立的程序，而是一套协作系统。它主要由三部分组成：

客户端 (Client)

守护进程 (Docker Daemon)

宿主机 (Host)
Docker C/S 架构：

Docker 采用客户端-服务器架构。

Docker Client 通过 REST API 与 Docker Daemon 进行通信，后者负责构建、运行和分发容器的繁重工作。
为了更直观地理解这三者的关系，我们把 Docker 系统比作一家**"智慧酒店"**：

Docker Client (旅客) ：就是你。你并不直接去客房打扫或搬家具，你只是向"酒店前台"下达指令，比如"我要订房"、"我要退房"。在电脑上，这就是你输入的 docker run 或 docker pull 命令。

Docker Daemon (酒店前台/管家)：这是核心。它接收旅客（Client）的指令，然后去查看哪些房间空着，去仓库拿床单（镜像），并最终安排入住（创建容器）。它常驻在后台，默默处理所有请求。

Docker Host (酒店大楼) ：这是提供服务的物理基础，包含大楼的宅基地、供水供电系统。它承载了 Daemon 进程和所有的"房间"（容器）。

1.1.1 核心组件的交互流程

在实际工作中，这三者的协作逻辑非常清晰：

Client 发令 ：你在终端输入命令。Client 可以和 Daemon 运行在同一台机器上，也可以通过网络连接到远程的 Daemon。

Daemon 执行 ：守护进程是 Docker 的"大脑"。它负责管理 Images（镜像） 、Containers（容器）、网络和磁盘卷。

Host 承载 ：宿主机提供了容器运行所需的内核环境（我们之前学过的 Namespace 和 Cgroups 就在这里生效）。

Docker 交互流程图：

1.2 Docker 核心组件拆解

我们已经认识了"旅客"（Client）和"酒店前台"（Daemon），接下来我们要拆解酒店运营中最核心的三样东西：装修模板、真实客房、以及方案图库。

这对应了 Docker 的三大支柱：

Docker 镜像

Docker 容器

Docker 仓库

1.2.1 Docker 镜像 (Image)：标准化的装修模板

Docker 镜像是一个只读的模板，包含了运行应用程序所需的所有代码、库、环境变量和配置文件。
酒店类比：

镜像就像是酒店的**"标准间装修图纸"**。它规定了房间里必须有空调、双人床和 WiFi 密码。这份图纸是静态的、不可修改的。无论你用这份图纸装修出多少个房间，它们最初的样子都是一模一样的。

1.2.2 Docker 容器 (Container)：实际入住的客房

Docker 容器是镜像的运行实例。你可以启动、开始、停止、移动或删除它。
酒店类比：

容器就是**"已经入住旅客的 9262 号房间"**。虽然它是按照镜像图纸装修的，但一旦旅客住进去，房间里就有了旅客的行李（运行产生的数据）、洗漱时间（进程状态）。如果旅客退房（销毁容器），酒店会按图纸把房间恢复原样，等待下一位旅客。

1.2.3 Docker 仓库 (Registry)：全球装修方案库

Docker 仓库 是集中存放镜像文件的地方。最著名的公开仓库就是 Docker Hub。
酒店类比：

仓库就像是一个**"全球酒店装修方案库"**。你想开一家中式餐厅，不需要自己设计，直接去库里搜索"中式模板"下载（Pull）下来即可。你也可以把自己设计好的"总统套房模板"上传（Push）上去分享给全世界。

1.3 组件的转换

理解这三者如何相互转换，是掌握 Docker 操作的关键：

Build (构建) ：将你的代码和环境"打包"成一个镜像（画好图纸）。

Pull (拉取) ：从远程仓库下载现成的镜像到本地。

Run (运行) ：基于镜像启动一个容器（按图纸交付房间）。

Docker 核心生命周期：构建、分发与运行：

2. Docker 版本选择与生产环境实践

2.1 从 Docker 到 Moby：开源的转折点

早期的 Docker 是一个单体项目，但随着社区壮大，为了让 Docker 更加模块化，Docker 公司在 2017 年启动了 Moby 项目。
Moby 项目：

它是 Docker 开源项目的上游核心。你可以把它理解为一套"零件库"，而我们平时使用的 Docker 软件则是用这些零件组装出来的成品。
目前，Docker 的引擎（dockerd）仓库就是从 Moby 仓库 fork 而来的。对于开发者来说，关注 Moby 意味着关注 Docker 最前沿的特性。

2.2 Docker CE vs Docker EE：社区与企业的抉择

目前市场上主要存在两个版本系列，它们的基础组件（如 Moby、containerd）是一致的，但在功能支持和收费模式上有所不同：

Docker CE (Community Edition) ：社区版。免费开源，适合个人开发者和小规模团队。它的组件直接来自于 Moby 等开源项目。

Docker EE (Enterprise Edition) ：企业版。收费版本，专为企业级关键业务设计。它在 CE 的基础上增加了高级安全功能（如镜像扫描、内容信托）以及商业级技术支持。

2.3 为什么版本选择在生产中至关重要？

在生产环境中，稳定性优于一切。

版本选择不当的风险：

兼容性断层 ：不同版本的 Docker API 可能会有细微差别，导致自动化脚本或 K8s 集群调用失败。

安全漏洞 ：旧版本可能存在已知的 CVE 漏洞，而 CE 版的维护周期通常比 EE 短，需要更频繁地手动升级。

资源占用 ：随着版本的更迭（例如从 LXC 到 runC 的演进），容器的底层性能和资源开销都在不断优化。
对于大多数自学或中小型开发环境，Docker CE 是性价比最高、资料最全的选择；而当你需要银行级别的安全保障和官方背书时，Docker EE 才是考虑对象。

3. 运行时之战：Docker 还是 Containerd？

为了做出的决策，我们需要拆开 Docker 的"黑盒"，看看它内部是如何一层层工作的。

3.1 Docker 的内部"套娃"结构

很多人以为 Docker 是一个单体软件，但实际上它是由多个组件嵌套而成的。

Docker Engine ：最外层的"管家"，负责处理用户的 API 请求。

containerd ：中间层的"调度员"，负责镜像管理和容器生命周期。它最初是 Docker 的一部分，后来独立出来成为了 CNCF 的工业标准。

runc ：最底层的"苦力"，根据 OCI 标准真正去调用内核（Namespace/Cgroups）来创建容器。

Docker 内部组件层级关系：

3.2 为什么 Kubernetes 弃用 Docker 转向 containerd？

在 K8s 的生产环境中，调用链越短越好。

原先 K8s 调用 Docker 需要经过：Kubelet -> Docker Shim -> Docker Engine -> containerd -> runc。
CRI (Container Runtime Interface)：

为了效率，K8s 引入了 CRI 标准。

由于 containerd 原生支持 CRI，调用链可以缩短为：Kubelet -> containerd -> runc。

这样做组件更少、更稳定，占用节点资源也更少。

3.3 生产环境建议：该选哪一个？

在实际生产（如腾讯 TKE）中，选择取决于你的使用场景：

建议选择 containerd 的场景：

追求极致的稳定性。

希望减少物理节点的内存和 CPU 损耗。

标准的 Kubernetes 生产集群节点。

必须保留 Docker 的场景：

需要在节点上直接运行 docker build 构建镜像。

需要使用 docker-compose 或 docker swarm。

现有的运维脚本高度依赖 Docker API。