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

🌱 创建: 2026/04/21 ⏱️ 更新: 2026/05/22

This content is not available in your language yet.

在 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

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