Pod 卡在 Terminating 状态答案

【问题标题】：Pods stuck in Terminating statusPod 卡在 Terminating 状态
【发布时间】：2016-05-28 23:39:07
【问题描述】：

我尝试删除带有 12 个 pod 的 ReplicationController，我可以看到一些 pod 卡在 Terminating 状态。

我的 Kubernetes 集群由一个控制平面节点和三个安装在 Ubuntu 虚拟机上的工作节点组成。

这个问题的原因可能是什么？

NAME        READY     STATUS        RESTARTS   AGE
pod-186o2   1/1       Terminating   0          2h
pod-4b6qc   1/1       Terminating   0          2h
pod-8xl86   1/1       Terminating   0          1h
pod-d6htc   1/1       Terminating   0          1h
pod-vlzov   1/1       Terminating   0          1h

【问题讨论】：

调度器和控制器管理器是否在运行？
可能与github.com/kubernetes/kubernetes/issues/51835相关
@PromisePreston：请不要故意在问题中添加自制标签-we remove them here。
@halfer，我似乎找不到一个 StackOverflow 政策，它反对将自制标签添加到我之前添加到问题中的问题中。您指向我的链接表明很多人不同意您的 POV。我的意思是对于为什么在问题中添加标签是错误的存在很多偏见，您只陈述了很多人不同意的 POV。事实上，为问题添加标签有助于更好地优化搜索引擎，它也有助于将问题带入更好的上下文中。您可以向我指出不同意向问题添加标签的 StackOverflow 政策。
你好，承诺。我提供的链接在两个方面是规范的：首先，它受到高度评价。这意味着社区已经接受了它，并且任何反对的立场都需要在另一个击败它的答案中出现。确实有一个反提案，但没有得到太多支持，而且被大大反对（+39 和 -19）。

标签： kubernetes

【解决方案1】：

您可以使用以下命令强制删除POD。

kubectl delete pod <PODNAME> --grace-period=0 --force --namespace <NAMESPACE>

【讨论】：

我在集群中执行了此操作，并且 pod 似乎已被删除，但是当我检查节点时，它的容器仍在运行。我最终在节点本身上重新启动了 Docker。 github.com/kubernetes/kubernetes/issues/25456 请注意，您没有隐藏此命令的系统性问题。
如果 pod 位于 default 命名空间以外的命名空间中，则需要包含 -n <namespace-name>，否则上述命令将不起作用。
@mqsoh : 强制删除只是将它从 api-server 存储（etcd）中删除，实际删除的资源可能会无限期地运行。
即使在使用上述命令后，我的 pod 仍处于终止状态。我尝试登录主机并使用 docker ps -a 命令检查容器是否存在。容器不存在，也无法删除终止的 pod。
"警告：立即删除不等待确认正在运行的资源已被终止。该资源可能会无限期地继续在集群上运行"什么资源？

【解决方案2】：

强制删除 pod：

kubectl delete pod --grace-period=0 --force --namespace <NAMESPACE> <PODNAME>

--force 标志是强制性的。

【讨论】：

但对我来说真正的问题是“为什么我们必须首先求助于这个？”在其他正常操作条件下，哪些情况会导致 pod 进入这种卡住状态？
好吧，我可以举一个例子，我们有一个优雅关闭的 java 容器，但它正在将自己的垃圾收集到死，因此对信号没有反应。
最好提供命名空间，否则在多命名空间环境中将找不到您的 pod，默认情况下它会在 kube-system 命名空间中查找。
一次强制删除一个命名空间中的所有 pod ktl get pods -o custom-columns=:metadata.name | xargs kubectl delete pod --force --grace-period=0

【解决方案3】：

最初的问题是“这个问题的原因是什么？”，答案在https://github.com/kubernetes/kubernetes/issues/51835 和https://github.com/kubernetes/kubernetes/issues/65569 讨论，见https://www.bountysource.com/issues/33241128-unable-to-remove-a-stopped-container-device-or-resource-busy

它是由 docker mount 泄漏到其他命名空间引起的。

您可以登录 Pod 主机进行调查。

minikube ssh
docker container ps | grep <id>
docker container stop <id>

【讨论】：

我不敢相信这是最不受欢迎的答案，也没有任何评论。虽然所有其他答案都解决了解决或解决问题的方法，但 OP 明确询问了首先出现这种情况的原因。
答案已经说明了这一点，但我想强调一下：确保在托管 pod 的节点中运行这些命令！

【解决方案4】：

我发现这个命令更简单：

for p in $(kubectl get pods | grep Terminating | awk '{print $1}'); do kubectl delete pod $p --grace-period=0 --force;done

它将删除默认命名空间中所有处于 Terminating 状态的 Pod。

【讨论】：

如果你想在 kube-system 这样的其他命名空间上运行它，请使用：for p in $(kubectl get pods -n kube-system| grep Terminating | awk '{print $1}'); do kubectl delete pod $p --grace-period=0 --force -n kube-system;done
这个答案对我来说完美地结合了所有其他答案。唯一需要注意的是，我有一堆孤立的 PVC 和一个 PV。所以，我用这个for p in $(kubectl get pvc | grep Bound | awk '{print $1}'); do kubectl delete pvc $p --grace-period=0 --force;done 改编了你漂亮的小脚本，然后删除了那个PV。

【解决方案5】：

从资源（pod、部署、ds 等）yaml 中删除终结器块：

"finalizers": [
  "foregroundDeletion"
]

【讨论】：

永久卷在此之后被删除。它的真正作用是什么？
当delete -grace-period=0 --force 没有解决时，这是唯一为我修复卡住的吊舱的东西。不过，我也希望能详细说明它的作用。
这个页面解释了foregroundDeletion。它是一个元数据值，指示对象正在删除。 kubernetes.io/docs/concepts/workloads/controllers/…

【解决方案6】：

实用答案——你总是可以通过运行来删除一个终止的 pod：

kubectl delete pod NAME --grace-period=0

历史答案 -- 1.1 版中存在一个问题，如果 Pod 的节点被不干净地从集群中移除，有时 Pod 会陷入 Terminating 状态。

【讨论】：

我想这就是问题所在。我关闭了一个 minion vm 而不从节点中删除。这是可接受的行为吗？或者是否有从 kubernetes 中删除这些 pod 的修复程序？
是的，在 1.2 版出现之前的解决方法是删除 pod。
您可以随时使用 kubectl delete pod NAME --grace-period=0 强制删除终止的 pod
文档说当运行kubectl delete ... 时，SIG_TERM 请求将被发送到容器。但是，如果在宽限期之后，容器仍在运行呢？我有一堆豆荚卡在Terminating，有些是用 go 编写的，有些是用 nodejs 编写的。 replicationController 被移除，容器仍在运行
kubectl delete pod PODNAME --grace-period=0 按照克莱顿的建议为我工作。

【解决方案7】：

在我的情况下，--force 选项不太有效。我仍然可以看到吊舱！它卡在终止/未知模式。所以运行后

kubectl delete pods <pod> -n redis --grace-period=0 --force

我跑了

kubectl patch pod <pod> -p '{"metadata":{"finalizers":null}}'

【讨论】：

在此之前，值得阅读kubernetes.io/docs/concepts/workloads/controllers/… 以了解终结器是什么。此外，查看被卡住的特定终结器可能会提示为什么它被卡住以及绕过是否安全......

【解决方案8】：

强制删除命名空间中的所有 pod：

kubectl delete pods --all -n <namespace> --grace-period 0 --force

【讨论】：

【解决方案9】：

如果--grace-period=0 不起作用，那么您可以这样做：

kubectl delete pods <pod> --grace-period=0 --force

【讨论】：

在某些情况下，这似乎有效，但实际上并没有删除。这可能与 kubelet 丢失 pod 状态并且无法获取状态所以离开它的问题有关..（例如 github.com/kubernetes/kubernetes/issues/51835 ）。我还没有找到清除它的方法。

【解决方案10】：

我最近在删除 rook ceph 命名空间时偶然发现了这一点 - 它卡在了 Terminating 状态。

唯一有帮助的是通过直接调用带有 curl 的 k8s api 来删除 kubernetes 终结器，如建议的 here。

kubectl get namespace rook-ceph -o json > tmp.json
删除 tmp.json 中的 kubernetes 终结器（保留空数组 "finalizers": []）
在另一个终端中运行 kubectl proxy 以进行身份验证，并按照 curl 请求向返回的端口运行
curl -k -H "Content-Type: application/json" -X PUT --data-binary @tmp.json 127.0.0.1:8001/k8s/clusters/c-mzplp/api/v1/namespaces/rook-ceph/finalize
命名空间消失了

详细的 rook ceph 拆解here。

【讨论】：

【解决方案11】：

我最近偶然发现了这一点，以释放集群中的资源。这是将它们全部删除的命令。

kubectl get pods --all-namespaces | grep Terminating | while read line; do 
pod_name=$(echo $line | awk '{print $2}' ) name_space=$(echo $line | awk 
'{print $1}' ); kubectl delete pods $pod_name -n $name_space --grace-period=0 --force; 
done

希望这对阅读本文的人有所帮助

【讨论】：

【解决方案12】：

我用这个命令删除了 pods

kubectl delete pod --grace-period=0 --force --namespace <NAMESPACE> <PODNAME>

但是当我尝试运行另一个 pod 时，它没有工作，它卡在“Pending”状态，看起来节点本身被卡住了。

对我来说，解决方案是重新创建节点。我只是去了 GKE 控制台并从集群中删除了该节点，因此 GKE 启动了另一个。

之后，一切又开始正常工作了。

【讨论】：

【解决方案13】：

除非容器已经退出，否则我不建议强制删除 pod。

验证 kubelet 日志以查看导致问题“journalctl -u kubelet”的原因
验证 docker 日志：journalctl -u docker.service
检查 pod 的卷挂载点是否仍然存在以及是否有人锁定它。
验证主机是否内存或磁盘不足

【讨论】：

【解决方案14】：

在进行强制删除之前，我会先进行一些检查。 1- 节点状态：获取你的节点运行所在的节点名称，你可以使用以下命令查看：

"kubectl -n YOUR_NAMESPACE describe pod YOUR_PODNAME"

在“节点”标签下，您将看到节点名称。你可以这样做：

kubectl describe node NODE_NAME

如果您发现任何异常情况，请检查“条件”字段。如果这没问题，那么您可以转到该步骤，重做：

"kubectl -n YOUR_NAMESPACE describe pod YOUR_PODNAME"

检查它挂起的原因，您可以在“事件”部分下找到它。我这样说是因为您可能需要在强制删除 pod 之前采取初步措施，强制删除 pod 只会删除 pod 本身而不是底层资源（例如卡住的 docker 容器）。

【讨论】：

【解决方案15】：

请尝试以下命令： kubectl patch pod -p '{"metadata":{"finalizers":null}}'

【讨论】：

点评来源： Stack Overflow 不鼓励仅使用命令/代码的答案，因为它们没有解释它是如何解决问题的。请编辑您的答案以解释此代码的作用以及它如何回答问题，以便它对 OP 以及其他有类似问题的用户有用。请参阅：How do I write a good answer?。谢谢
跟进@sɐunıɔןɐqɐp的评论，说真的，这个命令有什么作用？

【解决方案16】：

就我而言，我不喜欢解决方法。所以有步骤：

k get pod -o wide -> 这将显示哪个节点正在运行 pod
k get nodes -> 检查该节点的状态...我知道了 NotReady

我去修复了那个节点.. 就我而言，它只是重新启动 kubelet：

ssh that-node -> 运行 swapoff -a && systemctl restart kubelet

现在删除 pod 应该可以在不强制 Poor pod 的情况下工作。

【讨论】：

我喜欢你脚步背后的原因

【解决方案17】：

你可以使用awk：

kubectl get pods --all-namespaces | awk '{if ($4=="Terminating") print "oc delete pod " $2 " -n " $1 " --force --grace-period=0 ";}' | sh

【讨论】：

我做了一个小改动：kubectl get pods --all-namespaces | awk '{if ($4=="Terminating") print "kubectl delete pods " $2 " -n " $1 " --force --grace-period=0 ";}' |嘘

【解决方案18】：

发生这种情况的一个原因可能是关闭了一个节点（没有耗尽它）。在这种情况下的修复是再次打开节点；那么终止应该成功。

【讨论】：

【解决方案19】：

以下带有awk 和xargs 的命令可以与--grace-period=0 --force 一起使用以删除Terminating 状态的所有 Pod .

kubectl get pods|grep -i terminating | awk '{print $1}' | xargs kubectl delete --grace-period=0 --force pod

【讨论】：

我有同样的错误信息场景。我最近在我的集群中安装了一个NFS服务器，同一个节点池的一些节点出现了这个问题。我临时扩展了节点，问题解决了，但这不是最终的解决方案。我还在调查，因为节点有免费资源，没有什么可以证明这个问题
这种强制过程，对 Kubernetes 不利，不推荐这种操作……仅在排查的最后一种情况下使用

【解决方案20】：

我不得不在生产 Kubernetes 集群中遇到同样的问题。

一个 pod 在 Terminating 阶段卡住了一段时间：

pod-issuing   mypod-issuing-0   1/1     Terminating   0  27h

我尝试使用以下命令检查日志和事件：

kubectl describe pod mypod-issuing-0 --namespace pod-issuing
kubectl logs mypod-issuing-0 --namespace pod-issuing

但没有可查看的

我是如何解决的：

我运行下面的命令来强制删除 pod：

kubectl delete pod <PODNAME> --grace-period=0 --force --namespace <NAMESPACE>

这立即删除了 pod 并开始创建一个新的。但是，在创建另一个 pod 时，我遇到了以下错误：

无法附加或装载卷：未装载的卷=[数据]，未附加的卷=[数据 mypod-issuing-token-5swgg aws-iam-token]：等待条件超时

我必须等待 7 到 10 分钟，以便该卷与我删除的前一个 pod 分离，以便它可以用于我正在创建的这个新 pod。

【讨论】：