正如之前在这个线程中提到的，还有另一种方法可以使用kubectl没有公开的API来终止名称空间，即使用kubectl的现代版本，其中kubectl replace——raw可用(不确定从哪个版本)。通过这种方式，您将不必生成kubectl代理进程，并避免与curl的依赖(在一些环境中，如busybox是不可用的)。为了帮助其他人，我在这里留下了这个:

kubectl get namespace "stucked-namespace" -o json \
  | tr -d "\n" | sed "s/\"finalizers\": \[[^]]\+\]/\"finalizers\": []/" \
  | kubectl replace --raw /api/v1/namespaces/stucked-namespace/finalize -f -

删除下面列出的所有资源:

kubectl delete -n YOURNAMESPACE —-all

使用kubectl delete -n YOURNAMESPACE <resource> <id>，或者(如果你从上面的输出复制粘贴)kubectl delete -n YOURNAMESPACE <resource>/<id>，对于你看到的列出的每个资源。

kubectl delete -n YOURNAMESPACE <resource>/<id1> <resource>/<id2> <resource2>/<id3> <resource2>/<id4> <resource3>/<id5>等。

可能您试图删除资源，但由于部署或复制集资源，它们正在被重新创建，从而阻止名称空间释放依赖的资源并被清理。

我喜欢这个答案 它只有两个命令。

在一个终端:

kubectl proxy

在另一个终端:

kubectl get ns delete-me -o json | \
  jq '.spec.finalizers=[]' | \
  curl -X PUT http://localhost:8001/api/v1/namespaces/delete-me/finalize -H "Content-Type: application/json" --data @-

手动编辑nsyaml对我来说不起作用，编辑时没有抛出错误，但更改没有生效。

这招对我很管用:

在一次会议中:

kubectl proxy

在另一个外壳中:

kubectl get ns <rouge-ns> -o json | jq '.spec.finalizers=[]' | curl -X PUT http://localhost:8001/api/v1/namespaces/<rouge-ns>/finalize -H "Content-Type: application/json" --data @-

来源:https://virtual-simon.co.uk/vsphere-kubernetes-force-deleting-stuck-terminating-namespaces-and-contexts/

你可以运行一些东西。但这通常意味着，命名空间的自动删除无法完成，并且有一个正在运行的进程必须手动删除。要找到它，你可以做这些事情:

把所有的资料都集中到这个名字空间。如果这没有任何结果，继续下一个建议

$ kubectl get all -n your-namespace

一些命名空间附加了apiserivces，删除起来很麻烦。这可以是你想要的任何资源。然后，如果发现任何信息，就删除该资源

$ kubectl get apiservice|grep False

但主要的收获是，可能有一些东西没有完全去除。因此，您可以看到最初在该名称空间中有什么，然后可以看到yaml旋转了哪些内容以查看进程。或者你可以开始谷歌为什么不适当删除服务X，你会发现事情。

运行kubectl get apiservice

对于上面的命令，您将发现apiservice的Available Flag=Flase。

因此，只需使用kubectl删除apiservice，删除apiservice <apiservice名称>

执行此操作后，具有终止状态的名称空间将消失。