节点清理缓存后未同步，本质是节点状态未及时上报或控制平面未正确感知变更；需检查kubectl get nodes状态、kubelet服务与日志、pod真实运行态及api server通信是否正常。
节点清理缓存后未同步，本质不是“缓存失效”问题，而是**节点状态未及时上报或控制平面未正确感知变更**。Kubernetes 本身不管理应用层缓存，所谓“清理缓存”通常指手动执行了 echo 2 > /proc/sys/vm/drop_caches 或清空容器内临时目录等操作；若之后业务异常、服务响应不一致，真正要查的是：这台节点是否仍被调度器信任？其 Pod 是否真实健康？状态是否已同步到 API Server？
确认节点是否真正“就绪”且状态已同步
缓存清理本身不会让节点变 NotReady，但若操作触发了内存压力（如 drop_caches 后引发 OOM Killer 杀进程）、或恰好撞上 kubelet 心跳丢失窗口，就可能造成短暂失联。先验证当前状态：
- 运行
kubectl get nodes <node-name> -o wide</node-name>，看 STATUS 是否为 Ready，AGE 是否持续更新（非卡在几小时前） - 运行
kubectl describe node <node-name></node-name>，重点检查：
• Conditions 下Ready状态是否为True，Last Heartbeat Time 是否在 1 分钟内
• Events 区域是否有近期警告，例如NodeNotReady、SystemOOM、KubeletStoppedPostingNodeStatus - 对比该节点与其他节点的
InternalIP和PodCIDR是否一致——若 PodCIDR 为空或异常，说明节点注册信息不完整，同步已中断
检查 kubelet 是否正常上报状态
节点状态同步依赖 kubelet 主动向 API Server 发送心跳。缓存清理若导致系统负载飙升或内存紧张，kubelet 可能被延迟调度甚至被 OOM Killer 终止。
- SSH 登录该节点，执行
systemctl is-active kubelet，确认服务处于 active (running) - 查看最近日志：
journalctl -u kubelet -n 100 --no-pager | grep -E "(status|heartbeat|failed|oom)"
• 若出现failed to report node status或context deadline exceeded，说明与 API Server 通信异常
• 若有Out of memory: Kill process kubelet，则需检查内存限制和预留 - 检查 kubelet 配置中
--node-status-update-frequency（默认 10s），确认未被误设为过大值（如 5m），否则状态更新严重滞后
验证 Pod 实际运行与状态同步是否一致
即使节点显示 Ready，其上的 Pod 状态也可能未同步——比如容器已退出但 kubelet 还没上报，或 API Server 缓存了旧状态。
- 列出该节点上所有 Pod：
kubectl get pods -A --field-selector spec.nodeName=<node-name></node-name> - 对任一关键 Pod，执行：
•kubectl get pod <pod-name> -n <ns> -o wide</ns></pod-name>—— 查看 NODE 和 STATUS
•kubectl describe pod <pod-name> -n <ns></ns></pod-name>—— 检查 Events 中最后一条是否为Pulled/Created/Started，而非陈旧的BackOff或Failed - 进入节点，用
crictl ps -a或docker ps -a直接查容器真实状态，与 kubectl 输出比对。若容器已退出但 kubectl 显示 Running，说明状态同步断开
排查网络与证书层面的隐性阻断
缓存清理虽是本地操作，但若触发内核资源争抢（如 slab 内存暴涨），可能间接影响网络栈或 TLS 握手，导致 kubelet 无法维持与 API Server 的长连接。
- 在该节点上测试与 API Server 通信：
curl -k https://<api-server-ip>:6443/healthz</api-server-ip>，应返回ok - 检查 kubelet 客户端证书是否过期：
openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -noout -enddate - 运行
ss -tulnp | grep :6443，确认没有大量TIME_WAIT或连接堆积，排除 socket 耗尽
