Kubernetes 为什么要从 docker 切换 ContainerD

Docker 和 containerd 的关系

1. Docker 的结构：Docker 是一个完整的容器管理工具，提供了从镜像构建、容器运行到容器编排的全栈功能。它的结构本质上分为两部分：

   Docker CLI：用户与 Docker 交互的命令行工具。

   Docker Engine：负责容器生命周期管理的核心组件，包括镜像管理、容器运行、网络、存储等。

2. containerd 的定位：

   containerd 是一个容器运行时（container runtime），它是 Docker Engine 的核心组件之一，负责容器的低层管理任务，例如：下载和存储镜像。创建和运行容器。管理存储和网络。

   Docker 在 2017 年将 containerd 捐赠给了 CNCF（Cloud Native Computing Foundation），使其成为一个独立的开源项目。

   换句话说，Docker Engine 是一个高层封装，containerd 是 Docker Engine 内部使用的底层运行时。

3. 关系概述：

   Docker 通过调用 containerd 来管理容器的生命周期。

   containerd 是 Docker 的子组件，但可以独立使用，特别是在 Kubernetes 等场景下。

Kubernetes 从 Docker 切换到 containerd 的原因

Kubernetes 的容器运行时接口（CRI, Container Runtime Interface）允许其使用不同的容器运行时。Docker 并不是直接实现 CRI 的运行时，而是通过一个插件（dockershim）间接支持 Kubernetes。Kubernetes 从 Docker 切换到 containerd 的主要原因包括：

1. dockershim 的移除：

   Docker 本身并不直接支持 CRI，Kubernetes 借助 dockershim（一个适配层）来与 Docker 交互。

   维护 dockershim 增加了 Kubernetes 项目的复杂性，因此 Kubernetes 社区决定在 1.20 版本宣布弃用 dockershim，并在 1.24 版本彻底移除。

   containerd 是原生支持 CRI 的运行时，可以直接与 Kubernetes 通信，无需额外的适配层。

2. 性能和效率：

   containerd 是一个轻量级、专注于运行时功能的项目，性能更高，开销更小。

   Docker 是一个全栈工具，包含了许多 Kubernetes 不需要的功能（如 CLI 和镜像构建功能），在 Kubernetes 中显得冗余。

3. 简化容器运行时生态：

   切换到 containerd 后，Kubernetes 的容器运行时管理更加简单和高效，减少了中间层（dockershim）带来的复杂性。

影响分析

从 Docker 切换到 containerd 对 Kubernetes 的影响主要体现在以下几个方面：

1. 对 Kubernetes 集群的影响

• 正面影响：减少了 Kubernetes 和容器运行时之间的中间层（dockershim），提高了性能和运行时一致性。使用 containerd 后，Kubernetes 的运行时更贴合云原生标准（CRI）。

• 潜在问题：如果用户使用了 Docker 的特定功能（如 docker build 构建镜像、Docker CLI 管理容器等），需要额外适配或更改工作流。

2. 对开发者和运维的影响

• 镜像构建和管理：Docker 提供了强大的 CLI 和 docker build 功能，而 containerd 并不支持镜像构建。如果用户依赖 Docker CLI 构建镜像，需要切换到其他工具（如 BuildKit、Kaniko 或 Podman）。

• 调试和管理：Docker 提供了丰富的命令行工具用于调试和管理容器，而 containerd 则需要使用工具如 crictl 或直接与 Kubernetes API 交互。运维团队需要学习新的工具和流程。

3. 对生态系统的影响

• 更贴合云原生标准：containerd 是 CNCF 的项目，支持 CRI，切换后 Kubernetes 的架构更加标准化。

• 镜像构建工具的分离：由于 Docker CLI 不再是核心工具，镜像构建工具和运行时工具的职责更加明确（如使用 BuildKit 构建镜像、使用 containerd 运行容器）。

总结

• Docker 和 containerd 的关系：containerd 是 Docker Engine 的核心运行时组件，可以独立使用。

• Kubernetes 切换到 containerd 的原因：移除 dockershim 以简化架构。提高性能和效率。更贴合云原生标准。

• 切换的影响：Kubernetes 集群运行时更高效，但需要调整与 Docker CLI 相关的工作流。运维和开发团队需要学习新的工具（如 crictl）。

对于用户来说，切换到 containerd 可能需要额外的适配，但从长远来看，这种转变有助于 Kubernetes 的可维护性和性能优化。