Envoy Namespaces - Operating an Envoy-based Service Mesh at a Fraction of the Cost
summary
Proposes replacing one sidecar per pod with one Envoy per node that registers as multiple virtual Envoys to the control plane, cutting control-plane CPU from thousands of vCPUs to a few dozen in tested clusters and lowering network traffic from hundreds of MB/s to tens. Uses Cilium / Isovalent BPF for transparent injection and optional connect syscall redirection to avoid packet mangling. Notes work remains on per-tenant resource limits and request capping.
AI-written summary · about
chapters (9)
- 0:00Intro
- 0:29Context for Talk
- 1:51Control Plane with Sidecar Model
- 2:11Looks Familiar?
- 2:31Example (Moderate Scale) 500 nodes, 30 pods per node
- 4:11Example (Large Scale) 5 clusters, 1000 nodes per cluster, 30 pods per mode
- 4:52Shared Envoy Model One Envoy per Node
- 6:52Injecting a Shared Envoy
- 8:36Envoy Namespaces
related talks
10mLightning Talk: Envoy @ Netflix
26mRunning Envoy at the Edge
26mIntegrating Stateful Load Balancing At Scale In Envoy
39mThe evolution of service mesh with eBPF
36mFine Grained Mesh Metrics for Better Visibility With Native Performance
40mA Packet Eye View of the Istio Ambient Mesh
35mTransparent Chaos Testing with Envoy , Cilium and BPF
10mUsing VPP as Envoy's Network Stack