本博客地址：https://security.blog.csdn.net/article/details/129153459
参考文献：https://www.cnblogs.com/1234roro/p/16892031.html
一、总结
总结起来就是一句话：
k8s只是弃用了dockershim，并不是弃用了整个Docker（这里指容器），即不再支持让docker去调用containerd，而是直接操作containerd
具体可以溯源一下功能链，就很清晰了：
1、dockershim的作用是把外部收到的请求转化成docker daemon能听懂的请求，让docker daemon执行相关的容器操作；
2、docker daemon是Docker的守护进程，是docker engine中真正处理事务的部分，它的主要功能包括镜像管理、镜像构建、REST API、身份验证、安全、核心网络以及编排；
3、docker daemon捐献给CNCF后，就形成了containerd，而Kubernetes也是CNCF项目，因此它们的标准是一样的（CRI标准）；
4、所以对于容器的运行，就变成了Kubernetes直接调用containerd，相较此前本质上没有任何变化，只是去掉了一条复杂的调用链而已。
如下图所示：
二、历史
2016年，k8s发布了1.0版本，该版本可以正式用于生产环境，同年，k8s加入CNCF基金会；
2016年，k8s发布了1.5版本，引入了新的接口标准CRI，CRI规定k8s该如何调用容器运行时去管理容器和镜像，同时为了兼容docker（因为它用户量太庞大了），产生了转换适配组件（dockershim）；
2017年，Docker将docker engine拆分，将其中的docker daemon部分捐献给了CNCF基金会，形成了containerd；
2018年，containerd发布了1.1版本，正式支持CRI标准，与k8s实现集成（此时k8s是1.10版本），此时k8s可直接调用containerd；
2020年，k8s宣布将弃用对Docker的支持（此时k8s是1.20版本），未来将删除dockershim；
2022年，k8s发布了1.24版本，正式剔除dockershim；
至此，弃用对于Kubernetes和Docker来说都不会有什么太大的影响，因为他们两个都早已经把下层都改成了开源的containerd，原来的Docker镜像和容器仍然会正常运行，唯一的变化就是Kubernetes绕过了Docker，直接调用Docker内部的containerd而已。
具体关系参考下图：
