Kubernetes 为什么减少对 Docker 的依赖：容器运行时演进背后的技术考量

引言

容器技术的发展离不开 Docker 和 Kubernetes 的深度合作。Docker 推动了容器化技术的普及，而 Kubernetes 则为大规模容器编排和自动化管理提供了强有力的支持。然而，随着 Kubernetes 逐步发展，尤其是在容器运行时（Container Runtime）方面的需求发生变化，Kubernetes 在 1.20 版本中宣布将减少对 Docker 的依赖，并计划在 1.24 版本后停止维护 dockershim。这一决策引发了业界广泛关注，许多开发者和运维人员纷纷发问：“为什么 Kubernetes 要减少对 Docker 的依赖？” 本文将深入分析这一变动背后的原因，探讨容器运行时演进的技术驱动，并展望未来容器技术生态的发展趋势。

Kubernetes 与 Docker：最初的深度依赖

Kubernetes 自诞生以来，Docker 一直是其默认的容器运行时。作为一款完整的容器平台，Docker 提供了从容器镜像构建、容器启动、管理到镜像分发等全面功能，而 Kubernetes 作为容器编排工具，负责大规模容器的调度和管理。最初，Kubernetes 通过 Docker 提供的容器引擎来执行容器生命周期管理，这一合作使得二者成为容器化技术的黄金搭档，推动了容器技术的广泛应用。

然而，随着 Kubernetes 功能的不断扩展，特别是对容器运行时的高效性、灵活性和可扩展性提出了新的要求，Kubernetes 开始寻求更加精简且专注于容器生命周期管理的容器运行时。这一转型的契机出现在 Kubernetes 1.20 版本中，引入了容器运行时接口（CRI）和其它容器运行时的支持，最终在 Kubernetes 1.24 版本后正式停止维护 dockershim（Kubernetes 对 Docker 的兼容层），标志着 Kubernetes 开始减少对 Docker 的依赖。

从依赖到转型：Kubernetes 为什么减少对 Docker 的依赖

随着容器编排的需求不断发展，Docker 作为容器运行时的局限性逐渐显现，特别是在大规模生产环境中。Kubernetes 渴望通过采用更加轻量、专注于容器生命周期管理的容器运行时来提升效率。减少对 Docker 的依赖，实际上是 Kubernetes 在容器技术发展中的一个必然步骤。

1. Docker 的功能过于庞大

Docker 作为容器化平台，其功能远不止容器的运行和管理，还涵盖了镜像构建、容器网络管理、日志管理等多个方面。尽管这些功能对于开发人员来说非常有用，但 Kubernetes 在生产环境中对容器的管理需求相对简单，主要集中在容器的生命周期管理（启动、停止、调度等），而对其他诸如镜像构建、容器网络管理等功能并不依赖。

Kubernetes 的核心目标是提高容器调度和管理的效率，因此它希望能够采用更加精简的容器运行时，只关注容器的管理，而将其他功能交给更专门的工具来完成。Docker 的多功能性使得它作为容器运行时，包含了 Kubernetes 并不需要的复杂性和资源开销。因此，Kubernetes 寻求通过更简化的容器运行时来降低系统复杂度，提高运行效率。

2. 容器运行时接口（CRI）的引入

为了支持不同的容器运行时，Kubernetes 引入了 容器运行时接口（CRI），它是 Kubernetes 和容器运行时之间的标准接口。通过 CRI，Kubernetes 可以与多个容器运行时（如 containerd 和 CRI-O）进行集成，而不需要依赖某一个特定的容器引擎。CRI 为 Kubernetes 提供了更强的灵活性，使其能够根据不同需求选择合适的容器运行时。

虽然 Docker 支持 CRI，但 Docker 的实现较为臃肿，需要启动多个进程来支持容器的管理。这增加了 Kubernetes 集群的资源开销，并使得系统在性能上存在潜在瓶颈。相比之下，containerd 和 CRI-O 作为轻量级容器运行时，专注于容器的生命周期管理，符合 CRI 规范，能够显著减少资源消耗，提升系统的效率和可扩展性。

3. 更加轻量化的替代品：containerd 和 CRI-O

为了减少对 Docker 的依赖，Kubernetes 转向了更加专注于容器生命周期管理的轻量级容器运行时。containerd 和 CRI-O 是这方面的主要代表，它们都遵循 CRI 标准，专门为 Kubernetes 设计，去除了 Docker 中不必要的功能，如镜像构建、CLI 工具、容器网络等，这使得它们在 Kubernetes 环境中更加高效。

containerd 最初是 Docker 的子项目，后来成为独立的容器运行时，专注于容器的生命周期管理，包括容器的创建、启动、暂停、恢复等。它符合 OCI（Open Container Initiative）标准，是目前 Kubernetes 推荐的容器运行时之一。

CRI-O 是由 Kubernetes 社区开发的一个容器运行时，它专注于 Kubernetes 集群中的容器管理，并实现了 Kubernetes 的 CRI 规范。与 Docker 不同，CRI-O 通过去除不必要的功能，提升了 Kubernetes 集群的性能，特别适合大规模容器编排。

这些容器运行时相比 Docker 更加轻量、高效，能够显著减少 Kubernetes 集群中的资源开销，并提升容器管理的性能。

为什么 Docker 依然重要

尽管 Kubernetes 减少了对 Docker 作为容器运行时的依赖，但 Docker 在容器生态系统中依然扮演着重要角色，尤其是在容器镜像的构建、管理和分发方面。Docker 提供了强大的镜像构建工具，支持多种开发语言和平台的容器化，使得开发者能够快速构建并测试容器镜像。

Kubernetes 仍然完全支持 Docker 镜像格式（即 OCI 镜像标准），这意味着用户可以继续使用 Docker 构建镜像并将其部署到 Kubernetes 集群中。虽然 Kubernetes 在生产环境中转向更加精简的容器运行时，但 Docker 在开发、构建和分发容器镜像的过程中，仍然是一个无可替代的工具。

Kubernetes 1.24：dockershim 的正式废弃

Kubernetes 在 1.20 版本时宣布减少对 Docker 的依赖，而在 1.24 版本中正式停止了对 dockershim 的维护。dockershim 是 Kubernetes 为了与 Docker 兼容而开发的兼容层，它允许 Kubernetes 使用 Docker 作为容器运行时。然而，随着容器运行时接口（CRI）的普及和更加轻量的容器运行时的出现，Kubernetes 认为 dockershim 的维护已不再必要。

在 Kubernetes 1.24 版本后，Kubernetes 将不再为 Docker 提供专门的支持，意味着 Kubernetes 集群中的容器运行时将不再依赖 Docker，转而使用 containerd 或 CRI-O 等更精简的容器运行时。

未来展望：容器技术的模块化与标准化

Kubernetes 减少对 Docker 的依赖，标志着容器技术生态的逐步模块化和标准化。容器技术正在走向更加开放和灵活的方向，通过 CRI 标准，Kubernetes 可以根据自身的需求选择最合适的容器运行时。与此同时，Docker 作为容器镜像构建和管理工具，仍将在容器化生态中占据核心地位。

这一变化推动了容器技术的标准化，使得容器运行时不再是单一选择，开发者可以根据不同的使用场景和需求选择合适的容器运行时。容器技术的多样化将促进整个生态的健康发展，提高容器应用的可移植性和互操作性。

结语

Kubernetes 减少对 Docker 的依赖，体现了容器技术生态的演化。通过容器运行时接口（CRI）的引入，Kubernetes 可以根据不同的需求灵活选择容器运行时，而 Docker 依旧在容器镜像构建和管理方面发挥着重要作用。Docker 和 Kubernetes 在容器生态中各司其职，共同推动容器化技术向着更加高效、标准化、模块化的方向发展。

未来，Docker 和 Kubernetes 将继续在各自的领域内发挥着重要作用，推动容器化技术的创新与进步。

活动推荐

本周六（12月28日）下午，KubeSphere 社区联合 Higrass社区 在广州市阿里中心举办 云原生+AI Meetup，分享AI 网关开发、多集群架构、GitOps 实践等内容，聚焦云原生 AI 技术的落地难点，欢迎大家来玩！

本文由博客一文多发平台 OpenWrite 发布！