Adding Sidecars to Cloud Foundry - Gabriel Rosenhouse & Angela Chin
summary
Adds a sidecar per app (Envoy) that the platform injects alongside each container, with Diego issuing per-container certs so the router and sidecars do mutual TLS and the mesh can validate container identity. This fixes the Cloud Foundry route integrity problem by letting routers reject stale backends when the control plane (NATS) is down. Work is experimental but already wired into Diego and routing: Envoy runs as a proxy, Istio (pilot/mixer/CA) supplies dynamic configs and cert management.
AI-written summary · about
chapters (15)
- 0:00Introduction
- 0:57Microservices
- 3:07Cloud Foundry Router
- 6:27Sidecars
- 7:39Service Mesh
- 8:12Sidecar Load Balancing
- 8:52Route Integrity Problem
- 14:33Envoy Control Plane
- 14:58Use Case
- 15:38Sidecar Components
- 16:31Pilot Architecture
- 17:24Future Work
- 20:54Summary
- 21:23Acknowledgements
- 21:44Questions
related talks
24mHow the CF Service Mesh Could Solve Identity and Access...
32mWhy Sidecars? Moving the Stack out of the Monolith
50mService Mesh and Sidecars with Istio and Envoy
01h 07mImplementing Sidecars Microservice Pattern using Envoy Proxy
28mService Mesh and Sidecars with Istio and Envoy
47mService Mesh and Sidecars with Istio and Envoy
58mService Mesh and Sidecars with Istio and Envoy
28mEnvoy at Square