Where's My Pod, Already? A Tale of Cold-Start Struggles on Kubernetes
summary
Cold-start time drops from ~5–6s down to about 2s by instrumenting Kubernetes with Zipkin/ Istio traces and resource informers, removed initContainer to avoid duplicate CNI setup (halves pod startup), and fixing 1–2s polling loops in the autoscaler. Prototype hacks that work: a queue-proxy long‑poll readiness probe to edge‑trigger readiness, direct forwarding to notReady endpoints to bypass service delay, and an activator DaemonSet + local scheduling to avoid control‑plane variability; most changes are prototyped or unmerged but effective.
AI-written summary · about
chapters (17)
- 0:00Intro
- 1:01Overview
- 3:44The Problem
- 5:31Knative cold-Start Architecture
- 6:51Measurement (tracing)
- 10:47Init containers are expensive
- 12:23No init containers
- 12:43Other low hanging fruit
- 13:28Looking better..
- 14:08Readyness delay
- 15:39Readyness long polling
- 16:49Still 1s delay
- 18:03Dataplane delay
- 18:54NotReadyAddresses
- 21:19Direct request forwarding
- 23:21Kas controlplane perf.
- 26:32We have a ways to go
related talks
08m⚡ Fast Restarts, Not Just Fast Starts: Accelerating Pod Recovery
38mHow Can Pod Start-up Be Accelerated on Nodes in Large Clusters?
30mMaximizing Launch Reliability: Controlled Lift-off for Reliable Application Startup on…
29mProactive cluster autoscaling in Kubernetes
26mWait! Can Your Pod Survive a Restart?
35mFrom Minutes to Seconds: How we reduced ML models cold start time by 90% on Kubernetes
29mProactive cluster autoscaling in Kubernetes
28mContainer Checkpoint/Restore at Scale for Fast Pod Startup Time