Charts: [stable/postgresql] Make svc-headless optional

[giorgiosironi]

Is this a request for help?:

No, it's a proposal for a simplification for certain use cases

---

Is this a BUG REPORT or FEATURE REQUEST? (choose one):

Feature request, although I could work on this myself

Which chart:

stable/postgresql

What happened:

Two services pointing to the pods are created:

elife-xpub--test-postgresql            ClusterIP   172.20.183.51    <none>        5432/TCP         22h
elife-xpub--test-postgresql-headless   ClusterIP   None             <none>        5432/TCP         22h

These two services seem equivalent, if not for the fact that the headless one specifies not to proxy (clusterIp: None) and doesn't select on role: master like the other one.

What you expected to happen:

Since the default configuration consists of only 1 replica, it seems there is not much difference between the two services, so I would expect to be able to turn one of them off to simplify the architecture. I can see the simple use cases only relying on one of the two.

By default, I would add a boolean option that defaults to true but can be specified to be false to remove the headless service. Not sure which one should be the one that can be turned off.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.

[stale[bot]]

This issue is being automatically closed due to inactivity.

[juan131]

Hi @giorgiosironi

Why do you want to avoid using this service? I don't see any advantage on making them optional.

The "headless" services are used on statefulsets to guarantee that each pod has a "stable network ID" so pods can discover one each other.

Here you can find a nice blog talking about this feature:
https://www.quora.com/What-is-the-use-of-a-headless-service-in-Kubernetes

[giorgiosironi]

In my use case (no replicas) there is only 1 pod, hence the two services coincide; the headless one become one additional service that has to be documented and whose presence has to be explained to the people accessing the cluster. Hence why I was marking this just as a possible simplification.

[juan131]

Hi @giorgiosironi

What happens if a user scales the deployment/statefulset (using kubectl) after doing the chart release? I know it will simplify the solution deployed in the cluster for the scenario where there's only one pod but it avoids possible issues when scaling.

[User1m]

@juan131 thanks for the quora link explaining the need for headless service. I was under the incorrect impression it was used to loadbalance R/Ws across the master/slaves. So it possible to use 1 service definition that comes with the helm chart to loadbalance read/writes across slaves/master nodes?

Thanks!

[juan131]

So it possible to use 1 service definition that comes with the helm chart to loadbalance read/writes across slaves/master nodes?

By default the service created on this chart (see the manifest below) only acts as a loadbalancer for requests on "primary" nodes:

https://github.com/helm/charts/blob/master/stable/mongodb/templates/svc-primary-rs.yaml

You could create another service with all the nodes (primary and secondary nodes) as endpoints and it'll balance the requests using round-robin.

You could also create a specific service to access the secondary nodes and you can use a more complex algorithm on your app so it decides whether to target the primary or secondary nodes.

[User1m]

Hi @juan131 the guide found here states, under the Data Replication And Persistence section, that:

The master node receives all write operations, while the slave nodes repeat the operations performed by the master node on their own copies of the data set and are used for read operation. This model improves the overall performance of the solution. It also simplifies disaster recovery, because a copy of the data is maintained on each node in the cluster.

Which seems to imply that read-writes are auto managed and routed the appropriate service?

But your comment seems to imply that's not the case?

By default the service created on this chart (see the manifest below) only acts as a loadbalancer for requests on "primary" nodes

[juan131]

Sorry @User1m ! If you see my last comment you'll see that I thought you were talking about MongoDB!!

You're right, in the case of PostgreSQL there are two services: one that allows to access the slaves (read only) and one to access the master nodes. You can find the services manifests in the links below:

https://github.com/helm/charts/blob/master/stable/postgresql/templates/svc.yaml
https://github.com/helm/charts/blob/master/stable/postgresql/templates/svc-read.yaml

[User1m]

thanks for the clarification @juan131 :)

Just to make sure I'm getting it correctly, handling routing of read-writes to the appropriate svc has to be handled on the app-side and isn't automatically handled by anything in this chart? right?

[juan131]

Just to make sure I'm getting it correctly, handling routing of read-writes to the appropriate svc has to be handled on the app-side and isn't automatically handled by anything in this chart? right?

Exactly! The master and slaves are accessible via different services and, therefore, you need to configure your app to access the corresponding service for each type of operations.

[sandyleo26]

What happens if a user scales the deployment/statefulset (using kubectl) after doing the chart release? ... but it avoids possible issues when scaling.

could someone elaborate this as i failed to understand it. what exactly would be the issue if i use the standard service instead of headless service in the stateful set and then scale it? I know the difference between a headless and standard service in terms of discovery (the quora article) but i couldn't see the how postgres could benefit from it.