Introduction to envoy’s Dynamic Resource Discovery (xDS) protocol.

In a service mesh architecture, the Envoy proxy serves as the data plane, handling the actual traffic between services, while the control plane manages the configuration and policies for the data plane. Communication between the Envoy data plane and the control plane typically occurs over the xDS protocol.

The Envoy data plane can communicate with multiple control planes, depending on the specific service mesh implementation. For example, Istio uses a central control plane for managing the mesh, while Linkerd uses a decentralized control plane where each service has its own control plane instance.

When a new service instance is deployed, the Envoy proxy in that instance registers with the control plane to receive its configuration. The control plane then sends the appropriate configuration updates to the Envoy proxy, such as which service instances to route traffic to and what policies to apply.

This communication between the data plane and control plane happens through a set of xDS APIs, such as the ADS (Aggregated Discovery Service), CDS (Cluster Discovery Service), LDS (Listener Discovery Service), and RDS (Route Discovery Service) APIs. The Envoy proxy uses these APIs to receive updates about the current state of the service mesh, and to communicate back to the control plane about its own state, such as metrics or health checks.

https://www.tigera.io/app/uploads/2021/07/service-mesh-architecture.png

There are several benefits of using the xDS protocol for communication between the control plane and data plane in a service mesh architecture:

1. Dynamic configuration: The xDS protocol allows for dynamic configuration of the data plane, which means that the control plane can push configuration updates to the data plane in real-time. This enables fast and efficient updates to service discovery, load balancing, routing, and other networking configurations.
2. Standardization: The xDS protocol provides a standardized way for the control plane and data plane to communicate, which enables interoperability between different service mesh components. This means that service mesh vendors can build products that work seamlessly with other service mesh components that implement the xDS protocol.
3. Scalability: The xDS protocol supports a push-based model for updates, which means that the control plane can send updates to multiple data plane instances simultaneously. This makes it easy to scale up and down the number of data plane instances as needed to handle changes in traffic patterns.
4. Flexibility: The xDS protocol is designed to be extensible, which means that service mesh vendors can add new functionality and features to the protocol as needed. This enables service mesh architectures to evolve over time and adapt to changing requirements.
5. Debugging and monitoring: The xDS protocol includes APIs for retrieving debugging and monitoring information from the data plane. This makes it easy to monitor the health and performance of the service mesh, and to debug issues that may arise.

The xDS protocol is based on gRPC, a high-performance, open-source framework for remote procedure calls. It defines a set of APIs that the control plane can use to send configuration updates to the data plane. The data plane, in turn, uses these APIs to retrieve its configuration and receive updates as needed.

The xDS protocol consists of several APIs, each of which serves a specific purpose:

1. The CDS (Cluster Discovery Service) API is used to discover the set of upstream clusters for a given Envoy proxy. Upstream clusters represent the destination services that traffic should be routed to.
2. The EDS (Endpoint Discovery Service) API is used to discover the set of endpoints within each upstream cluster. Endpoints represent the specific instances of a given service that traffic should be routed to.
3. The LDS (Listener Discovery Service) API is used to discover the set of listeners that should be configured on each Envoy proxy. Listeners represent the network interfaces that the Envoy proxy should listen on for incoming traffic.
4. The RDS (Route Discovery Service) API is used to discover the set of routes that should be configured on each Envoy proxy. Routes represent the rules that determine how traffic should be routed between upstream clusters and endpoints.

When the control plane sends an update to the data plane, it typically does so using the ADS (Aggregated Discovery Service) API. The ADS API is used to send updates that affect multiple APIs at once, making it easy to update the entire configuration of the data plane in a single operation.

Once the data plane receives an update, it applies the new configuration and begins routing traffic according to the new rules. If any errors or issues arise, the data plane can send telemetry data back to the control plane using the gRPC-based telemetry API.

https://blog.christianposta.com/images/control-plane/xds-control-plane.png

Even though the xDS APIs are defined as above, the protocol is extensible to add any other APIs to send their own data structure. This extension can be used when developing cloud native applications with the separation of Control Plane and Data Plane to replicate configuration data of the application.