企业官网建设流程全解析

K3s 如何用 k3s token rotate 轮换服务器集群 token 并让其他 server 节点重新加入

【免费下载链接】k3sLightweight Kubernetes项目地址: https://gitcode.com/GitHub_Trending/k3/k3s

在多 server 节点的 k3s 集群里，server token 是节点加入集群的凭证，同时它还被用作加密集群 bootstrap 数据的口令，因此集群启动之后不能直接更换 token 值——各 server 节点必须使用同一个 token。当 token 需要按安全规范定期轮换、或被怀疑泄露时，正确做法是通过k3s token rotate子命令用旧 token 解密 bootstrap 数据、再用新 token 重新加密，然后让其余 server 节点带新 token 重新加入。本文基于仓库内的 server-token-rotation ADR 和 token 子命令实现，给出可逐步执行的轮换与重新加入流程。

轮换前的准备

执行k3s token rotate前需要确认三点：

• 集群是已启动的多 server 节点集群，你至少持有第一个 server 节点的操作权限；
• 你手里有当前正在使用的旧 token 值（用于命令参数-t）；
• 轮换成功后，其余 server 节点会短暂处于带旧 token 无法加入的状态，直到完成后续重启步骤。

执行k3s token rotate时，客户端会先输出一条警告（见 pkg/cli/token/token.go 第 152 行）：

WARNING: Recommended to keep a record of the old token. If restoring from a snapshot, you must use the token associated with that snapshot.

也就是说：轮换后旧 token 不要丢弃。从某个 etcd 快照恢复集群时，必须使用与该快照关联的那个 token，因此旧 token 需要记录并妥善保存。

在第一个 server 上执行 k3s token rotate

k3s token rotate支持两种用法（-t传旧 token）：

# 1a) 不指定新 token，由系统生成一个 16 字符的随机 token k3s token rotate -t <OLD_TOKEN>

或：

# 1b) 指定新 token 值 k3s token rotate -t <OLD_TOKEN> --new-token <NEW_TOKEN>

其中<OLD_TOKEN>是集群当前正在使用的 server token；--new-token是可选的自定义新 token，不传时服务端调用util.Random(16)生成 16 字符随机值（见 pkg/server/handlers/token.go 第 78-83 行）。

该命令并不是本地改文件，而是向 server 发起一次 API 请求（PUT /v1-<program>/token），由服务端完成：用旧 token 解密 bootstrap 数据、用新 token 重新加密、更新数据目录下的token文件与 passwd 文件。成功后命令输出：

Token rotated, restart k3s nodes with new token

这条输出（与 docker token 测试 中断言的Token rotated, restart k3s nodes with new token一致）说明轮换请求已被服务端接受，但集群里其他节点还带着旧 token，必须执行下一步。

走 1a) 分支时，到执行轮换的那个 server 上读取新生成的 token：

cat /var/lib/rancher/k3s/server/token

ADR 中给出的是vi /var/lib/rancher/k3s/server/token，用编辑器打开该文件同样可以。该文件内容即后续各节点重新加入要使用的新 token 值。

让其他 server 节点用新 token 重新加入

拿到新 token 后，在其余每个 server 节点上依次执行（会短暂停止并重启该节点的 k3s 服务，请逐个节点操作）：

systemctl stop k3s # 编辑 /etc/rancher/k3s/config.yaml，把其中的 token 值更新为新 token systemctl start k3s

注意systemctl stop k3s会停止该节点上的控制面进程，操作期间该节点上的 API 副本不可用；多 server 集群中逐台滚动执行，避免同时停掉所有 server。

验证所有节点回到 Ready

全部 server 节点重启完成后，用 kubeconfig 检查节点状态：

kubectl get nodes

判断标准：集群原有的所有 server 节点都出现在列表中且处于 Ready 状态，说明它们已用新 token 成功读取了重新加密后的 bootstrap 数据并重新加入集群。tests/docker/token/token_test.go 中的“Rotate server bootstrap token”用例正是按这条路径验证的：执行k3s token rotate -t <旧token> --new-token <新token>，给全部 server 写入新 token 后systemctl restart k3s，最终断言节点数不变且所有节点 Ready。

限制与边界

• 快照恢复必须用对应快照的 token：k3s token rotate自带的警告已说明这一点，轮换后保留旧 token 记录是必做事项。
• token 已泄露且怀疑节点被入侵时，rotate 不够：ADR 明确指出，若按 token 泄露的最坏情况处理，唯一能保证集群安全状态的方式是彻底重新安装集群（clean reinstall），因为恶意程序可能已植入后门。k3s token rotate适用于主动的定期轮换，或泄露被及时发现、尚未被恶意利用的场景。
• agent token 与 server token 相同时会被一并修改：服务端处理逻辑中，若 passwd 文件中 agent（node）的 token 与旧 server token 相同且未单独配置 agent token，则 agent token 也会随之更新为server:前缀的新值（见 pkg/server/handlers/token.go 第 94-98 行）。此时已加入的 agent 节点需要用新 token 重新加入，处理方式与上面的 server 节点相同：更新其/etc/rancher/k3s/config.yaml中的token值后systemctl restart k3s-agent。
• 集群启动后各 server 必须使用同一个 token，--new-token指定自定义值时可自行选择长度与字符，服务端会按内部逻辑做规范化处理。

相关文档：Support Rotating Server Tokens、token 子命令定义、rotate 客户端实现、服务端轮换处理、bootstrap 数据重新加密逻辑。

【免费下载链接】k3sLightweight Kubernetes项目地址: https://gitcode.com/GitHub_Trending/k3/k3s