为什么 Kubernetes 废弃 Docker

Kubernetes（简称 K8s）从 1.20 版本开始宣布废弃对 Docker 作为其默认容器运行时的直接支持（注意：这并不意味着 Docker 不能与 Kubernetes 一起使用，而是通过其他方法间接使用），转而推荐使用 Containerd 或其他兼容的容器运行时（如 CRI-O）。这是一个引发广泛讨论的变化，其中涉及技术架构、性能优化以及 Kubernetes 生态发展的多个方面。以下是具体原因和背后的逻辑：

---

1. 为什么 Kubernetes 废弃 Docker？

1.1 Docker 不是一个完全的容器运行时

Docker 是一个完整的容器管理工具，包含但不限于以下几个部分：

• 镜像管理（Image Management）：用于构建和分发容器镜像。
• 容器运行时（Container Runtime）：实际负责运行容器。
• CLI 工具（Docker CLI）：用于与 Docker 守护进程交互。

然而，Kubernetes 只需要 容器运行时，而 Docker 本身并不完全符合 Kubernetes 的容器运行时接口规范（即 CRI，Container Runtime Interface）。为了让 Docker 兼容 Kubernetes，必须通过一个称为 dockershim 的适配层。这个适配层增加了复杂性和维护成本。

从 Kubernetes 的角度来看，直接使用符合 CRI 标准的容器运行时（如 Containerd 或 CRI-O）会更高效，因为它们可以避免 dockershim 的中间层。

---

1.2 Docker 由多个工具组成，存在额外的开销

Docker 的架构设计目的是为开发者和运维人员提供一个完整的容器化工具链，但这也带来了一些不必要的开销：

• Docker 守护进程（dockerd）需要运行，增加了资源使用率。
• 它包含许多 Kubernetes 不需要的功能（如构建镜像、日志管理等），导致了性能的浪费。
• Kubernetes 只需要一个轻量级、高效的容器运行时，而像 Containerd 和 CRI-O 这样的工具更加精简，可以直接满足需求。

---

1.3 Docker 不符合 Kubernetes 的 CRI 标准

Kubernetes 在 2016 年引入了 CRI（Container Runtime Interface），这是一个用于与容器运行时交互的标准接口。CRI 的目标是：

• 为 Kubernetes 提供一种统一的方式与不同的容器运行时通信。
• 解耦 Kubernetes 和具体的容器运行时，实现多样化和灵活性。

Docker 是在 CRI 出现之前设计的，它并不原生支持 CRI。因此，Kubernetes 必须通过 dockershim 适配层将其连接到 CRI，这使得架构变得复杂且难以维护。相比之下， Containerd 是原生支持 CRI 的，这使它成为更合适的选择。

---

1.4 降低维护成本

Kubernetes 社区需要维护 dockershim 来支持 Docker，而 dockershim 的存在增加了代码复杂性和维护开销：

• Kubernetes 的开发人员需要不断更新 dockershim，以适配 Docker 和 Kubernetes 的新版本。
• 随着 Kubernetes 和社区的发展，减少不必要的组件和维护工作是合理的选择。

通过移除 dockershim，Kubernetes 的代码库可以变得更简单，同时也减少了由于适配层带来的潜在问题。

---

1.5 专注于容器运行时的最佳实践

Containerd 和 CRI-O 是专为容器运行设计的运行时：

• Containerd 是 Docker 的底层组件，由 Docker 公司开发，后来捐赠给 CNCF（Cloud Native Computing Foundation）。它是一个专注于容器运行的轻量级工具，完全符合 Kubernetes 的 CRI 标准。
• CRI-O 是由 Kubernetes 社区开发的一个 CRI 兼容运行时，专注于 Kubernetes 的需求。

这两个工具更加模块化和轻量化，与 Kubernetes 的需求更契合，因此社区更愿意推动它们的使用。

---

2. 为什么选择 Containerd？

Containerd 是 Docker 底层组件的一部分，但它独立于 Docker，主要提供容器生命周期管理功能。以下是选择 Containerd 的具体原因：

2.1 原生支持 CRI

Containerd 是一个 CRI 兼容的容器运行时，与 Kubernetes 的接口完全兼容，可以直接集成到 Kubernetes 中，而无需额外的适配层。

2.2 CNCF 支持

Containerd 是 CNCF（Cloud Native Computing Foundation）旗下的一个项目，与 Kubernetes 同属于 CNCF 生态系统，因此它的长期支持和社区发展都更有保障。

2.3 轻量化和高性能

Containerd 专注于容器运行时功能，没有 Docker 的附加功能（如镜像构建），因此更加轻量化和高效，对系统资源的占用较少。

2.4 Docker 的未来兼容性

虽然 Kubernetes 直接废弃了对 Docker 的支持，但 Docker 本身已经将其容器运行时部分拆分为 Containerd。因此，Containerd 可以看作是 Docker 的未来发展方向。

---

3. Docker 仍然可以和 Kubernetes 一起使用吗？

是的，即使 Kubernetes 废弃了对 Docker 的直接支持，你仍然可以通过其他方式在 Kubernetes 集群中使用 Docker：

3.1 使用 Containerd

Docker 本身依赖于 Containerd 作为其运行时，因此实际上可以通过 Containerd 使用 Docker 提供的功能。换句话说，即使 Kubernetes 放弃了对 Docker 的直接支持，Containerd 仍然可以成为桥梁。

3.2 使用工具兼容

• 如果你仍然需要使用 docker build 或其他 Docker 工具链，可以将其与 Kubernetes 的运行时分开管理。
• 例如，在开发环境中使用 Docker，而在生产环境中使用 Containerd 或 CRI-O。

---

4. 总结

Kubernetes 放弃 Docker 而转向使用 Containerd 或其他 CRI 兼容的容器运行时，主要基于以下几个原因：

1. Docker 不完全符合 CRI 标准：需要通过 dockershim 适配层，这增加了复杂性和维护成本。
2. 性能和资源优化：Docker 的功能过于全面，但 Kubernetes 只需要容器运行时部分，像 Containerd 这样的轻量级工具更高效。
3. 减少社区维护负担：移除复杂的 dockershim 适配层，让 Kubernetes 的代码库更简单。
4. CNCF 生态统一：Containerd 是 CNCF 的项目，与 Kubernetes 更紧密结合。

对于用户而言，虽然 Kubernetes 不再直接支持 Docker，但仍然可以通过 Containerd 等方式将 Docker 集成到 Kubernetes 集群中。总体而言，这一变化可以提升 Kubernetes 的性能、简化架构并支持更灵活的容器运行时选择。