基于Kubernetes部署Spring Boot后数据库CPU占用异常升高求助

针对你遇到的容器化后数据库CPU占用异常升高的问题，结合你的环境和部署配置，可从以下几个方向逐步排查：

1. 优先排查探针的影响 #

你的Deployment配置中，readinessProbe和livenessProbe的触发频率过高：

• periodSeconds: 2意味着每2秒就会发送一次探针请求
• failureThreshold: 30+timeoutSeconds:20，如果探针失败会持续重试30次，期间会产生大量请求

如果你的/actuator/probes/readiness或liveness接口内部依赖数据库查询（比如检查数据库连接可用性），那么高频的探针会直接导致数据库被反复查询，进而拉高CPU占用。

临时验证方案： #

修改探针参数，降低触发频率：

readinessProbe:
  httpGet:
    path: /actuator/probes/readiness
    port: 8080
  initialDelaySeconds: 20
  periodSeconds: 10  # 从2秒调整为10秒
  failureThreshold: 5  # 从30调整为5
  timeoutSeconds: 5  # 从20调整为5
livenessProbe:
  httpGet:
    path: /actuator/probes/liveness
    port: 8080
  initialDelaySeconds: 60
  periodSeconds: 15  # 从2秒调整为15秒
  failureThreshold: 5
  timeoutSeconds: 5

应用修改后观察数据库CPU是否下降，若明显降低则可确认是探针导致的问题。

长期优化建议： #

• 使用Spring Boot Actuator默认的无依赖探针接口（如/actuator/health/liveness），这类接口仅检查应用自身状态，不依赖外部资源
• 若必须自定义探针，确保接口内部不执行数据库查询或其他重操作

2. 检查数据库连接池配置差异 #

对比EC2环境与容器环境的Spring Boot数据库连接池配置（激活的是api profile）：

• 确认HikariCP的maximum-pool-size是否一致，容器环境若配置过高，会导致大量空闲连接占用数据库资源
• 检查connection-timeout、idle-timeout等参数，跨VPC网络延迟可能导致连接超时重试，进而产生无效的数据库请求

3. 验证数据库侧的实际请求 #

直接查看数据库的进程列表或慢查询日志，确认高CPU占用的来源：

• 若是大量重复的查询语句：排查应用是否有异常任务或循环查询逻辑
• 若是大量连接创建/销毁操作：检查连接池的回收机制，或跨VPC网络是否存在连接不稳定的情况

4. 排除HPA误扩容可能 #

执行kubectl get pods确认实际运行的Pod数量是否为1（你的HPA配置minReplicas:1），若出现多Pod运行，多个实例的后台任务叠加会导致数据库负载升高。

5. 确认应用镜像与EC2版本一致 #

检查容器镜像blablabla.amazonaws.com/back:test-latest的代码和配置是否与EC2环境完全一致，避免容器内存在额外的定时任务或逻辑导致数据库压力增加。

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