当Kubernetes pod进入CrashLoopBackOff状态时，您将解决潜在问题。你如何强迫它重新安排？
答案 0 :(得分：6)
通常，修复程序要求您更改有关pod配置的内容（docker镜像，环境变量，命令行标志等），在这种情况下，您应删除旧pod并启动新pod。如果您的pod在复制控制器（它应该是）下运行，那么您可以对新版本执行rolling update。
答案 1 :(得分：6)
对于应用新配置，应创建新的pod（旧的pod将被删除）。
如果您的广告连播是由Deployment或DaemonSet资源自动创建的，则每次更新资源的yaml后，此操作都会自动运行。
如果您的资源有spec.updateStrategy.type=OnDelete，则不会发生。
如果问题与docker图像中的错误有关，那么你解决了，你应该手动更新pod，你可以使用rolling-update功能，如果新图像有相同的标签，你可以只需删除破碎的吊舱。 （见下文）
如果节点发生故障，pod将在几个时间后在新节点上重新创建，旧的pod将在完全恢复损坏的节点后被删除。值得注意的是，如果您的广告连播是由DaemonSet或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的信息。
答案 2 :(得分：0)
对于有兴趣的人，我写了一个简单的舵图和python脚本，监视当前名称空间并删除任何输入CrashLoopBackOff的pod。
图表位于https://github.com/timothyclarke/helm-charts/tree/master/charts/dr-abc。
这是膏药。解决问题始终是最好的选择。在我的特定情况下，将历史性应用程序放入K8中，以便开发团队有一个共同的工作场所，将旧应用程序与新应用程序扼杀，比修复旧应用程序中的所有错误更可取。在名称空间中保留它以保持所有事物运行的幻觉可以节省时间。
答案 3 :(得分：-3)
用...摧毁豆荚时
$ kubectl get pods | awk '$3 == "CrashLoopBackOff" {print $1}'
吊舱将尝试重新启动。您可以使用
销毁包含Google吊舱的集群$ gcloud container clusters delete <pod name> --zone "<your zone>"