容器频繁重启时，最先暴露的信号往往不是重启计数，而是重启前一刻的OOMKilled标记、探针连续失败和节点资源水位异常。
容器重启在Kubernetes和Docker环境里像是一个结果,不是原因，很多人盯着kubectl get pods里的RESTARTS列，发现数字涨了才开始查，其实已经晚了，真正有用的信号在Pod被杀死之前就已经在事件流和指标里探头了，把这些信号抓准，可以把故障恢复时间从小时级压到分钟级。
容器频繁重启怎么排查：先看这4类最先暴露的信号
排查容器频繁重启,顺序很关键，一上来就翻应用日志容易被重启堆栈带偏，更高效的做法是按“内核→集群→应用”的路径走，因为多数情况下，被内核或kubelet杀掉的容器，应用日志里只留下一句“terminated”，根因不在这。
第一暴露信号：容器内存OOM重启信号在describe里最明显
容器内存OOM重启信号是所有信号中最先、也最好抓的一个，当Pod实际内存超过limit，内核OOM killer会直接杀掉容器，Kubernetes会在Pod状态里留下OOMKilled标记。
查看命令：
kubectl describe pod <pod-name> -n <namespace> | grep -A10 "Last State"- 如果看到
Reason: OOMKilled，不用再猜，内存超限就是直接原因。
这个信号有个特点：它常常和内存使用率突增同时出现，但重启计数可能还是0，比如Java堆没设置上限，GC跟不上分配速度，Pod在第一次OOM时RestartCount只显示1，但OOMKilled已经在describe里写得很清楚。
指标侧可以盯 container_oom_events_total，只要有增量就说明某个容器刚被OOM，这个指标比restart_count更早暴露问题，因为它记录的是“被杀”动作，不是“重启完成”状态。
第二暴露信号：探针连续失败比重启动作提前3次探测
Liveness探针连续失败是另一个早期信号,默认情况下，Kubernetes会容忍探针连续失败3次才重启容器，也就是说，当你看到RESTARTS增加时，探针已经失败至少3次了。
更早的暴露点在事件流里：
kubectl describe pod里的Warning Unhealthy事件- 消息类似
Liveness probe failed: HTTP probe failed with statuscode: 500
如果只盯重启次数,你会漏掉这3次失败窗口，正确做法是把探针失败事件接入告警，只要出现第一次Unhealthy就触发通知，多数情况下，应用还没完全挂掉，但已经在变慢或返回错误码，这时候介入可以避免重启。
Readiness探针失败不会直接重启容器,但会把Pod从Service后端摘掉，如果看到readiness失败和liveness失败同时出现，说明应用内部逻辑可能已经僵死，不是单纯资源问题。
第三暴露信号：节点内存和磁盘压力在驱逐前就冒头
容器重启不只发生在Pod内,节点级的压力会触发kubelet驱逐Pod，表现同样是重启，但驱逐前的信号比驱逐动作更早：节点内存使用率长时间高位、磁盘空间快速下降、系统OOM事件。
检查命令：
kubectl get nodes -o widekubectl describe node <node-name> | grep -A5 "Conditions"- 如果看到
MemoryPressure或DiskPressure为True，说明节点已经在告警。
在内核日志里会看到类似 oom-kill: constraint=CONSTRAINT_MEMCG 的记录，这个记录出现时，Pod可能还没重启，但很快就会发生，把节点级指标纳入监控，比如node_memory_MemAvailable_bytes、node_filesystem_avail_bytes，可以比Pod重启提前十几分钟发现趋势。
第四暴露信号：退出码和终止原因比应用日志更诚实
应用自己的退出码是容易被忽略的信号,容器退出码非0时，Kubernetes会记录在Last State里：
- 退出码137：通常被SIGKILL，大概率是OOM或驱逐
- 退出码143：SIGTERM，正常终止或滚动更新
- 退出码1或2：应用自身panic或参数错误
很多开发者第一反应是翻应用日志,但应用panic前的内存申请失败、连接池耗尽等，往往在退出码和内核日志里更早暴露，先看退出码和终止原因，再决定要不要深挖应用日志，比直接扎进堆栈高效得多。
docker容器重启监控指标：这三个数值比重启次数更早预警
容器环境里,重启次数kube_pod_container_status_restarts_total是一个滞后指标，它只告诉你“已经重启了N次”，更早期的预警来自下面三个指标。
- container_oom_events_total：记录容器被OOM killer击杀的次数，只要这个值增加，就说明内存限制被突破，重启是下一秒的事。
- kube_pod_container_status_last_terminated_reason：记录上一次终止原因，OOMKilled、Error、Completed等等，这个指标在重启次数还没明显上升时就能看到原因分布。
- kube_pod_container_status_waiting_reason：如果容器卡在CrashLoopBackOff，这个指标会给出等待原因，相比重启次数，它能区分是镜像拉取失败、还是启动命令错误。
表格对比一下：
| 指标 | 暴露阶段 | 能发现什么 | 滞后程度 |
|---|---|---|---|
| container_oom_events_total | 重启前 | 内存超限动作 | 低 |
| last_terminated_reason | 重启瞬间 | 上次被杀原因 | 低 |
| waiting_reason | 重启后等待 | CrashLoop原因 | 中 |
| restarts_total | 重启完成后 | 累计重启次数 | 高 |
从这张表可以看出,只看restarts_total等于在最后一棒才接球，应该把前三个指标放进Prometheus告警规则里，优先暴露问题。
容器重启告警阈值设置：别等Pod重启了才反应
告警阈值怎么设置,很多人会纠结，太敏感会刷屏，太迟钝会漏报，从实践来看，分三层比较合理。
第一层：探针失败连续2次告警
默认重启阈值是3次,所以第2次失败时介入，可以留出一次探测的缓冲，但不要把阈值设成1次，网络抖动会造成误报，在华东地区多可用区部署的集群里，跨可用区网络延迟会偶尔让探针超时，设成2次能减少相当一部分噪音。
第二层：内存使用率超过limit的80%进入观察
容器内存使用率到达limit的80%时，GC压力、页面换入换出已经开始明显，如果5分钟内持续在80%以上，就发提示级告警，不要等OOMKilled才报，那个已经是最后一刻。
第三层：节点内存可用剩余小于15%且持续10分钟
这个阈值需要按节点规格调整,多数团队会设在15%左右，但大内存节点可以设到10%，关键不是具体数字，而是要有“持续10分钟”的条件，避免瞬时波动误报。
告警渠道上,把重启类告警和CPU告警分开，容器频繁重启通常意味着应用状态丢失或连接池重建，影响面比CPU高，需要更短的响应时间。
K8s容器重启原因分析：从信号到根因的定位路径
有了前面的信号,接下来是怎么一步步定位根因，这里给出一个可复用的排查顺序。
- 先看describe的Last State：
kubectl describe pod <pod>，确认是OOMKilled还是Error退出。 - 再看事件流：
kubectl get events --field-selector involvedObject.name=<pod> -n <namespace> --sort-by=.lastTimestamp，过滤Unhealthy和FailedScheduling。 - 查节点压力：如果Pod重启集中在某个节点，
kubectl describe node <node>看MemoryPressure和DiskPressure。 - 拉取内核日志：在节点上执行
dmesg -T | grep -i "oom|kill"，确认是整机OOM还是cgroup OOM。 - 回到应用层级：确认非资源问题后，再看应用日志
kubectl logs <pod> --previous
--previous参数能拿到上一次容器的日志，往往包含panic堆栈。
这套路径的优点是每一步都在验证一个假设,不会被应用日志里的报错带偏，行业共识认为，容器重启的根因在资源层和探针层的占比在多数生产集群中超过一半，应用自身bug只占较小比例。
地域与云厂商场景下的信号差异
不同地域和云厂商的托管Kubernetes在信号暴露上略有差异,比如在华东地区，跨可用区网络抖动导致的探针失败比华北地区机房内抖动更常见，这和可用区之间的物理距离、专线质量有关，如果Pod分布在不同可用区且探针超时时间设得太短，可能会看到一批Pod同时出现Unhealthy事件。
在简米云ACK、酷番云TKE这类托管集群里，节点级指标有一部分被云监控接管，直接用Prometheus拉取node_exporter可能拿不全，这时要优先看云监控提供的内存和磁盘压力指标，再结合容器指标做关联，自建集群没有这个限制，但需要自己维护node_exporter和kube-state-metrics。
容器频繁重启监控里哪类信号最先暴露？
答：最先暴露的是容器终止原因和OOM事件信号，而不是累计重启次数。kubectl describe pod里的OOMKilled和container_oom_events_total指标在重启动作发生前就会留下痕迹，探针连续失败也早于重启，因为默认容忍3次失败。
K8s容器重启原因分析中，怎么区分OOM和代码panic？
答：看两个地方，一是Last State的Reason，OOMKilled表示内存超限，Error表示应用退出码非0，可能是panic，二是退出码，137通常是被SIGKILL，大概率是OOM；1或2是应用自身错误，如果退出码是1且日志里有stack trace，基本可以定位为代码panic，OOMKilled和代码panic的处置方向完全不同，前者调limit和堆参数，后者修bug。
docker容器重启监控指标要采集哪些？
答：优先采集container_oom_events_total、kube_pod_container_status_last_terminated_reason、kube_pod_container_status_waiting_reason和kube_pod_container_status_restarts_total，前三个指标比重启次数更早暴露问题，container_oom_events_total记录内存击杀，last_terminated_reason记录终止原因，waiting_reason记录CrashLoop等待原因，只采restarts_total会错过早期信号。
容器重启监控的核心不是数重启次数,而是盯住重启前那些“快要不行了”的信号，把OOMKilled、探针失败、节点压力这三类指标接进告警，多数重启故障都能在第一次真正中断业务前被发现。