今天，zouyee带各位看看关于前几天Kubernetes“废弃”docker支持的申明。首先，请各位稍安勿躁，主要还是中英文的翻译差别以及标题所引发的歧义，对Kubernetes开源项目有所了解的朋友，可能知道，该项目成功的原因之一，就在于对于接口及功能的版本管理，社区有一套完整且行之有效的方案，接口的兼容性、版本的多样性管理是驱动Kubernetes社区不断前行的内因。
先说结论：
1）对于使用者没有任何影响
2）对于开发者，若想保持原有docker使用方式只是新增一个已知组件
Kubernetes 1.20前后，对于docker的支持没有变化，只是将该部分代码（dockershim）独立出来，使用者可独立配置。
改变动因
维护dockershim已成为Kubernetes维护人员的一种负担。创建CRI标准就是为了减轻这种负担，并提升不同容器运行时的可移植性性。Docker本身目前没有实现CRI，但Containerd实现了CRI接口。
Dockershim一直是一种临时解决方案，此外，与dockershim不兼容的特性，如cgroups v2和用户命名空间，实现CRI接口的运行时也在慢慢探索并实现上述特性。
何时完全废弃dockershim
考虑到此更改的影响，它在Kubernetes 1.22之前不会被删除。
架构变化
在Kubernetes架构中，是由Kubelet组件负责与容器运行时交互的。Kubelet调用容器运行时的流程如下图所示。
CRI shim是实现CRI接口提供的gRPC server服务，负责连接Kubelet和Container runtime，Container runtime是容器运行时工具；具体的流程是Kubelet调用CRI shim接口，CRI shim响应请求，然后调用底层的Container runtime工具运行容器。Kubelet、CRI shim和Container runtime都部署在一个Kubernetes 业务节点上，前两者是以独立的守护进程的方式启动的，而Container runtime不是守护进程，它通常是一个命令行工具。
Kubernetes在1.5版本之前没有CRI接口，当时Kubelet内部只集成了两种容器运行时(Docker和rkt)的代码。但这两种容器运行时并不能满足用户的所有使用场景（rkt早已废弃），因为用户对容器的安全隔离性及性能在不同的应用场景有着不同的需求，用户希望Kubernetes能支持更多种的容器运行时。因此，Kubernetes在1.5版本推出了CRI接口，各个容器运行时只要实现了CRI接口规范，就可以接入到Kubernetes平台。
在推出CRI后，Kublet为了满足CRI接口，实现了dockershim以支持直接使用docker接口，前期Containerd为了支持CRI接口，实现了CRI-Containerd，但在Containerd 1.1发布后，CRI-Containerd被废弃，转而使用插件方式支持CRI，即CRI插件，当前Kubernetes(1.20之前)关于docker及Containerd的支持如下所示。
内置dockershim方式
containerd CRI方式
那么Kubernetes 1.20之后(1.22 之前)关于docker及Containerd的支持如下所示。
Kubernetes 1.20之后，若前期使用dockershim内置方式，那么只需要再部署dockershim即可，若使用containerd等runtime，则保持不变即可,当然，官方推荐配置为containerd方式。
