argocd

starlightBlog.tags.count

K8s 焦土政策：网关与证书系统的终极卸载指南

starlightBlog.post.date

这是一份针对 Kubernetes 集群的**“彻彻底底、连根拔起”**清理方案。

当你的网关和证书系统因为各种改动搅得一团糟，且面临诸如 ArgoCD 陷入死锁、命名空间卡在 Terminating 无法删除等极其顽固的底层状态错误时，**“焦土政策（物理核平）”**绝对是最有效、最干净的排障手段。

请严格按照以下顺序执行。这套连招能保证把系统里的残留基因拔得干干净净，绝不影响下一次重装。

---

☢️ 第一阶段：斩断源头 (切断 ArgoCD 重建链)

在使用 GitOps (如 ArgoCD) 时，决不能直接去删底层资源，否则 ArgoCD 会发现“建筑没了”，并立刻把它们重新拉起来。我们必须先切断图纸的下发。

1. 尝试常规删除应用

kubectl delete application cert-manager traefik -n argocd

2. 遭遇死锁？强行剥夺 ArgoCD 的遗愿清单

如果上面的命令卡住转圈（报错 metadata.finalizers: Forbidden），说明 ArgoCD 本身陷入了死结。立刻打开新终端，执行强制“拔管”：

kubectl patch application cert-manager -n argocd -p '{"metadata": {"finalizers": null}}' --type merge
kubectl patch application traefik -n argocd -p '{"metadata": {"finalizers": null}}' --type merge

执行后，ArgoCD 面板上的应用会瞬间消失，系统不再自动重建。

---

💣 第二阶段：深度扫荡 (清理 Webhooks 与 全局 CRDs)

这是 99% 的人重装失败的根源！ 命名空间好删，但全局注册的蓝图规范（CRD）和拦截器（Webhook）如果不清空，下次安装必定会报出各种版本冲突。

1. 摧毁潜伏的 Webhook

Cert-manager 会向 K8s API Server 注入拦截器，必须优先干掉，否则它会拦截你接下来的所有安装请求：

kubectl delete validatingwebhookconfiguration cert-manager-webhook --ignore-not-found
kubectl delete mutatingwebhookconfiguration cert-manager-webhook --ignore-not-found

2. 屠宰所有相关 CRD (蓝图基因)

# 删光 Traefik 和 Cert-manager 的残留基因
kubectl get crd -o name | grep -E 'traefik|cert-manager' | xargs kubectl delete

3. 扫荡残留的“全局权限” (RBAC)

这一步经常被忽视，导致重装时报 Ownership/Adoption 错误：

# 清理集群级别的角色与绑定
kubectl get clusterrole,clusterrolebinding -o name | grep -E 'cert-manager|traefik' | xargs kubectl delete

# 清理隐藏在 kube-system 核心区的领导者选举权限
kubectl get role,rolebinding -o name -n kube-system | grep cert-manager | xargs -I {} kubectl delete {} -n kube-system

---

🧨 第三阶段：核平街区 (强制清理 Namespace 内部残留)

如果你发现 Namespace 删不掉，或者里面总剩下一堆 Role, Service, ServiceAccount，那是它们身上带着 Finalizers（保护锁）。

1. 强制“碎锁”局部资源

在删除 Namespace 之前，先手动清除这些顽固住户的遗愿清单：

# 定义目标命名空间
TARGET_NS=("cert-manager" "traefik")

for ns in "${TARGET_NS[@]}"; do
  echo "正在强制碎锁 $ns 中的局部资源..."
  # 批量清除 Role, RoleBinding, ServiceAccount, Service 的保护锁
  kubectl get rolebinding,role,serviceaccount,service -n $ns -o name | xargs -I {} kubectl patch {} -n $ns -p '{"metadata":{"finalizers":null}}' --type merge
done

2. 物理超度 Namespace

现在执行删除指令，由于内部资源已碎锁，它们会随街区一并消失：

kubectl delete namespace cert-manager traefik --force --grace-period=0

---

💀 第四阶段：物理超度 (清理僵尸命名空间)

如果执行完第三步，使用 kubectl get ns 发现它们依然死死卡在 Terminating 状态，说明遭遇了**“僵尸命名空间”**。动用最后的 API 接口直连手段：

1. 开启通向集群心脏的后门

kubectl proxy &

2. 发射核弹指令，清空命名空间的 Finalizers

直接调用 API 接口，强行抹除 Namespace 最后的执念：

# 针对 cert-manager
curl -H "Content-Type: application/json" -X PUT --data-binary "{\"kind\":\"Namespace\",\"apiVersion\":\"v1\",\"metadata\":{\"name\":\"cert-manager\"},\"spec\":{\"finalizers\":[]}}" http://localhost:8001/api/v1/namespaces/cert-manager/finalize

# 针对 traefik
curl -H "Content-Type: application/json" -X PUT --data-binary "{\"kind\":\"Namespace\",\"apiVersion\":\"v1\",\"metadata\":{\"name\":\"traefik\"},\"spec\":{\"finalizers\":[]}}" http://localhost:8001/api/v1/namespaces/traefik/finalize

3. 验尸与关门

# 确认僵尸已经彻底消失
kubectl get ns

# 杀掉后台开启的 kubectl proxy
kill %1

---

💡 架构师总结 走完这完整的四阶段，你的集群就真正回到了**“像素级纯净”**的状态。所有的 Role、ServiceAccount 和全局权限都已化为灰烬。现在，你可以放心地去推送你配置了 OpenDNS 5353 端口 的新图纸，享受一次零报错的全新丝滑安装体验！

starlightBlog.post.tags

• kubernetes
• cert-manager
• traefik
• argocd

ArgoCD 密码重置：如何恢复遗忘的 admin 登录凭证

starlightBlog.post.date

故障背景

在日常运维中，如果遗忘了 ArgoCD Web 面板中 admin 账户的自定义登录密码，将导致无法通过图形界面管理应用。

ArgoCD 将 admin 账户的密码哈希值存储在名为 argocd-secret 的 Kubernetes Secret 资源中。当我们在 UI 界面修改密码时，系统实际上是在更新该 Secret 内部的 admin.password 字段。如果该字段被清空或移除，ArgoCD 将自动回退，允许使用系统在初始化时生成的默认密码进行登录。

基于这一底层逻辑，我们可以通过命令行强制重置密码状态。

---

密码恢复流程

请确保你的终端已连接到目标 K3s 集群，且具备操作 argocd 命名空间的高级权限。

步骤 1：移除自定义密码字段

使用 kubectl patch 命令，强行从存储配置的 Secret 中剔除自定义密码记录。这相当于清除了系统中后续添加的身份验证覆写规则。

kubectl patch secret argocd-secret -n argocd --type=json -p='[{"op": "remove", "path": "/data/admin.password"}]'

执行成功后，终端应返回 secret/argocd-secret patched。

步骤 2：重启 API Server 服务

密码字段移除后，需要重启 ArgoCD 的前端 Server 组件，使其强制重新读取底层的 Secret 状态。

kubectl rollout restart deploy argocd-server -n argocd

等待几秒钟，确保新的 Pod 成功启动并接管流量。

步骤 3：提取系统初始密码

此时，ArgoCD 已经回退到出厂安全状态。我们需要从专门存储初始密码的 Secret (argocd-initial-admin-secret) 中提取密码的 Base64 原文并进行解码。

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d && echo

请复制终端输出的这串随机字符串，这是你目前的唯一登录凭证。

步骤 4：登录并设置新密码

1. 浏览器访问你的 ArgoCD 面板。
2. 账号输入 admin，密码粘贴刚刚提取的初始字符串。
3. 登录成功后，导航至页面左侧的 User Info 选项卡。
4. 点击 Update Password，输入当前密码（初始密码）并设定一个新的、已妥善记录的自定义密码。

警告

安全提示： argocd-initial-admin-secret 仅设计为首次安装时的临时凭证机制。一旦你成功恢复访问并设置了新的自定义密码，建议将此初始 Secret 删除，以符合最小权限安全原则。

starlightBlog.post.tags

• kubernetes
• k3s
• argocd
• troubleshooting
• security

完全卸载 ArgoCD：级联删除与集群环境重置

starlightBlog.post.date

核心概念：级联删除 (Cascading Deletion)

在 GitOps 架构中，如果需要彻底重置测试环境或完全弃用当前的部署方案，我们需要将 ArgoCD 及其部署的所有业务应用一并清理。

ArgoCD 在创建 Application 资源时，默认会注入 resources-finalizer.argocd.argoproj.io 终结器 (Finalizer)。当执行删除操作时，ArgoCD 控制器会根据该终结器，主动向集群发送指令，依次删除该应用所关联的全部底层资源（如 Deployment、Service、ConfigMap 等）。这就是级联删除。

为了实现彻底卸载，我们必须保留这些终结器，并让 ArgoCD 控制器先完成全部业务资源的回收，然后再卸载 ArgoCD 自身组件。

---

彻底卸载流程 (Teardown Steps)

步骤 1：触发业务资源的级联删除

首先，直接删除 argocd 命名空间下的所有 Application 资源。 警告：此操作不可逆。执行后，由 ArgoCD 管理的所有实际业务（如 Portainer、数据库等集群应用）将立即开始停止并被销毁。

kubectl delete applications --all -n argocd

步骤 2：监控资源回收进度

由于涉及大量底层资源的终止与销毁，该过程可能需要数分钟。通过以下命令实时监控 Application 的状态：

kubectl get applications -n argocd -w

当命令输出为空，或提示 No resources found in argocd namespace. 时，表明所有被托管的业务资源已彻底清理完毕。

步骤 3：卸载 ArgoCD 核心组件

业务资源清理完成后，使用当初部署时相同的官方清单反向卸载 ArgoCD 控制器及相关组件：

kubectl delete -n argocd  -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

步骤 4：清理底层全局资源 (CRD 与命名空间)

最后，删除遗留的自定义资源定义 (CRD) 和专属命名空间。

1. 删除专属 CRD： (注意：如果集群内还有其他命名空间在使用 ArgoCD，请勿执行此步骤)

kubectl delete crd applications.argoproj.io applicationsets.argoproj.io appprojects.argoproj.io 2>/dev/null

2. 删除命名空间：

kubectl delete namespace argocd

---

进阶排障 (Troubleshooting)

如果在上述流程中遇到命令卡死或资源无法删除的情况，请参考以下处理方案：

1. Application 删除卡死

如果 kubectl delete applications 长时间无响应，通常是因为某些底层资源（如持久化存储卷）无法正常释放，导致 ArgoCD 控制器无法完成终结器逻辑。 可以通过强制移除 Finalizer 来跳过等待：

kubectl get apps -n argocd -o name | xargs -I {} kubectl patch {} -n argocd -p '{"metadata": {"finalizers": null}}' --type merge

2. Namespace 状态卡在 Terminating

如果最后一步删除 argocd 命名空间时一直卡在 Terminating 状态，说明 Kubernetes API 垃圾回收遭遇死锁。可使用 API 强制注销指令直接清除（需确保已安装 jq 工具）：

kubectl get namespace argocd -o json | \
  jq '.spec.finalizers = []' | \
  kubectl replace --raw "/api/v1/namespaces/argocd/finalize" -f -

完成以上步骤后，执行 kubectl get all -A，确认集群内已无相关组件残留，集群状态重置完成。

starlightBlog.post.tags

• kubernetes
• k3s
• argocd
• ops

跑路但不拆楼：如何安全卸载 ArgoCD 且保留所有业务应用

starlightBlog.post.date

🏗️ 核心概念：非级联删除 (Non-Cascading Deletion)

在赛博堡垒中，有时我们只想重装或卸载 ArgoCD 本身（比如迁移 GitOps 工具，或者清理测试环境），但绝不希望它把正在运行的业务应用（比如我们的存储大坝、可视化面板）一起删掉。

ArgoCD 在部署应用时，默认会给资源打上一个叫 resources-finalizer.argocd.argoproj.io 的终结器（相当于一根引爆线）。如果你直接执行 kubectl delete namespace argocd，它会顺着这根线把底层真实的 Pod 和 Service 全部“爆破”掉，甚至会导致整个命名空间卡死在 Terminating 状态。

要做到**“监工跑路，大楼照常营业”**，我们必须在拆除指挥中心前，偷偷剪断所有的引爆线。

⚠️ 高阶架构拆除警告：提防自愈反扑与违章建筑

1. 提防自愈反扑 (Self-Heal Trap)：如果你的集群使用了 App of Apps (套娃架构) 并且开启了自动修复 (selfHeal: true)。当你试图剪断子应用的引爆线时，总控制台会瞬间察觉并强行将其接回！这会导致后续删除时发生意外的连带破坏（例如 Pod 还在，但 Service 丢了）。因此，必须先瘫痪控制器，再执行清理。
2. 提防违章建筑 (Namespace Nuke)：卸载的最后一步会彻底夷平 argocd 命名空间。如果你之前图省事，把其他业务的 Service 或 Ingress 放在了 argocd 命名空间下，它们将遭受无差别的核打击。请确保 argocd 命名空间内只有纯粹的 GitOps 基础设施！

---

✂️ 无损拆除流程 (Safe Teardown Steps)

为了绝对的安全，我们将采用**“暗杀级”**施工法：先切断监工的大脑，再从容拆除。

步骤 1：瘫痪指挥中心大脑 (停止控制器)

这是应对复杂 GitOps 架构最关键的一步。我们必须先把 ArgoCD 的应用控制器副本数缩容为 0，让其失去对集群状态的监听和自愈能力。

kubectl scale statefulset argocd-application-controller -n argocd --replicas=0

(💡 监理提示：执行后，ArgoCD 变成了“瞎子和聋子”，绝对不会再产生任何反扑动作。)

步骤 2：从容剪断所有应用的“引爆线”

大脑死机后，我们就可以毫无顾忌地强制抹除所有 Application 对象的 Finalizer。

打开终端，执行这行“批量剪线”脚本：

kubectl get apps -n argocd -o name | xargs -I {} kubectl patch {} -n argocd -p '{"metadata": {"finalizers": null}}' --type merge

(💡 监理提示：执行完后，这些应用就已经彻底脱离 ArgoCD 的“同归于尽”机制了。)

步骤 3：销毁 GitOps 档案 (删除 Application 对象)

既然引爆线已经没了，且没有控制器来阻挠，我们现在就可以安全地删掉 ArgoCD 里的那些“项目档案”了。

kubectl delete apps --all -n argocd

这条命令会瞬间执行完毕，而你集群里的真实业务应用完全不会受到任何影响，它们已经变成了 K8s 的原生脱管应用。

步骤 4：拆除主体建筑 (反向执行安装脚本)

清空了档案后，我们就可以按图索骥，用当初浇筑时的官方图纸进行反向拆除，把 ArgoCD 的 Redis 缓存、API 服务等组件清理掉：

kubectl delete -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

步骤 5：深度清理残骸 (删除 CRD 与命名空间)

最后一步，把划拨给 ArgoCD 的专属园区，以及它留在 K8s 底层的那些自定义资源定义（CRD）连根拔起。

1. 彻底粉碎专属 CRD： (⚠️ 警告：这会删除全集群所有命名空间下的 ArgoCD 相关资源，确保你没有其他的 ArgoCD 实例在使用它们！)

kubectl delete crd applications.argoproj.io appprojects.argoproj.io applicationsets.argoproj.io

2. 抹平命名空间：

kubectl delete namespace argocd

---

🧰 进阶排障：应对“强拆”中的钉子户 (Troubleshooting)

在实际的集群拆迁中，K8s 的垃圾回收机制偶尔会发生死锁。如果你在执行上述步骤时卡住了，请使用以下“重火力”工程手段。

1. 漏网之鱼：AppProject 的终结器卡死

除了 Application，ArgoCD 的“项目对象” (AppProject) 也带有防删机制。如果你发现删除一直卡住，请再补上这一刀：

# 剪断所有项目的引爆线
kubectl get appprojects -n argocd -o name | xargs -I {} kubectl patch {} -n argocd --type json -p='[{"op": "remove", "path": "/metadata/finalizers"}]' 2>/dev/null

2. 清扫游荡的幽灵：全局权限残留

ArgoCD 拥有控制整个集群的极高权限，这意味着它创建的某些 ClusterRole 是不受命名空间限制的。拆除后，我们可以用标签（Label）进行一次全局扫荡：

kubectl delete clusterrole -l app.kubernetes.io/part-of=argocd 2>/dev/null
kubectl delete clusterrolebinding -l app.kubernetes.io/part-of=argocd 2>/dev/null

3. 终极黑魔法：强杀卡死的 Namespace

如果所有的图纸都已经清理完毕，但最后执行 kubectl delete namespace argocd 时依然无限卡在 Terminating 状态。这意味着 K8s 底层的 API Server 陷入了死循环，通常是因为残留的无法解析的资源阻塞了垃圾回收。

请掏出这段极其危险但也极其有效的 API 强制注销指令（需要宿主机已安装 jq 工具）：

kubectl get namespace argocd -o json | \
  jq '.spec.finalizers = []' | \
  kubectl replace --raw "/api/v1/namespaces/argocd/finalize" -f -

这条指令会直接绕过正常的垃圾回收流程，粗暴地把该园区的终结器全部清空，Namespace 瞬间就会灰飞烟灭！

---

🎉 验收：自由的业务大楼

至此，ArgoCD 已经被你彻底从集群中抹除，你可以使用 kubectl get pods -A 巡查一圈。

你会发现，argocd 命名空间已经彻底消失，且没有任何幽灵权限残留。但你之前通过它部署的真实业务，依然在各自的命名空间里稳健运行。现在，你可以随时重新安装一个崭新的 ArgoCD，再把它们重新“收编”回流水线中！

starlightBlog.post.tags

• kubernetes
• k3s
• argocd
• ops
• troubleshooting