Autoscaling Isn't Set-and-Forget: Tuning KEDA & Karpenter for Real Workloads.
summary
KEDA + Karpenter tuning focuses on concrete fixes: choose proactive metrics not CPU/memory, use KEDA scaling modifiers and the double-question-mark fallback to combine OpenTelemetry → Prometheus → Datadog, and lower cold-starts with bootstrap work (a released project called soi parallel image pulls, model compilation caching, and runi/BLM) that cuts GPU node startup from ~6–8 minutes to about 2 minutes. Watch HPA sync (15s) and KEDA polling (default 30s, KEDA 2.22 fixes), use node overlays, static capacity node pools and disruption budgets to survive Spot interruptions.
AI-written summary · about
chapters (14)
- 0:00Introduction to autoscaling
- 1:33KEDA and Karpenter overview
- 4:41Four scaling challenges
- 7:52Reactive vs proactive metrics
- 10:47Observability vs scaling metrics
- 12:30Fallback and scaling modifiers
- 15:58Polling interval misconceptions
- 19:07Scaling behavior defaults
- 20:30Cost efficiency with Karpenter
- 23:01Static capacity in Karpenter
- 24:25GPU workload optimization
- 26:13Speeding up node provisioning
- 29:22Handling scaling in safely
- 33:15Q&A session
related talks
46mScaling EDA Workloads with Kubernetes, KEDA & Karpenter
38mScaling EDA Workloads with Kubernetes, KEDA & Karpenter
29mCutting Costs and Boosting Efficiency with Karpenter and KEDA on Kubernetes
42mSmart scaling with Keda
46mKarpenter * Keda: The Winning FinOps Duo
42mScaling Kubernetes-based Event-driven Workloads with Keda & Karpenter
45mYour K8s Infinity Gaunlet: The Marvel of KEDA and Cluster-API for Infinite Scale
22mUse Karpenter to scale, optimize & upgrade K8s