uninstall

3 posts with the tag “uninstall”

赛博拆迁办：Headlamp 与网络组件的无痕卸载

Apr 22, 2026

在赛博工地里，会建高楼只是基本功，懂得如何干净利落地拆除才是老手的自我修养。Kubernetes 集群就像有洁癖的强迫症患者，如果留下一堆不再使用的孤儿资源（Orphaned Resources），不仅占用节点性能，还可能引发潜在的安全和网络冲突。

今天，“赛博拆迁办”正式进场。我们将按照“逆向工程”的逻辑，把上一篇部署的 Headlamp 仪表盘、权限通行证以及“四大天王” Service 全部连根拔起，做到真正的拔线走人、片甲不留。

🧹 拆除准备：确认拆迁目标

拆除之前，一定要确认我们即将操作的命名空间（Namespace）和资源名称，避免误伤友军。我们将要清理的内容包含：

Helm 部署的 my-headlamp 实例。
手搓的管理员权限（ServiceAccount、Secret、ClusterRoleBinding）。
网络压测时留下的四大 Service。

🚜 核心拆除作业

我们将利用之前保留的“施工图纸（YAML文件）”来进行反向拆除。这也是 GitOps 理念的一大优势：图纸即状态。当你想要销毁什么，只需将 apply 换成 delete。

卸载核心建筑：移除 Headlamp 应用

既然当初是用对讲机（Helm）呼叫的空投，现在也用它来撤场。执行以下命令，Helm 会自动分析并清理属于 my-headlamp 的所有关联资源（如 Deployment、内置 Service 等）。
Terminal window
```
helm uninstall my-headlamp --namespace kube-system
```
预期输出：release "my-headlamp" uninstalled。此时监控室的主体结构已坍塌。
拔除网络管线：销毁“四大天王” Service

LoadBalancer 还在占用发牌员的内网 IP，NodePort 还在宿主机上开着洞。果断切断它们，归还给 Cilium：
Terminal window
```
kubectl delete -f all-services.yaml
```
(如果你之前没保存文件，也可以像拆除权限那样，直接指定名字进行强制拆除：)
Terminal window
```
# 备用方案（无图纸强制拆除）
kubectl delete svc headlamp-nodeport headlamp-loadbalancer fake-headlamp-ext -n kube-system
```
预期输出会显示这几个 Service 被 deleted。Cilium 会瞬间感知并回收底层的 L2 ARP 广播和跨节点端口映射。
吊销上帝通行证：清理 RBAC 与 Secret

虽然应用不在了，但我们手搓的集群最高权限账号还留在 kube-system 里。这在安全规范中是绝对的“高危隐患”。直接拿原图纸反向操作：
Terminal window
```
kubectl delete -f headlamp-admin.yaml
```
(如果你之前没保存文件，也可以用命令行逐个击破：)
Terminal window
```
# 备用方案（无图纸强制拆除）
kubectl delete clusterrolebinding headlamp-admin
kubectl delete serviceaccount headlamp-admin -n kube-system
kubectl delete secret headlamp-admin-token -n kube-system
```
清理仓库图纸源 (可选)

如果你是个极致的强迫症，希望本地电脑也不留痕迹，可以把 Headlamp 的 Helm 仓库源从本地一并删掉：
Terminal window
```
helm repo remove headlamp
```

🔍 拆除验收：清点现场

老规矩，拆完必须验收。执行以下命令，看看现场有没有留下垃圾：

# 检查 Pod 是否已销毁
kubectl get pods -n kube-system | grep headlamp

# 检查网络 Service 是否已清理
kubectl get svc -n kube-system | grep headlamp

# 检查越权角色绑定是否已吊销
kubectl get clusterrolebinding | grep headlamp

如果上面三条命令敲下去，什么也没有输出，恭喜你，这片赛博空地已经彻底清理干净，网络拓扑也恢复到了最纯粹的状态。

包工头语录：能够随时随地一键搭建，也能胸有成竹一键销毁，才是掌控 Kubernetes 的终极自由！准备好这片干净的土地，我们要准备迎接下一个重磅工程了。

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

Apr 22, 2026

在赛博工地，拆迁工作也分危险等级。如果说卸载 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 分布式存储大坝

Apr 21, 2026

在 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

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