服务器K8s集群Pod频繁重启排查：从定位到修复的完整流程
Pod为什么频繁重启，先看这三个信号
Pod频繁重启的本质是容器进程反复退出，Kubernetes按重启策略拉起又失败。
排查前先确认现象属于哪类：kubectl get pods 的 RESTARTS 列持续增长，说明重启在发生；kubectl describe pod 的 Events 和 Last State 能告诉你上一次退出的原因；
容器退出码则是最直接的线索。
常见的退出码含义：
- 退出码 137：进程被 SIGKILL 终止，通常是内存超限（OOMKilled）或节点资源压力。
- 退出码 1：应用自身报错退出，需要看容器日志。
- 退出码 143：进程收到 SIGTERM，多为探针失败或优雅退出超时。
排查顺序建议从「看状态 → 看事件 → 看日志 → 看资源」四步走，不要一上来就改配置。
用kubectl定位重启根因
所有操作需要能访问集群的 kubeconfig，并具备查看 Pod、节点和事件的权限。
以下命令在默认命名空间执行，如果是其他命名空间加 -n <命名空间>。
第一步：查看 Pod 重启概况
kubectl get pods -o wide观察 RESTARTS 列。
如果某个 Pod 重启次数明显高于其他副本，问题大概率出在该 Pod 所在节点或它的配置上，而不是整个 Deployment。
第二步：查看上次退出的原因
kubectl describe pod 重点看三处：
Last State里的Reason，例如OOMKilled、Error。Events底部的记录，例如Back-off restarting failed container、Liveness probe failed。Containers段里的Limits和Requests，确认内存上限是否设置过小。
第三步：查看容器日志
如果容器已经重启，直接 kubectl logs 可能看不到崩溃前的输出，需要加 --previous：
kubectl logs --previous 如果 Pod 里有多个容器，用 -c <容器名> 指定。
日志里出现 Killed、signal: killed 或应用异常堆栈，基本能锁定方向。
第四步：确认资源使用
kubectl top pod
kubectl top node 如果 Pod 内存接近 limits 上限，或节点整体内存、CPU 压力偏高，就是资源问题。
注意 kubectl top 需要集群已部署 metrics-server，没有该组件时命令会报错，改用 kubectl describe node 看已分配资源。
针对不同原因的修复方式
OOMKilled 导致的反复重启
先确认应用真实内存需求，再调整 resources.limits.memory。
如果只是临时缓解，可以调大 limit，但更稳妥的做法是排查应用是否存在内存泄漏。
修改 Deployment 的 YAML：
resources:
requests:
memory: "256Mi"
limits:
memory: "512Mi"改完后执行 kubectl apply -f <文件> 生效。
注意 requests 和 limits 不宜差距过大，否则调度和实际运行会不一致。
探针配置不当导致的重启
Liveness probe failed 很常见，原因通常是初始启动时间超过 initialDelaySeconds，或探针路径返回非 200。
检查探针配置：
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
failureThreshold: 3启动慢的应用要把 initialDelaySeconds 调大，或改用 startupProbe 专门处理启动阶段。
探针超时太短也会误杀，timeoutSeconds 默认 1 秒，对响应慢的接口要适当放宽。
镜像拉取或启动命令问题
如果 Events 里出现 ImagePullBackOff 或 ErrImagePull，检查镜像地址、tag 和拉取密钥是否正确。
如果是 CrashLoopBackOff 但日志为空，可能是启动命令写错或依赖服务未就绪，需要确认 command 和 args 以及环境变量。
容易踩的坑和验证方法
几个高频误区值得留意：
- 只看 describe 不看 previous 日志：很多崩溃原因只在上一次容器日志里，不看就找不到根因。
- 探针路径写成应用首页：首页可能依赖数据库，数据库慢时探针就失败，应该用独立的健康检查接口。
- limit 设得和 request 一样小：突发流量下容易 OOM，建议留出合理余量。
- 忽略节点层面问题：如果多个不同应用的 Pod 在同一节点反复重启，要检查节点磁盘、内存和 kubelet 状态。
修复后验证方式：观察 kubectl get pods -w 一段时间，确认 RESTARTS 不再增长；
执行 kubectl describe pod 确认没有新的 Warning 事件；
用 kubectl top pod 确认内存稳定在 limit 以下。
如果重启停止且业务接口正常返回，说明问题已解决。
常见疑问
Pod重启和CrashLoopBackOff是什么关系？
CrashLoopBackOff 是容器反复崩溃后 Kubernetes 拉长重启间隔的一种状态，是频繁重启的结果而非原因。
看到它说明需要按上面的流程查退出原因。
调大内存limit后还是重启怎么办？
说明根因可能不在内存。
回到 describe 看 Events 和退出码，确认是不是探针失败、依赖服务不可用或节点异常，不要继续盲目加资源。
没有metrics-server怎么看资源？
可以用 kubectl describe node 查看节点的 Allocated resources 和 Conditions，
判断节点是否处于 MemoryPressure 或 DiskPressure 状态。
排查Pod频繁重启的核心思路是先拿到退出码和事件，再对照资源、探针、镜像三类常见原因逐一排除，最后用持续观察验证修复效果。
