问题出现得很突然，日志倒是留得挺全。阿里云 3 台 ECS 组 K8s 1.28 集群，Ubuntu 22.04 配 containerd 1.7，第二天把新节点加进集群，kubeadm join 报 could not find a JWS signature in the cluster-info ConfigMap for token ID，把昨天记下的命令原样复制也不管用。
刚开始盯着「有人执行过 kubeadm token delete 把旧 token 清掉了」，折腾了半个多小时，排掉了。
真正麻烦的地方在于，几个原因的现象几乎一样。kubeadm 的 bootstrap token 默认 24 小时过期，跨天就失效。少数情况下是cluster-info 的 ConfigMap 里已经清掉了对应的 JWS 签名。
少数情况下是控制面证书 key 轮换过，旧 token 的签名对不上。
动手时先看现有 token 和剩余有效期
kubeadm token list接着重新生成 token 并打印完整加入命令
kubeadm token create --print-join-command需要长期有效就把 TTL 设成 0
kubeadm token create --ttl 0 --print-join-command剩下的就是在新节点执行后确认节点状态
kubectl get nodes -o wide报错是间歇性的，我蹲守了半小时才抓到一次完整现场。
改完先别撤，确认这几项。kubectl get nodes 里新节点状态是 Ready，kubelet 日志没有 unauthorized，token list 里能看到新建的那条。
提醒一点。TTL 为 0 的 token 永不过期，方便同时也是风险，节点加入完成后应删掉临时 token，改用短期凭证。报错文案容易误导，真正的原因往往在相邻那一层的日志里。