问题描述：某个服务重启频率非常高，监控告警里产生了大量的“jvm内存超过limit 85%”和服务503告警
jvm内存超警戒告警

服务503不可用告警

问题原因：该服务的jvm启动参数设置不合理
排查思路：

1. 刚开始粗浅的认为是服务压力太大，于是增加pod数量，然而问题依旧

2. 查看服务运行状态，发现服务频繁重启
   

3. 查看该服务的pod资源配额配置
   

4. 进入容器，查看该服务的的jvm启动参数，发现最大堆内存设置竟然超过了pod资源配额的limit值
   

5. 调整jvm最大堆内存(Xmx)的值不超过pod资源配额limit的85%，问题解决
   

总结：jvm参数设置的时候，要综合考虑pod资源配额limit的值和告警触发值，否则容器很容易因为不合理的jvm参数设置达到pod资源配额的上限而被kill掉，导致频繁的触发告警。

k8s集群环境下，docker容器中运行镜像方式启动springboot项目。由于制作的镜像未对JVM的内存进行配置，那么 JVM 会默认设置堆栈的大小，这个大小是根据物理机的内存进行分配的。 那么物理机的内存越大，默认分配的内存就越大（最大堆栈=1/4 * 物理机内存，初始堆栈=1/64 * 物理机内存）。JVM 是不知道自己在Docker容器中运行的，jvm识别的是物理主机的内存，而不是k8s给pod分配的内存或docker容器的内存。

因此在没有给jvm指定内存大小的情况下，机器物理内存很大时，jvm默认占用的内存Xms超出了k8s分配给pod的内存，导致pod内存溢出，从而k8s不断重启pod。也可能是运行过程中，jvm不断申请内存直到最大堆内存Xmx，Xmx超出了k8s分配给pod的内存，从而k8s自动重启pod。

注意，jdk版本不同，配置参数可能也会不同。