K8S使用docker时，为什么需要使用dockershim?

在 Kubernetes 中，dockershim 是一个兼容层，旨在让 Kubernetes 与 Docker 容器运行时兼容。它充当了 Kubernetes 与 Docker 之间的桥梁，使得 Kubernetes 能够通过 Docker 来启动、管理容器，而不需要直接与 Docker 的底层 API 交互。

为什么 Kubernetes 需要 dockershim？

在 Kubernetes 最初的版本中，Kubernetes 使用 Docker 作为其容器运行时。当时，Docker 提供了一个容器运行时接口（Docker Engine API），而 Kubernetes 需要一个统一的方式来与各种容器运行时（包括 Docker）进行交互。为了让 Kubernetes 与 Docker 兼容，Kubernetes 依赖于 dockershim 来实现这一目的。

dockershim 是 Kubernetes 用来连接和管理 Docker 容器的桥梁，它封装了 Kubernetes 与 Docker 之间的通信细节。Kubernetes 的 Container Runtime Interface (CRI) 规范定义了容器运行时与 Kubernetes 的交互标准，而 dockershim 则是这个标准与 Docker 的实现。

具体来说，dockershim 的作用是：

1. 1. 桥接 CRI 与 Docker API： Kubernetes 的 CRI 是容器运行时与 Kubernetes 系统交互的标准接口。Docker 本身并没有原生实现 CRI，而是提供了自己的 API 和接口。因此，Kubernetes 需要 dockershim 来将 Kubernetes 的 CRI 调用转化为 Docker 容器运行时能够理解的 Docker API 调用。
2. 2. 容器管理： Kubernetes 通过 CRI 调用容器的生命周期管理（如启动、停止、拉取镜像等），而 dockershim 会把这些 CRI 调用转发到 Docker 引擎，利用 Docker 引擎的功能来管理容器。
3. 3. 兼容性层： 在 Docker 被作为 Kubernetes 容器运行时时，dockershim 充当了一个中间层，它为 Kubernetes 提供了与 Docker 交互的能力，保持了 Kubernetes 的高可用性和容器管理功能，同时与 Docker 进行兼容。

为什么 Kubernetes 逐渐弃用 dockershim？

从 Kubernetes v1.20 开始，Kubernetes 团队宣布将不再将 dockershim 作为默认的容器运行时，计划在后续版本中弃用它。弃用的主要原因如下：

1. 1. Kubernetes 和 Docker 目标不一致：
   • • Docker 是一个完整的容器化平台，除了容器运行时，还包括镜像构建、容器管理、容器编排等功能。对于 Kubernetes 来说，它只需要一个专注于容器生命周期管理的轻量级容器运行时。
   • • Docker 的复杂性和额外的功能（例如镜像构建、容器编排等）对于 Kubernetes 来说是多余的，这增加了系统的开销和复杂度。Kubernetes 需要的是一个专注于容器管理的轻量级工具，Containerd 和 CRI-O 更符合这一需求。
2. 2. 性能和稳定性：
   • • Docker 作为一个包含了镜像构建、镜像管理、容器运行等多种功能的大型平台，存在一些 Kubernetes 不需要的功能。运行这些额外功能会增加 Kubernetes 节点的资源占用和复杂度。
   • • Containerd 是从 Docker 中拆分出来的专注于容器生命周期管理的项目，相比 Docker 更加轻量和高效。它提供了 Kubernetes 需要的所有功能，而且不需要中间层（如 dockershim）。
3. 3. CRI 的原生支持：
   • • Containerd 和 CRI-O 已经原生支持 Container Runtime Interface (CRI)，这使得它们可以直接与 Kubernetes 进行交互，避免了像 dockershim 这样的兼容层。
   • • dockershim 需要额外的工作来桥接 Kubernetes 和 Docker，而使用 Containerd 和 CRI-O 则可以简化架构，减少维护的复杂性。
4. 4. Kubernetes 生态的清晰发展方向：
   • • Kubernetes 社区认为，Docker 作为容器构建工具的角色已经不再适合与 Kubernetes 紧密集成。为了避免未来 Kubernetes 的核心组件与 Docker 的复杂性耦合，决定不再通过 dockershim 支持 Docker，转而支持更轻量、标准化的容器运行时（如 Containerd 和 CRI-O）。
5. 5. 社区支持和未来发展：
   • • Kubernetes 社区越来越多地采用 Containerd 和 CRI-O，而这两个容器运行时已经得到了 CNCF（Cloud Native Computing Foundation）和 Kubernetes 社区的强力支持。Docker 自 2020 年以来已经不再是容器运行时的推荐标准，Containerd 和 CRI-O 被认为是 Kubernetes 最优的容器运行时选择。

dockershim 的弃用对 Kubernetes 集群的影响

1. 1. 不再需要 Docker：
   • • 从 Kubernetes v1.20 起，Kubernetes 集群可以不再使用 Docker 作为容器运行时，而是可以选择 Containerd 或 CRI-O。这意味着，集群管理员不再需要依赖 Docker 作为 Kubernetes 的容器运行时。
2. 2. 集群配置简化：
   • • 由于 Containerd 和 CRI-O 都是 Kubernetes 原生支持的容器运行时，弃用 dockershim 后，集群配置将变得更加简洁和一致。无需再进行额外的兼容配置，减少了 Kubernetes 集群的复杂性和潜在的故障点。
3. 3. 容器运行时的更高性能：
   • • Containerd 和 CRI-O 专注于容器的生命周期管理，去除了 Docker 中一些不必要的功能，因此它们更为轻量，性能更高。在容器管理方面，它们能够提供比 Docker 更高的效率，尤其是在大型 Kubernetes 集群中。

总结

• • dockershim 是 Kubernetes 与 Docker 容器运行时之间的桥梁，它使得 Kubernetes 能够通过 Docker 来管理容器。
• • Kubernetes 逐渐弃用 dockershim，转而推荐使用更轻量、专注的容器运行时如 Containerd 和 CRI-O，因为它们原生支持 Kubernetes 的 CRI，并且不需要额外的中介层，从而提高了集群的性能和稳定性。
• • 弃用 dockershim 可以减少 Kubernetes 集群的复杂性，简化维护工作，并且提高系统的效率。