Architecting Istio for Large-Scale Deployments: R&D and Service Me...
summary
Riskified runs Istio across ~1,000 microservices at ~25k requests/min and faces routing chaos from virtual services whose cross-object rule order is undefined. The platform centralizes gateways and host registration, then splits virtual services with a delegate virtual service split so devs own routing weights while platform owns hosts. A CRD sidecar that limits per-pod config cuts CPU by 70–80% and network by ~90% during spikes. Destination rules and mTLS remain self-service; automated host registration uses GitHub/Slack approvals.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 2:49Riskified and its scale
- 4:58Why Istio at Riskified
- 7:03Developer independence challenges
- 9:09Initial Istio/Kubernetes architecture
- 11:17Istio in self-service platform
- 13:24Virtual service dilemma risks
- 17:24Splitting virtual services safely
- 19:35Destination rules for developers
- 20:17Optimizing Istio proxy resources
- 22:01Adding authorization policies
- 22:45Current state and lessons
- 23:27Q&A
related talks
41mService Mesh beyond single clusters
31mClean-up Your Service Mess with Service Mesh
37mThe Service Mesh Wars: A New Hope for Kubernetes
21mServiceRouter: Hyperscale Service Mesh
38mHow We Manage Traffic for Thousands of Pods in a Multicluster Kubernetes Environment
31mBeyond the Limits: Scaling Kubernetes Controllers Horizontally
55mScaling out operational research with Rust
47mMonolith to Microserv. at 20M+ requests per second: Latency and Scale Challenges