-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Scaling support #381
Comments
@maxkondr , We use grpc-gateway in Kubernetes. We run grpc-gateway and the grpc server in the same process. Then you can easily scale it my scaling the combined process. |
@tamalsaha could you please provide some example. Sorry for such question, I am just starting my may to Kubernetes and gRPC world :) |
If you check the readme file, the CoreOS example is a good one for this. https://github.com/grpc-ecosystem/grpc-gateway#more-examples |
@maxkondr , we plan to use the gateway as a separate process next to the actual server (Java) running in a single container. Both the gateway and server will expose their ports, the gateway will use a local connection to the server. No experience yet, but this is how I want to start. |
@emicklei, I am working on the same scheme for the time being.... |
@tamalsaha, thanks for the hint. I have managed to develop solution for my case. |
Ok, the answer on my initial Q is simple: just use Kubernetes services (with type ClusterIP) for back-ends that I want to reach from gateway directly. |
Looks like this resolved itself. Thanks @maxkondr |
Hello,
I have recently discovered your project (good job btw) and now I am working on solution with integration grpc-gateway into Kubernetes infrastructure. And here the following question appears: does it support scaling of back-end side?
As I see from generated code based on .proto the TCP connection to service is established on startup. That means that once the gateway is connected to service it doesn't detect any changes on back-end side (except service down because in such a case the connection is terminated).
Is there smth that I missed?
One more: as I see it doesn't support any redistribution of incoming requests among connected services (in case I have 1 GW and N services of the same type and with different entry points).
I have patched runtime/mux.go but it would be nice to have such option out of box.
The text was updated successfully, but these errors were encountered: