很明显，有什么东西在复活荚果。虽然很多其他的答案让你看一切(复制集，作业，部署，有状态集，…)来找到可能重生pod的东西，但你可以只看pod，看看是什么衍生了它。例如:

$ kubectl describe pod $mypod | grep 'Controlled By:'
Controlled By:  ReplicaSet/foobar

这告诉你是什么创造了这个豆荚。然后你可以删除它。

首先列出部署

Kubectl得到部署

之后，删除部署

Kubectl删除部署<deployment_name>

如果你的pod有一个像name-xxx-yyy这样的名字，它可以被一个replicasets控制。名为name-xxx的应用程序，在删除pod之前，你应该先删除该副本集:

kubectl delete replicasets.apps name-xxx

这已经发生在我与一些破碎的“头盔”安装。你的部署可能有点混乱。如果前面的建议都不起作用，那么寻找一个守护进程并删除它。

如 Kubectl get daemonset——namespace

然后删除daemonset

kubectl delete daemonset --namespace <NAMESPACE> --all --force

然后尝试删除豆荚。

kubectl delete pod --namespace  <NAMESPACE> --all --force

检查吊舱是否消失了。

kubectl get pods --all-namespaces

您需要删除部署，然后再删除pod和副本集https://github.com/kubernetes/kubernetes/issues/24137

列出所有部署:

kubectl get deployments --all-namespaces

然后删除部署:

kubectl delete -n NAMESPACE deployment DEPLOYMENT

其中NAMESPACE是它所在的名称空间，DEPLOYMENT是部署的名称。如果NAMESPACE是默认值，则完全取消-n选项。

在某些情况下，它也可能由于作业或守护进程启动而运行。 检查以下内容并运行相应的删除命令。

kubectl get jobs

kubectl get daemonsets.app --all-namespaces

kubectl get daemonsets.extensions --all-namespaces

还要注意有状态集

kubectl get sts --all-namespaces

删除命名空间中的所有有状态集

kubectl --namespace <yournamespace> delete sts --all

一个一个地删除它们

kubectl --namespace ag1 delete sts mssql1 
kubectl --namespace ag1 delete sts mssql2
kubectl --namespace ag1 delete sts mssql3