How Lombard Odier Deployed VPA to Increase Resource Usage Efficiency
summary
Lombard Odier deploys the Kubernetes Vertical Pod Autoscaler via an OpenShift operator across multiple clusters (1300–1400 pods today, planning ~20,000) to tune pod requests automatically; VPA runs in request-only mode with p90 target recommendations and initial update behavior. CPU pressure is largely resolved (many Java defaults shrink to ~38m cores), memory tuning is in progress; governance tracks request vs usage monthly and VPA application already saved 18 GB RAM on dev.
AI-written summary · about
chapters (22)
- 0:00Resource efficiency in Kubernetes
- 2:06Resource allocation challenges 2020
- 3:30Pod placement optimization
- 5:57CPU vs memory requests/limits
- 9:03Request sizing with past behavior
- 11:07VPA percentiles for recommendations
- 12:31Vertical Pod Autoscaler (VPA)
- 13:57Configuring VPA for workloads
- 16:23VPA use cases and limitations
- 18:49VPA deployment at Lombard Odier
- 21:17Results and savings from VPA
- 22:23Key learnings from VPA
- 23:27VPA and CPU overcommit conflicts
- 24:30JVM workloads and startup peaks
- 25:33Future goals for memory density
- 26:57Improvements to VPA
- 28:21Tools for VPA recommendations
- 29:23Q&A: Prometheus vs CR storage
- 30:48Q&A: HPA vs VPA dilemma
- 31:51Q&A: JVM memory issues
- 32:55Q&A: Throttling on startup
- 33:56Closing remarks
