Service Mesh beyond single clusters
summary
Platform implements Istio for cross-cluster networking and mesh expansion, using dns interception (enabled in Istio 1.11) to make Kubernetes DNS visible to host apps and other clusters, and testing istiod horizontal scaling against heavy API-server load. Migration uses automated manifest generators, service entries, admiral and Kubernetes MCS (CAP-1645) export/import, and ingress gateways for remote endpoints. Results: about 10–15% adoption so far, proved stable, with planned rollouts aiming at 200 clusters and ongoing tuning of control-plane resources.
AI-written summary · about
chapters (12)
- 0:00Introduction to service mesh
- 2:18What is a delivery platform
- 5:04Service mesh benefits and Istio
- 8:37DNS challenges in multi-cluster
- 13:17DNS interception in Istio
- 16:47Control plane scalability
- 21:23Multi-cluster failover strategies
- 25:38Admiral and multi-cluster services
- 27:02Migration challenges
- 29:51Usability and automation
- 32:00Current setup and future plans
- 33:08Q&A session
related talks
28mService Mesh: Demystifying Istio
34mService Mesh for Developers
43mService Mesh for developers
01h 03mJust what is a "service mesh", and if I get one will it make everything OK?
33mBenefits of a Service Mesh When Integrating Kubernetes with Legacy Services
24mNavigating the Maze of Multi-Cluster Istio: Lessons Learned at Scale
36mBuilding a Multi Cluster/Env Service Mesh at Airbnb
47mDeploying Service Mesh in Production