Containerd 容器技术详解-CSDN博客

Containerd（Container Daemon）是一个开源的容器运行时，它提供了一种标准化的方式来管理容器的生命周期。该项目最初是由 Docker 开发团队创建的，并在后来成为一个独立的项目，被纳入了 Cloud Native Computing Foundation（云原生计算基金会 CNCF）的孵化项目中

特性	描述
容器生命周期管理	Containerd 管理容器的生命周期，包括容器的创建、运行、暂停、恢复、停止和销毁等操作
标准化接口	Containerd 提供了一个标准化的容器运行时接口，使得它可以与多个容器编排系统和工具集成，例如 Kubernetes、Docker Compose 等
镜像管理	它支持容器镜像的拉取、推送、保存和加载等操作。Containerd 使用 OCI（Open Container Initiative）规范定义容器镜像的格式
插件体系结构	Containerd 具有可扩展的插件体系结构，允许用户通过插件来扩展其功能，例如存储驱动、网络插件等
跨平台支持	Containerd 可以在不同的操作系统上运行，从而提供了跨平台的支持
与 Kubernetes 集成	Containerd 作为 Kubernetes 的默认容器运行时，与 Kubernetes 紧密集成，为容器工作负载的管理提供了良好的支持
安全性和隔离	Containerd 实现了严格的容器隔离和安全性措施，确保容器之间的隔离性以及对主机系统的安全性

总体而言，Containerd 提供了一个轻量级、高度可定制的容器运行时，为容器生态系统的发展提供了一个稳定和可靠的基础。它在容器生命周期管理、镜像管理和插件支持等方面为用户提供了丰富的功能

2.Containerd 的起源与背景

Containerd 的起源可以追溯到 Docker 项目。Docker 最初作为一个开源项目推出，旨在简化应用程序的打包、分发和部署过程。Docker 引入了容器的概念，将应用程序和其依赖项打包到一个容器中，使得应用在不同环境中可以一致地运行。
随着 Docker 的发展，其架构逐渐变得复杂，包含了许多功能，如镜像构建、服务编排等。为了更好地组织和管理这些功能，Docker 团队决定将 Docker 引擎拆分成多个组件，其中一个关键的组件就是 Containerd。

类别	详情
Docker 架构拆分	从单一大型引擎拆分为系列小型、可复用组件，目标是提升可维护性、模块化与可扩展性
Containerd 作为核心运行时	Docker 架构拆分后，被定位为 Docker 核心容器运行时，负责管理容器生命周期、镜像操作和基本运行时功能
贡献给 CNCF（云原生基金会）	Docker 团队为推动其发展，将 containerd 代码捐赠给 Cloud Native Computing Foundation（CNCF），使其成 CNCF 孵化项目
容器生态系统的标准化	设计遵循 Open Container Initiative（开放容器倡议 OCI）规范，该规范关注容器运行时和镜像格式标准化，意味着 containerd 可与符合 OCI 规范的其他容器工具和运行时互操作
独立的容器运行时	不局限于 Docker，可作为独立容器运行时，与多个容器编排系统和工具集成，给用户更多选择

总体而言，containerd 的起源是为了简化容器运行时的管理，并为容器生态系统提供一个开放、标准化的基础。其发展不仅服务于 Docker 生态系统，还为整个容器领域提供了一个通用的、可扩展的容器运行时

二.Containerd 架构

1.Containerd 架构概述

Containerd 的架构是 modularity（模块化）和可扩展性的体现，它被设计为一个轻量级、高度可定制的容器运行时。

可以看出 Containerd 采用的也是 C/S 架构,服务端通过 unix domain socket 暴露低层的 gRPCAPI 接口出去，客户端通过这些 API 管理节点上的容器，每个 Containerd 只负责一台机器，Pull镜像，对容器的操作(启动、停止等)，网络，存储都是由 containerd 完成。具体运行容器由 runc 负责。
为了解耦，Containerd 将系统划分成了不同的组件，每个组件都由一个或多个模块协作完成(core部分)，每一种类型的模块都以插件的形式集成到Containerd 中。

2.核心组件解析

Containerd 组件大致分为 Storage、Metadata 和 Runtime 这三个主要方面。

（1）.Storage（存储组件）

组件	功能描述	技术细节
Content	存储容器镜像的二进制数据（文件系统层、配置等）	- 使用内容可寻址存储（CAS）机制 - 支持压缩/解压缩（gzip/zstd） - 通过摘要（Digest）校验数据完整性
Snapshot	管理容器文件系统的快照（基于COW技术）	- 支持多种驱动（overlayfs、btrfs、devicemapper） - 快照树实现层共享（减少存储占用）
Diff	存储文件系统层间的差异数据	- 通过AUFS/Overlay2实现高效差异合并 - 支持白名单过滤（忽略特定文件变更）

（2）.Metadata（元数据管理）

组件	功能描述	技术细节
Images	管理镜像元数据（标签、层级关系、创建时间等）	- 兼容OCI镜像规范 - 支持多仓库镜像拉取（Docker Hub、私有仓库） - 支持镜像垃圾回收
Containers	管理容器元数据（配置、状态、网络等）	- 存储OCI运行时规范（runtime-spec）配置 - 与CRI（Container Runtime Interface）深度集成

（3）.Runtime（运行时管理）

组件	功能描述	技术细节
Tasks	管理容器内进程组（PID命名空间隔离）	- 通过`containerd-shim`托管进程 - 支持进程生命周期钩子（hooks） - 与runc/gVisor等运行时交互
Events	记录容器生命周期事件（创建/启动/停止等）	- 基于TTRPC协议实现实时事件流 - 支持事件过滤（如仅记录错误事件） - 与Prometheus监控集成

关键交互关系

三.安装配置 Containerd

1.安装 Containerd

#step 2:添加软件源信息

#列出可用版本

#安装 containerd

2.配置 Containerd

（1）.生成配置文件

（2）.配置镜像加速

修改配置文件

（3）.启动服务

四.镜像操作

1.拉取镜像

2.查看镜像

查看本地有哪些镜像可以使用 ctr images ls，默认査看到的的是 default 命名空间的镜像

査看 crictl拉取的镜像 :

3.检测本地镜像

主要査看其中的 STATUS，complete 表示镜像是完整可用的状态。

命令格式:
ctr images check

4.重新打标签

命令格式:
ctr images tag 当前镜像名称新镜像名称

5.删除镜像

6.镜像挂载到主机目录

7.镜像从主机目录卸载

8.镜像导出

9.镜像导入

五.容器类操作

Containerd 本身并没有直接支持端口映射的功能。端口映射通常是由容器运行时(比如 Docker、CRI-0)负责的，而不是容器的底层运行时(containerd)。

1.创建容器

# 基于 docker.io/library/nginx:latest 镜像创建一个叫 nginx 的容器

2.列出容器

3.查看容器的详细信息

4.删除容器

六.任务操作

通过 container create 命令创建的容器，并没有处于运行状态，只是一个静态的容器(仅仅只是一个创建容器的声明)。一个 container 对象只是包含了运行一个容器所需的资源及相关配置数据，表示 namespaces、rootfs 和容器的配置都已经初始化成功了，只是用户进程还没有启动。
一个容器真正运行起来是由 Task 任务实现的。

1.启动容器

#启动任务的时候要先有容器 #-d 放入后台

2.查看容器

3.进入容器里面

#进入到容器里面
#不过这里需要注意必须要指定 --exec-id 参数，这个 id 可以随便写，只要唯一就行

4.暂停容器

5.恢复容器

6.杀死容器

#杀死容器,ctr 没有stop 容器的功能，只能暂停或者杀死容器

7.删除任务

注:
虽然已经删除了任务，但是创建容器的时候，也创建了一个同名的快照，即便已经删除了任务，也可以使用“ctr task start -d nginx”命令，利用此快照将已删除的任务启动起来，使得此容器恢复运行。

8.删除容器

注意:
删除容器后快照也就没有了

9.获取容器的内存、CPU 和 PID 的限额与使用量

指标名称	示例值	单位	说明	典型场景分析
`memory.usage_in_bytes`	19223372036854771712	字节	容器内存使用量	该值接近2^64，表示未设置内存限制（`--memory`未指定或设为0）
`memory.stat.cache`	θ（未提供具体数值）	字节	内存缓存大小（Page Cache/Slab Cache）	高缓存值可能表示频繁的文件IO操作
`cpuacct.usage`	36365002	纳秒	容器累计CPU使用时间（所有核总和）	约36毫秒，表示轻量级任务
`cpuacct.usage_percpu`	[16788433, 19576569]	纳秒	各CPU核的使用时间	核间负载均衡良好（差异<15%）
`pids.current`	θ（未提供具体数值）	个	容器内活跃进程数量	空值可能表示未启用PID cgroup限制
`pids.limit`	θ（未提供具体数值）	个	容器允许的最大进程数	空值通常表示无限制（需结合`docker run --pids-limit`或k8s `pod.spec.pids`配置）

10.查看容器中所有进程在宿主机中的 PID

#先启动一个容器

#查看所有进程在宿主机的 pid

七.插件

在 Containerd 中，插件是一种机制，允许你通过加载和卸载插件来扩展 Containerd 的功能。插件可以提供不同的功能，例如容器存储、网络、监控等。Containerd 使用插件化的设计，使其可以适应各种不同的容器运行时和容器生态系统需求。

插件类型	功能描述
Shim 插件	负责管理容器的生命周期，容器任务启动时调用创建并监管容器进程，负责与容器进程通信、监控容器状态
Snapshotter 插件	处理容器的文件系统快照（Snapshots），定义容器文件系统结构，支持创建、管理和销毁快照，以及在不同容器间共享文件系统层
Task 插件	用于管理容器中的任务（Task），任务为容器内运行的一个或多个进程，与容器生命周期直接相关
Image 插件	负责处理容器镜像的拉取、推送、删除等操作，定义容器镜像的存储和元数据结构
Content Store 插件	管理容器内容（Content），包括镜像层和元数据，定义内容的存储和检索方式

这些插件允许用户根据实际需求选择性地配置 Containerd，并与其他容器运行时和编排系统进行集成。例如，通过选择不同的快照插件，你可以定制 Containerd 的文件系统管理方式。通过选择不同的网络插件，你可以适应不同的网络模型和需求。

插件化的设计使得 Containerd 可以灵活地适应不同的使用场景，并且可以方便地进行定制和扩展。

每个插件都提供了标准化的接口，使得插件可以被轻松地替换或新增，从而满足不同用户和组织的需求。

列出当前所有插件

八.命名空间

在 Containerd 中，命名空间（Namespace）是一种用于隔离资源和进程视图的 Linux 内核特性。命名空间允许在同一主机上运行的进程拥有不同的资源视图，从而实现资源隔离。Containerd 利用 Linux 的命名空间实现容器的隔离

命名空间类型	隔离内容	作用
PID 命名空间	进程 ID 空间	让不同命名空间的进程似在独立系统运行，确保容器进程不影响主机其他进程
Network 命名空间	网络栈	使容器网络环境独立于主机，容器可拥有自己网络接口、IP 地址、端口，不影响其他容器和主机网络配置
Mount 命名空间	文件系统挂载点	让容器有自己文件系统视图，各容器文件系统互不影响
UTS 命名空间	主机名和域名	允许容器有自己的主机名和域名
IPC 命名空间	进程间通信（IPC）资源	阻止容器内进程直接与主机或其他容器共享 IPC 资源
User 命名空间	用户和用户组视图	容器内进程可按容器内用户 / 组身份运行，不影响主机实际用户 / 组