Democratizing Service Mesh on Kubernetes
summary
Announces the Service Mesh Interface (SMI) — a portable API surface that already covers three concrete features: SMI traffic split (used with Flagger to run an automated canary and shift weights between versions), SMI metrics server (an aggregated API exposing ~five metrics: RPS, latency percentiles, success/failure counts) and SMI traffic policy (mTLS identities and intent-based routing wired into Consul/Istio/Linkerd via adapters). Adapters reconfigure each mesh dynamically, KubeCost and other tools consume the metrics, and the demos show the integrations working end to end.
AI-written summary · about
chapters (7)
- 0:00Intro
- 0:17Smart endpoints dumb pipes
- 0:54What is Service Mesh
- 4:22Traffic Split Demo
- 5:12Traffic Metrics Demo
- 6:14Traffic Policy Demo
- 7:25Why SMI
related talks
24mService Mesh Interface: Developer Friendly APIs for Service Mesh
28mService Mesh: Demystifying Istio
01h 03mJust what is a "service mesh", and if I get one will it make everything OK?
58mUsing Service Meshes and Kubernetes to Solve Service-to-Service Communications...
39mDo you need a Service Mesh?
30mA Developer’s Introduction to Service Mesh
34mService Mesh for Developers
53mService Mesh: What, Why, And How?
