Kubernetes Resource Requests and Limits for JVM Apps

Q: Kubernetes Resource Requests and Limits for JVM Apps

Memory: set `requests` to steady-state usage and `limits` to a safe ceiling (~1.5x heap). Use `-XX:MaxRAMPercentage=75.0` with `-XX:+UseContainerSupport` so heap tracks the cgroup limit automatically. CPU: set requests to typical usage; be cautious with CPU limits — they cause CFS throttling that freezes all JVM threads including GC. For latency-critical services, use Guaranteed QoS (requests == limits) on memory; often leave CPU limits unset for Burstable flexibility.

Intermediate·3 min read·

GoogleAmazonNetflixDynatrace

Fast recall

Quick revision

Core answer

Memory: set requests to steady-state usage and limits to a safe ceiling (~1.5x heap). Use -XX:MaxRAMPercentage=75.0 with -XX:+UseContainerSupport so heap tracks the cgroup limit automatically. CPU: set requests to typical usage; be cautious with CPU limits — they cause CFS throttling that freezes all JVM threads including GC. For latency-critical services, use Guaranteed QoS (requests == limits) on memory; often leave CPU limits unset for Burstable flexibility.

Interview Answer3 min

Kubernetes resource requests and limits are the two numbers the scheduler and kubelet use to decide where to place Pods and when to kill them. Getting them wrong for a JVM is one of the most common causes of OOMKilled pods and degraded cluster scheduling.

Requests — scheduling guarantees

resources.requests tells the scheduler how much CPU and memory the pod needs — the scheduler places the pod on a node that has at least this much available; if no node has enough, the pod stays Pending.
Requests define the Pod's QoS class: requests == limits gives Guaranteed (last to evict); requests < limits gives Burstable; no requests at all gives BestEffort (first to evict).
Set memory requests based on actual idle JVM footprint from kubectl top pod during normal operation; setting requests too low packs too many JVMs onto one node and they all OOMKill together when traffic hits.

Limits — enforcement ceilings

resources.limits.memory is a hard ceiling enforced by cgroups — exceed and the kernel OOMKills; no warning, no JVM cleanup.
Set memory limits to at least 1.3–1.5x the heap (-XX:MaxRAMPercentage) to account for metaspace, thread stacks, direct buffers — a JVM with 512MB heap needs at least 700–800MB total container limit.
CPU limits throttle using cgroup CPU quota — a JVM hitting the limit slows down but is not killed; excessive throttling (visible in container_cpu_throttled_seconds_total) degrades GC performance because GC threads are also throttled.

Recommended settings

Set requests.memory == limits.memory for Guaranteed QoS — JVMs have unpredictable memory footprints and should not compete with other pods; predictable allocation is worth the lost burst capacity.
Leave CPU limits unset or set generously — CPU throttling degrades latency under load without meaningful protection; use CPU requests for scheduling placement without CPU limits for execution.
For latency-critical services, set -Xmx and -Xms equal via matching RAMPercentage flags — this avoids full-GC pauses that happen when the heap resizes at runtime.

Observability

Alert on container_memory_working_set_bytes / limit > 0.85 for 10 minutes as an OOMKill early warning.
Alert on CFS throttled ratio > 5% for 15 minutes to catch CPU-throttling-induced latency before it shows up in the user experience.
Use Vertical Pod Autoscaler in recommend mode to discover correct sizing empirically over days — review suggestions before enabling automatic resizing.

Interview-ready guide

Interview answer

Requests — scheduling guarantees

resources.requests tells the scheduler how much CPU and memory the pod needs — the scheduler places the pod on a node that has at least this much available; if no node has enough, the pod stays Pending.
Requests define the Pod's QoS class: requests == limits gives Guaranteed (last to evict); requests < limits gives Burstable; no requests at all gives BestEffort (first to evict).
Set memory requests based on actual idle JVM footprint from kubectl top pod during normal operation; setting requests too low packs too many JVMs onto one node and they all OOMKill together when traffic hits.

Limits — enforcement ceilings

resources.limits.memory is a hard ceiling enforced by cgroups — exceed and the kernel OOMKills; no warning, no JVM cleanup.
Set memory limits to at least 1.3–1.5x the heap (-XX:MaxRAMPercentage) to account for metaspace, thread stacks, direct buffers — a JVM with 512MB heap needs at least 700–800MB total container limit.
CPU limits throttle using cgroup CPU quota — a JVM hitting the limit slows down but is not killed; excessive throttling (visible in container_cpu_throttled_seconds_total) degrades GC performance because GC threads are also throttled.

Recommended settings

Set requests.memory == limits.memory for Guaranteed QoS — JVMs have unpredictable memory footprints and should not compete with other pods; predictable allocation is worth the lost burst capacity.
Leave CPU limits unset or set generously — CPU throttling degrades latency under load without meaningful protection; use CPU requests for scheduling placement without CPU limits for execution.
For latency-critical services, set -Xmx and -Xms equal via matching RAMPercentage flags — this avoids full-GC pauses that happen when the heap resizes at runtime.

Observability

Alert on container_memory_working_set_bytes / limit > 0.85 for 10 minutes as an OOMKill early warning.
Alert on CFS throttled ratio > 5% for 15 minutes to catch CPU-throttling-induced latency before it shows up in the user experience.
Use Vertical Pod Autoscaler in recommend mode to discover correct sizing empirically over days — review suggestions before enabling automatic resizing.

03 · Deep dive