Kubernetes

JVM Settings & Tuning in Kubernetes

Running Java in Kubernetes changes how you think about JVM settings. The JVM no longer sees a fixed machine — it sees the CPU and memory limits you place on the pod, and it must cope with cgroup capping, container sharding and the container's ephemeral nature. Get the memory settings wrong and you get either OOMKilled pods or heap starvation.

This category covers how to reason about JVM memory and GC flags in a containerized world: how modern JDKs auto-detect container limits, how to size the heap relative to the pod memory limit, which collectors suit latency- vs throughput-bound service pods, and how to route diagnostics (JFR, Prometheus metrics) out of a pod and into your observability stack.

What you'll find here: Understand container-aware JVM defaults (UseContainerSupport, MaxRAMPercentage) · Size the heap safely relative to the pod memory limit · Choose GC / tuning by service type: G1, ZGC, Shenandoah, Parallel · Sidecars & agents: JMX exporter, JFR streaming, Prometheus

Kubernetes tools

In-depth guides in this category