先来看一下 kubernetes 和 Docker 的实际关系
在 什么是容器 一文中我们提到过，容器并不仅仅是docker，容器实际上是
OCI 组织定义的一套规范，包含 runtime spec 和 image format spec
Kubernetes 在 1.5 版本里（2016年）引入了CRI，于是 Docker 和 Kubernetes 关系就变成了下面这样
Dockershim是由社区维护的，可以让kubernetes正常使用docker的docker垫片
CRI-O
当容器运行时（Container Runtime）的标准被提出以后，Red Hat 的一些人开始想他们可以构建一个更简单的运行时，而且这个运行时仅仅为 Kubernetes 所用。这样就有了 skunkworks项目，最后定名为 CRI-O， 它实现了一个最小的 CRI 接口
最后这个结构演变成了这样
在本文写作的2021年，也就是距离CRI接口概念提出的6年之后，kubernetes已经成为了容器编排环境的事实标准，在话语权方面自然也开始高于原生的Docker，而反观Docker一边，似乎从来没有认真考虑过要支持 CRI 接口，仍然需要Kubernetes社区在仓库中维护 Dockershim
这也就不难理解为什么kubernetes打算开始逐渐移除对docker的支持
更不用说现在对于kubernetes而言，docker应该也不会支持它的一系列其他模块的接口
Docker 和 Kubernetes CRI 的关系更像是下面这样
Docker提供了远远超出于 CRI 需要的更多功能，提供了从运行到构建的全套工具，也正是因为这种负责和全能性，使得Kubernetes在和Docker对接时不得不付出更多成本。
还有许多新的CRI特性由于无法在 Dockershim上实现而一再被推迟发布，导致了kubernetes最终选择开始尝试从项目中移除Dockershim。
