Multi-Cluster Kubernetes and Service Mesh Patterns
summary
Walks through concrete patterns and tools for multi-cluster Kubernetes and service mesh: uses Envoy Proxy and Istio, runs two GKE clusters with a management plane on kind, and demonstrates a service mesh hub virtual mesh that federates identity via a shared root CA and achieves mutual TLS and cross-cluster routing. Shows config orchestration creating virtual services and service entries and routes 75% traffic from cluster one to reviews v3 in cluster two so the deployment actually fails over and balances across clusters.
AI-written summary · about
chapters (17)
- 0:00Intro
- 0:50CHRISTIAN POSTA
- 2:47SERVICE MESH JOURNEY
- 4:09Solo.io solves API connectivity & communication challenge
- 7:05Service proxy lives with application instance
- 11:13Pattern: flat network across pods
- 12:05Pattern: Different network, expose all services
- 13:11Pattern: Different network, controlled gateway
- 14:05Envoy is the magic behind service mesh
- 15:45Envoy to do application networking heavy lifting
- 16:14Envoy as backbone for multi-cluster communication federation
- 17:59Request racing
- 22:05Shared control plane, flat network
- 23:08Shared control plane, separate networks
- 24:31Separate control planes, separate networks
- 26:26Increased operator burden
- 29:22What to do about the added burden for the operator?
related talks
32mMulti Cluster and Multi Mesh Patterns
58mUsing Service Meshes and Kubernetes to Solve Service-to-Service Communications...
01h 11mMulti-cluster Service Mesh Workshop
34mIstio Multi-Cluster Service Mesh Patterns Explained
30mLife Outside the Cluster: Adding Virtual Machines to an Envoy Service Mesh
05mBest Practices on Setting up Multi Cluster Service Mesh in AWS
26mAn Introduction to Service Mesh in Action
01h 03mJust what is a "service mesh", and if I get one will it make everything OK?