Improve usability of gRPC probes in Kubernetes #33437
Conversation
| ---- | ||
|
|
||
| By default, the Quarkus Kubernetes will expose the HTTP port with name `http` which is bound to the Quarkus HTTP server, not the gRPC service. To expose the gRPC server instead, set the `quarkus.kubernetes.ingress.target-port=grpc` property in your application.properties: | ||
|
|
There was a problem hiding this comment.
How does that work with the new server where both http and gRPC are served on the same port?
There was a problem hiding this comment.
Can you share more details about this? But I guess that if both HTTP and gRPC are handing by the same port, it will work fine using the default http port name.
Though, if the port name grpc won't be generated any longer, we might need to revisit this statement.
There was a problem hiding this comment.
With the old gRPC server, http and gRPC are served on different ports.
With the new gRPC server, HTTP and gRPC are served on the same port (which is very likely going to be https).
Both mode are supported at the moment.
There was a problem hiding this comment.
@alesj do you think we could add tests for both cases?
There was a problem hiding this comment.
I took a deeper look into this that was implemented as part of #28654.
So, by default, it creates two servers: one for HTTP and another one for gRPC.
If quarkus.grpc.server.use-separate-server is false, then the gRPC port won't be listening.
Note that the grpc port is still bound to the generated Deployment/Service resources even though quarkus.grpc.server.use-separate-server is false. Because quarkus.grpc.server.use-separate-server is a runtime property, this might make sense. So, ultimately the user would need to select the target port (either http or grpc) of the generated resource.
We could again follow a best-effort approach, so if users use quarkus.grpc.server.use-separate-server=false at build time, we could remove the binding of the grpc port in the generated resources and use http by default as the target port. Wdyt @cescoffier ?
There was a problem hiding this comment.
+1 or having an explicit property on the kubernetes side.
There was a problem hiding this comment.
We already have an explicit property on K8s side which is quarkus.kubernetes.ingress.target-port.
I'd prefer doing We could again follow a best-effort approach, so if users use quarkus.grpc.server.use-separate-server=false at build time, we could remove the binding of the grpc port in the generated resources and use http by default as the target port. as part of another pull request after merging this pull request.
So, if you're ok with the rest of the changes, can we proceed with merging this pull request?
|
🙈 The PR is closed and the preview is expired. |
This comment has been minimized.
This comment has been minimized.
...ubernetes/vanilla/deployment/src/main/java/io/quarkus/kubernetes/deployment/ProbeConfig.java
Show resolved
Hide resolved
Plus, I'm adding a new guide about the usage of gRPC services in Kubernetes. Relates to quarkusio#33219 (comment)
Sgitario
force-pushed
the
improve_grpc_probes
branch
from
e47a6a3 to
81b09a8
Compare
|
@cescoffier PR updated with your two change requests. |
|
✔️ The latest workflow run for the pull request has completed successfully. It should be safe to merge provided you have a look at the other checks in the summary. |
These changes will read the runtime property `quarkus.grpc.server.use-separate-server` and if false, it won't expose the gRPC port in the generated K8s deployment resources. Relates quarkusio#33437 (comment)
These changes will read the runtime property `quarkus.grpc.server.use-separate-server` and if false, it won't expose the gRPC port in the generated K8s deployment resources. Relates quarkusio#33437 (comment)
These changes will read the runtime property `quarkus.grpc.server.use-separate-server` and if false, it won't expose the gRPC port in the generated K8s deployment resources. Relates quarkusio#33437 (comment) (cherry picked from commit 4ccaea0)
These changes will read the runtime property `quarkus.grpc.server.use-separate-server` and if false, it won't expose the gRPC port in the generated K8s deployment resources. Relates quarkusio#33437 (comment)
Plus, I'm adding a new guide about the usage of gRPC services in Kubernetes.
Relates to #33219 (comment)