Proposal: xDS API Support for gRPC

[BuddhiWathsala]

Summary

Modern software applications use a distributed deployment architecture to gain advantages like low latency and higher throughput. Service mesh is an infrastructure layer that we can add to the distributed application to achieve capabilities such as observability, traffic management, and security. Typically, in a service mesh, gRPC services use sidecar proxies (like Envoy) to communicate. However, the Envoy xDS API allows gRPC to deploy in a service mesh without a sidecar proxy. In this proposal, we intend to provide the xDS API support for the Ballerina gRPC module. Further, we will provide this feature in a generalized manner that other Ballerina standard libraries can easily plug the xDS capabilities.

Goals

To support features listed here [3], for example

• xDS Infrastructure in gRPC client channel
• Load balancing
• Circuit breaking
• Fault injection etc.

Non-Goals

• Test the usage of xDS with standard libraries other than gRPC.

Motivation

The distributed deployment architecture is essential for modern cloud applications to provide low latency and higher throughput. Now, the Ballerina gRPC library has evolved to a stage where we can develop complicated production-level applications by almost completing the primary features listed here [4]. Therefore, the next step of the Ballerina gRPC package is to provide the xDS feature and allow the library to reach state-of-the-art industrial standards.

Description

There are four variants of the xDS protocol that are categorized based on two dimensions [1]. The first dimension is:

1. State of the World (SotW) - client specify all the resources it is interested in with each request, and the server returns all the resources the client has subscribed to
2. Incremental - Both client and server communicate with deltas instead of sending all the resources back and forth

The second dimension is:

1. Basic xDS - using a separate gRPC stream for each resource type
2. Aggregated Discovery Service (ADS) - aggregating all the resource types into a single gRPC stream

Based the aforementioned dimentions, the four variants are:

1. SotW + Basic xDS
2. Incremental + Basic xDS
3. SotW + ADS
4. Incremental + ADS

gRPC does not have a plan to support Basic xDS capabilities, and it only has ADS. The initial gRPC xDS proposal supports SotW, and the incremental xDS will be available in future releases [2].

In xDS, there are four main types of APIs that the client uses [2].

1. Listener Discovery Service (LDS)
2. Route Discovery Service (RDS)
3. Cluster Discovery Service (CDS)
4. Endpoint Discovery Service (EDS)

These four main types are the ones that should add to the new Ballerina xDS library that will act as an xDS client. Ballerina gRPC library can import the xDS library to connect to a control plane.

xDS client needs relevant configurations to connect to an xDS server. These configurations will pass to a client via a bootstrap file. According to the gRPC specification, the location of the bootstrap file is determined via the environment variable GRPC_XDS_BOOTSTRAP. In the Ballerina context, we can use a configurable variable to get the bootstrap file location. Then, the users can set the file location using command-line argument, configuration file, or even as an environment variable.

Users only have to do two tasks to enable xDS in Ballerina gRPC. The users only have to do these tasks at the client-side since gRPC servers will not affect the xDS feature.

1. Add the xds prefix to the server URL. Then, gRPC will know that the client is going to use xDS API.
2. Provide the bootstrap configuration to connect to an xDS server.

Implementation

From the implementation perspective, what Go and Java have done is implement a different server for the xDS use case [5, 6]. For non-xDS cases, they have a default server implementation and for xDS, they have another implementation.

In the Ballerina context, we could think of adding a new listener implementation. But still, the implementation of that listener needs to use the Ballerina gRPC library for its internal calls.

Testing

• Locally test using a control plane
  • Go control plane
  • Java control plane
• Testing in Google cloud
  • Using Trafic Ditector without K8s
  • Using Trafic Ditector with K8s
• Using Istio

References

[1] https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol
[2] https://github.com/grpc/proposal/blob/master/A27-xds-global-load-balancing.md
[3] https://github.com/grpc/grpc/blob/master/doc/grpc_xds_features.md
[4] https://developers.google.com/protocol-buffers/docs/proto3
[5] Server - Go xDS Implementation
[6] Server - Java xDS Implementation

[BuddhiWathsala]

Before the implementation of the xDS API, we need this #2766 CLI level support. Therefore, we are prioritising the CLI fixes before the xDS implementation.

[niveathika]

This will not be added to the Swan Lake Update 1.