命名空间卡在terminating状态时，需先检查finalizers非空及deletiontimestamp是否设置；再逐层清理残留资源；若无效则清空finalizer强制解锁；最后才考虑etcd直删。
当Kubernetes命名空间卡在Terminating状态无法自动清理时，必须绕过默认的优雅删除流程，直接干预资源生命周期控制点。
确认命名空间当前状态与阻塞原因
执行 kubectl get ns rdbms 查看状态是否为 Terminating，并记录其存在时间。若回显中包含 DiscoveryFailed 字样，说明问题出在 APIService（如 metrics.k8s.io/v1beta1）不可达，此时强制删除前需先修复该 API 服务或临时禁用相关 finalizer；否则进入下一步排查。
运行 kubectl get ns rdbms -o yaml，重点检查 spec.finalizers 字段是否存在非空数组——【finalizers 不为空是命名空间无法退出 Terminating 状态的直接原因】。同时注意 deletionTimestamp 是否已设置，未设置说明删除操作根本未触发，不应使用强制删除手段。
逐层清理残留资源（推荐优先尝试）
第一步：列出所有命名空间级资源类型并批量探测残留
kubectl api-resources --namespaced -o name | xargs -n 1 kubectl get --ignore-not-found -n rdbms
这比单纯跑 kubectl get all -n rdbms 更彻底，能捕获 CustomResourceDefinition 实例、APIService 绑定对象等易遗漏项。若某类资源返回非空结果，立即针对性清理。
第二步：对常见顽固资源执行强制驱逐
对 Pod 执行 kubectl delete pod --all -n rdbms --grace-period=0 --force；对 PVC 执行 kubectl delete pvc --all -n rdbms（PVC 可能被 PV 保留策略锁定，需同步检查对应 PV 状态）；对 CRD 实例执行 kubectl delete $(kubectl api-resources --namespaced -o name | grep -v namespace) -n rdbms --all。
第三步：等待 30 秒后再次检查 kubectl get ns rdbms。若状态仍未变化，说明阻塞点不在用户资源层，而是 finalizer 或底层 API 机制问题，跳转至下一节。
直接移除 finalizer 强制解锁（高危操作）
方法一：通过 raw API 替换 finalize endpoint（最稳妥）
执行 kubectl get ns rdbms -o json > rdbms.json，用文本编辑器打开 rdbms.json，将 "spec": {"finalizers": ["kubernetes"]} 中的 finalizers 数组清空为 []，保存文件。然后运行 kubectl replace --raw "/api/v1/namespaces/rdbms/finalize" -f rdbms.json。此操作会触发 apiserver 立即完成命名空间清理流程。
方法二：使用 kubectl patch 快速清除（需 v1.22+）
kubectl patch ns rdbms -p '{"spec":{"finalizers":[]}}' --type=merge。该命令本质是向 /finalize 接口发送 PATCH 请求，效果与方法一一致，但更简洁。注意：如果集群启用了 RBAC 限制对 /finalize 的写权限，此命令会报错，此时必须改用方法一。
【执行前必须确认该命名空间下无任何业务关键资源正在运行，否则数据丢失风险极高】
终极兜底：通过 etcd 直接删除（仅限离线调试环境）
先获取命名空间 UID：kubectl get ns rdbms -o jsonpath='{.metadata.uid}'，假设返回 457788ddf-53d7-4hde-afa3-1fertg21ewe1。
连接 etcd 集群，执行：etcdctl del /registry/namespaces/rdbms。此操作不经过 Kubernetes 控制平面校验，【会永久丢失该命名空间元数据且不可逆，仅限测试集群或 etcd 已完整备份场景】。
操作完成后，重启 kube-apiserver 进程使缓存失效，再执行 kubectl get ns rdbms 应返回 “NotFound”。
