K3s Token 无内置过期时间，但因 server node-token 被覆盖、agent node-password 不一致、rancher registration-token 轮换或 CA 信任链断裂，会导致注册失败。
K3s 的 token 本身没有内置的“过期时间”，但实际使用中会因多种原因导致 agent 注册失败，表现常被误认为“token 失效或过期”。核心问题在于 token 对应的认证信息在 server 或 agent 端不一致、不可用或被覆盖。以下是几种典型场景：
server 节点 node-token 文件被意外覆盖或重生成
node-token 位于 /var/lib/rancher/k3s/server/node-token，是 server 启动时生成的一次性凭证（格式为 hash,username,password,group）。若手动清理 server 数据目录、重装 k3s、或执行了类似 k3s-uninstall.sh 的脚本，该文件可能被删除或重建，导致原有 agent 使用的旧 token 不再匹配 server 端的 basic auth 记录。
- 验证方式：对比 agent 启动时传入的
K3S_TOKEN和当前 server 上的node-token内容是否完全一致 - 注意：即使 hash 值相同，后三段（user/pass/group）也必须严格匹配，否则认证拒绝
agent 节点重复注册且 /etc/rancher/node/password 不一致
首次注册成功后，agent 会在本地生成 /etc/rancher/node/password 并保存与 server 协商后的节点凭据。若该文件被删除（如 VM 重置、手动清理、未用标准卸载脚本），agent 再次启动会生成新 password，而 server 仍保留旧记录，造成比对失败。
- 常见日志提示：
node name conflict或authentication failed for node - 解决方法：将 server 中
/var/lib/rancher/k3s/server/cred/node-passwd对应节点的 password 行复制到 agent 的/etc/rancher/node/password中（需保持内容原样，无空格换行）
Rancher 管理场景下 registration-token 被手动轮换或失效
当 K3s 集群由 Rancher 托管时，agent 使用的是 Rancher ui 中生成的 registration token（非 server 自带的 node-token），该 token 在 Rancher 后台有明确生命周期管理：
- Rancher 默认每 24 小时自动轮换一次 registration token（可配置）
- 手动在 UI 中点击 “Re-generate” 会立即作废旧 token
- 集群从 Rancher 注销后，原有 token 不再有效，必须重新下载
证书信任链断裂导致 token 认证流程中断
agent 注册过程依赖与 server 的 TLS 双向通信。若 server 使用自签名证书，而 agent 节点未将对应 CA 加入系统信任库，则无法完成 https 请求，token 根本无法送达 server 进行校验。
- 典型现象：agent 日志中出现
x509: certificate signed by unknown authority - 影响范围：所有基于该 server 地址的 API 调用（包括 token 解析、证书拉取、节点注册）均失败
- 修复动作：把 server 的 CA 证书（如
/var/lib/rancher/k3s/server/tls/server-ca.crt）复制到 agent 的/usr/local/share/ca-certificates/并运行update-ca-certificates