如何清除CrashLoopBackOff

Question

当Kubernetes pod进入CrashLoopBackOff状态时，您可以修复底层问题。您如何强制重新安排它？

Answer 1

要应用新配置，应创建新pod (旧pod将被删除)。

• 如果您的pod是由Deployment或DaemonSet资源自动创建的，则每次更新资源的yaml后，都会自动执行此操作。如果您资源具有spec.updateStrategy.type=OnDelete.

，则不会发生这种情况

• 如果您解决了docker镜像内部错误的问题，您应该手动更新pod，您可以使用rolling-update功能来实现此目的，如果新镜像有相同的tag，您可以直接移除损坏的pod。(见下文)

• 如果节点出现故障，几次后会在新节点上重新创建pod，待故障节点完全恢复后，旧pod将被移除。值得注意的是，如果您的pod是由DaemonSet或StatefulSet.

创建的，则不会发生这种情况

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

kubectl delete pod <pod_name>

或所有具有CrashLoopBackOff状态的pods：

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

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

Answer 2

通常，修复需要更改pod的配置( docker映像、环境变量、命令行标志等)，在这种情况下，您应该删除旧pod并启动新pod。如果您的pod在一个复制控制器下运行(它应该是这样的)，那么您可以对新版本执行rolling update。

Answer 3

对于任何感兴趣的人，我写了一个简单的舵图和python脚本，它监视当前的名称空间，并删除任何进入CrashLoopBackOff的pod。

图表在https://github.com/timothyclarke/helm-charts/tree/master/charts/dr-abc上。

这是一块石膏。修复问题始终是最好的选择。在我的具体案例中，将历史应用程序放到K8s中，以便开发团队有一个共同的工作场所，并用新应用程序扼杀旧应用程序，这比修复旧应用程序中的所有bug更可取。将其放在名称空间中以保持一切都在运行的假象，这就为我们赢得了时间。