Why You Need Performance Tests for Proper Kubernetes Scaling
summary
Kubernetes deployments that use default JVM/container settings routinely waste resources and spike cloud bills — one example shows a migration that suddenly costs tens of millions per year — so developers must run k6 or JMeter style load tests, capture JVM NMT and thread metrics, and iterate JVM flags. Using Spring Boot buildpacks and Graal native images changes startup and memory behavior; measured results include ~3,000 RPS warmup on JVM, container images of ~220MB native versus ~337MB JVM, and faster horizontal scaling when tuned.
AI-written summary · about
chapters (12)
- 0:00Introduction and context
- 2:33Cloud cost wake-up call
- 6:48Default JVM pitfalls
- 10:02Monitoring and SLOs
- 13:36Containers in development
- 17:52Kubernetes limits and defaults
- 19:02Scaling strategies
- 23:23Native vs JVM images
- 27:51Docker files vs build packs
- 36:27Performance testing basics
- 45:35Planning for scaling
- 49:06Q&A and resources
related talks
47mSecrets of Performance Tuning Java on Kubernetes
40mJava Performance on Kubernetes
46mKubernetes and the JVM
01h 59mKubernetes for Java Developers
31mLoad Testing Kubernetes: How to Optimize Your Cluster Resource Allocation in Production [I]
32mOptimizing Application Performance on Kubernetes
51mBest Practices to Spring to Kubernetes Easier and Faster
33mBest Practices for Applications on Kubernetes for Both Frequent Updates & Stabil...