xDS

xDS is the set of discovery APIs a control plane uses to configure a data plane at runtime. It grew out of Envoy and now lives partly in its own CNCF home at cncf/xds so that other proxies and meshes can speak it too. Where a traditional proxy reads a config file and restarts, an xDS client opens a stream and receives its listeners, routes, clusters and endpoints as Protobuf messages that can change under it while traffic flows.

• LDS, RDS, CDS, EDS - Separate discovery services for listeners, routes, clusters and endpoints, so each concern can be pushed independently.
• Protobuf all the way down - Every resource is a versioned Protobuf message, which makes the whole configuration surface machine-readable by definition.
• Incremental and state-of-the-world variants - Both delta and full-snapshot delivery, because a fleet of ten proxies and a fleet of ten thousand have different needs.
• Multiple implementations - Envoy, gRPC’s own load-balancing client, and several service meshes consume the same protocol.

xDS matters to API operations because it is where the runtime shape of an API estate is actually decided. A gateway or mesh configured through xDS has its routing, its upstream pools and its load-balancing policy expressed as data rather than as a config file somebody edited — which is the same argument OpenAPI makes about the contract, applied one layer down at the traffic tier. It is worth reading alongside gRPC and Protocol Buffers, because xDS is one of the largest production Protobuf API surfaces most teams never look at directly.