CRI连接超时导致节点NotReady，需依次验证kubelet状态与日志、CRI套接字路径及权限、containerd服务存活与配置兼容性、sandbox残留及cgroup driver一致性。
当Kubelet因CRI接口连接超时而反复崩溃或无法上报节点状态，表现为节点NotReady、Pod卡在ContainerCreating、kubelet日志中高频出现“context deadline exceeded”或“failed to connect to runtime”时，必须立即定位CRI通信链路中的阻塞点。
确认kubelet是否真的因CRI超时挂掉
先验证问题现象是否匹配：执行 systemctl status kubelet，若看到 Active: inactive (dead) 或频繁 restart，再运行 journalctl -u kubelet -n 50 --no-pager | grep -i "deadline\|timeout\|connect\|cri"。如果输出中反复出现 context deadline exceeded while connecting to runtime 或 failed to dial unix:///run/containerd/containerd.sock，说明CRI连接超时是直接诱因。
注意：仅凭 kubectl get nodes 显示 NotReady 不足以断定是CRI问题——也可能是kubelet进程还在跑但心跳中断。必须看日志里有没有明确的CRI连接失败记录。
检查CRI套接字路径与实际服务是否对齐
第一步：查kubelet启动时指定的CRI endpoint：
ps aux | grep kubelet | grep -o 'container-runtime-endpoint=[^[:space:]]*'
常见返回如 container-runtime-endpoint=unix:///run/containerd/containerd.sock。这个路径必须和实际运行的容器运行时监听路径完全一致。
第二步：确认该套接字文件存在且权限可读：
ls -l /run/containerd/containerd.sock
若返回 No such file or directory，说明containerd根本没启动，或配置了其他套接字路径；若返回权限为 srw-rw---- 但属组不是 root 或 containerd，kubelet可能因权限不足被拒绝访问——【kubelet默认以root身份运行，必须确保其对.sock文件有读写权限】。
第三步：用crictl直连测试（绕过kubelet）：
sudo crictl -r unix:///run/containerd/containerd.sock info
成功返回JSON表示CRI层就绪；若报 failed to connect，说明containerd进程未监听该路径；若报 permission denied，说明SELinux/AppArmor策略拦截或文件权限错误。
排查containerd服务是否存活且响应正常
方法一：检查服务状态与进程
sudo systemctl status containerd
重点看 Active: 是否为 active (running)，以及 Main PID 是否有有效数值。若显示 inactive (dead)，直接执行 sudo systemctl start containerd 并观察是否秒退。
方法二：查看containerd最近崩溃线索
sudo journalctl -u containerd --since "5 minutes ago" | grep -E "(panic|fatal|oom|failed|exit)"
磁盘满是最常见原因：containerd无法写入/var/lib/containerd会导致初始化失败，日志中会出现 failed to write metadata 或 no space left on device。此时需清理镜像、日志或临时文件。
方法三：验证containerd配置是否兼容当前内核
升级系统后若启用cgroup v2，而/etc/containerd/config.toml中仍保留 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] 下的 SystemdCgroup = true，就会导致runtime无法启动——因为cgroup v2不支持systemd driver。此时需将该值改为 false 并重启containerd。
检查sandbox残留与cgroup驱动冲突
第一步：确认kubelet与containerd使用的cgroup driver是否一致
查kubelet配置：ps aux | grep kubelet | grep -o 'cgroup-driver=[^[:space:]]*'，常见值为 cgroup-driver=systemd 或 cgroup-driver=cgroupfs。
查containerd配置：sudo sed -n '/\[plugins\.\"io\.containerd\.grpc\.v1\.cri\"\]/,/\[.*\]/ {/SystemdCgroup/p;}' /etc/containerd/config.toml。若kubelet用 systemd 而containerd配置中 SystemdCgroup = false，则必然超时。
第二步：强制清理僵死sandbox（仅当重启containerd后仍卡在CreatePodSandbox时使用）
sudo crictl ps -a | grep -E "(Pause|sandbox)" | awk '{print $1}' | xargs -r sudo crictl stop
sudo crictl ps -a | grep -E "(Pause|sandbox)" | awk '{print $1}' | xargs -r sudo crictl rm
这一步会清空所有沙箱容器，包括已退出但状态未同步的旧实例。操作后务必重启kubelet：sudo systemctl restart kubelet。
