Switch to headless service in HelmChart

[MarcoJanecki]

Hey folks,

during our deployment of Cerbos within an own HelmChart, we noticed some discrepancy i what we found best and what you used in your HelmChart.

You are using a service with a ClusterIP to expose your Cerbos Pods (which might be many) to the cluster.
We found articles (like this ) that substantiated that it would be a good idea to use at least a headless service for gRPC connections.

Did you have a reason to not use a headless service? I would be keen to hear the "pro" arguments for that (since I am at that exact point of decision right now)! 😃

Or might that even be room for improvement for your HelmChart? 😇

Have a good one!
Marco

[charithe]

Hi. Good question! If your gRPC client supports client-side load balancing (most do), a headless service is indeed the better choice. Because gRPC works over long-lived HTTP/2 sessions and could overwhelm a single server if that connection is heavily utilised, some proxies have special support for load balancing gRPC services -- which is what you get with a service mesh. So, if you have a service mesh in place, it would certainly help to make use of the gRPC service discovery and load balancing features provided by it.

Because Cerbos has a REST API as well and some users prefer to use that, in the Helm chart we've catered to the lowest common denominator and made the default service type a ClusterIP one. This is because it provides load balancing, which a headless service doesn't do.

The defaults provided by the Helm chart are probably not the best for your particular environment and deployment method. So we definitely encourage doing some testing and tweaking the chart defaults.

I just realised that we don't expose the clusterIP of the service in the Helm chart. We'll fix that ASAP. In the mean time, you can use Kustomize to patch that field: https://docs.cerbos.dev/cerbos/latest/installation/helm.html#_customizing_the_manifests

[MarcoJanecki]

Oh yes, that is very true. And you are right to cater to the lowest common denominator!

Since I did not yet come across a gRPC client which does not do load balancing, I didn't have it in mind.

As long as using your provided Java SDK for the client side, a headless server will bring benefits (since it brings load-balancing IIRC), correct? :)

[charithe]

Yes, the Java SDK has support for client-side load balancing. It'd be beneficial to use a headless service with it.

[MarcoJanecki]

Thank you so much. That helped a lot getting things straight in my head. 😃