1.关于CrashLoopBackOff的简单了解：
CrashLoopBackOff 是一种 pod的一种运行 状态，表示当前 Pod 中发生的重启循环：Pod 中的容器已启动，但崩溃然后又重新启动，一遍又一遍。
k8s 将在重新启动之间等待越来越长的回退时间，以便您有机会修复错误。因此，CrashLoopBackOff 本身并不是一个错误，而是表明发生了一个错误，导致 Pod 无法正常启动。
请注意，pod重新启动的原因是因为它restartPolicy设置为Always（默认情况下）或OnFailure，然后 kubelet 读取此配置并重新启动 Pod 中的容器并导致循环。这种行为实际上很有用，因为这为丢失的资源完成加载提供了一些时间，也为我们检测问题和调试提供了一些时间。
这解释了CrashLoop部分，但是BackOff时间呢？基本上，这是重启之间的指数延迟（10 秒、20 秒、40 秒……），上限为 5 分钟。当 Pod 状态显示 CrashLoopBackOff 时，表示它当前正在等待指示的时间，然后再重新启动 Pod。除非它被修复，否则它可能会再次失败。
2.pod状态CrashLoopBackOff查看：
通过kubectl get pods列出以下 pod 发现了处于此状态的一个或多个 pod ：
判断当前pod的状态是否是CrashLoopBackOff？
1）pod当处于READY( 0/1) 状态。
2）STATUS 状态显示CrashLoopBackOff
3）RESTARTS显示重新启动次数
以上三个信号显示：Pod 出现故障，它们正在重新启动。在重新启动之间，有一个宽限期，表示为CrashLoopBackOff.
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 的错误配置
备注： CrashLoopBackOff 本身并不是一个错误，而只是一个在 pod 中发生的重试循环的通知。
