EKS Fargate中Spring Boot应用Pod压测时崩溃问题排查求助

1. 核查Pod资源使用与限制 #

• 执行kubectl top pods查看崩溃前后Pod的CPU、内存使用率，对比部署时配置的resources.limits和requests，确认是否触发OOMKilled（内存溢出）或CPU throttling（CPU被限流）——Fargate对Pod资源采用硬限制，超出阈值会直接终止Pod。
• 执行kubectl describe pod <pod-name>查看Pod事件，重点关注Events段是否有OOMKilled、Terminated记录，以及具体退出码（Java应用常见退出码137为OOM或被信号杀死，1为应用自身未捕获异常）。

2. 校验JVM参数配置 #

• 确认Java 11的堆内存参数（-Xmx/-Xms）是否合理：若手动设置了堆内存，需保证-Xmx不超过Pod内存limit的70%-80%（预留非堆内存空间），避免因容器内存耗尽被Fargate杀死。
• 开启JVM GC日志：在启动参数中添加-Xlog:gc*:file=/var/log/gc.log，挂载日志卷后查看GC频率、内存回收情况，排查是否因频繁Full GC、内存泄漏导致OOM。
• 检查线程泄漏：若能在崩溃前获取线程快照，用jstack分析线程数；或在应用中集成线程监控，确认高负载下线程数是否暴增超出系统限制。

3. 排查Fargate平台侧问题 #

• 通过AWS EKS控制台进入对应Fargate Profile，查看Pod的平台侧日志与事件，排查是否存在网络中断、存储挂载失败、IAM权限不足（无法访问依赖服务）等平台层面错误。
• 确认当前AWS区域的Fargate资源配额是否充足，是否因资源不足导致Pod被驱逐。
• 验证网络连通性：在Pod内执行kubectl exec <pod-name> -- curl <依赖服务地址>或telnet，排查高负载下是否因依赖服务连接超时/中断导致应用崩溃。

4. 分析容器崩溃细节 #

• 执行kubectl get pod <pod-name> -o jsonpath='{.status.containerStatuses[0].state.terminated.exitCode}'获取容器退出码，对应判断原因：
  • 137：收到SIGKILL信号，多为OOM或kubelet主动终止
  • 1：应用自身抛出未捕获异常
  • 2：启动命令/参数配置错误
• 核查容器启动命令、环境变量是否正确，比如数据库地址、端口配置错误可能导致高负载下连接失败触发崩溃。

5. 验证HPA配置逻辑 #

• 执行kubectl describe hpa <hpa-name>查看HPA指标来源，确认CPU/内存指标是否正常采集，是否存在指标延迟或异常，导致Pod崩溃后才触发扩容。
• 检查HPA阈值设置是否合理，比如CPU使用率阈值过高，可能导致Pod在触发扩容前就因负载过载崩溃。

6. 校验负载测试细节 #

• 核查负载测试的请求类型、并发量、持续时间，是否存在突发极端流量（如瞬间并发数远超应用处理能力），导致线程池、连接池耗尽触发崩溃。
• 验证测试请求合法性，排查是否存在大payload、循环请求等异常请求导致应用处理失败。

7. 补充日志与监控 #

• 开启Spring Boot DEBUG日志：修改application.yml/application.properties，将核心模块（请求处理、数据库连接、线程池）的日志级别设为DEBUG，捕捉崩溃前的细节日志。
• 集成Prometheus+Grafana监控：采集JVM指标（堆内存、线程数、GC次数）、应用指标（请求量、响应时间、错误率），在负载测试时实时监控，定位崩溃前的指标异常。

内容的提问来源于stack exchange，提问作者ShefZee