Kubernetes 1.24 版本发布时，正式宣布弃用 Dockershim，转向 Containerd 作为默认的容器运行环境。

Kubernetes 为何弃用 Dockershim？

Docker 在早期没有实现ContainerRuntimeInterface (CRI)，而 CRI 是 Kubernetes 后来增加的对额外运行时的支持标准。Dockershim 的存在是为了支持将 Docker 硬编码到 Kubernetes 中，但随着容器化成为行业标准，Kubernetes 项目增加了对额外运行时的支持，比如通过 ContainerRuntimeInterface (CRI) 容器运行时接口来支持运行容器。

因此，在 Kubernetes 1.20 版本发布的时候提到未来会弃用 Dockershim 引擎，而在 Kubernetes 1.24 版本发布时，正式弃用之。

什么是 Containerd？

Containerd 是一种容器运行时引擎，原属于 Docker 的组件的一部分，主要提供容器生命周期管理（从创建到销毁容器）、拉取和推送镜像、存储管理（管理镜像及容器数据的存储）、调用 runc 容器运行等，现已由开源社区拆分脱离出来单独作为容器运行时项目。

在 Kubernetes 中，Containerd 作为容器运行环境，负责管理 Pod 的生命周期，包括容器的创建、启动、停止和删除等操作。与 Dockershim 相比，Containerd 具有更好的性能、更强的可扩展性以及更简洁的架构。

容器运行底层组件有哪些关系？

DockerClient 和 DockerDaemon

DockerClient 是 Docker 的客户端，它可以通过命令行或 API 向 DockerDaemon 发送请求。DockerDaemon 是 Docker 的核心组件，负责管理镜像、容器、网络和卷等资源，并将 DockerAPI 暴露给客户端。

Docker 镜像和 Docker 容器

Docker 镜像是只读的模板，包含了所有用于运行应用程序所需要的代码、库文件、环境变量和配置文件等内容。Docker 容器是基于 Docker镜像创建的可运行实例。每个容器都是一个独立的、轻量级的操作系统，它们之间相互隔离并且可以共享主机的内核。

CRI（ContainerRuntimeInterface）和容器运行时

CRI 是 Kubernetes 的容器运行时标准接口，满足这个标准的所有容器运行时都可以被使用。容器运行时则提供了一个轻量级的容器运行环境，用于创建、启动和停止容器。

OCI（OpenContainerInitiative）和 runc

OCI 是一个开放的容器组织，它制定了容器运行时的规范，包括运行时规范、容器镜像规范等。runc 是 OCI 标准的一个参考实现，它与容器所依赖的 cgroup/kernel 等进行交互，是容器最终运行的形态之一。

Containerd 在 Kubernetes 的运行变化

在 Kubernetes 1.24 版本以前，Kubernetes 通过调用 Docker 命令来创建容器。Kubernetes 将任务发送给 Docker 客户端，然后 Docker 客户端通过与 Docker 守护进程（daemon）通信来创建容器。Docker 守护进程会通过 Image 模块下载镜像并保存，然后通过 client 调用 containerd 创建并运行容器。

在这个过程中，如果需要给容器添加持久化存储，可以使用 volume 参数；如果需要配置容器网络，可以通过 network 参数来实现。Kubernetes 提供了更强大的卷挂载能力和集群级别的网络能力。在集群中，kubelet 只

容器化技术发展趋势

随着容器化技术的不断发展，Kubernetes 作为容器编排的领先平台，也在不断进化。弃用 Dockershim，转向 Containerd 是 Kubernetes 拥抱云原生技术的一个体现。

Containerd 具有更强的可扩展性、更好的性能和更简洁的架构，它将成为 Kubernetes 未来容器运行环境的主流选择。同时，Kubernetes 也将继续支持其他符合 CRI 标准的容器运行时，为用户提供更多选择。

总结

Kubernetes 弃用 Dockershim，转向 Containerd，标志着 Kubernetes 容器化技术的又一大进步。Containerd 将成为 Kubernetes 未来容器运行环境的主流选择，为用户提供更强大、更灵活的容器化体验。

k8s为啥不建议用docker了？

因为社区认为Containerd 作为 Kubernetes 的容器运行时目前已经足够成熟，无需再通过 dockershim 使用 Docker 作为 Kubernetes 的容器运行时。

这也标志着 Docker 为 Kubernetes 提供一个现代化的容器运行时的承诺最终兑现了。

在 Kubernetes 提出 CRI 时，有人建议在 Docker 中实现它。但是这种方式也会带来一个问题，即使 Docker 实现了 CRI，但它仍然不是一个单纯的容器运行时，它本身包含了大量的非 “纯底层容器运行时” 所具备的功能。

Docker一问世就广受好评，发展迅速，于是在2015年左右，不满足只做容器引擎的Docker开始尝试提供容器编排能力，对单机场景推出了Docker Compose，对集群场景推出了Docker Swarm。

也就在同年，Google推出了同样具备容器编排能力的Kubernetes，并在与Docker Swarm和Apache Mesos的三方大战中大获全胜。于是在之后的一段时间里形成了“集群容器编排用Kubernetes，单机容器引擎用Docker”的潜规则。

从Docker到Kubernetes

2013 年，随着PaaS发展壮大，这个领域的从业者们发现了 PaaS 中最为棘手也最亟待解决的一个问题：究竟如何给应用打包？无论是 Cloud Foundry、OpenShift，还是 Clodify，面对这个问题都没能给出一个完美的答案。一个并不引人瞩目的 PaaS 创业公司 dotCloud，却选择了开源自家的一个容器项目 Docker，正好提供了一种非常便利的打包机制，然后就一发不可收拾，围绕着 Docker 项目进行集成与创新涌现出来，包括Mesosphere公司的Mesos项目等等，Docker 公司也顺势推出了Docker Compose、Swarm 和 Machine“三件套”，docker生态圈很快发展起来了，开启了一个新的容器时代。

2014年6月，谷歌公司正式宣告了Kubernetes项目的诞生。这个时候容器出现多样化，包括google公司lmctfy容器，coreos的rkt容器。Google公司提出和Docker合作，与Docker公司共同推进一个中立的容器运行时库作为Docker项目的核心依赖。此时Docker并不担心，因为它维护的 Docker 社区也足够庞大，Docker项目已是容器生态的标准。于是，2015 年 6 月 22 日，由 Docker 公司牵头，CoreOS、Google、RedHat 等公司共同宣布，Docker 公司将 Libcontainer 捐出，并改名为 RunC 项目，交由一个完全中立的基金会管理，然后以 RunC 为依据，大家共同制定一套容器和镜像的标准和规范，这就是OCI。明显OCI的成立容器玩家们出于自身利益进行干涉的一个妥协结果，所以尽管Docker 是 OCI 的发起者和创始成员，但并没有很积极的去推动，Docker注重是它商业价值。

2015年12月11日，Google、RedHat 等开源基础设施领域玩家们，共同牵头发起了一个名为 CNCF（Cloud Native Computing Foundation）的基金，主要是以kubernetes项目为基础打造一个平台级生态。由于Kubernates项目焕然一新的设计理念和号召力，2016年以后kubernates社区得到了空前的发展。

2016年6月，Docker v.1.12发布，直接内置Docker Swarm（多主机多容器的编排解决方案） 2016年12月， Kubernetes 发布 CRI （Container Runtime Interface， 容器运行时接口）

2017年，Docker 分拆了 Containerd，支持CNI，将这个组件分解为一个单独的项目，使得 Docker 将容器的管理功能移出 Docker 引擎，并移入一个单独的守护进程中，即 Containerd，并将其捐赠给了CNCF社区。同时Docker公司宣布将Docker项目改名为Moby，交给社区自行维护。

2017年10月，Docker公司将自己的主打产品Docker EE 内置Kubernetes项目，预示着Kubernetes的胜出，成为容器编排的标准。

2017年11月 ，K8s支持containerd 2018年 k8s集成containerd，正式GA，把CRI plugin嵌入 containerd中 2019年 rkt 终止使命被CNCF归档 2019 年 Mirantis 收购 Docker 的企业服务

OCI 代表 开放容器标准 ， 它标准化了容器工具和底层实现（technologies）之间的大量接口。 他们维护了打包容器镜像（OCI image-spec）和运行容器（OCI runtime-spec）的标准规范。 他们还以runc的形式维护了一个 runtime-spec 的真实实现， 这也是containerd和CRI-O依赖的默认运行时。 CRI 建立在这些底层规范之上，为管理容器提供端到端的标准

全称Container Runtime Interface，（容器运行时接口）是一个用来扩展容器运行时的接口，能让 kubelet 无需重新编译就可以广泛使用各种容器运行时的插件接口。CRI 由protocol buffers和gRPC API还有streaming 库 构成。用户不需要关心内部通信逻辑，而只需要实现定义的接口就可以，包括 RuntimeService 和 ImageService。

其实准确来讲，Docker和容器不是一回事，但Docker普及了Linux容器这种技术模式，并在开发底层技术方面发挥了重要作用。 容器的生态相比于单纯的 Docker，已经进化到了一个更宽广的领域

2020年 Kubernates 宣布移除dockershim，现在1.20版本以后，能使用但是kubelet会打印警告日志。最新消息dockershim 计划在 Kubernetes 1.24 版被移除， 请参阅 移除 Kubernetes 增强方案 Dockershim

主流的容器运行时有 containerd，docker engine，cri-o，Mirantis Container Runtime（商业版）

Containerd是一个工业标准的容器运行时，它强调简单性、健壮性和可移植性。它可以在宿主机中管理完整的容器生命周期：容器镜像的传输和存储、容器的执行和管理、存储和网络等，是目前适用最广泛。

Containerd 的配置文件默认为 /etc/containerd/[^ssh-copy-id]

containerd 将容器相关的数据持久化在 /var/lib/containerd/中（docker 默认在 /var/lib/docker/）

containerd 提供ctrCLI。 containerd 相比docker, 多了 namespace 概念, 每个image和container 都会在各自的namespace下可见, 目前k8s会使用 作为命名空间。

容器时依赖task，task 管理容器，删除容器，得先终止task

CRI Tools是社区针对 CRI 接口开发的CLI及验证工具。

它包括两个工具：crictl 和 critest。crictl 是一个容器运行时命令行接口，适用所有CRI兼容的容器运行时，与Docker cli类似功能，但是docker cli只适用于Docker运行时。由于Kubernetes 是支持所有CRI兼容的容器运行时，所以推荐crictl用于 Kubernetes 节点上 pod、容器以及镜像的除错工具。

针对pod操作如下：

critest 则是一个容器运行时的验证测试工具，用于验证容器运行时是否符合 Kubelet CRI 的要求。除了验证测试，critest 还提供了 CRI 接口的性能测试，比如 critest -benchmark

根据上文内容知道Docker也是依赖Containerd，因此安装Docker同时也安装Containerd，那么切Containerd就可以不用再安装，当然你也可以将 Docker 和 containerd 完全卸载掉，然后重新安装。

Containerd 中默认已经实现了 CRI，但是是以 plugin 的形式配置的，之前 Docker 中自带的 containerd 默认是将 CRI 这个插件禁用掉了的（使用配置 disabled_plugins = [cri]），所以这里我们重新生成默认的配置文件来覆盖掉, 具体查看上面Containerd 配置

接下来配置kubelet，修改/etc/sysconfig/kubelet，container-runtime指定容器运行时，默认值是docker， --container-runtime-endpoint指定运行时套接字地址，containerd套接字unix:///run/containerd/

配置完成后启动containerd和kubelet

重启完成后查看节点状态