Kubernetes中Dockershim与containerd的使用历史及相关技术疑问

1. Kubernetes中Dockershim与containerd的发展历史 #

• 早期Kubernetes诞生时，Docker是容器领域的绝对主流，K8s直接硬编码对接Docker引擎。后来K8s推出容器运行时接口（CRI），目的是统一容器运行时的接入标准，让K8s兼容多种容器运行时，不再局限于Docker。
• 但Docker本身并未实现CRI标准，为了让K8s能继续支持Docker，K8s官方开发了Dockershim——一个适配器组件，它把K8s的CRI请求转换成Docker引擎可识别的API调用，相当于在CRI和Docker之间搭建了转接桥。
• containerd原本是Docker项目的底层组件，负责容器创建、销毁、存储管理等核心生命周期操作。2017年Docker将containerd捐给CNCF，使其成为独立项目，之后containerd完成了CRI标准的实现，成为符合K8s要求的原生CRI运行时。
• 随着containerd、CRI-O等原生CRI运行时逐渐成熟稳定，K8s官方认为维护Dockershim是额外技术负担，且会阻碍CRI生态发展，于是在Kubernetes 1.20版本宣布停止对Dockershim的支持，并在1.24版本彻底移除该组件。

2. Docker与Kubernetes兼容的真相及你的理解验证 #

• 你用kubeadm搭建集群并安装Docker Daemon能顺利初始化，核心原因是：kubeadm会自动检测到Docker内置的containerd，并配置Kubernetes直接对接这个containerd作为CRI运行时，而非直接使用Docker引擎本身。Docker Daemon本身依然不符合CRI标准，无法被K8s直接调用。
• 你的理解有部分正确，也需要补充纠正：
  • 正确部分：最初Kubernetes确实依赖Docker，通过Dockershim管理容器；containerd实现CRI标准后，Kubernetes可直接对接它，不再需要Dockershim这个适配器。
  • 纠正补充：K8s停止支持Dockershim的核心原因，一是维护Dockershim的成本高，二是官方希望推动社区使用原生符合CRI标准的运行时（如containerd、CRI-O），减少对非标准Docker引擎的依赖，而非单纯因为Docker内部用了containerd。另外，你的集群能正常运行，本质是用了containerd作为CRI，而非Docker直接作为CRI运行。

内容的提问来源于stack exchange，提问作者Hwan E