Cluster autoscaling in Kubernetes
summary
Shows a concrete pattern: create a large placeholder pod with a low priority so it is evicted when real pods need space, keeping the cluster autoscaler always having a node request in flight. Uses Kubernetes HPA, the official Cluster Autoscaler, an instance calculator, a scheduler simulator and a Black Friday game. Reports timing: HPA ~90s, cloud request ~30s, boot ~3–4 minutes and join ~30s versus the placeholder path of 3 minutes → 7 seconds. Notes cost tradeoffs and uses priority -1 for eviction.
AI-written summary · about
chapters (16)
- 0:00Introduction
- 1:16Autoscaling promises vs realities
- 2:19Scheduler assigns pods to nodes
- 3:41Requests and limits for scaling
- 5:28Node resource reservations
- 7:17Delays in autoscaling timing
- 8:21Black Friday autoscaling game
- 11:58Reducing autoscaling delays
- 12:19Optimizing node sizing
- 14:06Pre-warming nodes with placeholders
- 18:05Demo: placeholder pod scaling
- 21:58Real autoscaling behavior
- 23:24Overprovisioning with placeholders
- 24:08Reactive vs proactive autoscaling
- 27:14Cost-effective alternatives
- 28:17Q&A
related talks
29mProactive cluster autoscaling in Kubernetes
34mIntroduction to Autoscaling
29mProactive cluster autoscaling in Kubernetes
35mSIG Autoscaling Intro
29mKubernetes Autoscaling: Beyond One Size Fits All
34mPredictive autoscaling patterns in Kubernetes
24mSIG-Autoscaling: Introduction + HPA/VPA Updates
17mScaling Made Simple: Implementing Autoscaling for Optimal K8s Performance