如何清除CrashLoopBackOff

Question

当Kubernetes pod进入CrashLoopBackOff状态时,您将解决潜在的问题.你怎么强迫它重新安排？

Answer 1

要应用新配置,应创建新窗格(旧窗格将被删除).

• 如果您的pod是由资源Deployment或DaemonSet资源自动创建的,则每次更新资源的yaml后,此操作都会自动运行.如果你的资源有,那就不会发生spec.updateStrategy.type=OnDelete.

• 如果问题与docker图像中的错误有关,那么你解决了,你应该手动更新pod,你可以使用滚动更新功能,如果新图像有相同的标签,你可以删除损坏的pod.(见下文)

• 如果节点发生故障,pod将在几个时间后在新节点上重新创建,旧的pod将在完全恢复损坏的节点后被删除.值得注意的是,如果你的pod是由DaemonSetor 创建的,那就不会发生StatefulSet.

你可以通过任何方式手动删除崩溃的pod:

kubectl delete pod <pod_name>

或所有CrashLoopBackOff状态的豆荚:

kubectl delete pod `kubectl get pods | awk '$3 == "CrashLoopBackOff" {print $1}'`

如果您有完全死的节点,则可以添加--grace-period=0 --force选项以从kubernetes中删除有关此pod的信息.

Answer 2

通常,修复程序要求您更改有关pod的配置(docker镜像,环境变量,命令行标志等)的内容,在这种情况下,您应删除旧pod并启动新pod.如果您的pod在复制控制器(它应该是)下运行,那么您可以对新版本进行滚动更新.

Answer 3

不幸的是，五年过去了，这样的场景似乎依然如此。

@kvaps 上面的回答提出了一种替代方案（滚动更新），本质上是更新（覆盖）而不是删除 Pod——滚动更新的当前工作链接 能够删除 Pod 的替代方案不是创建 Pod，而是创建一个 Pod创建部署，并删除包含 Pod 的部署（可能会被删除）。

$ kubectl get deployments -A 
$ kubectl delete -n <NAMESPACE> deployment <DEPLOYMENT>

# When on minikube or using docker for development + testing
$ docker system prune -a

第一个命令显示所有部署及其各自的命名空间。这帮助我减少了删除共享相同名称（名称冲突）但来自两个不同命名空间的部署的错误。

第二个命令删除恰好位于命名空间下的部署。

在开发模式下工作时，最后一个命令会有所帮助。本质上，删除所有未使用的图像，这不是必需的，但有助于清理和节省一些磁盘空间。

另一个重要的技巧是尝试了解 Pod 失败的原因。问题可能完全依赖于其他地方，k8s 做了很多记录。为此，以下一项可能会有所帮助：

$ kubectl logs -f <POD NAME>
$ kubectl get events 

StackOveflow 上的其他参考： /sf/answers/3895334411/