一、什么是 CrashLoopBackOff

CrashLoopBackOff 是一种 Kubernetes 状态，表示 Pod 中发生的重启循环：Pod 中的容器已启动，但一遍又一遍的崩溃然后又重新启动。

Kubernetes 将在重新启动之间等待越来越长的BackOff时间，以便您有机会修复错误。因此，CrashLoopBackOff 本身并不是一个错误，而是表明发生了一个错误，导致 Pod 无法正常启动。

Pod 在 Running、Failed 和 Waiting 之间循环

请注意，它重新启动的原因是因为它restartPolicy设置为Always（默认情况下）或OnFailure，然后 kubelet 读取此配置并重新启动 Pod 中的容器并导致循环。这种行为实际上很有用，因为这为丢失的资源完成加载提供了一些时间，也为我们检测问题和调试提供了一些时间，稍后会详细介绍。

这解释了CrashLoop部分，但是BackOff时间呢？基本上，这是重启之间的指数延迟（10 秒、20 秒、40 秒……），上限为 5 分钟。当 Pod 状态显示 CrashLoopBackOff 时，表示它当前正在等待指示的时间，然后再重新启动 Pod。除非它被修复，否则它可能会再次失败。

Pod 处于循环中。尝试运行，但失败了，所以进入失败状态。稍等片刻以帮助您调试，则会尝试再次运行。如果问题没有解决，就陷入了循环，将再次失败

二、如何检测集群中的 CrashLoopBackOff？

最有可能的是，您通过kubectl get pods列出一个或多个处于此状态的 Pod：

$ kubectl get pods
NAME                     READY     STATUS             RESTARTS   AGE
flask-7996469c47-d7zl2   1/1       Running            1          77d
flask-7996469c47-tdr2n   1/1       Running            0          77d
nginx-5796d5bc7c-2jdr5   0/1       CrashLoopBackOff   2          1m
nginx-5796d5bc7c-xsl6p   0/1       CrashLoopBackOff   2          1m

从输出中，您可以看到最后两个 pod：

不处于READY( 0/1) 状态。
他们的状态显示CrashLoopBackOff。
列RESTARTS显示重新启动次数。

这三个信号指向我们解释的内容：Pod 出现故障，它们正在重新启动。在重新启动之间，有一个宽限期，表示为CrashLoopBackOff.

您可能在 Pod 处于Running或Failed状态的短暂时间内找到它。

CrashloopBackoff 的时间线。每次失败时，BackoffTime 和 Restart Count 都会增加

三、CrashLoopBackOff 的常见原因

重要的是要注意 CrashLoopBackOff 不是导致 pod 崩溃的实际错误。请记住，它只是显示STATUS列中发生的循环。您需要找到影响容器的潜在错误。

与实际应用程序相关的一些错误是：

错误配置： 就像配置文件中的错误配置
资源不可用： 例如未挂载的 PersistentVolume
错误的命令行参数： 要么丢失，要么不正确的命令行参数
bug 和异常: 这可以是任何异常，对你的应用来说都是非常具体的

最后是网络和权限的错误：

您试图绑定被占用的端口。
内存限制太低，容器被 Out Of Memory 杀死。
liveness 探针返回错误，未报告 Pod 已 Ready。
只读文件系统，或缺乏权限。

以上这些只是可能原因的列表，可能还有很多其他原因。

现在让我们看看如何深入挖掘并找到真正的原因。

四、调试、排障和修复

上文，了解到 pod 最终处于 CrashLoopBackOff 状态的原因有很多。现在，怎么知道是哪个在影响？让我们回顾一下可以用来调试它的一些命令，以及使用它的顺序。

这可能是我们最好的做法：

检查pod 描述。
检查pod 日志。
检查 events。
检查 deployment。

1.查看 pod 描述：kubectl describe pod

该kubectl describe pod命令提供特定 Pod 及其容器的详细信息：

$ kubectl describe pod the-pod-name
Name:         the-pod-name
Namespace:    default
Priority:     0
…
State:          Waiting
Reason:       CrashLoopBackOff
Last State:     Terminated
Reason:       Error
…
Warning  BackOff                1m (x5 over 1m)   kubelet, ip-10-0-9-132.us-east-2.compute.internal  Back-off restarting failed container
…

从描述输出中，您可以提取以下信息：

当前 podState是 Waiting.
等待状态的原因是 CrashLoopBackOff。
上一个 状态是 Terminated。
上次终止的原因 是 Error。

这与我们一直在解释的循环行为一致。

通过使用kubectl describe pod，您可以检查以下配置错误：

Pod 定义
容器
为容器拉取的镜像
为容器分配的资源
错误或缺少的参数
…

…
Warning  BackOff                1m (x5 over 1m)   kubelet, ip-10-0-9-132.us-east-2.compute.internal  Back-off restarting failed container
…

在最后几行中，您会看到与此 pod 关联的最后一个事件的列表，其中之一是"Back-off restarting failed container"，这是重启循环的事件。即使发生了多次重新启动，也应该只有一行。

2.查看日志：kubectl logs

您可以查看 pod 的所有容器的日志：

kubectl logs mypod --all-containers

或者指定的容器：

kubectl logs mypod -c mycontainer

日志可能会显示有用的信息。

3.查看事件：kubectl get events

可以列出相关的事件：

kubectl get events

或者，您可以使用以下命令列出单个 Pod 的所有事件：

kubectl get events --field-selector involvedObject.name=mypod

请注意，此信息也出现在describe pod输出的底部。

4.检查部署：kubectl describe deployment

您可以通过以下方式获取此信息：

kubectl describe deployment mydeployment

如果deployment定义了所需的 Pod 状态，它可能包含导致 CrashLoopBackOff 的错误配置。

结合起来看

在下面的示例中，您可以看到如何挖掘日志，在其中发现命令参数中的错误。

调试 Crashloopbackoff。它显示了三个终端以及几个调试命令之间的关系。

五、在 Prometheus 中检测 CrashLoopBackOff

如果您使用 Prometheus 进行监控，这里有一些提示可以帮助您在发生 CrashLoopBackOff 时发出警报。

使用以下表达式，可以快速扫描集群中处于CrashLoopBackOff状态的容器。您需要提前部署 Kube State Metrics

https://github.com/kubernetes/kube-state-metrics

kube_pod_container_status_waiting_reason{reason="CrashLoopBackOff"} == 1

检测 pod 状态为 CrashLoopBackOff 的 PromQL 示例

或者，你可以用以下方法跟踪 pod 发生的重启次数:

rate(kube_pod_container_status_restarts_total[5m]) > 0

基于重启率检测 CrashLoopBackOff 的 PromQL 示例

警告：并非集群中发生的所有重启都与 CrashLoopBackOff 状态有关。

重新启动和 crashloopbackoff 之间的相关性。并非所有重启都是由 crashloopbackoff 引起的

在每个 CrashLoopBackOff 周期之后应该有一个重新启动可能有与 CrashLoopBackOff 无关的重新启动。

可以创建如下所示的 Prometheus 警报规则，当任何 pod 处于此状态时接收通知：

- alert: RestartsAlertexpr: rate(kube_pod_container_status_restarts_total[5m]) > 0for: 10mlabels:severity: warningannotations:summary: Pod is being restarteddescription: Pod {{ $labels.pod }} in {{ $labels.namespace }} has a container {{ $labels.container }} which is being restarted

六、结论

在这篇文章中，我们看到了 CrashLoopBackOff 本身并不是一个错误，而只是一个在 pod 中发生的重试循环的通知。

我们看到了它所经过的状态的描述，以及如何使用kubectl命令跟踪它。

此外，我们还看到了可能导致此状态的常见错误配置，以及您可以使用哪些工具来调试它。

最后，我们回顾了 Prometheus 如何帮助跟踪和提醒 Pod 中的 CrashLoopBackOff 事件。

虽然不是一个直观的消息，但 CrashLoopBackOff 是一个有用的概念，它是有意义的，没有什么可害怕的。

参考：https://u.kubeinfo.cn/7AO7bG

7 张图解 CrashLoopBackOff，如何发现问题并解决它？相关推荐

30 张图解：面试必问的 TCP 重传、滑动窗口、流量控制、拥塞控制
前言前一篇「硬不硬你说了算!近 40 张图解被问千百遍的 TCP 三次握手和四次挥手面试题」得到了很多读者的认可,在此特别感谢你们的认可,大家都暖暖的. 来了,今天又来图解 TCP 了,小林可能会迟 ...
(转) 一张图解AlphaGo原理及弱点
一张图解AlphaGo原理及弱点 2016-03-23 郑宇,张钧波 CKDD 作者简介: 郑宇,博士, Editor-in-Chief of ACM Transactions on Intellig ...
16 张图解带你掌握一致性哈希算法
摘要:一致性哈希是什么,使用场景,解决了什么问题? 本文分享自华为云社区<16 张图解 | 一致性哈希算法>,作者:小林coding. 如何分配请求? 大多数网站背后肯定不是只有一台服务器 ...
Oracle存在gap,发现gap及解决
发现gap及解决 1,在primary端执行 SELECT * FROM V$ARCHIVE_GAP; THREAD# LOW_SEQUENCE# HIGH_SEQUENCE# ----------- ...
13张图解分布式系统服务注册与发现机制，给你整明白
本文 Github/javamap 已收录,有Java程序员进阶技术知识地图以及我的系列文章,欢迎大家Star. 在微服务架构或分布式环境下,服务注册与发现技术不可或缺,这也是程序员进阶之路必须要掌 ...
http中的请求头各部分都是什么意思_硬核！30 张图解 HTTP 常见的面试题
每日一句英语学习,每天进步一点点: 前言在面试过程中,HTTP 被提问的概率还是比较高的. 小林我搜集了 5 大类 HTTP 面试常问的题目,同时这 5 大类题跟 HTTP 的发展和演变关联性是比较 ...
吊打面试官！近 40 张图解被问千百遍的 TCP 三次握手和四次挥手面试题
作者 | 小林coding 来源 | 小林coding(ID:CodingLin) 不管面试 Java .C/C++.Python 等开发岗位, TCP 的知识点可以说是的必问的了. 任 TCP 虐我 ...
25张图解Redis连环面试！击溃面试官！
很多人问我,面试到底考察什么?面试官究竟想听到怎样的回答?针对这类疑惑,我觉得最好的解答,无疑是带着大家,以面试官视角,去进行面试,知己知彼,百战不殆,这就是我写这个系列的初衷. 话不多说,接下来就来 ...
硬不硬你说了算！近 40 张图解被问千百遍的 TCP 三次握手和四次挥手面试题
来自:小林coding 每日一句英语学习,每天进步一点点: 前言不管面试 Java .C/C++.Python 等开发岗位, TCP 的知识点可以说是的必问的了. 任 TCP 虐我千百遍,我仍待 T ...

7 张图解 CrashLoopBackOff，如何发现问题并解决它？