【发布时间】：2016-05-28 23:31:38
【问题描述】：
当 Kubernetes pod 进入 CrashLoopBackOff 状态时，您将解决根本问题。如何强制重新安排？
【问题讨论】：
标签： kubernetes
【发布时间】：2016-05-28 23:31:38
【问题描述】：
为了应用新配置，应该创建新的 pod（旧的将被删除）。
-
如果您的 pod 是由
Deployment或DaemonSet资源自动创建的，则此操作将在您每次更新资源的 yaml 后自动运行。 如果您的资源有spec.updateStrategy.type=OnDelete，则不会发生这种情况。 -
如果问题与您解决的 docker 镜像内部的错误有关，您应该手动更新 pod，您可以为此使用rolling-update 功能，如果新镜像具有相同的标签，您可以删除损坏的 pod。 （见下文）
-
如果节点发生故障，pod 会在一段时间后在新节点上重新创建，旧的 pod 将在损坏的节点完全恢复后移除。值得注意的是，如果您的 pod 是由
DaemonSet或StatefulSet创建的，则不会发生这种情况。
您可以通过任何方式手动移除崩溃的 pod：
kubectl delete pod <pod_name>
或所有具有CrashLoopBackOff 状态的 pod：
kubectl delete pod `kubectl get pods | awk '$3 == "CrashLoopBackOff" {print $1}'`
如果您有完全死节点，您可以添加 --grace-period=0 --force 选项以从 kubernetes 中删除有关此 pod 的信息。
【讨论】：
-
delete pod 确实会删除当前的 pod，但它会使系统再次回到所需的状态，这意味着它将创建另一个 pod，如果其中的服务中断，它将再次显示 CrashLoopBackOff。有关如何完全“取消部署”失败的 pod 的任何提示？
-
我不得不使用：
kubectl delete pod `kubectl get pods --all-namespaces | awk '$4 == "CrashLoopBackOff" {print $2}'` -n <namespace> -
滚动更新的链接在几年前已更改。目前正确的链接是这样的：kubernetes.io/docs/tutorials/kubernetes-basics/update/…
通常，修复需要您更改 pod 的配置（docker 映像、环境变量、命令行标志等），在这种情况下，您应该删除旧的 pod 并启动一个新的 pod。如果您的 pod 在复制控制器下运行（应该是这样），那么您可以对新版本执行 rolling update。
【讨论】：
-
有趣的是，我们在版本不变的地方部署了“快照”。当 RC 更新时，状态并没有清除，但我会试试你的想法。
-
更新 RC 是不够的，您还必须替换现有的 pod，方法是杀死它们或按照建议执行滚动更新。
-
如何找到究竟是什么失败了？
-
@holms - 你试过运行
kubectl logs -f <pod>吗？这将向您显示最近退出的容器运行的标准输出。 -
以上关于滚动更新的链接目前已损坏 (404)，因此，这里是 new one。但是，就我而言，当我像上面提到的@Robert Bailey 一样运行
kubectl logs -f <pod>时，我收到一条错误消息，因为它无法加载应用程序，因为预期的文件不存在以启动应用程序。我更新了此配置以引用正确的文件，它按我的预期工作。
对于任何感兴趣的人，我编写了一个简单的 helm chart 和 python 脚本，它监视当前命名空间并删除任何进入 CrashLoopBackOff 的 pod。
图表位于https://github.com/timothyclarke/helm-charts/tree/master/charts/dr-abc。
这是贴膏药。解决问题始终是最好的选择。在我的具体情况下，将历史应用程序放入 K8s 以便开发团队有一个共同的工作场所，并用新应用程序扼杀旧应用程序比修复旧应用程序中的所有错误更可取。将它放在命名空间中以保持一切都在运行的错觉会赢得时间。
【讨论】：
不幸的是，5 年后，这种情况似乎to still be the case。
@kvaps 上面的回答提出了一个替代方案（滚动更新），它本质上是更新（覆盖）而不是删除一个 pod -- the current working link of rolling updates 能够删除 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 上的其他参考： https://stackoverflow.com/a/55647634/132610
【讨论】：