05、containerd 容器概述

官方文档： https://containerd.io

2016年12月14日，Docker公司宣布将containerd从Docker中分离，交由开源社区独立发展和运营。containerd是一个完整的容器运行时，可独立运行并管理容器，其主要职责是镜像管理和容器执行。它通过containerd-shim接口层向下对接runc项目，实现容器运行时与Docker Daemon的解耦，使得Docker Daemon可以独立升级。

containerd能够在宿主机上管理完整的容器生命周期，包括：

容器镜像的传输与存储
容器的创建、执行与销毁
存储管理（管理镜像及容器数据）
网络管理（管理容器网络接口及网络）
调用runc等符合OCI规范的运行时执行容器操作

ctr： containerd 的命令行客户端工具。

1、containerd 与 Docker 的关系

Docker 包含 containerd 作为其容器运行时核心。containerd 专注于容器生命周期的底层管理（运行时），而 Docker 在此基础上提供了更上层的功能，例如镜像构建、用户友好的CLI和API等。

containerd 提供的API较为底层，主要面向容器编排工具开发者等集成用户，而非最终用户。

2、containerd 在容器生态中的角色

containerd 主要定位是嵌入更上层的系统（如Kubernetes等容器编排平台），作为其容器运行时组件，而非直接面向最终用户。

它以守护进程（daemon）形式运行在宿主机上，通过Unix Domain Socket暴露底层的gRPC API。上层系统通过这些API来管理宿主机上的容器生命周期、镜像、存储和网络。

3、 Kubernetes 弃用 Docker 支持，转向 containerd 的原因

核心原因在于：containerd 更轻量、资源占用更低，且 Docker 底层本身依赖 containerd。

Kubernetes 等工具通过容器运行时接口（CRI）调用容器运行时（如 containerd、CRI-O）来实际完成容器的创建、运行和销毁工作。Docker 自身使用 containerd 作为其运行时。Kubernetes 在 1.24 版本之前支持使用 Docker（通过 dockershim），但从 1.24 版本开始正式弃用 Docker 支持，转而直接支持 containerd、CRI-O 等符合 OCI 规范的容器运行时。这些运行时最终通过 runc 与操作系统内核交互来管理容器。

关键概念说明

CRI (Container Runtime Interface): Kubernetes 定义的一个插件接口，使 kubelet 能够使用不同的容器运行时。集群中的每个节点都需要安装一个兼容的容器运行时，kubelet 才能启动 Pod 及其容器。CRI 是 kubelet 与容器运行时之间通信的主要协议。
OCI (Open Container Initiative): 一个由 Linux 基金会支持的开源项目，致力于制定容器格式（OCI Image Spec）和运行时（OCI Runtime Spec）的开放行业标准。主流的容器运行时（如 runc, containerd, CRI-O）都遵循 OCI 规范。

性能与资源占用优化

当使用 Docker 作为 Kubernetes 容器运行时时，调用链较长：
kubelet –> dockershim (内置于旧版 kubelet) –> dockerd (Docker Daemon) –> containerd

当直接使用 containerd 作为 Kubernetes 容器运行时时，调用链显著缩短：
kubelet –> CRI plugin (内置于 containerd) –> containerd

优势：