kubelet与容器运行时通信中断导致节点notready，需检查cri套接字路径、containerd/cri-o服务状态、sandbox残留及selinux/apparmor权限。
这个问题本质是 kubelet 与底层容器运行时（如 containerd 或 cri-o）之间通信中断，导致节点无法创建、管理或上报 Pod 状态，最终表现为 Worker 节点 NotReady、kubelet 日志中反复出现 “connection refused” 或 “context deadline exceeded” 错误，且 kubectl get nodes 显示状态停滞、kubectl describe node 中 NodeConditions 持续为 NodeReady: False 或 NodeStatusUnknown。
确认 CRI 套接字路径与实际服务状态是否匹配
kubelet 启动时依赖 --container-runtime-endpoint（旧版 --container-runtime=remote --runtime-request-timeout）指定的 Unix 套接字路径连接运行时。常见路径包括：
-
unix:///run/containerd/containerd.sock（containerd 默认） -
unix:///var/run/crio/crio.sock（cri-o） -
unix:///var/run/dockershim.sock（已弃用，仅旧版本 Docker 引擎）
执行以下命令验证：
- 查 kubelet 实际使用的 endpoint：
ps aux | grep kubelet | grep -o 'container-runtime-endpoint=[^[:space:]]*' - 检查该套接字文件是否存在且可访问：
ls -l /run/containerd/containerd.sock - 测试连通性：
sudo crictl -r unix:///run/containerd/containerd.sock info（若返回正常 JSON，说明 CRI 层就绪；若报错 “failed to connect” 或 “permission denied”，即为断流根源）
排查 containerd（或对应 CRI）进程是否存活且健康
即使套接字文件存在，也可能因进程僵死、OOM 被杀、或配置崩溃而无法响应请求：
- 检查服务状态：
sudo systemctl status containerd（或crio）——关注 Active 是否为active (running)，且 Main PID 有值 - 查看 containerd 最近日志：
sudo journalctl -u containerd --since "10 minutes ago" | grep -E "(error|panic|failed|oom)" - 高频诱因示例：磁盘满导致 containerd 无法写入元数据；升级后配置语法错误（如
/etc/containerd/config.toml中 plugin 配置错位）；systemd 单元文件被覆盖导致启动参数异常
检查 sandbox 生命周期冲突与残留状态
重启节点或 containerd 后，旧 sandbox（Pod 容器沙箱）可能因状态未清理干净而“占位”，新 Pod 创建时卡在 CreatePodSandbox 阶段，进而阻塞 kubelet 整体工作流：
- 典型日志线索：
"CreatePodSandbox for pod \"xxx\" failed: rpc error: code = Unknown desc = failed to create sandbox container: sandbox name \"xxx\" is reserved" - 手动清理方法（谨慎操作）：
sudo crictl pods --quiet | xargs -r sudo crictl stoppsudo crictl pods --quiet | xargs -r sudo crictl rmpsudo systemctl restart containerd - 注意：此操作会终止当前所有 Pod，请确保节点已
kubectl drain或处于维护窗口
验证 kubelet 与 CRI 的权限和 SELinux/AppArmor 上下文
尤其在加固环境（如 RHEL/CentOS + SELinux、Ubuntu + AppArmor）中，权限不足会导致 kubelet 能看到 socket 文件但无法发起有效 RPC 调用：
- 临时禁用 SELinux 测试：
sudo setenforce 0，再试crictl info—— 若恢复则需修复策略，而非永久关闭 - 检查 containerd 进程标签：
ps -eZ | grep containerd，应为system_u:system_r:containerd_t:s0类似可信上下文 - 查看 audit 日志中拒绝记录：
sudo ausearch -m avc -ts recent | grep containerd，据此生成自定义策略模块
不复杂但容易忽略：CRI 断流往往不是孤立故障，而是磁盘压力、OOM killer 干预、或 systemd 服务依赖顺序错乱引发的连锁反应。优先从 crictl info 和 journalctl -u containerd 入手，比直接重启 kubelet 更高效。
