1、Containerd容器运行时

containerd容器运行时

1.什么是containerd

我们知道很早之前的 Docker Engine 中就有了 containerd，只不过现在是将 containerd 从 Docker Engine 里分离出来，作为一个独立的开源项目，目标是提供一个更加开放、稳定的容器运行基础设施。分离出来的 containerd 将具有更多的功能，涵盖整个容器运行时管理的所有需求，提供更强大的支持。

containerd 是一个工业级标准的容器运行时，它强调简单性、健壮性和可移植性，containerd 可以负责干下面这些事情：

管理容器的生命周期（从创建容器到销毁容器）
拉取/推送容器镜像
存储管理（管理镜像及容器数据的存储）
调用 runc 运行容器（与 runc 等容器运行时交互）
管理容器网络接口及网络

2.目前containerd的内部架构

切换到 containerd 可以消除掉中间环节，操作体验也和以前一样，但是由于直接用容器运行时调度容器，所以它们对 Docker 来说是不可见的。因此，你以前用来检查这些容器的 Docker 工具就不能使用了。

你不能再使用 docker ps 或 docker inspect 命令来获取容器信息。由于不能列出容器，因此也不能获取日志、停止容器，甚至不能通过 docker exec 在容器中执行命令。

当然我们仍然可以下载镜像，或者用 docker build 命令构建镜像，但用 Docker 构建、下载的镜像，对于容器运行时和 Kubernetes，均不可见。为了在 Kubernetes 中使用，需要把镜像推送到镜像仓库中去。

从上图可以看出在 containerd 1.0 中，对 CRI 的适配是通过一个单独的 CRI-Containerd 进程来完成的，这是因为最开始 containerd 还会去适配其他的系统（比如 swarm），所以没有直接实现 CRI，所以这个对接工作就交给 CRI-Containerd 这个 shim 了。

然后到了 containerd 1.1 版本后就去掉了 CRI-Containerd 这个 shim，直接把适配逻辑作为插件的方式集成到了 containerd 主进程中，现在这样的调用就更加简洁了。

3.containerd架构

containerd 可用作 Linux 和 Windows 的守护程序，它管理其主机系统完整的容器生命周期，从镜像传输和存储到容器执行和监测，再到底层存储到网络附件等等。

上图是 containerd 官方提供的架构图，可以看出 containerd 采用的也是 C/S 架构，服务端通过 unix domain socket 暴露低层的 gRPC API 接口出去，客户端通过这些 API 管理节点上的容器，每个 containerd 只负责一台机器，Pull 镜像，对容器的操作（启动、停止等），网络，存储都是由 containerd 完成。具体运行容器由 runc 负责，实际上只要是符合 OCI 规范的容器都可以支持。

为了解耦，containerd 将系统划分成了不同的组件，每个组件都由一个或多个模块协作完成（Core 部分），每一种类型的模块都以插件的形式集成到 Containerd 中，而且插件之间是相互依赖的，例如，上图中的每一个长虚线的方框都表示一种类型的插件，包括 Service Plugin、Metadata Plugin、GC Plugin、Runtime Plugin 等，其中 Service Plugin 又会依赖 Metadata Plugin、GC Plugin 和 Runtime Plugin。每一个小方框都表示一个细分的插件，例如 Metadata Plugin 依赖 Containers Plugin、Content Plugin 等。比如:

Content Plugin: 提供对镜像中可寻址内容的访问，所有不可变的内容都被存储在这里。
Snapshot Plugin: 用来管理容器镜像的文件系统快照，镜像中的每一层都会被解压成文件系统快照，类似于 Docker 中的 graphdriver。

总体来看 containerd 可以分为三个大块：Storage、Metadata 和 Runtime。

注意：containerd里面相对于之前我们的docker，它多了一个tasks内容，tasks其实就相当于是一个任务，这个任务它要去运行一个容器的话它是要依赖于这个runtimes的，就是tasks它不是真正的容器。

4.containerd客户端命令工具

containerd这一块的镜像和docker中还是非常相似的；

containerd的镜像管理工具crictl也符合docker的命名规范，因此切换后难度也不是很大；

前面我们介绍了可以使用 ctr 操作管理 containerd 镜像容器，但是大家都习惯了使用 docker cli，ctr 使用起来可能还是不太顺手，为了能够让大家更好的转到 containerd 上面来，社区提供了一个新的命令行工具：nerdctl。nerdctl 是一个与 docker cli 风格兼容的 containerd 客户端工具，而且直接兼容 docker compose 的语法的，这就大大提高了直接将 containerd 作为本地开发、测试或者单机容器部署使用的效率。

FAQ

如何查看containerd与k8s版本之间的兼容性？

🍀

gpt：如何查看containerd与k8s版本之间的兼容性？

如何查看containerd与k8s版本之间的兼容性？

查看 containerd 与 Kubernetes (k8s) 版本之间的兼容性通常需要参考它们的官方文档或发布说明。以下是一些一般性步骤，以帮助您了解它们之间的兼容性：

查看 Kubernetes 官方文档：首先，您可以查看 Kubernetes 官方文档，了解每个 Kubernetes 版本所建议的 containerd 版本。 Kubernetes 维护一个文档，其中包含了与各种容器运行时的兼容性信息。
查看 containerd 官方文档：同样，您也可以查看 containerd 的官方文档，以了解不同 containerd 版本与 Kubernetes 的兼容性。 containerd 通常会发布有关其与 Kubernetes 的兼容性信息的文档或发布说明。
查看社区资源：除了官方文档，您还可以查看 Kubernetes 和 containerd 社区的资源，如邮件列表、论坛或 GitHub 存储库。这些资源可能包含有关兼容性问题和最佳实践的讨论。
查看容器平台的文档：有时，容器平台（如 Docker、CRI-O 等）也会提供有关其与 Kubernetes 的兼容性信息，因为它们作为 Kubernetes 容器运行时的替代方案。
测试和验证：最终，为了确保兼容性，最好进行测试和验证。在您的测试环境中尝试安装所需的 containerd 和 Kubernetes 版本，然后运行一些工作负载，以确保它们可以正常运行并且没有不兼容的问题。

请注意，containerd 和 Kubernetes 的兼容性信息可能会随着版本更新而变化，因此始终参考官方文档和资源以获取最新的信息是非常重要的。此外，还要牢记，特定的 Linux 发行版和容器操作系统也可能影响 containerd 与 Kubernetes 的兼容性，因此要确保这些组件也是与所选版本兼容的。

🍀

containerd github参考

https://github.com/containerd/containerd/blob/main/RELEASES.md#kubernetes-support