Skip to content

CONCEPT Cited by 2 sources

xDS protocol

xDS is Envoy's family of dynamic-configuration APIs: a streaming gRPC protocol over which a control plane pushes cluster, endpoint, listener, route, and secret updates to data-plane clients. Originally designed for Envoy-as-sidecar, it has become the de facto interface between any control plane and any L7 data plane — including gRPC client libraries (xds: resolver) and custom clients.

What the letters mean

  • CDS — Cluster Discovery Service (define logical clusters).
  • EDS — Endpoint Discovery Service (pod/instance addresses + metadata per cluster).
  • LDS — Listener Discovery Service (ports/listeners on the data plane).
  • RDS — Route Discovery Service (HTTP routing rules).
  • SDS — Secret Discovery Service (TLS cert distribution).
  • ADS — Aggregated Discovery Service (all of the above over one stream, in ordered updates).

"xDS" = any / all of these.

Why xDS became generalizable

  • Streaming, not polling. Updates flow in ms, without TTL-driven staleness.
  • Metadata-rich. Unlike DNS, xDS endpoints carry zone, region, weight, health, locality priority, arbitrary labels — everything an L7 LB needs for patterns/zone-affinity-routing or shard-aware routing.
  • Protocol, not implementation. Any control plane that implements xDS can drive Envoy, gRPC clients, or custom clients; any client that speaks xDS can consume updates from any xDS control plane.
  • Versioned and extensible. v2/v3 progression, well-defined proto schemas.

Non-sidecar uses

The relevant pattern: ship xDS beyond Envoy sidecars to:

  • gRPC client libraries. gRPC's xds: resolver subscribes directly; the library does L7 LB in-process.
  • Custom RPC frameworks. Embedded xDS clients in Scala (Armeria), Go, Java, etc. — same protocol, different consumers.
  • Mix internal + edge. One xDS control plane can feed both an ingress Envoy and every internal client library, giving unified topology.

Seen in

  • sources/2025-10-01-databricks-intelligent-kubernetes-load-balancing — Databricks built a custom xDS control plane (systems/databricks-endpoint-discovery-service) that serves (a) their Armeria-based Scala RPC clients and (b) Envoy ingress gateways via ClusterLoadAssignment / EDS. The same protocol compatibility is what lets internal and external traffic share a single topology source of truth.
  • sources/2024-10-28-dropbox-robinhood-in-house-load-balancing — Dropbox's Robinhood uses EDS the same way for both Envoy and gRPC clients, but the endpoint weights come from a PID feedback-control loop per backend rather than topology-only metadata. This pushes xDS further: not just "here are the endpoints and their zones," but "here are the endpoints and the weights the control plane has derived from each node's observed utilization vs the fleet average." gRPC-side consumption via A27 + a custom EDF-based weighted-RR picker (because gRPC upstream hadn't shipped endpoint-weight WRR at the post's date). Same one-control-plane-two-consumer-shapes pattern as Databricks EDS, confirming that xDS is the general LB-integration contract — control planes emit, clients consume, and what they agree on is richer than pod addresses.
Last updated · 200 distilled / 1,178 read