xDS Support in gRPC
summary
gRPC can obtain its configuration via xDS, removing sidecar proxies and yielding about a threefold improvement in queries per CPU-second in benchmarks. Implementation adds an http api listener type and changes LDS/CDS to per-channel named requests instead of Envoy’s wildcard-at-startup behavior. Current support is the aggregated state-of-the-world xDS variant on the gRPC client (server and incremental aggregated are planned). Management servers must send requested resources reliably (servers must resend resources and respect that wildcard only on first request), and bootstrap with an xds:// URI.
AI-written summary · about
chapters (15)
- 0:00Intro
- 0:34Background
- 0:48Envoy Service Mesh Deployment
- 1:11Why Support xDS in RPC?
- 2:59Proxyless Service Mesh Deployment
- 3:24Changes in xDS to Support Non-Proxy Clients
- 5:50What is an API Listener?
- 7:39How Envoy Uses LDS and CDS
- 11:01Client Caching Behavior
- 13:14Unsubscribing from a Resource
- 14:22Other Gotchas
- 15:16What xDS Servers Need To Do To Support RPC
- 16:20Things to Watch Out For
- 19:58Roadmap
- 22:35Final Thought
related talks
16mxDS in gRPC for Service Mesh
20mProxyless Service Mesh with gRPC
23mA Simplified Service Mesh With gRPC
26mFeature Work In GRPC; XDS And Not
25mAdapting Our XDS Control Plane for Proxyless gRPC
38mgRPC xDS Updates: ExtAuthz and ExtProc
33mgRPC For Microservices: Service-mesh and Observability
23mHow Proxyless gRPC Works in a Service Mesh