检查弃用 Dockershim 对你的影响
Kubernetes 的 dockershim 组件使得你可以把 Docker 用作 Kubernetes 的
容器运行时。
在 Kubernetes v1.20 版本中，内建组件 dockershim 被弃用。
本页讲解你的集群把 Docker 用作容器运行时的运作机制，
并提供使用 dockershim 时，它所扮演角色的详细信息，
继而展示了一组验证步骤，可用来检查弃用 dockershim 对你的工作负载的影响。
检查你的应用是否依赖于 Docker
虽然你通过 Docker 创建了应用容器，但这些容器却可以运行于所有容器运行时。 所以这种使用 Docker 容器运行时的方式并不构成对 Docker 的依赖。
当用了替代的容器运行时之后，Docker 命令可能不工作，甚至产生意外的输出。 这才是判定你是否依赖于 Docker 的方法。
- 确认没有特权 Pod 执行 docker 命令。
- 检查 Kubernetes 基础架构外部节点上的脚本和应用，确认它们没有执行 Docker 命令。可能的命令有：
- SSH 到节点排查故障；
- 节点启动脚本；
- 直接安装在节点上的监视和安全代理。
- 检查执行了上述特权操作的第三方工具。详细操作请参考: 从 dockershim 迁移遥测和安全代理
- 确认没有对 dockershim 行为的间接依赖。这是一种极端情况，不太可能影响你的应用。 一些工具很可能被配置为使用了 Docker 特性，比如，基于特定指标发警报，或者在故障排查指令的一个环节中搜索特定的日志信息。 如果你有此类配置的工具，需要在迁移之前，在测试集群上完成功能验证。
Docker 依赖详解
容器运行时是一个软件，用来运行组成 Kubernetes Pod 的容器。 Kubernetes 负责编排和调度 Pod；在每一个节点上， kubelet 使用抽象的容器运行时接口，所以你可以任意选用兼容的容器运行时。
在早期版本中，Kubernetes 提供的兼容性支持一个容器运行时：Docker。
在 Kubernetes 发展历史中，集群运营人员希望采用更多的容器运行时。
于是 CRI 被设计出来满足这类灵活性需要 - 而 kubelet 亦开始支持 CRI。
然而，因为 Docker 在 CRI 规范创建之前就已经存在，Kubernetes 就创建了一个适配器组件：dockershim。
dockershim 适配器允许 kubelet 与 Docker交互，就好像 Docker 是一个 CRI 兼容的运行时一样。
你可以阅读博文 Kubernetes 容器集成功能的正式发布
切换到容器运行时 Containerd 可以消除掉中间环节。 所有以前遗留的容器可由 Containerd 这类容器运行时来运行和管理，操作体验也和以前一样。 但是现在，由于直接用容器运行时调度容器，所以它们对 Docker 来说是不可见的。 因此，你以前用来检查这些容器的 Docker 工具或漂亮的 UI 都不再可用。
你不能再使用 docker ps 或 docker inspect 命令来获取容器信息。
由于你不能列出容器，因此你不能获取日志、停止容器，甚至不能通过 docker exec 在容器中执行命令。
你仍然可以下载镜像，或者用 docker build 命令创建它们。
但用 Docker 创建、下载的镜像，对于容器运行时和 Kubernetes，均不可见。
为了在 Kubernetes 中使用，需要把镜像推送（push）到某注册中心。