JVM and Kubernetes walk into the bar...
summary
Shows how Kubernetes resource requests and limits map to Linux cgroups and how modern JVMs read those cgroup values: memory limits from cgroups become the JVM max heap basis (default maxHeapPercent 25%) and exceeding that can cause OOM kills. Demonstrates with live-created pods, docker/container inspect output, kubectl, and java -XX flags, and reproduces a CPU-count bug where giving 500 millicores without a CPU limit made Java 17.0.4 see only one CPU (fixed in 17.0.6).
AI-written summary · about
chapters (7)
- 0:00Introduction
- 4:39What is a container
- 14:19Kubernetes resource management
- 27:10JVM in containers
- 38:38Java memory and CPU
- 46:07Best practices and pitfalls
- 49:16Summary and Q&A
related talks
47mCPU & Memory, Requests & Limits, QoS & CFS: The JVM in the Kubernetes Pod
05mtalks to
50mWhy you’re going to FAIL running Java on docker!
42mContainers & Java: What I wish I have been told!
58mContainer Friendly Java 9
48mJava in Containers - Part Deux
45mCatching the 137-Killer: A Java Memory Forensics Investigation
35mNO ONE PUTS Java IN THE CONTAINER
