工地日记

赛博拆迁办：安全切断外接大水管 (卸载 NFS 动态供应器)

starlightBlog.post.date

在赛博工地，拆迁工作也分危险等级。如果说卸载 Longhorn 相当于“定向爆破承重墙”，那么卸载 NFS 动态供应器仅仅相当于**“辞退了一个水管工”**。

因为 NFS 的实际数据都安全地躺在你远端的 TrueNAS 或群晖里，K3s 集群内运行的仅仅是一个负责“自动建文件夹和接管子”的调度程序（Provisioner）。所以，它的卸载过程非常轻松且无痛。

尽管如此，为了保证集群状态的绝对干净，包工头还是建议你按照标准协议进行拆除。

⚠️ 拆除前置：清退依赖水管的租客

安全规范

在辞退水管工之前，最好先确认集群里是否还有应用正在使用 nfs-client 这个存储类（StorageClass）。

如果还有应用在用，当你卸载了供应器后，这些应用原本挂载的旧硬盘虽然还能读写，但未来如果它们意外重启或者你需要扩容，由于失去了“水管工”的调度，它们可能会陷入异常状态。

检查指令：

# 查看是否还有绑定到 nfs-client 的 PVC（存储声明）
kubectl get pvc -A | grep nfs-client

(如果输出为空，说明水管已经全部闲置，可以放心开拆。如果还有业务在使用，请先决定是保留业务，还是将其连同 PVC 一并删除。)

🚜 核心拆除作业

呼叫 Helm 拆迁队 (Uninstall Provisioner)

因为我们是使用 Helm 规范化部署的，直接用一条命令就可以把水管工（Pod）、它的权限（RBAC）以及图纸代号（StorageClass）全部带走：
Terminal window
```
helm uninstall nfs-provisioner -n kube-system
```
预期输出：release "nfs-provisioner" uninstalled。此时，K8s 已经失去了自动在 NAS 上划分目录的能力。
打扫物理 NAS 的残余数据 (Manual Cleanup)

还记得我们在上一篇配置 values.yaml 时，特意加了一个防爆机制 archiveOnDelete: true 吗？

正是因为这个机制，即使你之前在 K8s 里删除了测试用的 PVC，水管工也不会真的去删你 NAS 里的数据，而是会将那个文件夹重命名，加上 archived- 前缀。

现在，水管工已经被我们辞退了，这部分“赛博垃圾”就需要你手动去清理了：
- 登录你物理 NAS 的后台（TrueNAS / 群晖）。
- 打开文件管理器，进入你分配给 K8s 的那个共享根目录（例如 /mnt/pool/k8s_nfs）。
- 你会看到一些名字带有 archived- 开头的文件夹。如果你确认这些数据都已经没用了，直接在 NAS 后台右键 -> 删除即可，彻底释放物理空间。
清理本地 Helm 仓库 (可选)

如果你有极度的强迫症，不想在本地电脑上留下任何痕迹，可以顺手把官方的图纸源也删掉：
Terminal window
```
helm repo remove nfs-subdir-external-provisioner
```

🔍 拆除验收

最后，敲下这行命令，看看 K8s 的“存储物资局”里还有没有这张图纸：

kubectl get storageclass

如果输出的列表中已经找不到 nfs-client，且终端里没有任何关于 nfs-provisioner 的报错，那么恭喜你，这根外接大水管已经被安全、干净地彻底切断！

赛博拆迁办：安全定向爆破 Longhorn 分布式存储大坝

starlightBlog.post.date

在 Kubernetes 的世界里，无状态应用（如之前部署的 Headlamp）卸载起来就像拔掉 U 盘一样简单。但是，存储组件是集群的“承重墙”。

Longhorn 作为底层存储大坝，掌管着所有容器的命脉数据。为了防止新手误操作导致“删库跑路”的悲剧，Longhorn 官方在底层上了一道极其死板的“物理锁”。如果你直接暴力执行卸载，整个 longhorn-system 命名空间会永远卡在 Terminating（挂起）状态，你的 K8s 集群将陷入无尽的死锁僵局。

今天，包工头就结合官方的卸载与排错指南，带你按照正规的“定向爆破协议”，一步步安全、干净地拆除这座大坝，并解决拆除过程中可能遇到的所有疑难杂症。

⚠️ 拆除前置警告：清退所有租客！

极度危险

在执行任何卸载命令前，为了防止损坏集群，官方强烈建议： 你必须手动删除所有正在使用 Longhorn 卷的 Kubernetes 工作负载（包括 PersistentVolume, PersistentVolumeClaim, StorageClass, Deployment, StatefulSet 等）。 一旦拆除开始，所有基于 Longhorn 创建的虚拟硬盘数据将瞬间灰飞烟灭！请务必提前做好数据备份。

🚜 核心爆破流程 (Helm 方式)

解除数据自毁保护锁 (The Safety Catch)

这是卸载 Longhorn 最核心、最不可省略的一步。默认情况下 deleting-confirmation-flag 是关闭的，卸载任务会直接报错拦截。我们需要强制告诉 Longhorn 控制器：“我确定要销毁一切”。

在终端敲入这行指令，修改核心配置，允许删除操作：
Terminal window
```
kubectl -n longhorn-system patch -p '{"value": "true"}' --type=merge lhs deleting-confirmation-flag
```
预期输出：setting.longhorn.io/deleting-confirmation-flag patched。保护锁现已解除。
呼叫 Helm 拆迁队 (Uninstall Release)

保护锁解除后，我们就可以正常呼叫 Helm 执行反向拆除了。它会自动释放 Cilium 分配的 LoadBalancer IP，并遣散所有节点的存储引擎容器。
Terminal window
```
helm uninstall longhorn -n longhorn-system
```
稍等片刻，直到终端提示 release "longhorn" uninstalled。
清理大坝废墟 (Delete Namespace)

确认 Helm 卸载完毕后，我们将整个存储专区物理抹除：
Terminal window
```
kubectl delete namespace longhorn-system
```
打扫物理宿主机的残渣 (Node Data Cleanup)

注意：这一步需要到你所有的 3 台 Ubuntu 物理机/虚拟机上分别执行！ 虽然 K8s 里的组件删除了，但 Longhorn 之前在你的宿主机磁盘上生成的物理数据块依然保留着。为了彻底归还磁盘空间，直接使用 rm 大法：
Terminal window
```
sudo rm -rf /var/lib/longhorn
```
恢复 Linux 内核秩序 (可选)

如果你确定这几台机器以后再也不碰基于 iSCSI 的存储，可以把之前我们立下的“开机规矩”撤销掉。
Terminal window
```
sudo rm /etc/modules-load.d/longhorn.conf
sudo systemctl disable --now iscsid
```

🛠️ 疑难杂症与抢修指南 (Troubleshooting)

在赛博工地，意外总是难免的。如果你在卸载过程中遇到了卡死、报错，或者突然“手滑”后悔了，请参考以下官方急救方案：

💊 症状 1：手滑卸载了，但我不想删！（取消卸载）

如果你不小心执行了 helm uninstall（且当时没开保护锁导致它卡在 uninstalling 状态），你可以利用 Helm 的时光机功能紧急回档。

抢修指令：

# 1. 查找 Longhorn 卸载前的最后一个正常版本号 (REVISION)
helm list -n longhorn-system -a

# 2. 假设查到上一个正常版本是 1，执行强制回滚：
helm rollback longhorn 1 -n longhorn-system

提示 Rollback was a success! 代表大坝抢修成功，数据保住了！

💊 症状 2：Namespace 一直卡在 Terminating，CRD 删不掉

这是 Kubernetes 卸载存储组件最常见的恶疾：Finalizer 幽灵锁。因为底层引擎已经被你删了，K8s 还在傻傻等待底层引擎来确认删除这些 CRD（自定义资源），从而形成死锁。

抢修指令（暴力清除所有 Longhorn 状态）： 执行以下脚本，它会遍历所有 Longhorn 的 CRD，强行抹除它们的 Finalizer，然后连根拔起。

# 批量强拆：剥夺所有 Longhorn 资源的终结器
for crd in $(kubectl get crd | grep longhorn.io | awk '{print $1}'); do
    kubectl get $crd -n longhorn-system -o name 2>/dev/null | xargs -I {} kubectl patch {} -n longhorn-system -p '{"metadata":{"finalizers":null}}' --type merge 2>/dev/null
done

💊 症状 3：执行清理脚本时报错 Webhook 找不到

如果你在执行上面那个清理脚本时，K8s 抛出了类似这样的错误： Internal error occurred: failed calling webhook "validator.longhorn.io"... service "longhorn-admission-webhook" not found

这是因为残缺的卸载过程把 Webhook 服务删了，但注册表里还留着它的名字，导致 K8s 每次修改资源都想去请求一个不存在的验证服务。

抢修指令： 删除这些拦截请求的幽灵配置，为清理脚本放行：

kubectl delete ValidatingWebhookConfiguration longhorn-webhook-validator
kubectl delete MutatingWebhookConfiguration longhorn-webhook-mutator

删除这两个配置后，重新执行症状 2中的 CRD 清理脚本，即可丝滑通关。

🔍 终极验收

历经波折后，执行最后的扫尾质检：

kubectl get crd | grep longhorn
kubectl get ns | grep longhorn

如果上述命令没有任何输出，恭喜你，这座赛博存储大坝已经被完美定向爆破，所有的顽疾和锁链都已被彻底斩断！

K3s + Cilium 踩坑实录：Longhorn 插件无限重启？揪出 eBPF 路由脑裂的幕后黑手

starlightBlog.post.date

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

在咱们上一期对 K3s 故障节点进行了“核弹级强拆”并重新加入集群后，本以为可以顺利盖起 Longhorn 存储大坝了。结果，Longhorn 的核心存储特派员 longhorn-csi-plugin 却一直在无限崩溃重启（CrashLoopBackOff）。

表面上看是存储插件坏了，但经过一顿抽丝剥茧，最后发现：这根本不是存储的锅，而是一起典型的网络大动脉断裂案！

今天这篇排错实录，我们就来复盘一下如何解决这种“查号台还活着，但去查号台的路被炸断了”的底层网络脑裂问题。

💥 案发现场：伪装成存储故障的网络崩塌

当时查看 longhorn-csi-plugin 的崩溃遗言（Logs），发现了极其关键的一行报错：

E0419 00:36:26.346354       1 main.go:167] "Error connecting to CSI driver" err="context deadline exceeded"
time="2026-04-19T00:36:30.790662906Z" level=warning msg="Failed to initialize Longhorn API client Get \"http://longhorn-backend:9500/v1\": dial tcp: lookup longhorn-backend on 10.61.0.10:53: read udp 10.60.2.244:53943->10.61.0.10:53: i/o timeout. Retrying"

日志翻译： Longhorn 插件启动时，需要找集群内部的“114查号台”（CoreDNS，IP 为 10.61.0.10:53）去查询总控中心的地址。结果请求发出去后，如同石沉大海，直接报了 i/o timeout（连接超时）。因为拿不到总控地址，插件干脆拒绝启动，最后被 Kubelet 当做死进程给毙了。

🕵️‍♂️ 抽丝剥茧：派出侦察兵探路

为了验证是不是真的连不上 DNS，我跑到后台看了一眼 CoreDNS 的状态，发现它分明是 1/1 Running，活得好好的，安安稳稳地跑在 k3s-master-02 节点上。

接着，我拉起了一个带 nslookup 工具的 busybox 侦察兵进行极限测试：

kubectl run -i --tty --rm debug-net --image=busybox --restart=Never -- nslookup kubernetes.default

返回的结果非常绝望：

;; connection timed out; no servers could be reached

结论：查号台活得好好的，但去找查号台的路，全断了。

🧠 底层逻辑：大动脉为什么会断？

这要归咎于咱们这套集群的高级架构。

在安装 K3s 时，我们加上了 --disable-kube-proxy 参数。这意味着 Kubernetes 传统的基于 iptables 的内部流量转发机制被废弃了。全集群的 Service IP（包括内部 DNS 地址 10.61.0.10），全靠 Cilium 的 eBPF 机制在 Linux 内核底层进行拦截和高效转发。

但是！咱们刚才对 k3s-master-03 执行了“核弹级强拆”，导致整个集群的 Cilium 路由映射表（BPF Maps）出现了严重的数据断层和脑裂。

Cilium 彻底迷失了方向，不知道该怎么把 UDP 53 端口的请求跨节点发给 k3s-master-02 上的 CoreDNS，于是网络包在内核层直接被无情丢弃。底层网络一断，上层依赖内部域名的 Longhorn 存储插件自然跟着全军覆没。

🛠️ 抢修方案：网络管线“大换血”

既然病根在底层的路由表缓存，咱们不需要重装，只需要强制集群对网络管线进行一次滚动重启（Rollout Restart），让 eBPF 重新绘制整张全网路由表即可。

请依次执行这排雷三把斧：

第一斧：强制重建 Cilium 网络映射表

让所有节点的 Cilium 特派员重新扫描集群，重写内核里的路由规则：

kubectl rollout restart ds cilium -n kube-system

(敲完后喝口水等个半分钟，让 3 个节点的 Cilium Pod 挨个重启完成)

第二斧：顺手重启查号台 (CoreDNS)

为了防止 CoreDNS 本身残留什么僵尸缓存，给它也来一记还我漂漂拳：

kubectl rollout restart deploy coredns -n kube-system

第三斧：再次派出侦察兵验证验收

等上面的网络和 DNS Pod 都处于 Running 状态后，重新敲一遍之前的测试命令：

kubectl run -i --tty --rm debug-net --image=busybox --restart=Never -- nslookup kubernetes.default

💡 预期结果： 只要这次没有报 timed out，而是瞬间返回了类似 Server: 10.61.0.10 和 Address: 10.61.0.10:53 的解析结果（即便带了 NXDOMAIN 的小 Bug 也不影响），就说明全集群的大动脉彻底打通了！

大动脉一通，之前卡在 CrashLoopBackOff 的 longhorn-csi-plugin 就会瞬间找回组织，自动停止报错并挂载成功。

包工头施工笔记： 排查 K8s 故障时，如果上层应用报“连接超时”，不要急着重装应用。拔出网络排错“侦察兵”测一下底层连通性，往往能事半功倍。“遇到 eBPF 脑裂，一键 Rollout 重启网络插件”，这是赛博工地里必须掌握的保命神技！

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

starlightBlog.post.date

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

最近在给 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 数据库文件）。

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

你的节点之前因为某种原因加入集群失败，本地生成了一份残缺或错误的 ETCD 数据。
你执行了官方卸载脚本，卸载了 K3s 程序。
你重新执行加入命令。
新安装的 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

PVE 宿主机实战：4T USB 硬盘挂载与 NFS 权限配置指南

starlightBlog.post.date

在 PVE 环境中，将大容量 USB 硬盘挂载至宿主机并开启 NFS 共享，是实现跨虚拟机数据共享的高效方案。但在实际操作中，磁盘识别错误会导致数据丢失，网段配置不当会导致访问受阻。本文记录了从底层格式化到权限调优的标准流程。

一、物理硬盘初始化

1. 确认硬盘标识（极重要）

在执行任何格式化操作前，必须核对物理磁盘。

lsblk

注意： 观察磁盘容量（如 3.7T）和类型。通常系统盘为 sda，外挂盘可能为 sdb 或 sdc。请在后续步骤中将 /dev/sdb 替换为你实际识别到的磁盘代号。一旦选错，数据将不可恢复。

2. 创建分区与格式化

对于超过 2T 的硬盘，必须使用 GPT 分区表：

# 使用 fdisk 工具（以 /dev/sdb 为例，请按实际修改）
fdisk /dev/sdb

# 交互指令：
# 输入 g (创建 GPT 分区表)
# 输入 n (创建新分区，起始和结束扇区均按回车保持默认)
# 输入 w (写入并退出)

# 格式化分区为 ext4
mkfs.ext4 /dev/sdb1

3. 实现持久化挂载

使用 UUID 挂载可以防止 USB 插拔后驱动器路径改变。

# 获取 UUID
blkid /dev/sdb1
# 记录 UUID="xxxxxxxx-xxxx-..." 部分

# 创建挂载点
mkdir -p /mnt/nfs

# 修改系统挂载表
nano /etc/fstab

# 在末尾添加（替换为你实际的 UUID）：
UUID=你的UUID /mnt/nfs ext4 defaults 0 2

# 生效挂载
mount -a

二、 NFS 服务安装与核心权限配置

1. 安装服务

apt update && apt install -y nfs-kernel-server

2. 配置共享权限（/etc/exports）

编辑配置文件：nano /etc/exports，添加如下配置：

/mnt/nfs 10.0.0.0/16(rw,sync,no_subtree_check,no_root_squash,insecure)

💡 参数详解与调整说明：

网段地址 (10.0.0.0/16)： 必须按实际修改。这里的地址定义了谁能访问此共享。
- 如果你的 IP 是 192.168.1.x，请填入 192.168.1.0/24。
- 使用 /16 掩码（如 10.0.0.0/16）可以覆盖 10.0.x.x 范围内的所有 IP，适合多子网环境。
insecure (关键)：默认 NFS 要求客户端使用 1024 以下端口，而 Kubernetes/K3s 等容器化平台挂载时常使用高位随机端口。不加此参数会导致 Access Denied。
no_root_squash：允许客户端以 root 权限写入，这对于需要持久化存储的应用（如数据库、媒体库）至关重要。

三、服务生效与状态验收

修改配置后必须手动刷新导出表：

# 强制重新导出所有路径
exportfs -ra

# 查看当前生效的完整配置
exportfs -v

验收标准： 在 exportfs -v 的输出中，确认包含了你设置的路径和网段，并且权限列表中出现了 insecure。

运维建议

磁盘休眠：部分 USB 硬盘盒会自动进入休眠，可能导致 Pod 首次挂载超时。
网络防火墙：若挂载失败，请检查 PVE 节点是否开启了数据中心防火墙，确保 2049 端口已对目标网段放行。

⚠️ 拆除前置：清退依赖水管的租客

🚜 核心拆除作业

🔍 拆除验收

⚠️ 拆除前置警告：清退所有租客！

🚜 核心爆破流程 (Helm 方式)

🛠️ 疑难杂症与抢修指南 (Troubleshooting)

💊 症状 1：手滑卸载了，但我不想删！（取消卸载）

💊 症状 2：Namespace 一直卡在 Terminating，CRD 删不掉

💊 症状 3：执行清理脚本时报错 Webhook 找不到

🔍 终极验收

💥 案发现场：伪装成存储故障的网络崩塌

🕵️‍♂️ 抽丝剥茧：派出侦察兵探路

🧠 底层逻辑：大动脉为什么会断？

🛠️ 抢修方案：网络管线“大换血”

第一斧：强制重建 Cilium 网络映射表

第二斧：顺手重启查号台 (CoreDNS)

第三斧：再次派出侦察兵验证验收

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

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

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

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

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

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

🏁 验收施工成果

一、 物理硬盘初始化

1. 确认硬盘标识（极重要）

2. 创建分区与格式化

3. 实现持久化挂载

二、 NFS 服务安装与核心权限配置

1. 安装服务

2. 配置共享权限（/etc/exports）

💡 参数详解与调整说明：

三、 服务生效与状态验收

运维建议

一、物理硬盘初始化

三、服务生效与状态验收