在不断发展的容器化世界中，两个关键组件经常被混淆：Dockershim 和 containerd。虽然它们在管理容器方面都发挥着重要作用，但它们的用途却截然不同。本文深入探讨了它们的功能，深入探讨了 Dockershim 和 containerd 之间的区别。
揭秘 Dockershim：Docker Orchestrator Bridge
Dockershim 是 Docker 运行时垫片的缩写，是 Kubernetes 容器编排平台中的一个特定组件。它的主要功能是充当 Kubernetes 和 Docker 之间的桥梁。以下是 Dockershim 角色的细分：
- Kubernetes 通信： Kubernetes 使用容器运行时接口 (CRI) 与容器运行时进行交互。Dockershim 将 Kubernetes 的 CRI 请求转换为容器引擎 Docker 能够理解的命令。
- Docker 引擎集成： Dockershim 依赖 Docker 引擎的功能来管理容器生命周期（创建、启动、停止、删除）。它本质上充当 Kubernetes 的转换器，以利用 Docker 的功能。
Dockershim 的缺点：
虽然 Dockershim 最初达到了其目的，但它也有局限性：
- 供应商锁定：它将 Kubernetes 与 Docker 绑定在一起，阻碍了使用替代容器运行时（例如 containerd 或 CRI-O）。
- 功能有限： Dockershim 仅提供了像 containerd 这样的成熟容器运行时所提供的部分功能。
进入 containerd：通用容器运行时
另一方面，Containerd 是一个轻量级容器运行时，它为管理容器镜像、进程和存储提供了底层基础。它拥有几个关键功能：
- 供应商无关：与 Dockershim 不同，containerd 的设计与容器编排平台或容器引擎无关。它实现了 CRI，允许各种编排器（如 Kubernetes）直接与其交互。
- 丰富的功能：与 Dockershim 相比，Containerd 提供的功能更加丰富，包括镜像管理、进程监控、检查点和沙盒功能。
- 独立运行： Containerd 可以独立于 Docker 或任何其他容器引擎运行。它提供模块化方法，允许用户选择最适合其需求的镜像管理工具。
containerd的崛起：
Containerd 的灵活性和功能使其成为寻求摆脱供应商锁定的容器编排平台的自然选择。结果：
- Kubernetes 和 containerd： Kubernetes 已从 Dockershim 转型，使 containerd 成为大多数部署的默认容器运行时。
- Docker 拥抱 containerd：有趣的是，Docker 本身现在在底层利用 containerd，利用其功能进行自己的容器管理。
Dockershim 与 containerd：正面比较
结论：Dockershim 的基础和 containerd 的未来
虽然 Dockershim 在 Kubernetes 早期发挥了重要作用，但 containerd 的灵活性和功能集使其成为容器编排平台的首选。随着容器化的不断发展，containerd 将继续成为一项基石技术，为管理容器化应用程序提供强大且与供应商无关的基础。
