了解 CrashLoopBackOff并发现问题并解决它

2023-12-17 本文已影响0人宇晨棒棒的

1.关于CrashLoopBackOff的简单了解：

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

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

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

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

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

2.pod状态CrashLoopBackOff查看：

通过kubectl get pods列出以下 pod 发现了处于此状态的一个或多个 pod ：

pod截图

判断当前pod的状态是否是CrashLoopBackOff？

1）pod当处于READY( 0/1) 状态。

2）STATUS 状态显示CrashLoopBackOff

3）RESTARTS显示重新启动次数

以上三个信号显示：Pod 出现故障，它们正在重新启动。在重新启动之间，有一个宽限期，表示为CrashLoopBackOff.

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

3.查找pod处于CrashLoopBackOff的原因

1）查看 pod 描述：kubectl describe pod

排查一下：pod的相关配置，是否存在异常

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

2）查看pod的日志：kubectl logs pod名

如果发送错误的 pod 中有错误的值，日志可能会显示有用的信息

3）查看事件：kubectl get events

kubectl get events

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

kubectl get events --field-selector involvedObject.name=pod名称

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

4）检查部署：kubectl describe deployment

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

kubectl describe deployment mydeployment

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