Docker和containerd之概览(Overview of Docker and Containerd)
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 runtimeLoaded: loaded (/usr/lib/systemd/system/containerd.service; enabled; vendor preset: disabled)Active: active (running) since 二 2023-06-13 18:55:26 CST; 5h 4min agoDocs: https://containerd.ioProcess: 17524 ExecStartPre=/sbin/modprobe overlay (code=exited, status=0/SUCCESS)Main PID: 17526 (containerd)Tasks: 9Memory: 20.8MCGroup: /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的命名空间。

