Idea: Split the service for nats int two one for cluster traffic and one for client/external traffic

[svallebro]

When looking into this helm chart for nats I noticed that it defines the service to publish not-ready addresses.

It is needed to get the cluster of nats pods to talk to each other and establish the cluster.
But that also means that a client can be directed to a pod that is about to shut down as it is still published even when it is not ready.

I'd imagine more people than me are puzzled by this behavior.
I have not looked into what it would take to do this but it has popped up as an idea. Interested to hear what your ways to keep the minimal downtime when doing upgrades and restarts of pods.

[caleblloyd]

That is a good idea, however the Headless Service name is immutable so it is unlikely that we could change its name. So we would have to add a service under a different name.

Next, you get into the case that people use all kinds of different "things" to expose their services. ClusterIP, Load Balancers, Ingresses, Istio Virtual Services, Istio Ingress Gateways and more. You can add whatever customization that you need today, this is our recommendation currently for doing that:

https://artifacthub.io/packages/helm/nats/nats#using-nats-chart-as-a-dependency

I think that adding a 2nd Service could be a good idea, but I don't want to go down the slippery slope of templating out everyone's unique way of exposing their services in YAML with GoTpl, when it is already possible to add that on in many ways.

[svallebro]

Yeah, that seems reasonable, we got plans to do just that but haven't got around to it yet. Thanks for your input.

[caleblloyd]

This has been done in the nats 1.0.0 Helm Chart