本节提供从 dockershim 迁移到其他容器运行时的必备知识。
自从 Kubernetes 1.20 宣布 弃用 dockershim， 各类疑问随之而来：这对各类工作负载和 Kubernetes 部署会产生什么影响。 我们的弃用 Dockershim 常见问题可以帮助你更好地理解这个问题。
Dockershim 在 Kubernetes v1.24 版本已经被移除。 如果你集群内是通过 dockershim 使用 Docker 作为容器运行时，并希望 Kubernetes 升级到 v1.24， 建议你迁移到其他容器运行时或使用其他方法以获得 Docker 引擎支持。
建议从 dockershim 迁移到其他替代的容器运行时。 请参阅容器运行时 一节以了解可用的备选项。 当在迁移过程中遇到麻烦，请上报问题。 那么问题就可以及时修复，你的集群也可以进入移除 dockershim 前的就绪状态。
你的集群中可以有不止一种类型的节点，尽管这不是常见的情况。
下面这些任务可以帮助你完成迁移：
本任务给出将容器运行时从 Docker 改为 containerd 所需的步骤。 此任务适用于运行 1.23 或更早版本 Kubernetes 的集群操作人员。 同时，此任务也涉及从 dockershim 迁移到 containerd 的示例场景， 以及可以从此页面 获得的其他容器运行时列表。
安装 containerd。进一步的信息可参见 containerd 的安装文档。 关于一些特定的环境准备工作，请遵循 containerd 指南。
kubectl drain <node-to-drain> --ignore-daemonsets
将 <node-to-drain> 替换为你所要腾空的节点的名称
systemctl stop kubelet
systemctl disable docker.service --now
遵循此指南 了解安装 containerd 的详细步骤。
containerd.io 包。关于为你所使用的 Linux 发行版来设置
Docker 仓库，以及安装 containerd.io 包的详细说明，可参见
开始使用 containerd。配置 containerd：
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml
重启 containerd：
sudo systemctl restart containerd
启动一个 Powershell 会话，将 $Version 设置为期望的版本（例如：$Version="1.4.3"），
之后运行下面的命令：
下载 containerd：
curl.exe -L https://github.com/containerd/containerd/releases/download/v$Version/containerd-$Version-windows-amd64.tar.gz -o containerd-windows-amd64.tar.gz
tar.exe xvf .\containerd-windows-amd64.tar.gz
解压缩并执行配置：
Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force
cd $Env:ProgramFiles\containerd\
.\containerd.exe config default | Out-File config.toml -Encoding ascii
# 请审查配置信息。取决于你的安装环境，你可能需要调整：
# - the sandbox_image （Kubernetes pause 镜像）
# - cni bin_dir 和 conf_dir 的位置
Get-Content config.toml
# （可选步骤，但强烈建议执行）将 containerd 排除在 Windows Defender 扫描之外
Add-MpPreference -ExclusionProcess "$Env:ProgramFiles\containerd\containerd.exe"
启动 containerd：
.\containerd.exe --register-service
Start-Service containerd
编辑文件 /var/lib/kubelet/kubeadm-flags.env，将 containerd 运行时添加到标志中：
--container-runtime=remote 和 --container-runtime-endpoint=unix:///run/containerd/containerd.sock"。
对于使用 kubeadm 的用户，可以考虑下面的问题：
kubeadm 工具将每个主机的 CRI 套接字保存在该主机对应的 Node 对象的注解中。
使用 kubeadm 的用户应该知道，kubeadm 工具将每个主机的 CRI 套接字保存在该主机对应的 Node 对象的注解中。
要更改这一注解信息，你可以在一台包含 kubeadm /etc/kubernetes/admin.conf 文件的机器上执行以下命令：
kubectl edit no <node-name>
这一命令会打开一个文本编辑器，供你在其中编辑 Node 对象。
要选择不同的文本编辑器，你可以设置 KUBE_EDITOR 环境变量。
更改 kubeadm.alpha.kubernetes.io/cri-socket 值，将其从
/var/run/dockershim.sock 改为你所选择的 CRI 套接字路径
（例如：unix:///run/containerd/containerd.sock）。
注意新的 CRI 套接字路径必须带有 unix:// 前缀。
保存文本编辑器中所作的修改，这会更新 Node 对象。
systemctl start kubelet
运行 kubectl get nodes -o wide，containerd 会显示为我们所更改的节点上的运行时。
最后，在一切顺利时删除 Docker。
sudo yum remove docker-ce docker-ce-cli
sudo apt-get purge docker-ce docker-ce-cli
sudo dnf remove docker-ce docker-ce-cli
sudo apt-get purge docker-ce docker-ce-cli
本页面描述查明集群中节点所使用的容器运行时 的步骤。
取决于你运行集群的方式，节点所使用的容器运行时可能是事先配置好的，
也可能需要你来配置。如果你在使用托管的 Kubernetes 服务，
可能存在特定于厂商的方法来检查节点上配置的容器运行时。
本页描述的方法应该在能够执行 kubectl 的场合下都可以工作。
安装并配置 kubectl。参见安装工具 节了解详情。
使用 kubectl 来读取并显示节点信息：
kubectl get nodes -o wide
输出如下面所示。CONTAINER-RUNTIME 列给出容器运行时及其版本。
对于 Docker Engine，输出类似于：
NAME STATUS VERSION CONTAINER-RUNTIME
node-1 Ready v1.16.15 docker://19.3.1
node-2 Ready v1.16.15 docker://19.3.1
node-3 Ready v1.16.15 docker://19.3.1
如果你的容器运行时显示为 Docker Engine，你仍然可能不会被 1.24 中 dockershim 的移除所影响。 通过检查运行时端点，可以查看你是否在使用 dockershim。 如果你没有使用 dockershim，你就不会被影响。 看下是否是使用的 dockershim，如何是 dockershim 则会受到在 Kubernetes 1.24 中移除 dockershim 的影响。 反之则不会受到影响。
对于 containerd，输出类似于这样：
# For containerd
NAME STATUS VERSION CONTAINER-RUNTIME
node-1 Ready v1.19.6 containerd://1.4.1
node-2 Ready v1.19.6 containerd://1.4.1
node-3 Ready v1.19.6 containerd://1.4.1
你可以在容器运行时 页面找到与容器运行时相关的更多信息。
容器运行时使用 Unix Socket 与 kubelet 通信，这一通信使用基于 gRPC 框架的 CRI 协议。kubelet 扮演客户端，运行时扮演服务器端。 在某些情况下，你可能想知道你的节点使用的是哪个 socket。 如若集群是 Kubernetes 1.24 及以后的版本， 或许你想知道当前运行时是否是使用 dockershim 的 Docker Engine。
cri-dockerd 使用 Docker Engine，
那么集群不会受到 Kubernetes 移除 dockershim 的影响。
可以通过检查 kubelet 的参数得知当前使用的是哪个 socket。
查看 kubelet 进程的启动命令
tr \\0 ' ' < /proc/"$(pgrep kubelet)"/cmdline
如有节点上没有 tr 或者 pgrep，就需要手动检查 kubelet 的启动命令
在命令的输出中，查找 --container-runtime 和 --container-runtime-endpoint 标志。
container-runtime 标志值不是 remote，则你在通过 dockershim 套接字使用
Docker Engine。
或者如果集群使用的 Docker engine 和 dockershim socket，则输出结果中 --container-runtime 不是 remote,--container-runtime-endpoint 参数，查看套接字名称即可得知当前使用的运行时。
如若套接字 unix:///run/containerd/containerd.sock 是 containerd 的端点。如果你通过 dockershim 来使用 Docker Engine，可在
迁移到不同的运行时
找到更多信息。或者，如果你想在 Kubernetes v1.24 及以后的版本仍使用 Docker Engine，
可以安装 CRI 兼容的适配器实现，如 cri-dockerd。
cri-dockerd。
Kubernetes 对与 Docker Engine 直接集成的支持已被弃用并将被删除。 大多数应用程序不直接依赖于托管容器的运行时。但是，仍然有大量的遥测和监控代理依赖 docker 来收集容器元数据、日志和指标。 本文汇总了一些信息和链接：信息用于阐述如何探查这些依赖，链接用于解释如何迁移这些代理去使用通用的工具或其他容器运行。
在 Kubernetes 集群中，有几种不同的方式来运行遥测或安全代理。 一些代理在以 DaemonSet 的形式运行或直接在节点上运行时，直接依赖于 Docker Engine。
从历史上看，Kubernetes 是专门为与 Docker Engine 一起工作而编写的。 Kubernetes 负责网络和调度，依靠 Docker Engine 在节点上启动并运行容器（在 Pod 内）。一些与遥测相关的信息，例如 pod 名称， 只能从 Kubernetes 组件中获得。其他数据，例如容器指标，不是容器运行时的责任。 早期遥测代理需要查询容器运行时和 Kubernetes 以报告准确的信息。 随着时间的推移，Kubernetes 获得了支持多种运行时的能力，现在支持任何兼容容器运行时接口的运行时。
一些代理和 Docker 工具紧密绑定。比如代理会用到
docker ps
或 docker top
这类命令来列出容器和进程，用
docker logs
订阅 Docker 的日志。
如果现有集群中的节点使用 Docker Engine，在你切换到其它容器运行时的时候，
这些命令将不再起作用。
如果某 Pod 想调用运行在节点上的 dockerd，该 Pod 必须满足以下两个条件之一：
举例来说：在 COS 镜像中，Docker 通过 /var/run/docker.sock 开放其 Unix 域套接字。
这意味着 Pod 的规约中需要包含 hostPath 卷以挂载 /var/run/docker.sock。
下面是一个 shell 示例脚本，用于查找包含直接映射 Docker 套接字的挂载点的 Pod。
你也可以删掉 grep '/var/run/docker.sock' 这一代码片段以查看其它挂载信息。
kubectl get pods --all-namespaces \
-o=jsonpath='{range .items[*]}{"\n"}{.metadata.namespace}{":\t"}{.metadata.name}{":\t"}{range .spec.volumes[*]}{.hostPath.path}{", "}{end}{end}' \
| sort \
| grep '/var/run/docker.sock'
/var/run 的父目录而非其完整路径
（就像这个例子）。
上述脚本只检测最常见的使用方式。
在你的集群节点被定制、且在各个节点上均安装了额外的安全和遥测代理的场景下， 一定要和代理的供应商确认：该代理是否依赖于 Docker。
我们通过 谷歌文档 提供了为各类遥测和安全代理供应商准备的持续更新的迁移指导。 请与供应商联系，获取从 dockershim 迁移的最新说明。