线上K8s环境中，Pod不定期频繁重启、陷入CrashLoopBackOff状态，是后端和运维最常遇到的棘手问题。这类故障大多不会直接抛出明显报错，很多时候是间歇性重启，开发排查日志看不出异常，运维查节点状态也无明显告警，很容易陷入无从下手的困境。

大部分人排查这类问题只会简单看一眼实时日志，找不到报错就束手无策。实际上Pod重启核心就两类原因：应用自身异常退出、集群资源与调度机制触发强制重启。

本文结合真实线上故障，梳理一套可直接落地的完整排查SOP，从状态确认、日志分析、退出码解读、资源核查、探针检测到最终根因定位，全程实操命令+问题复盘，适配所有K8s环境。

一、初步确认Pod状态，锁定故障范围

排查第一步不要直接看日志，先通过基础命令摸清Pod整体状态，明确重启次数、当前运行状态、所在节点、重启时间规律，快速缩小排查范围。

# 查看Pod基础状态、重启次数 kubectl get pod xxx-xxx -n namespace # 详细查看Pod事件、重启记录、退出原因 kubectl describe pod xxx-xxx -n namespace

执行命令后重点关注两个核心信息：

1. Restart Count：重启次数，如果持续递增，说明容器反复崩溃重启；

2. Events事件区：重点筛选OOMKilled、Probe Failed、Error、Terminated等关键字，这是系统层面的直接报错。

很多场景下，应用日志无报错，但describe结果会明确显示资源不足、探针超时等问题，这是新手最容易忽略的点。

二、核心排查：容器日志精准定位应用异常

Pod频繁重启，80%的问题根源在应用本身。常规实时日志只能看到当前启动后的输出，崩溃瞬间的报错日志会随容器退出被清空，这也是很多人查不到问题的核心原因。

排查崩溃重启日志，必须加 --previous 参数，查看上一次退出容器的历史日志。

# 查看上一次崩溃容器的完整日志（核心命令） kubectl logs xxx-xxx -n namespace --previous # 实时监控当前容器日志，配合重启观察报错 kubectl logs -f xxx-xxx -n namespace # 多容器Pod，指定容器查看历史日志 kubectl logs xxx-xxx -c container-name --previous -n namespace

常见应用层报错场景

1. 启动参数、配置文件错误：配置项缺失、yaml格式错误、环境变量未注入，容器启动直接退出；

2. 端口占用/端口冲突：应用监听端口被节点其他进程占用，启动失败；

3. 依赖服务异常：数据库、Redis、MQ连接超时、密码错误、地址变更，应用初始化失败主动退出；

4. 代码未捕获异常：全局未处理的panic、空指针、数组越界，直接导致进程终止。

三、通过退出码精准判断重启根因

容器每次退出都会携带对应的退出码，结合退出码可以快速区分是应用问题、系统问题还是资源问题，不用盲目试错。在kubectl describe的容器状态中可以直接看到Exit Code。

整理线上最高频的退出码对应问题：

Exit Code 0：正常退出。大概率是应用主动执行了退出逻辑，比如脚本执行完毕、健康检测回调主动终止进程，并非故障。

Exit Code 1：通用业务异常。代码报错、配置错误、参数非法，基本都是应用本身代码问题。

Exit Code 137：最常见！系统强制杀死进程。99%是内存超限被OOM终止，超出容器limits内存限制。

Exit Code 139：程序段错误。内存非法访问、指针异常，纯代码层面问题。

Exit Code 143：优雅退出超时。K8s发送停止信号后，应用未在规定时间内收尾，被强制杀死。

四、资源限制排查：解决隐性OOM、CPU超限重启

很多Pod重启没有任何业务日志报错，退出码137是高频现象，基本可以锁定是资源限制配置不合理导致的强制重启。

K8s中resources分为request和limits，很多开发部署时直接抄模板，request和limits配置不合理，极易引发隐性故障：

1. limits设置过小：业务流量波动、批量任务、日志打印峰值时，内存瞬间打满，触发OOMKilled重启；

2. request设置过大：节点资源充足但可调度资源不足，导致Pod频繁被驱逐、重启；

3. 只配置request不配置limits：无法限制资源峰值，单个Pod占用节点大量资源，引发节点压力，被集群调度重启。

实操核查命令

# 查看Pod资源配置 kubectl get pod xxx-xxx -n namespace -o yaml | grep -A 10 resources # 实时查看Pod资源占用情况 kubectl top pod xxx-xxx -n namespace

真实线上案例复盘

之前遇到一个Java微服务Pod，每日凌晨固定重启2-3次，业务日志无任何报错，describe显示OOMKilled，退出码137。

排查发现：容器limits内存设置为512Mi，日常运行仅占用200Mi左右，看似充足。但凌晨定时任务执行时，批量数据处理会瞬间堆内存峰值，短时突破512Mi，直接被系统杀进程重启。

解决方案：将limits调整为1Gi，同时优化定时任务分批处理，峰值内存回落，重启问题彻底解决。

五、探针异常排查：无声无息的高频重启诱因

很多Pod重启和代码、资源无关，纯粹是健康探针配置不合理导致的主动重启。这类问题最隐蔽，日志无报错，资源占用正常，新手几乎排查不出来。

K8s的livenessProbe存活探针、readinessProbe就绪探针，会定时检测容器状态，连续多次检测失败后，会直接重启容器。

高频问题场景：

1. 探针超时时间设置过短：服务启动慢、初始化耗时久，探针提前检测失败，触发重启；

2. 探针路径错误：接口地址写错、端口配置不匹配，检测持续失败；

3. 业务卡顿导致探针响应超时：流量高峰期接口响应变慢，超出探针阈值。

核查方式：kubectl describe pod 中搜索 livenessProbe、readinessProbe，查看失败次数、超时时间、检测间隔。

优化思路：适当调整initialDelaySeconds启动延迟、timeoutSeconds超时时间、failureThreshold失败阈值，适配业务启动和运行特性。

六、节点层面排查：排除集群调度与节点压力问题

如果单个节点上多个Pod频繁重启，并非单个业务问题，需要排查节点状态。节点资源压力、磁盘压力、网络异常，都会触发集群驱逐策略，导致Pod批量重启。

# 查看Pod所在节点 kubectl get pod xxx-xxx -o wide -n namespace # 查看节点状态、压力标签 kubectl describe node node-xxx # 查看节点资源占用 kubectl top node

重点关注节点标签：memory-pressure、disk-pressure、network-pressure，任意压力触发都会导致集群驱逐Pod，实现重启重建。

七、最终通用排查SOP（可直接收藏复用）

后续遇到Pod频繁重启，无需盲目排查，按以下步骤逐一落地，99%问题均可定位：

1. kubectl get pod 确认重启次数、运行状态；

2. kubectl describe pod 查看事件、退出码、探针状态、重启原因；

3. kubectl logs --previous 抓取崩溃瞬间历史日志，定位业务异常；

4. kubectl top pod 核查实时内存、CPU占用，判断是否资源超限；

5. 检查yaml资源request/limits配置，适配业务峰值；

6. 核对探针配置参数，排除检测误杀；

7. 核查节点资源压力，排除集群调度驱逐问题。

八、总结

Pod频繁重启从来不是单一问题，日志报错优先查应用代码与配置，无报错优先查资源OOM和探针异常，批量重启优先查节点状态。

日常开发部署中，不要直接套用默认资源配置和探针参数，结合业务峰值流量、启动耗时、定时任务特性适配参数，能规避绝大多数间歇性重启问题。这套排查流程适配所有K8s版本，线上通用，可直接用于生产故障排查。