1、概述
在当今的技术领域，容器技术的崛起与发展离不开 Docker 和 Kubernetes 的紧密合作。Docker 以其创新性的容器化技术，推动了容器在全球范围内的广泛应用，为开发者提供了从容器镜像构建、容器启动与管理到镜像分发等一站式服务。Kubernetes 则专注于大规模容器的编排和自动化管理，在容器集群的调度、资源分配以及服务的稳定运行方面发挥着关键作用，二者的协同合作成为容器技术迅速发展的重要驱动力。
然而，随着 Kubernetes 的不断演进，其对容器运行时的要求也日益提高和细化。从 1.20 版本开始，Kubernetes 逐渐降低对 Docker 的依赖程度，并在 1.24 版本后停止维护 dockershim，这一决策引发了行业内的广泛关注和讨论。众多开发者和运维人员不禁要问：Kubernetes 为何会做出这样的改变？这背后有着怎样的技术因素和发展趋势？本文将深入剖析这一变化背后的原因，探讨容器运行时演变的技术驱动力，并展望未来容器技术生态的发展方向。
2、Kubernetes 与 Docker 的早期紧密合作
早期，Kubernetes 诞生之际，Docker 作为当时最为成熟且功能全面的容器平台，自然而然地成为了 Kubernetes 默认的容器运行时。Kubernetes 借助 Docker 强大的容器引擎来实现容器的生命周期管理，包括容器的创建、启动、停止等操作。这种紧密的合作模式使得二者在容器技术领域迅速崭露头角，成为推动容器技术普及的重要力量，为容器技术的广泛应用奠定了坚实的基础。
然而，随着 Kubernetes 功能的不断扩展，特别是对容器运行时的高效性、灵活性和可扩展性提出了新的要求，Kubernetes 开始寻求更加精简且专注于容器生命周期管理的容器运行时。这一转型的契机出现在 Kubernetes 1.20 版本中，引入了容器运行时接口（CRI）和其它容器运行时的支持，最终在 Kubernetes 1.24 版本后正式停止维护 dockershim（Kubernetes 对 Docker 的兼容层），标志着 Kubernetes 开始减少对 Docker 的依赖。
随着业务场景的拓展和技术的深入发展，Kubernetes 在功能不断丰富的同时，对容器运行时的需求也发生了显著变化，高效、灵活和可扩展成为其新的追求目标。在此背景下，Kubernetes 开始重新审视与 Docker 的合作关系，并积极探索更契合其发展需求的容器运行时方案。
Docker 作为一个综合性的容器平台，其功能丰富多样，涵盖了镜像构建、容器网络管理、日志管理以及容器运行管理等多个方面。虽然这些功能对于开发者在开发和测试阶段具有一定的便利性，但在大规模生产环境中，Kubernetes 对容器运行时的核心需求主要集中在容器的高效调度和稳定的生命周期管理上。Docker 的众多额外功能，在这种场景下，反而增加了系统的复杂性和资源开销。例如，在大规模集群环境中，一些不必要的功能模块会占用额外的 CPU、内存等资源，影响了 Kubernetes 集群的整体性能和资源利用率。因此，为了提升系统效率和降低复杂度，Kubernetes 寻求更为精简且专注于容器生命周期管理的运行时方案，以摆脱 Docker 带来的复杂功能体系的束缚。
为了实现对多种容器运行时的支持，Kubernetes 引入了容器运行时接口（CRI）。CRI 定义了 Kubernetes 与容器运行时之间的标准通信接口，使得 Kubernetes 能够与不同的容器运行时进行集成，不再局限于单一的容器引擎。
尽管 Docker 对 CRI 提供了支持，但其实现方式相对复杂且资源消耗较大。为了满足 Kubernetes 的要求，Docker 需要启动多个进程来实现容器管理，这在 Kubernetes 集群中引入了较高的资源开销和潜在的性能瓶颈。相比之下，containerd 和 CRI-O 等轻量级容器运行时，严格遵循 CRI 规范，专注于容器的生命周期管理，去除了 Docker 中的一些非核心功能，如镜像构建工具、命令行界面（CLI）工具以及复杂的容器网络配置等。这种精简的设计使得它们在 Kubernetes 环境中能够以更低的资源消耗实现更高效的容器管理，为 Kubernetes 提供了更灵活、高效的容器运行时选择，有力地推动了 Kubernetes 向多容器运行时架构的转变。
在 Kubernetes 减少对 Docker 依赖的过程中，containerd 和 CRI-O 凭借其出色的性能和精准的功能定位，逐渐成为主流的轻量级容器运行时选择。
containerd 最初是 Docker 的子项目，后发展成为独立的专注于容器生命周期管理的运行时，遵循 OCI（Open Container Initiative）标准，在容器的创建、启动、暂停、恢复等方面表现出色，已成为 Kubernetes 推荐的容器运行时之一，在众多生产环境中得到了广泛应用。
CRI-O 由 Kubernetes 社区开发，专为 Kubernetes 集群定制，紧密围绕 CRI 规范进行设计，通过优化和精简功能，有效降低了系统资源占用，在大规模容器编排场景中，在容器启动速度、资源利用率以及集群扩展性等方面展现出显著优势，受到了广大 Kubernetes 用户的欢迎。
相较于 Docker，containerd 和 CRI-O 的轻量级特性使其在 Kubernetes 集群中能够显著降低资源开销，提升容器管理的效率和性能，为 Kubernetes 在大规模生产环境中的稳定运行和高效扩展提供了有力保障。
尽管 Kubernetes 在容器运行时方面逐渐减少对 Docker 的依赖，但这并不意味着 Docker 在整个容器生态系统中失去了价值。实际上，Docker 在容器镜像的构建、管理和分发等领域仍然具有重要作用，其独特的价值不可忽视。
Docker 提供的强大镜像构建工具，支持多种开发语言和平台，能够帮助开发者快速构建并测试容器镜像。而且，Kubernetes 完全支持 Docker 镜像格式（即 OCI 镜像标准），这使得开发者可以继续使用 Docker 构建镜像，并将其部署到 Kubernetes 集群中，确保了技术选型的灵活性和延续性。因此，Docker 在容器镜像的构建和分发环节仍然占据着核心地位，是容器技术生态中不可或缺的一部分。
随着 Kubernetes 1.20 版本中对减少 Docker 依赖的战略规划逐渐推进，1.24 版本正式宣告了 dockershim 的终结。dockershim 作为 Kubernetes 与 Docker 之间的兼容层，曾经在二者的合作中起到了关键作用，使得 Kubernetes 能够顺利地将 Docker 作为容器运行时进行集成和管理。然而，随着 CRI 的广泛应用以及 containerd、CRI-O 等轻量级容器运行时的成熟，dockershim 的维护成本逐渐增加，其存在的必要性也逐渐降低。
在 Kubernetes 1.24 版本之后，Kubernetes 正式告别了对 Docker 的直接依赖，全面转向更为精简、高效的容器运行时，如 containerd 和 CRI-O 等。这一转变标志着 Kubernetes 在容器运行时领域进入了一个全新的发展阶段，为其在大规模容器编排和管理方面的进一步创新和优化奠定了基础。
注意： Kubernetes1.24之后版本节点使用docker作为容器运行时（不推荐）
安装cri-docker，确保节点已提前装好docker容器运行时。
wget https://github.com/Mirantis/cri-dockerd/releases/download/v0.3. 2/cri-dockerd-0.3.2-3.el7.x86_64.rpm
rpm -ivh cri-dockerd-0.3.2-3.el7.x86_64.rpm
systemctl daemon-reload
systemctl enable cri-docker --now
systemctl start cri-docker
修改 Kubelet 配置，将容器运行时配置为 containerd，编辑/var/lib/kubelet/kubeadm-flags.env 文件，在该文件中可以添加kubelet 启动参数，修改完Kubelet配置后，重启节点Kubelet服务即使用docker作为节点的容器运行时。
KUBELET_KUBEADM_ARGS="--cgroup-driver=cgroupfs --container-runtime=remote --container-runtime-endpoint=unix:///var/run/cri-dockerd.sock --pod-infra-container-image=harbor.xxx.xxx:443/xxx/pause:3.4.1"
Kubernetes 减少对 Docker 依赖的这一演变过程，不仅是一次技术上的调整，更是容器技术生态向模块化、标准化方向发展的重要体现。通过 CRI 标准的成功引入和推广，Kubernetes 实现了容器运行时选择的多样化和灵活性，能够根据不同的应用场景和需求，选择最合适的容器运行时。
与此同时，Docker 在容器镜像构建和管理方面的优势依然明显，将继续在容器技术生态中发挥重要作用。未来，Docker 和 Kubernetes 将在各自擅长的领域持续发展，共同推动容器技术向更加高效、标准化、模块化的方向迈进，实现容器技术生态的协同发展和繁荣。
总之，Kubernetes 与 Docker 在容器技术生态中的角色演变，反映了技术发展的内在需求和趋势。二者将在不断变化的技术环境中，继续发挥各自的优势，为容器技术的创新与进步贡献力量，引领容器技术走向更加辉煌的未来。
参考：《浅析容器运行时 》
参考：《浅析Kubernetes CRI》
