心跳丢失但网络通畅，问题在于Kubelet与控制面通信链路中间环节，需重点排查证书有效性、API Server地址配置、容器运行时（PLEG）健康状态及系统资源压力四类隐性故障。
心跳丢失却网络通畅，说明问题不在基础连通性，而在 Kubelet 与控制面的通信链路中间环节。重点排查证书、配置、运行时状态和资源压力这四类隐性故障。
检查 Kubelet 客户端证书是否有效
K3s agent 注册后依赖定期刷新的客户端证书向 server 发送心跳。证书过期或签名不匹配会导致心跳被拒绝，但 curl 测试 6443 端口仍可能返回 200（healthz 不校验证书）。
- 执行
openssl x509 -in /var/lib/rancher/k3s/agent/pki/kubelet-client-current.pem -noout -dates查看有效期 - 若证书已过期，需重启 k3s agent 服务触发自动轮换；若轮换失败，检查 server 节点时间是否同步、CA 证书是否被意外替换
- 对比 agent 和 server 上的
/var/lib/rancher/k3s/server/tls/client-ca.crt内容是否一致
确认 Kubelet 是否真正连接到正确的 API Server
K3s agent 启动时会读取 /var/lib/rancher/k3s/agent/etc/k3s-agent-env 或环境变量中的 server 地址。错误的地址（如残留旧 IP、DNS 解析异常、代理配置干扰）会导致 Kubelet 持续尝试连接不可达端点，日志中出现 connection refused 或 i/o timeout，但本地 nc -zv 测试可能因防火墙放行而“看似通”。
- 运行
ps aux | grep k3s | grep server=确认实际连接的目标 - 在 agent 节点执行
curl -k https://，观察是否返回 401（认证层通）还是 403/404（路由或权限问题）:6443/api/v1/nodes/ - 检查
/etc/rancher/k3s/config.yaml中server:配置是否为当前可用 master 地址，避免写死已下线节点
验证容器运行时与 PLEG 健康状态
心跳上报由 Kubelet 主动发起，但前提是其内部 Pod Lifecycle Event Generator（PLEG）能正常工作。若 containerd 响应缓慢、镜像拉取卡住或存在大量僵尸容器，PLEG 会进入 not healthy 状态，Kubelet 将暂停上报节点状态，导致 NotReady。
- 执行
sudo ctr containers list | wc -l查看容器数量是否异常偏高（>500 可能影响性能） - 运行
sudo systemctl status containerd确认运行时进程存活且无 restart 频繁记录 - 查看 Kubelet 日志中是否有
PLEG is not healthy或failed to update node status关键报错 - 临时执行
sudo ctr namespaces list和sudo ctr c ls -n k8s.io判断命名空间和容器元数据是否可读
排查系统级资源与内核限制
内存不足、inode 耗尽或内核参数限制（如 fs.inotify.max_user_watches 过低）不会阻断 TCP 连接，但会让 Kubelet 无法完成文件监听、证书加载或事件处理，表现为心跳静默。
- 检查 inode 使用率：
df -i /var/lib/rancher/k3s，若使用率 >95%，清理旧日志或镜像 - 查看内存压力：
free -m和cat /proc/meminfo | grep -E "MemAvailable|OomKill" - 确认 inotify 限制：
cat /proc/sys/fs/inotify/max_user_watches，建议不低于 524288 - 检查 dmesg 输出：
dmesg -T | tail -20是否有 OOM killer 杀掉 kubelet 或 containerd 的记录
