为什么k8s不支持docker-kubernetes

 为什么Kubernetes不再支持Docker？

在Kubernetes 1.20版本之后，Kubernetes宣布逐步停止对Docker作为容器运行时的支持。这一改变在容器管理领域引起了广泛关注。许多人不禁疑惑：Kubernetes与Docker一向密切合作，为何会做出这样的决定？本文将深入解析Kubernetes与Docker之间的关系变化，探讨这一转变背后的原因，以及对用户和开发者的影响。

1. Kubernetes和Docker的关系：从合作到转变

Kubernetes最初在设计时，是为了协调管理Docker容器，提供了自动化的容器调度和集群管理能力。然而，Docker本身不仅仅是一个容器运行时，它还包括开发工具和镜像管理功能。Kubernetes使用Docker作为运行时，需要依赖一个称为Dockershim的适配层，以实现与Docker的通信。Dockershim是一个中间层，负责将Kubernetes的指令转换为Docker能够理解的格式，并通过Docker来启动和管理容器。

然而，Dockershim带来的架构复杂性和维护成本逐渐成为Kubernetes发展的负担。Kubernetes社区长期以来都计划去除这个额外的中间层，并转向使用更符合Kubernetes标准的运行时接口（Container Runtime Interface, CRI）。

2. 容器运行时接口（CRI）：简化运行时管理

为了让Kubernetes支持多种容器运行时，社区在Kubernetes 1.5版本引入了CRI标准。CRI是一组标准化接口，旨在让Kubernetes的核心组件Kubelet能够与任何支持CRI的容器运行时进行通信。通过CRI，Kubernetes可以与如containerd和CRI-O这样的轻量级运行时直接集成，避免了像Dockershim这样的额外适配层。

Docker并未原生支持CRI，因此，Kubernetes团队需要通过维护Dockershim来使Docker运行时与Kubernetes兼容。然而，随着containerd等CRI兼容运行时逐渐成熟且稳定，Kubernetes社区决定不再继续维护Dockershim，这样可以简化Kubernetes的代码库，提升系统的效率和稳定性。

3. Docker被弃用的技术原因

• 架构简化与性能优化：Docker是一个全面的容器管理工具，不仅包括容器运行时，还包括开发、构建、镜像管理等功能。然而，对于Kubernetes而言，只需要一个负责运行容器的基础组件，因此Docker显得过于复杂。通过直接使用containerd等轻量化的CRI兼容运行时，Kubernetes可以减少系统层级间的额外消耗和复杂性。

• 减少维护负担：维护Dockershim需要额外的人力和代码管理。随着社区对CRI标准的完善，使用专门为Kubernetes设计的运行时（如containerd和CRI-O）可以减少维护复杂性，提高系统的兼容性和稳定性。

4. 这对用户的影响：Docker镜像依然可用

值得注意的是，Kubernetes停止支持Docker作为运行时，并不意味着完全放弃Docker。Docker依然在容器开发和镜像构建中发挥着重要作用，用户仍然可以使用Docker镜像来构建应用程序，并将这些镜像部署在Kubernetes集群上。Kubernetes只是建议在生产环境中使用更轻量化的容器运行时。

对于已经在使用Docker作为运行时的Kubernetes用户，Kubernetes在1.20版本发布后提供了过渡期，给开发者足够的时间迁移到containerd或CRI-O等其他运行时。在1.22版本之后，Dockershim被完全移除，用户必须确保使用的运行时符合CRI标准。

5. 未来的发展趋势：从Docker到容器生态的多样化

Kubernetes逐步脱离对Docker的依赖，标志着容器生态系统的成熟与多样化。通过CRI接口，Kubernetes为不同类型的运行时提供了统一的标准，使得用户可以根据自己的需求选择最合适的运行时，如：

• containerd：由Docker公司开发，但专注于容器运行时部分，与Kubernetes深度集成，成为大多数Kubernetes发行版的默认选择。
• CRI-O：由Red Hat开发的轻量级容器运行时，专为Kubernetes设计，支持OCI（开放容器标准）。

这些替代方案在提供类似Docker的基础功能的同时，也更加符合Kubernetes对容器管理的需求。

结论：Docker在Kubernetes中的角色转变

Kubernetes不再支持Docker作为容器运行时，是为了简化架构、提升性能，并适应现代化容器管理需求的结果。这一变化并不意味着Docker将退出容器生态，而是Docker从直接的运行时角色转向了容器开发和构建工具的角色。用户可以继续使用Docker构建应用程序镜像，同时在Kubernetes中使用更加轻量化的运行时来管理容器集群。对于开发者和运维团队而言，理解这一转变，选择合适的运行时，是确保系统稳定和高效运行的关键。

这一转变标志着容器技术的进一步成熟，也为Kubernetes用户提供了更丰富的选择。随着containerd、CRI-O等新兴容器运行时的崛起，Kubernetes的生态将继续向着更灵活、更高效的方向发展。

更多了解：

Kubernetes与Docker对比如何选择 

为何很多公司不用k8s-kubernetes详解