[Feature] Design a restful style backend services to handle cluster operations
Search before asking
- [X] I had searched in the issues and found no similar feature requirement.
Description
A follow up issue of https://github.com/ray-project/kuberay/issues/53.
web service is one of the convenient way to interact with user. this doesn't require user to have any domain knowledge. At the same time, RESTful API doesn't need any dependency. Curl + json payload is every thing user need.
This backend service underneath should leverage generate clients to interact with RayCluster custom resources(depend on https://github.com/ray-project/kuberay/issues/29). So the chain of component call would be
client -> backend service (using client to create CR) -> apiserver
Use case
User who don't have kubectl knowledge or permission can use REST API to create/delete Ray Cluster on Kubernetes.
Related issues
https://github.com/ray-project/kuberay/issues/53 https://github.com/ray-project/kuberay/issues/29
Are you willing to submit a PR?
- [ ] Yes I am willing to submit a PR!
Grpc
The GRPC protocol provides an extremely efficient way of cross-service communication for distributed applications. The public toolkit includes instruments to generate client and server code-bases for many languages allowing the developer to use the most optimal language for the task.
Protocol Buffers are a language-neutral, platform-neutral extensible mechanism for serializing structured data. Protoc also provides different community plugins to meet different needs.
Since we may have different clients to interactive with our services, we will generate gateway RESTful APIs and OpenAPI Spec at the same time.
Backend service
The service will implement gPRC server as following graph shows.
- A
ResourceManagerwill be used to abstract the implementation of CRUD operators. - ClientManager manages kubernetes clients which can operate Kubernetes native resource and custom resources like RayCluster.
RayClusterClientcomes from code generator of CRD

Just two comments:
- maybe change the name "ClientManager" to "KubernetesClientManager" to make it more clear?
- Do we need to provide a "ClientAPI" to wrap those rpc calls to those backend servers?
- maybe change the name "ClientManager" to "KubernetesClientManager" to make it more clear?
We may need to involve DB later. ClientManager is to manage clients for all resources (kubernetes, db, external deps)
- Do we need to provide a "ClientAPI" to wrap those rpc calls to those backend servers?
Both openapi and grpc will be generated. It's not included in PR. Let's review the proto definition in https://github.com/ray-project/kuberay/issues/53 and then I will check them in.