从Docker到Containerd：Kubernetes容器运行时演进深度解析

在Kubernetes的世界里，容器运行时是一个基础且关键的组件。它负责真正在主机上启动和停止容器。近年来，随着Kubernetes的成熟，其默认的容器运行时环境经历了重大演变，从我们熟知的Docker转向了更为底层和精简的Containerd。本文将深入剖析Docker、Containerd的架构差异，并结合实际案例说明这一转变带来的影响。

一、核心概念：什么是容器运行时？

简单来说，容器运行时是负责运行容器的软件。它根据容器镜像（OCI Image）创建隔离的、资源受限的进程（容器）。Kubernetes本身不直接处理这些底层操作，而是通过容器运行时接口（CRI） 与运行时进行交互。

在Kubernetes的视角下，它只关心："请在这个Pod里启动一个包含A镜像的容器"。至于如何拉取镜像、如何创建命名空间和Cgroups、如何运行容器，这些都是容器运行时的职责。

二、演进历程：从"Docker时代"到"后Docker时代"

要理解今天的格局，我们需要回顾一下历史。

早期：直接集成Docker

在Kubernetes早期，它是通过一个内置的dockershim组件直接与Docker Engine集成。Docker是当时事实上的容器标准，这种集成方式简单直接。对于用户而言，体验非常顺畅：安装Docker，安装Kubelet，即可工作。
变革：CRI的引入与Docker的"包袱"

为了支持更多的容器运行时（如RKT、Containerd），Kubernetes推出了容器运行时接口（CRI） 。这是一个插件接口，任何实现了CRI的运行时都可以被Kubernetes使用。

然而，Docker Engine本身没有实现CRI 。它是一套完整的容器化解决方案，包含构建、镜像格式、网络、存储、运行时等一大堆功能。为了继续使用Docker，Kubernetes不得不维护一个特殊的适配器------dockershim。这个组件将Kubelet发出的CRI请求（如RunPodSandbox）翻译成Docker Engine能理解的API请求。
现状：拥抱标准的Containerd

dockershim的维护给Kubernetes社区带来了额外的负担，且架构上显得冗余。与此同时，Docker Engine内部的容器运行时正是Containerd------一个更专注、更轻量、性能更好的纯运行时组件。Containerd天然就实现了CRI。

因此，从Kubernetes v1.20开始宣布弃用dockershim，并在v1.24版中正式移除，转向将Containerd作为默认的运行时推荐。这标志着Kubernetes与Docker Engine的"解耦"，进入了更开放、更标准化的"后Docker时代"。

三、架构深度解析：Docker vs. Containerd

让我们通过两张架构图来直观理解它们的区别。

1. 使用Docker Engine（通过dockershim）的架构

diff 复制代码

+---------------------------------------------------+
|                 Kubernetes Kubelet                 |
+---------------------------------------------------+
|                 CRI Interface                     |
+---------------------------------------------------+
|                 dockershim (适配器)                |  <- 由K8s维护的翻译层
+---------------------------------------------------+
|                 Docker Daemon REST API             |
+---------------------------------------------------+
|      Docker Engine (容器管理、构建、网络、存储...)    |  <- 功能丰富但沉重
+---------------------------------------------------+
|                 containerd (内部组件)              |  <- 实际负责容器生命周期
+---------------------------------------------------+
|                 runc (底层运行时)                  |  <- 真正创建容器进程
+---------------------------------------------------+

工作流程：

Kubelet通过CRI发出指令（例如：运行一个Nginx容器）。
dockershim将这个CRI请求翻译成Docker API请求（例如：docker create/start）。
请求发送给Docker Daemon。
Docker Daemon内部调用其内置的Containerd来执行操作。
Containerd最终调用runc来创建容器。

痛点：

路径长：请求需要经过多次转发，增加了延迟和故障点。
资源重：Docker Daemon本身消耗更多CPU和内存。
架构复杂：引入了不必要的抽象层。

2. 直接使用Containerd的架构

diff 复制代码

+---------------------------------------------------+
|                 Kubernetes Kubelet                 |
+---------------------------------------------------+
|                 CRI Interface                     |
+---------------------------------------------------+
|             cri-containerd plugin (CRI插件)        |  <- Containerd内置的CRI实现
+---------------------------------------------------+
|                 containerd (纯运行时)               |  <- 核心：镜像、容器管理
+---------------------------------------------------+
|                 runc / runsc (底层运行时)           |  <- 支持多种OCI运行时
+---------------------------------------------------+

工作流程：

Kubelet通过CRI发出指令。
Containerd内置的cri插件直接接收并处理CRI请求。
Containerd管理镜像和容器生命周期，并直接调用runc。

优势：

路径短：架构扁平，效率更高，稳定性更好。
资源轻：少了Docker Daemon这一层，资源占用显著降低。
更纯粹：专注容器运行时核心职责，符合Kubernetes的期望。

四、核心区别与实际影响总结

特性	Docker Engine	Containerd
定位	完整的容器化平台，面向开发者	专注的、工业级的容器运行时，面向基础设施
架构复杂度	高，包含大量非必要功能（如`docker build`，Swarm）	低，核心只有镜像和容器管理
与K8s集成	需通过`dockershim`（已废弃），非原生	原生支持CRI，是Kubernetes的"一等公民"
资源占用	较高（内存、CPU）	更低，通常比Docker少20%-30%的内存占用
CLI工具	功能强大的`docker`命令	功能基础的`ctr`命令（不适合人类使用），或`crictl`（推荐）
API	丰富的Docker API	更底层的Containerd API，以及标准的CRI

对用户的实际影响：

你不能再使用docker命令进行故障排查 ：这是最大的变化。在节点上，你无法直接执行docker ps或docker logs来查看Kubernetes创建的容器。
使用新的CLI工具：
- crictl ：Kubernetes社区推荐的CRI调试工具。它的命令格式与docker类似，例如 crictl ps, crictl logs。
- ctr：Containerd自带的命令行工具，更底层，但对用户不友好，一般不推荐直接使用。
性能与稳定性提升：更少的组件意味着更少的潜在问题和高负载下更好的性能。

五、实战案例：故障排查场景对比

假设一个Pod一直处于Pending状态，我们怀疑是容器启动失败。

场景：在节点上查看容器日志。

案例1：使用Docker作为运行时的旧集群（K8s < 1.24）

找到问题Pod所在的节点和容器ID。
SSH登录到节点。
使用熟悉的Docker命令查看日志：
perl 复制代码
```
# 查找容器ID
docker ps -a | grep <pod-name>

# 查看日志
docker logs <container-id>
```
这种方式直观，但依赖于已废弃的架构。

案例2：使用Containerd作为运行时的现代集群（K8s >= 1.24）

找到问题Pod所在的节点和容器ID（可以从kubectl describe pod <pod-name>获取）。
SSH登录到节点。

使用crictl工具（需要先配置，或通过/var/run/containerd/containerd.socksocket）。

python 复制代码

# 根据Pod名查找容器ID
crictl pods --name <pod-name>
crictl ps -p <pod-id>

# 查看容器日志
crictl logs <container-id>

# 或者更直接地，通过镜像名模糊查找
crictl ps | grep nginx
crictl logs <container-id>

虽然命令变了，但功能和效果一致，且架构更优。

进阶案例：使用crictl进行深度调试

crictl的功能非常强大，几乎覆盖了所有调试场景：

python 复制代码

# 检查容器详情（包括资源限制、挂载点等）
crictl inspect <container-id>

# 在运行的容器中执行命令
crictl exec -it <container-id> /bin/sh

# 拉取镜像到节点（用于离线环境或预缓存）
crictl pull nginx:latest

# 查看容器资源使用情况（类似docker stats）
crictl stats

六、结论与展望

从Docker到Containerd的转变，是Kubernetes生态走向成熟和标准化的必然结果。它标志着Kubernetes不再依赖一个特定的、庞大的容器平台，而是基于开放标准（如OCI、CRI）来构建其基础设施。这种解耦带来了更清晰的边界、更好的性能、更高的稳定性和更低的资源开销。

对于开发者和运维人员而言，需要理解并适应这一变化：

对于应用开发者：这一变化基本无感。你仍然可以像以前一样使用Dfile构建镜像，并在Kubernetes的YAML中引用它们。因为镜像标准（OCI）没有变。
对于集群运维人员 ：这是必须掌握的知识。你需要熟悉Containerd的配置、日志位置以及新的调试工具链（crictl）。

未来，容器运行时的生态会继续发展，除了Containerd，还有像CRI-O这样的优秀选择。同时，安全容器（如Kata Containers，通过runsc运行时）等新技术也建立在Containerd等基础运行时之上。牢牢掌握Containerd，就是掌握了理解现代Kubernetes容器编排根基的钥匙。

从Docker到Containerd：Kubernetes容器运行时演进深度解析

一、 核心概念：什么是容器运行时？

二、 演进历程：从"Docker时代"到"后Docker时代"

三、 架构深度解析：Docker vs. Containerd

四、 核心区别与实际影响总结

五、 实战案例：故障排查场景对比