NotReady 问题需逐层排查：先检查 kubelet 状态与日志（证书、运行时、cgroup、inode），再验证容器运行时连通性与配置路径，接着确认节点网络、资源压力条件及 API Server 连通性。
节点显示 NotReady 但 kubectl describe node 没报关键错误，说明问题可能藏在底层组件或资源状态里，需要逐层向下排查。
检查 kubelet 运行状态和日志
kubelet 是节点就绪的核心代理，NotReady 往往源于它无法正常上报心跳或注册成功。
- 登录对应节点，执行
systemctl status kubelet确认服务是否 active（running）且无 recent crash - 用
journalctl -u kubelet -n 100 --no-pager查看最近日志，重点关注：
– “failed to run Kubelet”、“cgroup not mounted”、“failed to start container runtime”、
– “node not found”、“failed to get node info”、“certificate has expired” - 常见诱因：证书过期（尤其是 /var/lib/kubelet/pki/ 下的 client.crt/server.crt）、Docker/containerd 未启动、cgroup v2 与 kubelet 不兼容、磁盘 inode 耗尽（日志里常有 “no space left on device” 却不提示磁盘满）
验证容器运行时是否就绪
kubelet 依赖运行时（如 containerd 或 dockerd）来拉镜像、启 Pod。即使服务 running，也可能卡在通信环节。
- 查运行时状态：
systemctl status containerd或systemctl status docker - 手动测试连通性：
–crictl ps（需安装 cri-tools）应能列出容器，若报 “connection refused” 或 timeout，说明 kubelet 与运行时 socket 通信失败
– 检查 kubelet 启动参数中的--container-runtime-endpoint（如unix:///run/containerd/containerd.sock）是否与实际 socket 路径一致 - 注意：某些系统中 containerd 默认监听
/run/containerd/containerd.sock，但 kubelet 配置成了/var/run/containerd/containerd.sock—— 路径不匹配会导致静默 NotReady
检查节点资源与健康信号
即使组件都 running，kubelet 仍可能因无法上报关键指标而被 API Server 标为 NotReady。
- 运行
kubectl get node，确认-o wide INTERNAL-IP是否可路由，且与节点真实 IP 一致（NAT 或多网卡环境下易出错） - 检查节点是否被人为 cordoned 或 unschedulable：
kubectl get node，返回-o jsonpath='{.spec.unschedulable}' true不影响 Ready 状态，但配合其他问题会加剧异常 - 查看 kubelet 上报的 conditions：
–kubectl get node-o jsonpath='{.status.conditions}' | jq
– 重点看KubeletReady、Ready、MemoryPressure、DiskPressure、PIDPressure的status和reason字段，有时status: False但reason是空或 generic，需结合日志交叉判断
快速验证网络与 API Server 连通性
节点需能稳定访问 kube-apiserver 才能维持 Ready 状态。
- 在问题节点上执行：
curl -k https://，应返回 “ok”；若超时或拒绝，检查防火墙、代理、证书信任链（如 /etc/kubernetes/pki/ca.crt 是否缺失或过期）: /healthz - 确认 kubelet 使用的 client cert/key 是否有效：
openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text -noout 2>/dev/null | grep -E "Not Before|Not After" - 如果集群启用了 NodeRestriction 准入控制器，确保该节点的 Node 对象存在且未被误删（
kubectl get node能查到，但状态异常时可能已被 API Server 清理）