Introduction to Ambient Mesh
summary
Ambient Mesh replaces per-pod sidecars with a per-node proxy and a per-namespace proxy to avoid restarting workloads and cut overhead: a z-tunnel (Rust) daemonset implements node-to-node mTLS and preserves pod identities, a waypoint proxy (Envoy) handles optional L7 policies, and the new hbone protocol tunnels multiple streams over one mTLS connection. Traditional Istio sidecars cost ~0.35–0.4 vCPU and ~40–50 MB each; Ambient aims non-disruptive migration and Gateway API–based routing.
AI-written summary · about
chapters (24)
- 0:00intro
- 0:27preamble
- 0:37about abdel
- 1:01istio current architecture
- 3:43gateway for ingress into the mesh
- 6:15all sorts of policies
- 7:12all this logic needs to be enforced at the "edge"
- 7:30sidecars
- 10:26ambient mesh datapath goals
- 11:35architecture
- 12:57ambient mesh layers
- 13:43secure overlay
- 14:29l7 policies
- 14:59traditional istio deployment
- 15:18ambient mesh deployment
- 15:39traditional istio proxy traffic
- 16:08hbone
- 16:40istio traffic management
- 18:06gateway api oss
- 19:33what is the gateway api?
- 20:33role oriented resource model
- 21:01more expressive routing
- 21:32gateway - route relationships
- 22:36thank you!
related talks
11mIstio Ambient Mesh: Sidecar vs Sidecar-less, Explained Simply
48mIstio Ambient Mesh deep dive
39mThe Future of Service Mesh
32mEmbracing the Future: The Effortless Mutual TLS and Traffic Control Without Sidecars
01h 27mGetting Started with Istio Ambient Mesh
31mThe Future of Service Meshes: Sidecarless or eBPF?
22mIs Istio Ambient Mesh Secure?
06mLife of a Request in Istio Ambient Mesh