K8s容器运行时，移除Dockershim后存在哪些疑惑？

K8s容器运行时，移除Dockershim后存在哪些疑惑？

大家好，我是秋意零。

K8s版本截止目前（24/09）已经发布到了1.31.x版本。早在K8s版本从1.24.x起（22/05），默认的容器运行时就不再是Docker了或者说Dockershim。

发行版本 | Kubernetes

Patch Releases | Kubernetes

最直接的原因，就是影响了性能。因为K8s调用Docker中Containerd容器运行时需要一个中间层Dockershim，造成了多余的性能和系统稳定性问题。具体是怎么个事呢，这里就来捋上一捋！同时介绍runc、ctr、crictl、nerdctl都是怎么个事！

内心OS：1.24第一版本早在22/05就发布了，距今已经过去2年多了。现在才来捋属实感觉有点晚了，不知有没有朋友和我一样一直没有捋明白呢😬！

如果是 那就接着往下看，有用点个赞、评论明白了😘！

Containerd 简介

官方解释：containerd 是一种行业标准的容器运行时，强调简单性、健壮性和可移植性。它可作为 Linux 和 Windows 的守护进程使用，可以管理其主机系统的完整容器生命周期：镜像传输和存储、容器执行和监督、底层存储和网络附件等。

一句话总结：Containerd 是一种基于 CRI 的容器运行时，用于管理容器的生命周期。

PS：

• 容器运行时：是负责运行容器的软件

• CRI：这个接口是 Kubernetes 与容器运行时交互的标准接口

K8s架构理解：【探索 Kubernetes|容器基础进阶篇 系列 4】理解现代云原生时代的引擎

捋上一捋

1）为什么不继续使用Docker作为运行时

Docker并不是一个“物件”，他是一个完整技术栈。它技术栈中有一个叫做 “containerd” 的部件本身，才是一个容器运行时。

执行yum install docker-ce，验证Docker是否包含Containerd，最简单的方式。

Docker 它提供了很多用户体验增强功能，而这简化了我们用户开发工作时的操作。然而 Kubernetes 用不到这些增强的用户体验，毕竟它并非人类。

因为这个用户友好的抽象层，Kubernetes 集群不得不引入一个叫做 Dockershim 的工具来访问它真正需要的 containerd。 这不是一件好事，因为这引入了额外的运维工作量，同时影响性能与稳定性，而且还可能出错。

2）为什么K8s不直接访问Docker中的Containerd组件，为什么需要Dockershim呢？

Docker Engine 没有实现（CRI）接口，因此 Kubernetes 项目创建了特殊代码来帮助过渡， 并使 Dockershim 代码成为 Kubernetes 的一部分。Dockershim 代码一直是一个临时解决方案（因此得名：shim 垫片）。

如果 Docker 兼容 CRI，就不需要这个 Dockershim 了。

3）Docker构建/拉取的镜像，K8s还能使用嘛？

Docker 构建的镜像并不是 Docker 特有的镜像，它是一个基于 OCI 的镜像。任一以 OCI 为标准构建的镜像，K8s都是可以使用的。

PS：

• OCI：定义了容器运行时的规范和镜像格式规范

K8s架构理解：【探索 Kubernetes|容器基础进阶篇 系列 4】理解现代云原生时代的引擎

Containerd 与 runc 关系

官方解释：runc是一个 CLI 工具，用于根据 OCI 规范在 Linux 上生成和运行容器。

GitHub - opencontainers/runc

1）Containerd 与 runc 关系

Containerd 的运行时要求非常低。与 Linux 和 Windows 容器功能集的大多数交互都是通过 runc 和特定于操作系统的库处理的。所有Containerd 依赖于 runc 来实现具体功能。

• runc 是一个低级别的工具，用于创建、运行和管理容器的进程。它是容器运行时（container runtime）的一部分，主要用于执行容器内的应用程序。runc 实现了 OCI（Open Container Initiative）规范，允许开发者以标准化的方式创建和运行容器。
• Containerd 是一个更高层次的容器管理系统，它负责管理容器的整个生命周期，包括容器的创建、启动、停止以及镜像的管理等。Containerd 提供了一个稳定、可插拔的架构，允许开发者以高度可定制的方式管理和编排容器。

**总结：**Containerd 和 runc 之间的关系可以类比为主管与执行者的关系。Containerd 作为主管，负责高层次的管理工作，如容器和镜像的生命周期管理，而 runc 作为执行者，负责具体容器进程的创建和运行。

ctr、crictl、nerdctl 分不清？

1）ctr 是 containerd 的原生自带命令行客户端工具，主要用于与 containerd 进行低级别的交互。它提供了对 containerd 的全面管理能力，包括镜像管理、容器管理、沙箱管理等。

2）crictl 是 Kubernetes Container Runtime Interface (CRI) 的客户端工具，用于与实现了 CRI 接口的容器运行时（如 containerd 或 Docker）进行交互。它提供了类似于 docker 命令的高级功能，使得用户可以方便地管理容器和镜像。

3）nerdctl 是 containerd 的另一个命令行工具，它的设计目标是提供一个与 docker 命令相似的体验，使得用户可以无缝地从 Docker 迁移到 containerd。nerdctl 提供了许多与 docker 命令相同的子命令，使得迁移更加简便。但只支持 containerd 容器运行时。

常用操作指令

Containerd容器运行时，存在NameSpace的概念。创建好K8s集群后Containerd中存在两个名称空间default与k8s.io

NameSpace就好比，Windows系统中的文件夹，每个NameSpace内容相互隔离。

注意：与K8s的名称空间类似，不过不要搞混了。K8s名称空间是隔离资源，Containerd名称空间是隔离镜像。

ctr、crictl、nerdctl

1. ctr 默认采用 default 名称空间

   切换名称空间：-n参数选择不同的名称空间ctr -n k8s.io images ls

2. crictl 默认采用 k8s.io 名称空间

3. nerdctl 默认采用 default 名称空间

   切换名称空间：在 /etc/nerdctl/nerdctl.toml 中添加或修改配置 namespace = "k8s.io"

1）Ctr（不常用，可忽略，了解即可）

镜像管理

1. 查看镜像
ctr images ls # images可以简写为i。如：ctr i ls 
查看指定名称空间镜像
ctr -nk8s.io images ls
2. 下载镜像
ctr image pull <镜像名称>
3. 删除镜像
ctr image rm <镜像名称>
4. 镜像导出
ctr i export <导出名称> <需要导出的源镜像名称>
5. 镜像导入
ctr i import <镜像被导出时的镜像名称>
6. 修改tag
ctr images tag <源镜像名称> <>
7. 查看名称空间
ctr ns ls

容器管理

1. 查看运行的容器
ctr container ls  # container可以简写为c。如：ctr c ls 
2. 创建容器
ctr container create <镜像名称> <容器名称>
3. 查看容器中跑的进程
ctr task ls
4. 停止容器
ctr tasks kill <容器名称>
5. 删除容器
ctr tasks delete <容器名称>

crictl、nerdctl常用指令，就不列出来，网上可以找到很多。

2）crictl

crictl 常见的命令大全 (aliyun.com)

3）nerdctl

简单的nerdctl命令使用，操作手册-CSDN博客

参考

容器运行时 | Kubernetes

GitHub - containerd/containerd：开放可靠的容器运行时

End