CrashLoopBackOff 是什么
CrashLoopBackOff 是容器反复退出后呈现的稳定状态：进程启动、失败、退出，kubelet 按指数退避的节奏再次拉起，等待时间逐次增长并封顶。它不是一个原因，而是一个结果——真正的原因要从上一次终止的退出码、被杀前的日志与配置里找。
状态里那个时间说明什么
状态列里跟着的时间后缀是下一次重启前的等待时长，随连续失败次数增长。它反映的是「已经失败了很多次」，而不是故障持续时间。看到等待时间已经很长，说明问题从一开始就存在且没有被解决，此时反复删除重建只会重新走一遍同样的循环。
基本信息
| 适用环境 | 任何 Kubernetes 发行版，与容器运行时和 kubelet 的重启策略共同作用 |
|---|---|
| 触发条件 | 容器进程退出且重启策略为总是或失败时重启 |
| 退避机制 | 等待时间随失败次数增长并有上限 |
| 关键证据 | 上一次终止的退出码与原因、被杀前的日志、对象事件 |
| 常见后果 | 副本长期不可用，滚动更新与自动扩缩一起被拖住 |
| 排查入口 | 先看描述信息的终止段，再读上一个实例的日志 |
典型使用场景
- 发布后服务起不来：新版本镜像或配置有问题，全部副本同时进入循环
- 配置缺失：依赖的密钥或配置文件没有挂载导致进程启动即退出
- 命令写错：启动命令指向不存在的可执行文件，进程立刻返回
- 依赖不可达：启动阶段连接数据库失败，进程选择直接退出
- 内存超限：容器被反复终止，表现为重启计数持续增长
- 探针配置错误：存活检查过严导致进程被反复重启
标准三件套
标准三件套
kubectl get pod web-x -o wide # 确认状态与重启次数
kubectl describe pod web-x | sed -n '/State:/,/Events:/p' # 看当前与上一次状态
kubectl logs web-x --previous --tail=200 # 上次退出前的日志，关键证据
kubectl logs web-x --tail=100 # 当前实例的日志
kubectl get events --field-selector involvedObject.name=web-x --sort-by=.lastTimestamp退出码线索
| 退出码 | 常见含义 | 下一步 |
|---|---|---|
| 1 | 应用自身报错：异常抛出、配置缺失 | 读上一次日志找异常 |
| 126 | 命令存在但不可执行：权限或格式问题 | 检查文件权限与可执行位 |
| 127 | 找不到命令：镜像内没有该程序 | 核对启动命令与镜像内容 |
| 137 | 被强制终止：常见于内存超限 | 看内存上限与用量 |
| 143 | 收到终止信号后退出 | 确认是否为探针或缩容触发 |
按阶段缩小范围
- 启动阶段就退出：重点看启动命令、配置文件与挂载是否就绪
- 运行一段时间后退出：重点看内存、依赖连接与探针设置
- 所有副本同时异常：指向镜像、配置或依赖，而不是单个实例
- 只有部分副本异常：指向该实例的节点、本地卷或调度约束
等待时间后缀随失败次数增长，是排查时判断「已经失败多次」的重要信号，也说明问题具有确定性而非偶发。
容器从未成功启动过时上一个实例的日志可能为空，此时应转向查看对象事件与挂载情况。