K3s节点失联主因是Lease心跳中断，需检查网络连通性、证书有效性（client-k3s.pem/key）、kubelet是否正常更新NodeLease、系统资源及时间同步（偏差≤1分钟）。
这是 K3s 节点失联的典型表现，本质是节点无法持续向服务端（server node）上报心跳（通过 Lease 机制），导致控制平面认为节点已离线。
检查节点网络连通性与证书有效性
K3s 使用双向 TLS 认证，节点必须能稳定访问 server 的 API 地址（默认 https://<server-ip>:6443），且本地证书未过期或被误删。
- 在 agent 节点执行：
curl -k https://<server-ip>:6443/healthz，确认能返回ok；若超时或拒绝连接，说明网络不通或 server 未监听该地址 - 检查
/var/lib/rancher/k3s/agent/client-k3s.pem和client-k3s-key.pem是否存在且可读；证书通常有效期为 1 年，可通过openssl x509 -in /var/lib/rancher/k3s/agent/client-k3s.pem -noout -dates查看有效期 - 若证书过期或缺失，重启 k3s agent 会自动重签（前提是 server 正常且 agent 首次注册用的 token 仍有效）；如 token 已失效，需重新生成并更新 agent 启动参数
确认节点 Lease 更新是否被阻塞
K3s agent 通过 kubelet 每 10 秒更新一次 NodeLease 对象。若 kubelet 卡住、资源耗尽或 etcd（或 sqlite）写入延迟高，lease 就无法刷新。
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 在 agent 节点运行：
journalctl -u k3s-agent -n 50 --no-pager | grep -i "lease\|node status"，观察是否有持续上报日志；若长时间无输出，说明 kubelet 未正常工作 - 检查系统资源：
top或htop看 CPU/内存是否打满；df -h /var/lib/rancher/k3s确保磁盘未满（尤其 sqlite db 文件增长快时） - 如使用嵌入式 sqlite（默认），高负载下可能因 WAL 锁或 fsync 延迟导致 lease 更新失败；可临时启用
--with-node-id并观察是否缓解（减少部分元数据竞争），但根本解法是优化 I/O 或切换到轻量级外部 DB（如 dqlite）
排查时间同步问题
Lease 依赖准确的时间戳判断过期。若节点间系统时间偏差超过 1 分钟（Kubernetes 默认容忍窗口），server 可能拒绝过期或未来时间的 lease 更新。
- 在所有节点执行：
timedatectl status，确认System clock synchronized: yes且偏差 - 避免仅依赖 systemd-timesyncd；生产环境建议统一配置 chrony 或 ntp，并指向同一可靠 NTP 源
- 特别注意虚拟机、容器化节点或云主机——某些平台（如 AWS EC2）需额外启用
chrony并禁用 hypervisor 时间同步冲突
验证 server 端状态与日志
“node not found” 错误也可能源于 server 侧状态异常，例如节点注册信息丢失、etcd/dqlite 数据损坏或 controller-manager 异常。
- 在 server 节点执行：
kubectl get nodes和kubectl get leases -A | grep <node-name>，确认节点对象和对应 lease 是否真实缺失 - 查看 server 日志：
journalctl -u k3s -n 100 --no-pager | grep -i "node\|lease\|register"，重点找failed to update node lease、node not found for lease或注册阶段的certificate signed by unknown authority - 若发现大量 “context deadline exceeded” 或 “i/o timeout” 报错，大概率是 backend 存储响应慢（sqlite 写入卡顿、dqlite leader 切换中、或外部 etcd 不可用）
