Kubernetes弃用Docker却支持containerd相关技术问题解答

该调整的具体含义 #

Kubernetes v1.24版本正式移除内置的dockershim组件，所谓“移除对Docker的支持”本质上是停止维护dockershim适配层，而非不支持Docker生成的容器镜像：

• Kubernetes的kubelet组件仅需要对接符合CRI（容器运行时接口）标准的 runtime 来管理容器生命周期，Docker本身没有原生实现CRI接口，之前版本是靠Kubernetes内置的dockershim做协议转换，才实现了kubelet和Docker daemon的对接。
• 所有Docker构建的符合OCI（开放容器标准）的镜像，依然可以在Kubernetes集群中正常运行，开发环节使用Docker的流程完全不受影响，仅集群运维人员需要将集群的容器运行时切换为containerd、CRI-O等原生支持CRI的组件。

两个核心疑问解答 #

是否存在两个不同的containerd，分别为Kubernetes支持的版本及Docker自身使用的版本？ #

不存在，两者是同一个开源组件。
containerd最早由Docker开发，负责容器的生命周期管理（创建、启停、存储、网络调度等），是Docker架构中的核心底层组件，后来Docker将containerd捐献给CNCF托管，成为通用的开源容器运行时项目。我们日常安装Docker的时候，会默认附带安装并启动containerd服务，这个containerd和Kubernetes支持的独立部署的containerd没有任何差异。

若二者为同一组件，为什么Kubernetes无法对接、使用Docker daemon内置的containerd？ #

核心原因有两个：

• 接口不兼容：早期containerd内嵌在Docker daemon中时，没有对外暴露符合CRI标准的交互接口，kubelet无法直接和这个内嵌的containerd通信，只能通过Docker daemon加dockershim的链路做多层适配。后来containerd成为独立项目后，官方才推出了内置的CRI插件，独立部署的containerd开启该插件后即可直接被kubelet对接调用。
• 链路冗余无意义：如果对接Docker daemon作为Kubernetes的运行时，调用链路为kubelet -> dockershim -> docker daemon -> containerd，比直接对接独立containerd的kubelet -> containerd多了两层冗余链路，不仅会增加性能损耗、提升故障概率，也会额外提高Kubernetes社区的维护成本，完全没有必要。

内容的提问来源于stack exchange，提问作者Sandeep kumar singh