K3s server重启后agent掉线主因是信任状态失效或连接参数不匹配，需依次检查server地址与端口、token有效性、证书信任链完整性及节点名称唯一性。
K3s server 重启后 agent 全部掉线但日志无明显错误，通常不是证书或网络连通性问题，而是 agent 与 server 之间信任状态失效或连接参数不匹配导致的“静默失联”。重点排查 server 地址、token 有效性、证书信任链和 agent 启动时的连接行为。
检查 agent 是否仍在使用旧的 server 地址或端口
K3s server 重启后若监听地址、端口或 TLS 终止方式（如从 HTTPS 切到 HTTP）有变化，agent 会持续尝试旧配置并静默失败。agent 日志里可能只显示“Failed to connect to”或反复重试，但不报错细节。
- 在任一 agent 节点上执行：sudo cat /var/lib/rancher/k3s/agent/etc/k3s-agent-env，确认
K3S_URL和K3S_TOKEN是否仍指向当前 server 的正确地址（如https://192.168.1.10:6443） - 检查 server 是否实际监听了该端口：sudo ss -tlnp | grep :6443（注意：K3s 默认用 6443，非 8443）
- 若 server 启用了
--tls-san或绑定了特定 IP，请确保 agent 连接的地址在 SAN 列表中，否则 TLS 握手会失败且日志可能只显示 “x509: certificate is valid for ... not ...”
确认 agent 使用的 token 是否仍然有效
K3s server 重启不会自动刷新 token，但若 server 是全新初始化（如误删 /var/lib/rancher/k3s/server），旧 token 就彻底失效。agent 持有已过期或不存在的 token 时，server 会直接拒绝连接，且默认不记录详细拒绝原因。
- 在 server 上查看当前有效 token：sudo cat /var/lib/rancher/k3s/server/node-token
- 对比 agent 的
K3S_TOKEN值是否一致；若不一致，需用新 token 重启 agent：sudo k3s agent --server https://SERVER_IP:6443 --token NEW_TOKEN - 注意：token 文件仅在 server 首次启动时生成，重启不会覆盖；但如果 server 数据目录被清空或重装，token 就变了
验证 agent 证书是否被 server 认可
K3s agent 首次注册时会生成证书并由 server 签发，后续复用。server 重启后若 CA 证书或私钥丢失（如 /var/lib/rancher/k3s/server/tls 被删），就无法校验 agent 证书，导致连接被拒。
- 检查 server 证书目录完整性：ls -l /var/lib/rancher/k3s/server/tls/{client-ca.crt,server-ca.crt,server-ca.key}
- 若缺失关键文件（尤其是
server-ca.key），server 无法签发或校验证书，agent 会卡在 TLS handshake 阶段。此时需从备份恢复，或重新初始化 server 并让 agent 重新入网 - agent 端可临时加
--debug启动，观察日志中是否有x509相关报错，定位是证书不可信还是握手超时
检查 agent 是否因节点名称冲突被 server 拒绝
K3s server 重启后会加载已有 node 状态。如果 agent 启动时使用的 --node-name（或主机名）与之前注册的节点名重复，且旧节点状态未清理，server 可能拒绝新连接以避免冲突。
- 在 server 上运行：kubectl get nodes，确认掉线节点是否还显示为
NotReady或残留状态 - 若存在同名旧节点，手动删除：kubectl delete node node-name，再重启对应 agent
- 也可在 agent 启动时显式指定唯一名称：--node-name $(hostname)-$(date +%s)，避免命名冲突
