当前位置：首页 > article >正文

Docker和containerd之概览（Overview of Docker and Containerd）

article 2026/3/5 19:30:33

Docker和containerd之概览

容器本质上就是一个进程。
Namespace是一种逻辑分组机制，允许您将集群资源划分为独立的虚拟环境。每个 Namespace 为资源提供了一个范围，使得不同的团队、应用程序或环境可以在同一集群中共存，而不会相互干扰。
Cgroups（是control groups的简写）是Linux内核用来限制、控制与分离一个进程组的资源（如CPU、内存、磁盘输入输出等）的功能。

它是Google的工程师在2006年发起的一个项目，2008年通过 Namespace 实现资源（网络、文件、系统等）隔离，通过 Cgroups 实现资源（CPU、内存）限制，让我们使用起来就感觉像在操作虚拟机一样，但其和虚拟机本质上的区别，那就是容器和宿主机是共享同一个内核的容器和宿主机是共享同一个内核的。为了将我们的应用进程运行在容器中，当然就需要有一些方便的接口或者命令去调用 Linux 的系统功能来实现，而容器运行时就是用来运行和管理容器进程、镜像的工具。

容器运行时分类

k8S为什么不支持docker了？

随着Docker的普及，容器化领域出现了Docker公司独占的趋势。为了应对这一局面，Docker将其libcontainer组件捐赠给OCI（开放容器倡议）组织，并将其更名为Runc，以去除与Docker的关联。Runc主要定义了镜像和运行时的规范。

为防止Docker的垄断，容器领域的几位领军人物成立了CNCF（云原生计算基金会），Kubernetes成为该基金会的代表作，容器编排领域也以K8S的胜出而告终。此时，Docker决定将其containerd组件捐赠给CNCF，以提升自身的存在感。

在2020年，Kubernetes 宣布弃用 dockershim，正式切换到容器运行时接口（CRI）。CRI 是一组接口，用于解耦 Kubernetes 平台与特定容器运行时的实现，最早在 Kubernetes 1.5中引入，充当kubelet和容器运行时之间的桥梁。弃用的主要原因并非 Kubernetes 无法使用 Docker，而是 CRI 的实现不再支持 dockershim，因此只支持兼容 CRI 接口的容器。

要不要放弃使用docker？

继续使用docker的优缺点：

未来面临无法升级和使用高版本K8S环境；
没有增加学习成本。

使用containerd的优缺点：

命令不一样，有学习成本；
暂时的字段格式略有区别；
更简单、更稳定、更高效。

总结来说，Docker 是一个全面的容器管理解决方案，而 containerd 是一个专注于容器运行时的轻量级组件。

docker和containerd区别：

docker和containerd的镜像存储目录不一致，说明他们不是共享的，但是镜像可通用。

Containerd详解

官网：https://containerd.io/

containerd安装

官网下载地址：https://containerd.io/downloads/

# containerd软件包[root@node1 ~]# wget https://github.com/containerd/containerd/releases/download/v1.7.14/containerd-1.7.14-linux-amd64.tar.gz# runc软件包[root@node1 ~]# wget https://github.com/opencontainers/runc/releases/download/v1.2.0-rc.3/runc.amd64# cni软件包wget https://github.com/containernetworking/plugins/releases/download/v1.3.0/cni-plugins-linux-amd64-v1.3.0.tgz注：containerd默认不会自带runc（真正创建容器的程序），所以需要安装runc程序，以及cni网络插件（容器之间网络通信所需）。解压缩，安装tar -zxvf  containerd-1.7.14-linux-amd64.tar.gz -C /usr/local# runc安装install -m 755 runc.amd64 /usr/local/sbin/runc# cni安装mkdir -p /opt/cni/bintar -zxvf /opt/cni/bin cni-plugins-linux-amd64-v1.1.1.tgz# 生成Containerd配置文件containerd config default > /etc/containerd/config.toml# 2条配置修改：# 65行：sandbox_image = "registry.aliyuncs.com/google_containers/pause:3.8" 【修改pause容器镜像为国内】# 137行：SystemdCgroup = true 【让Runc使用system cgroup驱动，对容器进行资源划分，隔离。】# wq保存退出配置Systemd管理Containerd# 下载Containerd官方提供的Service文件：https://raw.githubusercontent.com/containerd/containerd/main/containerd.service# 将内容完整的复制到该路径下： vim /usr/lib/systemd/system/containerd.service启动Containerdsystemctl start containerdsystemctl status containerd● containerd.service - containerd container runtime   Loaded: loaded (/usr/lib/systemd/system/containerd.service; enabled; vendor preset: disabled)   Active: active (running) since 二 2023-06-13 18:55:26 CST; 5h 4min ago     Docs: https://containerd.io  Process: 17524 ExecStartPre=/sbin/modprobe overlay (code=exited, status=0/SUCCESS) Main PID: 17526 (containerd)    Tasks: 9   Memory: 20.8M   CGroup: /system.slice/containerd.service           └─17526 /usr/local/bin/containerd

ctr和crictl使用

可以使用ctr或者crictl进行管理containerd，crictl是为K8S而生，只要当k8s.io命名空间存在才可使用。

ctr操作

## 列出镜像ctr i ls## 拉取镜像ctr i pull docker.io/library/redis:alpine## 查看命名空间ctr ns ls## 运行容器ctr run -t registry.cn-hangzhou.aliyuncs.com/imooc/redis:alpine redis## 查看运行的容器ctr c ls## 查看容器运行任务ctr t ls## 杀死容器ctr t kill redis## 删除容器任务，但是容器中还可以看到，只是停止运行ctr t rm redis## 删除容器ctr c rm redis

crictl操作

## 列出镜像crictl images## 查看容器crictl ps## 查看PODcrictl pods

docker运行的容器在containerd是否看得到？

可以，如下图docker运行容器的容器ID可在containerd的task中匹配进行对应。两者的区别只是命名空间的不同，docker默认用的是default，而containerd使用的是moby，如果是K8S拉起containerd的话，则K8S会默认在containerd拉起并使用一个K8S.io的命名空间。