2020年12月初，Kubernetes在发布v1.20的时候重磅宣称将逐渐弃用Docker，一石激起千层浪，瞬间引爆容器圈；但没想到已经过去两个月时间了，还有文章用UC体误导吃瓜群众，“还在学Docker?”、“Docker已死!”； 额… 累了，毁灭吧，赶紧的…

所以在此梳理下整件事情的来龙去脉，若有不正确的地方还请指正，非常感谢！

快速回顾

最初Docker是建立在Linux的LXC容器技术之上，但LXC最早也是由Google贡献给Linux的，所以一定程度上说没有Google就没有Docker。

Docker一问世就广受好评，发展迅速，于是在2015年左右，不满足只做容器引擎的Docker开始尝试提供容器编排能力，对单机场景推出了Docker Compose，对集群场景推出了Docker Swarm；也就在同年，Google推出了同样具备容器编排能力的Kubernetes，并在与Docker Swarm和Apache Mesos的三方大战中大获全胜。

于是在之后的一段时间里形成了“集群容器编排用Kubernetes，单机容器引擎用Docker”的潜规则。
但Kubernetes对于这种合作机制并不满意，因为Kubernetes更贴近用户的上层容器编排能力不想局限于Docker这一种底层容器Runtime，市面上还其他的容器Runtime，比如rkt/frakti等，Kubernetes全都要…

所以Kubernetes于v1.5提出了CRI - Container Runtime Interface，这是一种自上而下的标准，旨在适配底层不同的容器Runtime；

在kubernetes和容器runtime之间加一层CRI标准进行解耦，kubernetes作为client只和CRI提供的service进行交互，这里CRI主要提供两种service：管理镜像的ImageService和管理pod与container的RuntimeService；

各容器Runtime厂商可以选择接入CRI标准，但Docker拒绝了，所以kubernetes不得不自己来实现和维护docker shim来适配Docker；

同时Docker也没闲着，联合一众厂商提出了OCI - Open Container Initiative，这是一种自下而上的标准，旨在规范化容器格式与Runtime，也向CNCF贡献了OCI的实现runC；

同时Docker也向"主动"向CNCF贡献了docker deamon的精简版containerd；

至此，Kubernetes准备要去除Docker的条件基本形成…

对于上面的整个链路来说，一直在维护dockershim的kubernetes认为是时候尝试去除docker了，首次尝试是推出了cir-containerd，这是一个符合CRI标准的containerd插件，真正的做到了去Docker化；

此外还有由红帽推出的更激进的CRI-O，docker去除的更彻底；

尽管有containerd和CRI-O，但用户早已习惯使用docker，所以kubernetes并没有急于立刻停掉dockershim；

就这样过了几年，随着containerd的正式毕业，CRI-O的稳步孵化，kubernetes终于决定要真正去除Docker，在发布v1.20的时候正式宣布将去除dockershim，建议用户做好准备选择使用containerd或者CRI-O。

有何影响

• 对于普通开发者来说毫无影响，可以继续使用Docker打包并在单机运行镜像；
• 对于集群运维同学来说，在Kubernetes升级到v1.22之后需要准备好containerd或CRI-O环境；但只要不升级也没有任何影响…

写在最后

Docker虽然没有像一些文章里宣传的那样消亡，但被Kubernetes一点点蚕食也是不争的事实，同时Podman的出现也在尝试将Docker推向幕后… 或许几年后Docker真的会退出历史舞台吧…