关于Kubernetes与Docker环境的关系，众所周知，早期的Kubernetes需要部署Docker环境作为其容器运行的基础。具体而言，Kubernetes通过在各个节点上部署kubelet来调用Docker的API，进而创建Pod。这一过程并非直接调用，而是通过一个名为dockershim的适配层来转换请求。那么，为何在Kubernetes的1.24版本之后，决定弃用Docker及其dockershim呢？
先来了解一下早期Kubernetes如何利用Docker创建容器：
步骤一，kubelet会通过CRI（容器运行时接口）调用dockershim，请求创建一个新的容器。
步骤二，dockershim接收到请求后，将其转化为Docker API的格式，并发送至Docker守护进程（dockerd）以请求创建容器。
步骤三，在Docker 1.12版本之后，原本作为单一执行体的Docker分为三个部分：runC、containers以及dockerd。
特别指出的是，dockerd本身并不直接参与容器的创建过程，而是发出请求给containers部分来创建容器。
步骤四至六详细描述了容器创建过程中的各个部分协同工作的情况：containers在接收到请求后不直接创建容器，而是启动一个contained-shim进程来操作容器；contained-shim随后调用runC这个命令工具来启动容器；runC启动完容器后会退出，而containerd-shim则作为容器进程的父进程，负责收集并上报容器进程的状态给containerd。
从高层到低层，容器运行时被分为两个层次：高层运行时（如contained）主要负责镜像的拉取和解压，而低层容器运行时（如runC）则负责容器的生命周期管理。
综合上述描述，我们可以明白在Kubernetes创建容器的流程中，dockershim和Docker主要起到了桥梁和连接的作用。而Kubernetes更期望的是kubelet和containerd之间能够直接通信。containerd从Docker中独立出来并捐献给了CNCF（云原生计算会），并且通过集成CRI plugin实现了对Kubernetes的CRI支持，从而使得kubelet可以直接与containerd通信。