helm

3 posts with the tag “helm”

赛博拆迁办：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 的报错，那么恭喜你，这根外接大水管已经被安全、干净地彻底切断！

彻底清理并重新部署 Portainer：解决存储与权限冲突

Apr 17, 2026

在通过 Helm 将 Portainer 的底层存储从 local-path 更改为 longhorn 时，直接执行 helm upgrade 通常会导致升级失败。这主要由以下三个原因造成：

PVC Immutable 报错：Kubernetes 规范限制了已绑定 PVC 的 storageClassName 是不可变的，不能直接修改覆盖。
全局权限冲突：Helm 尝试创建全局的 ClusterRoleBinding 时，会因为系统中存在历史安装遗留的同名资源而报错。
手动资源残留：通过 kubectl apply 手动创建的 Service（例如手动配置的 LoadBalancer）不在 Helm 的管理范围内，helm uninstall 不会自动将其回收。

为了保证新配置能够顺利应用，必须先彻底清理命名空间下的所有关联资源，然后执行干净的重装。以下是完整的操作步骤。

第一阶段：彻底清理残留资源

注意： 执行以下清理命令将删除该节点上 Portainer 的所有历史数据。请在操作前确认数据已备份或不再需要。

1. 卸载 Helm 发布版本

首先，通过 Helm 卸载现有的 Portainer 实例：

helm uninstall portainer -n portainer

2. 删除命名空间下的所有资源及 PVC

由于 Helm 卸载操作会保留 PVC 以及未被其管理的手动资源，需要使用以下命令强制清空 portainer 命名空间：

kubectl delete all --all -n portainer
kubectl delete pvc --all -n portainer

3. 清理全局权限绑定

ClusterRole 和 ClusterRoleBinding 是集群级别的资源，不包含在特定命名空间内。需要手动删除它们以解决后续的权限冲突报错：

kubectl delete clusterrolebinding portainer
kubectl delete clusterrole portainer

4. 验证清理结果

执行以下命令检查命名空间，确认环境已完全清空：

kubectl get all,pvc -n portainer

正常情况下，终端应返回：No resources found in portainer namespace.

第二阶段：执行全新安装

环境清理完毕后，使用配置好 Longhorn 存储的 portainer-values.yaml 文件重新执行 Helm 安装命令：

helm install portainer portainer/portainer \
  -n portainer \
  --create-namespace \
  --set persistence.storageClass=longhorn \
  --set nodeSelector=null \
  -f portainer-values.yaml

第三阶段：验证部署与恢复服务

1. 检查集群资源状态

安装完成后，检查 Pod 和 PVC 的状态。确认 PVC 已经绑定到 longhorn，并且 Pod 处于 Running 状态：

kubectl get pods,pvc,svc -n portainer -o wide

2. 恢复手动创建的 Service (视情况执行)

如果你之前的外网访问依赖于手动创建的 Service（例如名为 portainer-lb-manual 的资源），并且该配置没有整合进 Helm 的 values.yaml 中，你需要重新应用该配置文件来恢复服务的对外暴露：

# 请将文件名替换为你实际使用的 yaml 文件
kubectl apply -f portainer-lb-manual.yaml

执行完毕后，即可通过分配的 IP 地址访问 Portainer 并完成初始管理员密码的设置。