对于Kubernetes最终用户，此次调整同样不会有太大影响。Docker不会就此消亡，你也仍然可以继续将Docker作为开发工具使用。Docker会继续构建起不计其数的容器，而运行docker build命令所生成的镜像仍可在Kubernetes集群内正常运行。

如果你使用的是GKE或者EKS等托管Kubernetes服务，则需要确保在未来的Kubernetes版本彻底去除Docker支持之前，为你的工作节点引入受支持的容器运行时。如果节点中包含自定义项，你可能需要根据当前环境及运行时要求做出更新。请与服务供应商合作，确保正确完成升级测试及规划。

如果你的集群一直在滚动扩展，则需要配合变量以避免服务中断。在1.20版本中，你将收到Docker弃用警告。而在未来的Kubernets版本(计划在2021年下半年发布的1.23版本)中，Docker运行时将被彻底移除、不再受到支持，届时您必须切换至其他兼容的容器运行时，例如containerd或者CRI-O。只需要保证你所选定的运行时，能够支持当前使用的Docker守护程序配置即可(例如日志记录)。

既然问题不大，人们在慌什么?在怕什么?

这里我们需要探讨两种不同的环境，而这也是恐慌情绪的根源。首先，在Kubernetes集群内部存在一种叫作容器运行时的东西，负责提取并运行容器镜像。Docker是目前最流行的运行时选项(其他常见选项还包括containerd与CRI-O)。但Docker在设计上并未考虑到被嵌入Kubernetes这种用法，所以可能引发问题。

很明显，这里我们提到的“Docker”并不是同一种东西——它代表着一整套技术栈，而containerd高级容器运行时则是Docker中的一部分。Docker很酷、实用性极强，提供多种用户体验增强功能，让我们能够在开发过程中轻松完成协同交互。但是，用户体验增强功能对Kubernetes来说并非必需，因为Kubernetes并不是什么人类协作方。

结果就是，要想让containerd这个人类友好型抽象层发挥作用，Kubernetes集群就必须引入另一款名为Dockershimi的工具。但这款工具的介入又引发了新的问题，因为我们必须额外加以维护，否则就可能引发安全问题。事实上，Dockershim早在Kubelet 1.23版本时就已经被移除，或者说Kubelet很早就取消了将Docker作为容器运行时的功能。这时候很多朋友可能要问，既然Docker栈中已经包含containerd，Kubernetes为什么还要画蛇添足地搞出个Dockershim?