Lightning Talk: Not One Size Fits All, How to Size Kubernetes Clusters - Jeff Sloyer, IBM
summary
Explains concrete rules: categorize workloads (Go = CPU-light, Java/Node = memory-heavy), size nodes accordingly, and set requests vs limits so pods only schedule when capacity exists and map to QoS classes (BestEffort/Burstable/Guaranteed). Use node selectors for SSD or specialized hardware, enforce anti-affinity to avoid colocating replicas, and apply taints and tolerations to reserve nodes — example: dedicated Prometheus nodes with ~64 GB RAM in production to keep monitoring stable.
AI-written summary · about
chapters (6)
related talks
09mLightning Talk: Optimize the Ray Schedule and Autoscaling on Kubernetes Cloud: A Hetero...
11mLightning Talk: How Jenga & Tetris Can Help Run More Containers with Lesser Costs & Downtime
06m⚡ Lightning Talk: Colocating Data Workloads and Web Services on Kubernetes to Improve Resource Utilization
21m07 Lightning talks
08mLightning Talk: Orchestrating Kubernetes Clusters on HPC Infrastructure
10m⚡ Lightning Talk: Navigating the Complexities of Stateful Workloads in Kubernetes
11mLightning Talk: The Adaptive Edge: Balancing Cost Efficiency, Usability, and Performance Tradeoffs
29mRight-Size Your Kubernetes Deployments