You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 19, 2024. It is now read-only.
the discovery-lb.yaml file is badly named. It should be 'service' not 'lb' and probably 'internal' rather than 'discovery'. I suspect that I am partly to blame for this - if so, sorry.
it is specifically for cluster-internal services (raft, discovery etc.) so why would you want to expose it to the outside work by using a load balancer ? This could be quite bad from a security perspective because by default cluster-internal protocols are not authenticated.
raft can be a bottleneck for cluster performance so adding an extra network hop to a load balancer is not at all desirable.
I think the only option for the service defined in discovery-lb.yaml should be a headless ClusterIP type by default. Unless there is a use case that I am not thinking of.
n.b. The only possible reason that I can think of for trying this is if you are spreading a single Neo4j cluster over multiple K8s clusters and I do not believe that is in the scope of the helm chart - nor do I think it is necessary for that use case.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I think the only option for the service defined in
discovery-lb.yaml
should be a headless ClusterIP type by default. Unless there is a use case that I am not thinking of.n.b. The only possible reason that I can think of for trying this is if you are spreading a single Neo4j cluster over multiple K8s clusters and I do not believe that is in the scope of the helm chart - nor do I think it is necessary for that use case.
The text was updated successfully, but these errors were encountered: