BuddhiWathsala
commented
2 years ago Before the implementation of the xDS API, we need this https://github.com/ballerina-platform/ballerina-standard-library/issues/2766 CLI level support. Therefore, we are prioritising the CLI fixes before the xDS implementation.
niveathika
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
Non-Goals
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:
The second dimension is:
Based the aforementioned dimentions, the four variants are:
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].
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.
xdsprefix to the server URL. Then, gRPC will know that the client is going to use xDS API.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
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