K3s 高可用集群踩坑实录：节点加入失败死锁？四步“核弹级强拆”彻底清理脏数据

大家好，我是赛博包工头。欢迎回到赛博工地。

最近在给 HomeLab 打 K3s 高可用（HA）集群地基的时候，遇到了一个非常搞心态的坑：新加入的控制节点（比如 Master 03）死活连不上主集群，一直处于 NotReady 或者疯狂重启的状态。

如果你去查日志（journalctl -u k3s），会发现满屏都在刷类似这样的报错：

rpc error: code = Unavailable desc = connection error: desc = "transport: authentication handshake failed: context deadline exceeded" failed to get etcd status

很多兄弟遇到这种情况，第一反应是：“卸载重装！” 结果跑完官方的卸载脚本，再重新安装，发现问题依旧，还是同样的报错！

今天，我们就来扒一扒这个坑的底层原因，并给出一套“挫骨扬灰”级别的强拆重装方案。

---

🔍 案情分析：为什么卸载重装没用？

罪魁祸首在于：K3s 官方提供的卸载脚本 /usr/local/bin/k3s-uninstall.sh “太温柔了”。

为了防止用户手残误删掉宝贵的生产数据，这个官方脚本在卸载程序时，故意保留了 /var/lib/rancher/k3s 这个核心数据目录（里面存着本地的 ETCD 数据库文件）。

这就导致了一个致命的逻辑死锁：

1. 你的节点之前因为某种原因加入集群失败，本地生成了一份残缺或错误的 ETCD 数据。
2. 你执行了官方卸载脚本，卸载了 K3s 程序。
3. 你重新执行加入命令。
4. 新安装的 K3s 程序一启动，直接读取到了上一波残留的“脏数据”。它拿着这套旧的、错误的身份凭证去向主集群报到，立刻又被主集群的安保机制拒之门外，当场死锁崩溃。

所以，想要真正重装，我们必须把这台机器上的残骸彻底炸平。

---

🧨 终极核弹强拆与重装指南

请严格按照以下 4 步流程操作，少一步都不行。

第一步：执行官方卸载（停机熄火）

首先，在出故障的节点（例如 Master 03）上，把 K3s 进程停掉并执行常规卸载：

/usr/local/bin/k3s-uninstall.sh

(如果是 Agent 节点，执行 /usr/local/bin/k3s-agent-uninstall.sh)

第二步：手动清理物理残骸（🔥 最关键的一步）

这是官方脚本漏掉的，也是破除死锁的核心。我们必须把它的老巢彻底炸平。 依然在 故障节点（Master 03） 上执行：

sudo rm -rf /var/lib/rancher/k3s
sudo rm -rf /etc/rancher/k3s
sudo rm -rf /var/lib/kubelet

⚠️ 警告：执行完这一步，该节点上的所有 K3s 本地数据将彻底灰飞烟灭，不可恢复。

第三步：去主节点注销“僵尸户口”

因为 Master 03 之前卡死过，主集群可能还保留着它的“僵尸档案”。为了防止主集群出于安全防范拒绝它重新加入，我们需要去主节点把它踢掉。

登录到健康的 主节点（例如 Master 01，10.0.10.10），执行：

kubectl delete node k3s-master-03

第四步：重新注入灵魂（满血复活）

现在，Master 03 已经是一张纯洁的白纸，主集群里也没有了它的黑历史。 回到 故障节点（Master 03），重新粘贴你规划好的加入命令

---

🏁 验收施工成果

执行完第四步后，在终端里等个大概 30 秒。然后切回你的本地电脑或主节点，敲一下查岗命令：

kubectl get nodes