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

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

请注意,它重新启动的原因是因为它的restartPolicy设置为Always(默认)或OnFailure。kubelet正在读取此配置并重新启动 Pod 中的容器并导致循环。这种行为实际上是有用的,因为这为丢失的资源完成加载提供了一些时间,也为我们检测问题和调试提供了时间——更多关于稍后。

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

在本文中,您将看到:

1.什么是CrashLoopBackOff?

2.如何检测CrashLoopBackOff问题

3.CrashLoopBackOff 的常见原因

4.用于调试CrashLoopBackOff的Kubernetes工具

5.如何用Prometheus检测CrashLoopBackOff

如何检测集群中的 CrashLoopBackOff?

最有可能的是,您通过使用kubectl get pods列出 pod 来发现一个或多个处于此状态的 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。

您也可能“幸运”地在短时间内找到处于Running或Failed状态的 Pod。

CrashLoopBackOff 的常见原因

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

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

• 错误配置: 就像配置文件中的错字。

• 资源不可用: 就像未挂载的 PersistentVolume。

• 错误的命令行参数: 要么丢失,要么不正确。

• 错误和例外: 这可以是任何东西,非常具体到您的应用程序。

最后,来自网络和权限的错误是:

• 你试图绑定一个现有的端口。

• 内存限制太低,所以容器被Out Of Memory 杀死。

• liveness probes 中的错误 没有报告 Pod 准备就绪。

• 只读文件系统,或者一般来说缺少权限。

再一次,这只是可能原因的列表,但可能还有很多其他原因。

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

如何调试、故障排除和修复 CrashLoopBackOff 状态

从上一节中,您了解到 pod 最终处于 CrashLoopBackOff 状态的原因有很多。现在,你怎么知道是哪一个在影响你?让我们回顾一下您可以用来调试它的一些工具,以及使用它的顺序。

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

1. 检查pod 描述。

2. 检查 pod logs。

3. 检查事件。

4. 检查部署。

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”。

• 上一个(或上一个)状态是“终止”。

• 上一次终止的原因是“错误”。

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

通过使用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 日志

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

kubectl logs mypod --all-containers

进入全屏模式 退出全屏模式

甚至是该 pod 中的容器:

kubectl logs mypod -c mycontainer

进入全屏模式 退出全屏模式

如果受影响的 pod 中有错误的值,日志可能会显示有用的信息。

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 的错误配置。

放在一起

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

如何在 Prometheus 中检测 CrashLoopBackOff

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

您可以使用以下表达式快速扫描集群中 CrashLoopBackOffstatus中的容器(您将需要Kube State Metrics):

kube_pod_container_status_waiting_reason{reason="CrashLoopBackOff"} == 1

进入全屏模式 退出全屏模式

或者,您可以使用以下命令跟踪 pod 中发生的重启次数:

rate(kube_pod_container_status_restarts_total[5m]) > 0

进入全屏模式 退出全屏模式

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

在每个 CrashLoopBackOff 周期之后应该有一个重新启动 (1),但可能有与 CrashLoopBackOff (2) 无关的重新启动。

之后,您可以创建如下所示的 Prometheus 警报规则,以在您的任何 pod 处于此状态时接收通知:

- alert: RestartsAlert
  expr: rate(kube_pod_container_status_restarts_total[5m]) > 0
  for: 10m
  labels:
    severity: warning
  annotations:
    summary: Pod is being restarted
  description: Pod {{ $labels.pod }} in {{ $labels.namespace }} has a container {{ $labels.container }} which is being restarted

进入全屏模式 退出全屏模式

结论

在本文中,我们看到了 CrashLoopBackOff 本身不是错误,而只是 pod 中发生的重试循环的通知。

我们看到了它通过的状态的描述,然后是如何使用kubectl命令跟踪它。

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

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

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

---

使用 Sysdig Monitor 更快地调试 CrashLoopBackOff

Advisor 是 Sysdig Monitor 中的一种新的 Kubernetes 故障排除产品,将故障排除速度提高了 10 倍。 Advisor 显示问题的优先级列表和相关的故障排除数据,以发现最大的问题区域并加快解决时间。

自己免费试用30天!