Resource policy connects a Pod’s declared scheduling footprint to the container’s runtime boundaries. It does not describe every resource the application consumes: database connections, remote concurrency, file descriptors, queues, and heap-adjacent memory need separate budgets.
Quick answer
Kubernetes uses requests when scheduling Pods and commonly uses CPU requests as an autoscaling utilization denominator. CPU limits can throttle execution; memory limits can lead to container termination when usage cannot be reclaimed. A container-aware JVM sizes itself from visible constraints, but heap is only part of process memory. Replica count and thread count must remain consistent with database pools and downstream capacity.
Learning objectives
- Explain how requests and limits affect scheduling, runtime CPU, memory failure, and autoscaling signals.
- Build a complete Java process budget across heap, metaspace, native memory, thread stacks, buffers, agents, and external concurrency.
Prerequisites
Complete Kubernetes Probes and Graceful Shutdown and Java Concurrency for Backend Systems. The sequence is in the course and topic cluster.
Capacity is wider than the heap
A CPU request expresses scheduling weight and reserved capacity policy; it is not a guaranteed latency result. CPU throttling can lengthen request and probe duration even while the process remains alive. A memory request guides placement, while the effective limit is a hard boundary from the application’s perspective. OOM evidence must distinguish a container limit termination from a Java heap exception or node pressure.
For a Spring service, budget:
- Java heap and live-set headroom.
- Metaspace, code cache, direct buffers, native libraries, agents, and thread stacks.
- Request, executor, and connection queues.
- Database pool connections per Pod multiplied by maximum replicas.
- Startup and rollout overlap, when old and new replicas coexist.
Production failure scenario
A team raises the HPA maximum from 10 to 40 replicas. Each Pod owns 20 database connections, so a traffic event permits 800 potential connections against a database budget of 250. Pods remain within CPU limits while pool acquisition and transaction latency explode.
Bound admission, reduce per-Pod pool ownership, cap replicas against dependency capacity, and inspect transactions and queries before increasing either pool. CPU headroom did not prove database capacity.
Common misconceptions
- A request is not a performance guarantee.
- A memory limit is not the same as
-Xmx. - OOMKilled does not necessarily mean a Java heap leak.
- More replicas or virtual threads do not create database or downstream capacity.
- A high CPU limit does not prevent noisy-neighbor or node-placement effects.
Decision checklist
- Measure representative CPU, resident memory, latency, and allocation behavior.
- Reserve headroom for non-heap memory, startup, diagnostics, and rollout overlap.
- Derive total connection and downstream concurrency from maximum replicas.
- Make probe and deadline budgets tolerant of expected throttling, not unbounded.
- Alert on user impact, throttling, OOM reason, pool wait, and dependency saturation together.
- Revalidate resource policy after JVM, agent, base image, or workload changes.
Continue with Kubernetes Scheduling, Disruption, and High Availability.
Related reading
- Kubernetes Probes and Graceful Shutdown for Spring Boot
- JVM Native Memory, Metaspace, and Container OOM Diagnosis
- Evidence-Based JVM Tuning and Capacity Verification
- Kubernetes Horizontal Pod Autoscaling for Backend Services
- Spring Boot Performance Optimization
Official sources
- Kubernetes resource management for Pods and containers, accessed August 18, 2026.
- Kubernetes Pod quality of service classes, accessed August 18, 2026.
- Java container support, accessed August 18, 2026.