Why We Ditched Kube-proxy: Scaling 10M Daily Browser Sessions With Kubernetes Endpoi...
summary
Platform scrapes 850+ retailers and 10M pages/day with thousands of ephemeral browser pods, peaking at 8K concurrent pods where kube-proxy’s iptables and conntrack exhaust and spike latency. The team replaces kube-proxy routing with direct pod allocation using the EndpointSlice API, introduces proxy pods that hold websocket requests until a worker pod is leased, adds custom HPA metrics from scrape queues to scale 4K→16K concurrent scrapes on spot VMs, and cuts egress ~60% with a MinIO cache, yielding ~40% latency improvement.
AI-written summary · about
chapters (15)
- 0:00Introduction
- 1:05Commerce IQ platform overview
- 2:50Browser Farm platform purpose
- 4:16Exclusive pod allocation needs
- 6:03Kubernetes service limits
- 7:26Readiness probes issues
- 8:31Custom proxy architecture
- 10:42New proxy pod and worker system
- 12:30Edge cases and failures
- 15:41Live system demo
- 17:23Chaos simulation demo
- 20:32MinIO for caching and profiles
- 21:35Kubernetes primitives mismatch
- 22:39Why CNI solutions like Cilium didn't help
- 23:21Summary
related talks
28mScale Kubernetes to Support 50,000 Services [I]
31mUnleashing the Tides of Kubernetes Networking by Removing kube-proxy
20mOperating High Traffic Websites on Kubernetes
27mPods on Steroids - A Case Study of Migrating Flipkart.com to K8s on Bare Metal
28mProxy Service: A New Network Traffic Abstraction in Kubernetes
32mScaling Kubernetes Application to 1M Users
34mOperating High Traffic Websites on Kubernetes
30mK8s Under Fire: Igniting Performance & Burning Through Bottlenecks with Kube-Burner