I've installed neo4j after playing with it in Sandbox onto my Kubernetes cluster using the official stable/neo4j helm chart.
I would like to make this neo4j cluster accessible remotely (not just within the Kubernetes cluster) so I've written a service to expose the bolt port. The cluster has one LEADER & two FOLLOWER role servers, which is great for redundancy. However, when I try and access my service, it's a gamble as to whether I'll be served a LEADER or a FOLLOWER.
If I'm connected to a follower and I attempt a write, I get -
Neo.ClientError.Cluster.NotALeader: No write operations are allowed directly on this database. Writes must pass through the leader. The role of this server is: FOLLOWER
Here is my service -
- port: 7687
Am I missing something, is there something specific I need to do? I've also raised an issue on the Helm package.
EDIT -- I'm editing this comment in May 2020. A specific example is available on how to do this, you can read all about it here.
My older response below:
This topic is covered in this article, under the subheading, "Looking at Neo4j from Outside of Kubernetes"
Additionally, "Querying Neo4j Clusters" will describe how all of this works, and why you're running into trouble. I recommend reading both -- they cover what's going on in your scenario, why it doesn't work, and also suggest possible approaches.
Thank you! I'll have a read!
Suggestions are great, but they're not practical solutions without examples. These are problems generally only of interest to people "who need to make it work right now". They don't have the time to try to figure it out for themselves and spend a few days or weeks to change configurations. Actually answering the question of "how to make it go" in a typical 3 node cluster running on kubernetes would be good. (I've got < 12 hours to solve this problem before it has to be live, and there's a powerful need to sleep that has to share that 12 hours). The only allowable access is via either an Ingress route or via a Load Balancer, the application that needs to connect can only get there via a LoadBalancer since it needs to route traffic over the Internet and the the cluster nodes do not have public IPs on them which makes the NodePort approach unsuitable (even if only vaguely described without any practical information).
Another alternative would be to develop and make available a bolt connection proxy that just deals with the internal/external DNS naming problems.