Kubernetes 1.20起弃用Docker，containerd是当前唯一推荐的生产级容器运行时；需正确配置CRI插件、SystemdCgroup=true、镜像加速，并显式设置kubelet的container-runtime-endpoint为containerd.sock，否则将导致节点NotReady或容器启动失败。
Kubernetes 1.20 起已弃用 docker 直接作为 CRI 的支持，containerd 是当前生产环境唯一推荐、稳定且被所有主流发行版（包括阿里云 ACK、kubeadm、RKE2、K3s）默认采用的容器运行时。强行继续用 docker 会导致 kubelet 启动失败、节点 NotReady、镜像拉取超时等连锁问题。
确认当前节点运行时和 CRI 状态
先看实际在跑什么，别凭感觉操作：
- 执行
kubectl get node -o wide，观察CONTAINER-RUNTIME列是否显示docker://或containerd:// - 检查
kubelet是否还在用 dockershim：运行ps aux | grep kubelet，若参数中含--container-runtime=docker或未显式指定--container-runtime-endpoint，说明仍走旧路径 - 验证
containerd是否已安装并监听：运行sudo systemctl status containerd；再试sudo ctr --namespace k8s.io containers list，若报 “connection refused” 或 “no such file”，说明 socket 未就位或服务未启
配置 containerd 启用 CRI 插件并适配 systemd cgroup
containerd 默认配置不自动启用 CRI 接口，且若 kubelet 使用 systemd cgroup 驱动（kubeadm 1.22+ 默认），而 containerd 配置里 SystemdCgroup = false，会导致容器启动后立即退出——这是最常被忽略的兼容性断点。
- 生成基础配置：
sudo mkdir -p /etc/containerd && sudo containerd config default | sudo tee /etc/containerd/config.toml - 强制启用 CRI 插件：确保配置中
[plugins."io.containerd.grpc.v1.cri"]段落未被注释或禁用；若存在disabled_plugins = ["cri"]，必须删掉整行 - 关键修复 cgroup 驱动：将
SystemdCgroup = false改为SystemdCgroup = true（位置在[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]下） - 国内环境务必配镜像加速：在
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]下添加endpoint = ["https://<code>your-mirror.mirror.aliyuncs.com"]，否则pause镜像拉取失败，kubelet 卡在ContainerCreating
让 kubelet 正确对接 containerd socket
kubelet 不会自动发现 containerd，必须显式告诉它 CRI endpoint 地址。不同部署方式写法不同，混用会导致启动失败：
- 使用 kubeadm：优先改
/var/lib/kubelet/instance-config.yaml，写入containerRuntimeEndpoint: unix:///run/containerd/containerd.sock；该文件存在时，kubeadm-flags.env中的--container-runtime-endpoint会被忽略 - 手动部署或老版本：编辑
/var/lib/kubelet/kubeadm-flags.env，追加--container-runtime-endpoint=unix:///run/containerd/containerd.sock（注意不能写成--container-runtime=remote，该参数已废弃） - 绝对不要同时设
--container-runtime=docker和--container-runtime-endpoint，kubelet 会拒绝启动并报错conflicting runtime flags - 重启前确认 socket 路径真实存在：
ls -l /run/containerd/containerd.sock；若不存在，systemctl restart containerd后仍未生成，大概率是配置中 CRI 插件未启用或 TOML 语法错误
节点腾空、切换与验证要点
单节点集群切运行时风险极高，控制面组件（如 coredns、metrics-server）可能因 CRI 切换中断而无法恢复，务必按顺序操作：
- 先
kubectl cordon <node-name></node-name>封锁节点，再kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data</node-name>驱逐所有 Pod；若报错 “cannot delete DaemonSet-managed Pods”，加--force强制（仅限工作节点） - 停
kubelet再停docker：sudo systemctl stop kubelet && sudo systemctl stop docker；不先停 kubelet，它可能反复尝试连 docker socket 导致日志刷屏 - 验证
containerd已就绪后再启 kubelet：sudo systemctl start containerd && sudo systemctl start kubelet - 验证成功标志有三个：
kubectl get node -o wide显示containerd://；sudo crictl ps能列出 pause 容器；kubectl get pod -A所有系统 Pod 处于Running状态且READY列为1/1或更高
真正卡住的地方往往不是安装命令，而是 containerd 配置里 CRI 插件没开、cgroup 驱动不匹配、或 kubelet 还在读一个过期的 instance-config.yaml 缓存。每次改完配置，用 sudo containerd --config /etc/containerd/config.toml config dump 看最终生效项，比猜更可靠。
