Networking the Service Mesh Proxy: Where We Are, Where We’re Going
summary
Comparing concrete networking methods and tradeoffs for sidecar injection: Sto CNI installs via daemonset and uses iptables TPROXY to redirect pod traffic today; it supports Istio annotations, handles IPv6, and avoids NET_ADMIN init containers. Cilium’s eBPF/socket redirect path promises much lower CPU and fewer TCP stack hops. Lifecycle choices contrast mutating-webhook injection (init containers not proxied) with starting Envoy from the CNI (proxy invisible to Kubernetes, needs external monitoring and resource accounting). Integration with Network Service Mesh is proposed but still exploratory.
AI-written summary · about
chapters (15)
- 0:00Intro
- 0:55Problem: Networking the Proxies
- 2:14Traffic Redirect Approaches
- 4:41Proxy Lifecycle Approaches
- 6:13Review of Kubernetes CNI
- 7:26Istio-cni deep dive
- 9:09Istio-cni life of a packet
- 11:39Istio-cni Features
- 12:26Istio-cni future work
- 14:20Istio-cni relationship to other projects
- 17:14Network Service Mesh Architecture
- 18:13NSM service chaining example
- 19:02NSM and Istio-cni integration
- 20:26Cilium: Networking the Proxy
- 24:18References and how to contribute
related talks
31mThe Future of Service Meshes: Sidecarless or eBPF?
35mNext-level Kubernetes Networking with Cilium - Nico Meisenzahl and Philip Welz
31mFrom CNI to Service Mesh: Demystifying Kubernetes Networking
11mCilium Service Mesh
34mUnderstanding the Kubernetes Networking Layer
43mService Mesh and the future of networking
40mCloud, Kubernetes, and Service Networking - Taming the Turtles
25mStretching CNI Boundaries with Service Meshes, a Roadmap for the Future