Benefits of a Service Mesh When Integrating Kubernetes with Legacy Services
summary
Claims that Istio lets Kubernetes talk to legacy hosts are tested using Istio 1.0→1.1 with Envoy sidecars on VMs and control plane in-cluster; problems include nonroutable pod CIDRs (CGNAT), DNS tweaks, init-container iptables needing privileged net_admin, and telemetry failing because proxies try pod IPs — inbound expansion doesn’t work in 1.1. Built a short-term service mesh light (Apache TLS offload + host proxy) that helps migrations; Envoy sidecar on VMs and mutual TLS work outbound, but multi‑tenancy, performance and inbound expansion still need fixes.
AI-written summary · about
chapters (10)
- 0:00Intro
- 2:53About United Internet
- 6:28About Kubernetes
- 13:36Benefits of a Service Mesh
- 17:09How a Service Mesh works
- 20:01Master Expansion
- 22:08Security Concerns
- 25:05DNS Issues
- 30:13Whats next
- 32:28Summary
related talks
26mAn Introduction to Service Mesh in Action
34mService Mesh for Developers
28mService Mesh: Demystifying Istio
58mUsing Service Meshes and Kubernetes to Solve Service-to-Service Communications...
01h 03mJust what is a "service mesh", and if I get one will it make everything OK?
41mService Mesh beyond single clusters
39mThe Future of Service Mesh
19mService Mesh and Your Legacy Apps: Connecting to Kubernetes with Consul
